[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: MS thinks HTTP Needs Replacing???
> From: Andrzej Jan Taramina [mailto:andrzej@c...] <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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|