Re: The CPA composition tool

[Martin Sachs <msachs@cyclonecommerce.com>]

Hi, Sacha

Thank you very much for your comments.  My responses are embedded below (MWS:).

Regards,
Marty

At 05:08 PM 10/14/2003 +0800, Sacha Schlegel wrote:
>Hi Mr Sachs
>
>Hope you are having time to comment on two things I am working on.
>
>1st issue:
>----------
>
>Going over the specifications (CPPA spec, Appendix E - CPA composition),
>once again, I still have lots of those "aha's" experiences.
>
>I really see an advantige of being part of a project from the early
>beginning, where reasons for certain decision can be followed more
>easily.
>
>What currently makes me think is the following:
>
>The BusinessTransactionCharacteristic attributes are quite important.
>The BusinessTransactionCharacteristic element, among one or more (which
>makes me even more thinking) ChannelId element, is a child element of
>ThisPartyActionBinding. The CanSend (or CanReceive) element holds the
>ThisPartyActionBinding.
>
>The BusinessTransactionCharacteristice attributes dictate (maybe wrong
>word) that some elements down the XML tree, in particular the Packaging,
>DocExchange and Transport way, have to be present or not.
>
>Theoretically, two CanSend elements, with different
>BusinessTransactionCharacteristic attributes (eg once with "transient"
>isConfidentiality, once with "none" isConfidentiality), can use the same
>delivery channel, thus the same transport element. The transport element
>must have a TransportSecurityProtocol to enalbe "transient"
>confidentiality.
>
>So looking soely at the CanSend element with the "none"
>isConfidentiality attribute in its BusinessTransactionCharacteristics
>element I find a TransportSecurityProtocol element which is NOT
>necessary for this particular CanSend element.

MWS: The example you give here is not a particular problem.  Because one of 
the CanSend elements requires transient confidentality and the other 
requires no confidentially, a run-time system would configure the transport 
security implementation into the delivery channel implementation.  The 
run-time would ensure that transport security is "turned on" for those 
transactions that require it and turned off for those that require "none". 
I do not believe that the CPPA team has actually discussed the problem you 
raise, so I hope that this is the correct answer.  I also hope that someone 
else who sees your message and my response will respond and especially tell 
us what existing run-time systems would actually do.

MWS:  I will be much more concerned if you come up with an example where 
the combination of characteristics is such that the two CanSends cannot 
share a delivery channel definition.  However even this is not a real 
problem since two diffferent delivery channels does not mean two separate 
delivery channel implementations.  It does mean that the run-tiem design 
has to be very flexible.


>Not sure if the advantage of using the IDREF XML data type for
>DeliveryChannel, Packaging, DocExchange and Transport overweights the
>disadvantages.


MWS: If the main disadvantage of IDREF is the one you describe above,  this 
does not say that IDREFs cause major problems.  It does mean, as you say 
below, that "real" CPP or CPA validation is necessary. I would think it a 
natural extension of a CPA or CPP composition tool to be able to take an 
existing CPP or CPA and perform a "semantic" validation.


>The way how a CPP is constructed starts to get interesting, but for an
>application receiving a CPP or a CPA should not trust the document and
>must validate the document. Validation here does not only to check if it
>is a valid XML document but also that it is logically a valid CPA or
>CPP.


MWS:  As I said above, this is very true.  I hope that tool implementers do 
have semantic validators.


>Summary: A real CPP or CPA validation is necessary; The XML schema is
>not enough.
>
>Having quickly looked at Schematron, that might be a variant to validate
>CPP's and CPA's. It would be great to have those rules (eg if the
>document is a CPA each CanSend, CanReceive element must have one
>OtherPartyActionBinding element) in a descriptive way and having those
>rules be part of the CPPA spec.


MWS:   Some rules of this kindare stated in the text of the CPPA 
specification.  If you notice places where more rules should be stated, 
please let us know.


>On a sidenote: I havent looked closer at the MessageCharacteristics
>element but I guess it holds similar issues.
>
>2nd issue:
>----------
>
>Are the "Negotiation Requirements" and "Collaboration Protocol Agreement
>Simple Negotiation Business Process Model" still maintained documents of
>the CPPA Negotiation team?
>
>
>Kind regards
>
>Sacha Schlegel
>--
>------------------------------------------------
>Sacha                                   Schlegel
>------------------------------------------------
>4 Warwick Str, 6102 St. James, Perth,  Australia
>sacha@schlegel.li                www.schlegel.li
>public key:            www.schlegel.li/sacha.gpg
>------------------------------------------------

*************************************
Martin Sachs
standards architect
Cyclone Commerce
msachs@cyclonecommerce.com