RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases e-Bus ines s Architecture Technical Specification for Public Review])

I agree with Duane's clarification of how the ebXML specification works in
that the ebXML Messaging layer >relies< on the existence of a pre-existing
agreement as defined in a CPA to specify how the ebXML MS layer should
behave.

The advantage of a CPA is that the recipient of a message can immediately
use the information in the previously agreed CPA to access that
configuration data to determine how to process and respond to a message. The
disadvantage of this is that it requires the agreement to be set up >in
advance< which makes spontaneous use more difficult as you can't send an
ebXML Message until the agreements are in place. It also raises the issue of
how do you negotiate the agreement in the first place and keep it up to date
over time.

There was a lot of debate as to whether ebXML Messaging should >require< a
CPA where I took the view that you can and should separate messaging layer
from "business process" layers and that it should be possible to use the
messaging layer without any pre-agreement being necessary (although they are
possible and sometimes desirable as I discuss later).

This means you should be able to do the following:
1. Discover information about a service (e.g. using WSDL) which should
include information about the additional SOAP features that the service
supports or requires (e.g. Reliable Messaging, use of signatures,
conversations and choreographies) - see more below.
2. Use that information to send a message to the service that includes as
features (i.e. SOAP headers), the necessary information for the destination
to determine what to do with the message
3. The destination, when it receives the message, checks the SOAP headers
and other data in the message against its policies as represented in the
WSDL (or elsewhere) and decide if the message is OK to process.
4. If the message is OK, then it could be processed and the response
generated if required.

There are also use cases where you might want to use features on their own,
e.g. Reliable Messaging, or encryption or signatures, without using anything
else.

For example you might want to be able to go to a service to get an
electronic coupon from a club you belong to so that you can then use it to
get a discount on a B2C purchase. This would be a valid use case for doing
secure reliable messaging. However I don't see this as B2B type of
interaction where two businesses need to set up an agreement in advance
including names, addresses etc. This might be a one-off interaction where
the requestor of the coupon wants to remain anonymous and going through the
ebXML agreement process would be overkill. 

Another example would be where you are using SOAP and Reliable Messaging to
synchronize data in your PC with data in your PDA over an 802.11b wireless
link which can drop at any time. A good way of doing this would be to use
SOAP and an RM protocol together as it removes the need for application to
worry about it. I don't see why creating an ebXML CPA would or should be
necessary.

On the other hand, there will be use cases where there are long-standing
business relationships with repeat business where negotiating and making
agreements in advance (as ebXML does) makes complete sense.

So my take would be:
1. The messaging layer should allow support for the set of additional
features required (e.g. security, reliability, conversations, etc)
2. Use of the features in a message either separately or together should be
identified by extensions in the SOAP headers so that the recipient of the
message can determine what the sender expects them to do with the message.
3. The specification, ngotiation, and enforcement of agreements as in ebXML
should be possible, but as a layer on top.

Hope this helps.

David

-----Original Message-----
From: Duane Nickull [mailto:duane@xmlglobal.com]
Sent: Wednesday, February 12, 2003 1:40 PM
To: www-ws-arch@w3.org
Cc: www-ws-arch@w3.org
Subject: Re: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
e-Busines s Architecture Technical Specification for Public Review])





Champion, Mike wrote:
=
> Roger raises a very important point, IMHO. Does anyone who is involved in
> ebXML(or any other company/ organization who has this view of the world)
> want to make a case for the WSA conception of a messaging layer  having to
> understand and enforce business-level rules? 
 >>>>>>
I will tackle this one.  The text is probably not clear enough in our 
(UN/CEFACT) spec and we will address this during our face to face in 
early March.

What the messaging layer must do it provide enforcement via a 
gatekeeping functionality (an explicit tie-in to the Business Agreement 
between the sender and the receiver).  Any ebXML that arrives asserts 
that it exists as "part" of a business relationship.  It does this by 
asserting a unique identifier to an XML representation of that Business 
Agreement called a CPA.  The messaging layer can access an API to verify 
if that CPA ID is valid.

Furthermore,  since any single business relationship may involve several 
concurrent threads of a business process (ie - procurement), the 
incoming message must specify a Conversation ID, an assertation that it 
is one message belonging to a specific choreography of messages (thread?).

WSDL + SOAP do not have this functionality explicitly required, however 
that would not stop someone from implementing it by requiring that tie 
in as one of the required parameters. Therefore, WSDL + SOAP can provide 
this.  It is conceivable that someone could implement a WSDL/SOAP WS 
that had a tie in to an ebXML CPA instance.

This is what was meant by the statement in the architecture document. 
We obviously may need to re-visit this sentence to see if we need to 
clarify it.   Please also keep in mind that the UN/CEFACT architecture 
is not ebXML specifc.  It is not dependant on ebXML components being 
used and actually presumes that WSDL + SOAP may be an underlying 
implementation strategy.  Therefore, we (UN/CEFACT eBusiness 
Architecture Working Group) need to make sure we get this right.

> It seems a bit like asking IP
> to understand HTTP.  On the other hand, maybe our textbook notions of
> protocol layering are not holding up in the Real World, e.g. firewalls
> arguably *should* understand IP, TCP, HTTP, SOAP, SAML, WS-Security, etc.
> and their interrelationships.  
>>>>>>>>>>>
This was driven out of a set of business requirements collected by over 
2000 contributors around the globe.  The messaging layer does not need 
to understand what the layers up the stack are doing, just be capable of 
enforcing those rules of engagement.  Therefore,  a transport level 
acknowledgement should not to be construed as a business acceptance of 
the message etc etc.

Duane Nickull
-
VP Strategic Relations,
Technologies Evangelist
XML Global Technologies
****************************
ebXML software downloads - http://www.xmlglobal.com/prod/