- From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
- Date: Fri, 14 Feb 2003 14:00:06 -0600
- To: www-ws-arch@w3.org
- Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01624A37@bocnte2k3.boc.chevrontexaco.net>
Mike suggested that I might usefully try to write down some thoughts about the messaging layer and how it relates to issues like security and business processes. OK, I'm going to try to wing this, based on my perceptions of a bunch of things I have heard. I'm not sure how useful or to the point this is going to be -- or correct, of course -- but let me take a crack at it. First a notational matter: Unless explicitly called out, I'm going to use the phrase "Web service" to refer to something that conforms to the WSA, and in particular uses SOAP and WSDL. EbXML is an interesting example of a messaging service that is not such a Web service (although it uses an old version of SOAP it does not use WSDL), although it is clearly a Web service in the more general sense. What is a "layer"? Apologizing to those of you who really know how to define these things, I think that a layer is a grouping of functions that is hierarchical, in the sense that there are a layers above and below a given layer. A layer interacts only with the layers directly above and below it. The application layer is above the messaging layer, the transport layer below. Examples of inhabitants of the application layer include ERP systems (like SAP), office applications (like Excel or InfoPath) and Web applications (like an ASP or JSP). Examples of messaging layer implementations include Web services and ebXML. Examples of transport layer implementations include HTTP and SMTP./ Note that if you have a God-like view of the IT world you may be aware that there are actually a large number of layers, and the Messaging layer is just the Nth. In that view, the Nth layer only interacts and is aware of the (N-1)th and (N+1)th layer. If, however, you are an imaginary inhabitant of the Nth layer, unless you are of a particularly religious or philosophical bent and desire to speculate about the nature of the universe, all you really need to know about are the layers above and below. Specifically, the messaging layer interacts with the transport layer but need not be aware that there are lower level functions that might be, for example, in a network layer. The messaging layer knows about HTTP, not TCP/IP. The messaging layer might get information from the HTTP headers, or even get the whole header, but it is not concerned with the TCP/IP headers. A layer may have, from its own point of view, some internal structure or even sublayering. This is not relevant to a neighboring layer's interactions with it except in terms of how the interface is organized. For example, one might imagine defining a management layer that sits between the messaging layer and the application layer -- but I think that this is not really what people want to do. If you did so the applications would only be able to interact with the messaging layer through the management layer, and the management layer would not be able to interact directly with the transport layer. This does not seem right, so I think that the management function is a substructure of the messaging layer which might have a higher/lower relationship with some other parts of the messaging layer when viewed internally, but when viewed from another layer appears simply as a grouping of the interface functions. Sorry if this is too dumby -- I just want to be very clear what I am talking about, particularly if anything I am saying is incorrect. OK, now I think that all generalized Web services are entirely contained in the messaging layer. Right? Let me take a different, more functional cut at what the messaging layer is in terms of Web services. The messaging layer is in charge of what is in the SOAP headers, whereas the application layer is responsible for the body. More specifically, the messaging layer might mess around with the body by doing things like encrypting it, but after decryption the messaging layer would hand the body to the application layer of the receiver exactly as the body was given to it by the sender. The messaging layer has no business changing the data in the body -- as far as it is concerned the body is just bits or characters. And I think that it also has no business trying to analyze the contents of the data in the body. If you agree with the preceding statements I think it may have consequences down the line that are non-trivial. The last statement may be a bit strong, but that's the way it seems to me other layers work. We have now encountered the concepts of sender and receiver. There may also be intermediaries, and I think that how to handle intermediaries is in the scope of the messaging layer, but I am not very knowledgeable about this so I'm not going to pursue it for the moment. Let's take an even more specific view of what the messaging layer is: It is the set of functions that is performed by messaging service software. This software may service more than one application and often runs on a different server than the application. So now we have a view, for which there is an obvious diagram, of how these layers work: You have a sender application on the top left that gives a message body at time T1 to the sender message service (below the sender app but still on the left). The sender message service now attempts at time T2 to send the message to the receiver by giving it to the transport layer. (If an acknowledgement protocol is in play there may be a number of attempts, each with a different T2). The transport layer "somehow" (as far as the messaging layer is concerned this could be magic) delivers the message to the receiver messaging service (on the right) at time T3. The transport layer is below both messaging layers and bridges left and right. The receiver messaging service gives the message to the receiver application at time T4. Parenthetically, I think that the times T1 and T3 are of particular interest in business applications (although it might be T4). One might imagine spaces in the messaging header for both timestamps, although I don't know whether either SOAP or ebXML explicitly do so. This consideration, however, illustrates that the receving message service (and I'm sure intermediary message services) may write things into the message header. The applications or transport services, however, cannot. And the messaging layer has no business writing things into the body. That is, if a timestamp is going to be in the body I think that the application has to copy it there from the message header, not the messaging service. This is probably best not done, but I guess there's no law against it. OK, now it might be interesting to make a list of some of the functions that are included in the messaging layer and others that are not -- and perhaps some I'm not sure of. There are some overarching functions, like security and reliability, in which many layers potentially participate. The mode of participation, however, may be somewhat specific to that layer. For security, I think that the messaging layer is particularly responsible for message integrity (via digital signature checksums), encryption and decryption of the message body as a whole (the application layer may also encrypt portions of the body), and authentication operations (via digital signatures or userid/password). I think that some other functions like authorization are more centered in the application layer and the message layer simply passes the information through. (If I'm wrong about these things it the corrections should be interesting). On the reliability front, the primary role of the messaging layer is probably implementation of an acknowledgement infrastructure, as illustrated by the WS-Reliability spec and ebXML reliable messaging. Timedate stamps of the various types mentioned above obviously belong in the headers written by the messaging layer. It seems to me that this might even include T4. The message header, which is the responsibility of the message service layer, may contain metadata describing the contents of the body and pointers to documents that may be used in conjunction with the body (schemas, WSDL files, etc). What about various forms of validation? Obviously the messaging layer is responsible for validating the form and meaning of the message header, and I think may validate that the message body has arrived intact by comparing some sort of checksum. Can it validate the message body itself? One could imagine various levels of such validation: that the XML of the message body is well formed, that it is valid with respect to some schema pointed to by (or contained in, I suppose) the message header, that the message body is consistent with the WSDL defining the interface accessed, or that the message satisfies various business constraints. I think that the understanding of the role of layering described above says that the messaging layer should not do any of these things, but maybe this is unreasonable. Perhaps the messaging service should not be required to do any such thing but might do so as a value-added service? I'm not clear on this at all. It seems to me that there are all sorts of murky issues that arise when you consider conversations and context. Certainly the message header may contain metadata describing this context. The application layer may also do so. Where do various types of state information belong? I don't know if this will work, but it seems to me that information related to the identity of the message or the timing of its transmission, as well as the identity of the conversation and the place in the conversation that the message holds might all usefully be handled by the messaging layer. This means, I think, that the messaging layer might be aware of business rules involving, for example, how soon a response to a message must occur in order to be valid. I suspect, but do not know for sure, that this kind of thing might indeed be in the ebXML messaging layer but I doubt that it is currently in Web services. I should probably stop here. I've probably included enough misinterpretations so that there is plenty of grist for the mill. Perhaps I should end by articulating a few questions that might be interesting to explore in the context defined here (and presumably fixed by those who know better): 1 - What does ebXML use instead of WSDL and how does it work? I have been told, but only partially understand, that the mechanism makes a clean distinction between concepts that are munged together in WSDL and that this is useful. 2 - How close is ebXML to being conformant to WSA architecture as we currently understand it. WSDL is obviously one issue -- are there others? This might be of interest to both ebXML and WSA architects, the latter because it might be interesting to know whether modifications to WSA could make it easier for ebXML to be conformant. Also it would be interesting to know if ebXML feels that some architectural constraints are hostile to implementing business processes. 3 - Do ebXML and Web services have differences in how functions are apportioned to the application and messaging layer, particularly in the areas of business process validation?
Received on Friday, 14 February 2003 15:00:20 UTC