Re: Gateways

Hi Mark,

Mark Baker wrote:
> Sorry about the hastiness. 8-)

No problem. :-)

> Right.  By my definition, a gateway has to terminate messages.

Ok.

>>The SOAP message is interpreted at the application layer before 
>>being forwarded. I feel this is different for your typical 
>>gateway: the gateway would not, in general, have to understand 
>>the contents of the message --- just as a layer 2 router would 
>>not have to understand the contents of the packet being forwarded.
> 
> Uh oh, it's that layering issue again.  8-O
> 
> If the underlying protocol is an application protocol, like HTTP, then
> SOAP and HTTP are at the same layer.  So for SOAP bound to HTTP, a SOAP
> node may be an HTTP gateway.  Hmm, not sure if that helped clarify
> things or not.

Ok.

> In your other message you wrote;
> 
>>Is "interface" the widely accepted term here? I can't help but 
>>think you're talking about network interfaces; hence I don't get 
>>the notion we are converting from one protocol to another.
> 
> Well, an application protocol defines an interface, so I think it's
> appropriate.

I'll take your word for it.

>>Re. "gateways that are SOAP nodes are not SOAP intermediaries", I 
>>am reading Henrik's answer[1] somewhat differently.
>>
>>He says: "gateways are not SOAP intermediaries", meaning SOAP 
>>intermediaries do processing at a higher level: they understand 
>>and possibly process the message; gateways typically do not.
> 
> I'm quite sure that's not what he meant.  He means that gateways,
> like HTTP gateways, are not SOAP intermediaries because they
> terminate messages (which includes terminating SOAP messages,
> because they're at the same layer).

I've just re-read your definition, and I think I'm starting to 
understand your point-of-view. I'm seeing things slightly 
differently (but I don't claim a lot of expertise in HTTP gateways).

With that proviso, how would you best describe Host II in figure 
2.2 [1] ? Could this be an HTTP gateway?

>>But he then adds: "One could imagine SOAP intermediaries being 
>>underlying protocol gateways", meaning a SOAP intermediary might 
>>not process the message at all but simply switch protocols.
>>
>>I think this fits perfectly with the figure at [2] and my earlier 
>>note [3].
> 
> Mostly agreed, but his use of the term "gateway" there is different than
> mine.  I agree that both definitions of the term are in common use, but
> I believe the definition I use to be more common, especially in the
> context of HTTP which has a well-defined meaning for it, consistent with
> mine;
> 
> http://www.zvon.org/tmRFC/RFC2616/Output/chapter1.html#sub3

Interesting he wouldn't agree with his own production. ;-)

> I think we need to pick one definition and run with it.  What I proposed
> isn't perfect, but I think it's good enough to go with for now.

I think yours doesn't carry as clearly the notion that a gateway 
terminates a message. The following sentence was certainly 
enlightening to me: "Unlike a proxy, a[n HTTP] gateway receives 
requests as if it were the origin server for the requested resource".

> (P.S. while I'm talking to you, ws-desc issue #65 isn't mine 8-)

You're quite correct; yet another effect of the cut-and-paste 
syndrome. Corrected (thanks to Google).

Jean-Jacques.

[1] http://www.w3.org/2000/xp/Group/1/08/14-am/xmlp-am.html#Fig2.2