[
Lists Home |
Date Index |
Thread Index
]
> From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
<snip/>
> One easy way to solve this problem is by decoupling the
> request from the
> response. Send a request (with an indication of how to
> respond....a URL, Web
> Services Callback, and email address etc.) and receive a "transaction
> received" HTTP response (which should be almost immediate).
> Some time
> later the service uses the response indicator info to send a
> "real" response to
> the transaction. Damn....that sure sounds like message
> queuing doesn't it?
That's the right way when you can get away with it. But some interactions
can't afford an open-ended contract for when the response finds its way back
to the originator of the request.
> Someone
> said that it is best not to hide network plumbing issues from
> developers (due to
> latency, unreliability, etc.)....so I think the implication
> is a poor one.
I'd formulate this differently. APIs *should* hide the network plumbing
issues from developers. That's a good thing. They just shouldn't obscure the
fact that you are interacting with a remote resource. The point is to
promote application models that intelligently take into account issues such
as network latency, security, etc., not to create extraneous gruntwork for
the developer. The EJB model is a good one, IMO. You know when you are
interacting with a remote object; that is quite explicit. But when you do
interact with one, it is with simple method calls that hide network plumbing
and protocol details.
|
