RE: [ebxml-msg] some issues affecting header design

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Title: Message

CPA for v 3.0...

 

CPA 2.1 maintenance version will offer support for WS configuration. So far, this is mainly for allowing WSDL to be used in the "DocExchange" component of profiles and agreements, and mainly the support is for portType/Interface, Operations, Message, and Type with Binding and Service wsdl:definitions ignorable.

 

What is missing in 2.1 is a way of  incorporating all the SOAP header blocks/modules and also relating the as yet unvetted approaches to "Policy" that exist (from XACML and WSPL to WS-Policy). This material does not seem a stable part of WS yet, so convergence to it is not feasible currently.

 

I think Agreements will always be 2-sided, even if one side supplies nearly all the detail.

 

But eventually WS will give up with its obsession to let just one side determine all the details. I think this will happen when it comes up with a way to do RequestResponse with 2 one-ways. This is probably the most dominant mode of b2b interaction over the Internet and is likely to remain so for some time for both business and technological reasons IMO, When WS puts together 2 one-ways, both sides contribute to the configuration info. Then the CPPA approach is on a par with extended wsdl offered up by both sides.

 

(I assume that eventually some stds group will decide how to annotate the wsdl to deal with all the details CPPA currently handles. For a while I thought the features/properties constructs would be the way these extensions were added. But presumably the WS-Policy proponents wish to churn things up. Already minority reports have been written up against feature/properties. This makes everything in this area a matter of UD.)

 

So in the above situation, I think the principle of convergence favors going slow on the exact form for CPPA 3.0. Possibly the WS people will come up with an easier approach for easy cases (an admitted weakness of current CPPA), and ebMS can take advantage of that. At the moment, CPPA does not have an agreed upon approach to 3.0 for reasons mentioned above and others as well.

 

If Sender is allowed to control RM behavior, then CPPA can always add a perMessage "agreement" for that area. However, the PKI alignment (trust policy) is probably not something you want to handle on a perMessage basis. In fact, it is not just PKI. Even using basic auth would probably not make much sense if done on a perMessage basis with Sender makes up all credentials/tokens and Receiver takes whatever Sender sends...

 

I think Trust and ServiceLevel are inherently going to be things needing preconfiguration in b2b unless the b2b CAs become defacto standardized worldwide. Even then the documentation of expected collaboration protocol functionality, and adherence to that agreement, is likely to remain a cultural fixture of most business collaborations

 

3. CPA configuration:
- An important decision that will affect message header design is where the agreement (including Reliability contract)
needs be configured (Sender only vs. Sender+Receiver)
The aproach in current WS-R, is the Sender only needs be configured. If we keep this approach, then a Receiver will only need

to obtain CPA info from message header. This is not currently the case in ebMS 2.0.
Could that be achieved at least for messaging functions? Need to evaluate the value of this.
There seems to be some exception with security info (e.g. certificates).

[JWT] IMO the CPA(or similar mechanism) should continue to define the entire messaging(RM, transports, security, etc.) contract between two parties. I would like to discuss this further since this topic has been debated often in the past.