Re: Reliable HTTP

Well said. HTTPR seems to regard SOAP messaging as 'just another
application', when in fact it's an application protocol framework.
Are there any uses cases for HTTPR that don't (or shouldn't) involve
SOAP?


On Wed, Jul 18, 2001 at 10:21:47AM -0700, john d. beatty wrote:
> 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
> 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA USA)

Received on Wednesday, 18 July 2001 16:40:04 UTC