RE: Messaging Service Layer

Roger:

 

(Roger and I exchanged some mails and here is a summary of what we felt
was important) 

 

In terms of layers, ebXML  deals with 3 layers, messaging, collaboration
and application. Then you need to consider the design time artifacts
that are need for all layers to operate. ebXML has 3 levels that play
together: a collaboration definition (common to anyone who use it -good
for industry level definitions), a profile (CPP) unique to every partner
who engages in this collaboration, an agreement common to any two
partners which engage in this collaboration. 

 

ebXML messaging layer relies on SOAP like web services

WS does not have a collaboration layer yet. ebXML can be used with or
without the collaboration layer.

ebXML is not designed to be interacted with a browser via XSLT.

 

I like better the split between profile and agreement. In my opinion,
WSDL packages the two in one concept. A profile describes the technical
capabilities on "my" side and "your" side while an agreement binds 2
profiles together. If you don't like "agreement" because it looks like a
business term, call it ws-binding. The problem of WSDL as I see it is
that how do you keep "outbound" definitions open such that they can be
populated as needed for 1,2, ..n partners. CPP/CPA does just that for
you. In particular you could each support several transport, but during
the agreement we decide on the one we want to use together).

 

Now clearly ebXML was designed to solve very specific problems
identified to be an issue when building very large b2b communities, e.g.
business transactions versus RPCs not to mention callbacks, how do we
reduce the cost of adding partners, . Ah I almost forgot, the I word,
interoperability. Clearly this represents a subset of the scope that
WSDL wants to address and this is fine. However when Assaf tells us all
about the flexibility of web services, he sells him short of building
interoperable infrastructure. For instance if you leave a collaboration
protocol out of the scope it means that people will re-invent one, for
themselves, e.g. by using operation faults. But after a few of these
"creative" usages of the infrastructure, you would have lost any hopes
of interoperability not to mention the implementation nightmare so
support a few of of them. I don't think that anyone cannot argue that
interoperability is goal #1 of any such infrastructure. 

 

I think that the layering Collaboration/Profile/Agreement is far more
efficient (b2b or not b2b, and in the context of run-time discovery)
than web service definition/web service choreography. I don't think that
ebXML is any more tightly bound than web services or adopting this
layering would make web services more tightly bound and less flexible.
Of course we can look inside these layers to decide if one is more
tightly bound than the others. 

 

Cheers,

 

JJ- 

 

 

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org] On
Behalf Of Cutler, Roger (RogerCutler)
Sent: Friday, February 14, 2003 3:00 PM
To: www-ws-arch@w3.org
Subject: Messaging Service Layer

 

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?