Re: Reliable HTTP

John Ibbotson wrote:

>A recent thread on this list commented on the need for reliable delivery of
>messages via HTTP. IBM has just released a first draft specification to
>support reliability over HTTP. Together with a primer, it is available from
>www.ibm.com/developerworks/webservices.
>We welcome any comments and feedback on this specification.
>John
>
My concern with HTTPR for use with SOAP is that we are not being 
consistent with SOAP-RP in where we are encoding messaging 
infrastructure features.  Specfically, SOAP-RP uses the SOAP 
extensibility model to place a messaging infrastructure feature (message 
routing) into the message header, whereas as HTTPR is creating a new 
wrapper layer around the HTTP payload to implement reliable messaging.

The Primer for HTTPR states: "However, doing this involves the 
application in low-level processes, such as message resend, complicating 
and confusing the definition of higher-level business processes."

I don't think this is quite true; a SOAP-RP-based messaging 
infrastructure will not necessarily need to involve the application in 
the SOAP-RP-compliant headers.

The way I see it, SOAP-RP is creating another layer in the stack by 
putting infrastructure elements in the SOAP header, whereas HTTPR is 
creating another layer in the stack by wrapping payloads.  But they're 
both creating another layer in the stack, but in slightly different 
places. Maybe a good question to ask is why SOAP-RP does it the way it 
does.  One advantage is that when the message routing information is 
placed in the header, the message is self-contained and can travel from 
hop-to-hop over different transports (say a path looks like 
HTTP-SMTP-HTTP) and still carry things like reverse message paths. 
Another advantage is that we can still use existing transports without 
modifying them in any way.

Maybe the biggest issue is how to handle reliability when there are 
multiple hops in the message (using the SOAP-RP model), potentially 
using multiple protocols.  In this case, it seems that using the SOAP-RP 
reverse paths is pretty important to communicate back transport failures 
to the sender (how hop-by-hop reliability should be addressed as 
important...). It makes sense to me to include the necessary reliability 
information the same way that SOAP-RP includes the routing information.

However, I'm still open to the possibility that perhaps reliability is 
fundamentally different from routing and perhaps it should be captured 
at a different level in the stack.  The other reasons given in the 
Primer for HTTPR for putting the reliability information below the 
application-layer are:

  - "this would make it very difficult to do things like the message 
batching optimizations discussed above."

May be a good reason.  I was wondering if using DIME combined with a 
"batch-id" is a SOAP header would work, but maybe that's an abuse of 
DIME (SOAP-in-DIME is pretty much meant as a better attachment 
mechanism, not a boxcarring/batching mechanism to my knowlege).

  - "there are important existing transports that already support 
reliable messaging and encode the necessary formats and protocols at the 
transport level."

We still need to consider end-to-end reliability in the multi-hop 
situation.  Also, if we're just talking plain point-to-point messaging, 
a reliability model using the SOAP extensibility model would be 
optional, so I'm not sure this makes a case of not putting the 
reliability in the SOAP header.

john

Received on Wednesday, 18 July 2001 13:21:48 UTC