>>> But what we need most, also inside the corporate firewalls, is >>> real queued (persistent) messaging over HTTP. > > What I mean is: if the sender is unable to transmit message(s) (over > HTTP), it will persist the message(s) locally and retry at regular > intervals to transmit the message. The receiver at its end will > keep state to filter duplicate messages. > ... > Nice examples of such persistent protocols are... RNIF (RosettaNet)
RN is an example of doing this with HTTP. RN uses two web servers, always on, to send messages back and forth. The current work in a "lighter weight" RN (where the "client" does not have an "always on" service) uses a SOAP client talking to an "always on" SOAP server. The client "polls" for responses. Nothing would prevent a comination of these two approaches, e.g. an intermittent pure HTTP client talking to an always on HTTP service. This would be not unlike a feed reader talking to a syndication server, and the messages could even be based on Atom. Local persistence and retry seems to be a local decision, but would also tie into the service level agreement. If it is going to be part of a standard of some kind, that is another thing still. Local persistence and rety does not seem to me to be part of a wire protocol specification, however. HTTP does not seem to preclude any of this, inside or outside the corporate firewall. -Patrick ------------------------ Yahoo! Groups Sponsor --------------------~--> Yahoo! Groups gets a make over. See the new email design. http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
