- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Tue, 10 Apr 2001 15:11:27 -0700
- To: "'Mark Nottingham'" <mnot@akamai.com>, "XML Distributed Applications List" <xml-dist-app@w3.org>
Mark, Sorry for the (huge) delay - here is the 2nd attempt - the thread is at [1] >> The interesting thing is that the RPC convention imposes similar >> types >> of constraints on the SOAP envelope - it talks about where to stick >> the method call parameters and what the headers can be used for in the >> case of RPC. In many ways, this is very close to a protocol binding >> but where the HTTP protocol binding binds to an actual protocol >> (HTTP), the RPC convention binds to an abstract "RPC protocol". >> >> This is actually not new in that we in the MIME multipart binding >> also >> binds to something that is not really a protocol (MIME). We also have >> the notion of "nested" protocol bindings in that MIME multipart can be >> used in combination with HTTP etc. Similarly the RPC "binding" can be >> used over HTTP in which case the request/response maps directly to the >> HTTP request/response. However, if we use the RPC "binding" over SMTP >> then we have to compensate in order to get a request/response model >> and we can do that by making a module that provides this >> functionality. > >Maybe it's just the terminology, but this is very confusing. I >think I know what you mean, but it might be good to use a term >other than binding, or more fully explain this. Ok, a more specific example is the SOAP MIME multipart related spec [2] and see how that relates to the SOAP spec [3]. The SOAP MIME multipart is effectively a protocol binding in its own right - it defines how a SOAP message can be embedded within a MIME multipart related message and how one can use URIs to refer to individual entity bodies within the multipart message. However, MIME multipart is in itself not really a protocol - it is a message description format and so it doesn't say where to send the message etc. However, the MIME multipart binding can be nested to fit within other protocols that support MIME entities. For example, one can nest the SOAP/MIME multipart binding and the HTTP binding to get a mechanism for exchanging the message. The point about the RPC convention is that it has a lot in common with a binding in that it imposes constraints on the SOAP message (what can go in the body and in the headers) and also defines a message exchange pattern: request/response. However, similar to the SOAP MIME multipart binding, the RPC convention doesn't actually provide a mechanism for exchanging messages. In order to solve this problem, the RPC convention can be nested with the HTTP binding or some other binding. In the case of HTTP, HTTP naturally supports request/response. However, it doesn't support RPC as such and therefore some of the conventions are expressed within the SOAP envelope. One could imagine nesting the RPC convention with other bindings like an SMTP binding that doesn't support request/response. In order to compensate, we could therefore define a module that took care of the correlation between requests and responses. As more an more modules get defined one can wonder whether SOAP eventually won't "grow up" and simply become a complete protocol in its own right with enough modules for handling the 80% case. One can even imagine nesting the RPC convention within MIME multipart within HTTP. >> I think we are getting close - I like the notion that the AM can >> support multiple causality models but doesn't define any. The >> interesting thing is that once you talk about causality, it could be >> that I have to send you 5 messages before you send me one - that is we >> have sender:receiver relationships that include >> >> 1:1 >> 1:m >> n:1 >> m:n > >I'd go a bit further. One of the things that BEEP does is >separate the concept of who establishes the connection from >who originates exchanges; initiator/listener vs. client/server. > >We've been talking about message exchange patterns and the >flow of messages, but not how they relate to the establishment >of the connection to a 'service URI', although there has been >hand-waving about the service URI itself. Should we pick this >apart into a separate layer (service layer)? Yes, I think that makes to do so. One reason for that is that we avoid getting into the situation of having to define how to export endpoints. Henrik [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Mar/0216.html [2] http://www.w3.org/TR/SOAP-attachments [3] http://www.w3.org/TR/SOAP/
Received on Tuesday, 10 April 2001 18:19:23 UTC