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.
