RE: [ebxml-cppa] FW: BTP+CPPA

BTP and CPP/CPA: a preliminary review of what features in BTP may need be reported and controlled by a CPP/A., as many business exchanges will be controlled through a transaction mechanism:

BTP requires the use of a coordinating entity, that may be a third party entity, or one of the transaction actors. Even before this, initiating a transaction requires access to a “Factory”, which is the real starting point. The CPP of a transactional-capable party should then specify the URL of a BTP Factory, (the “target address” in a BEGIN message). In the CPP of a transactional party, the Factory address could be: (1) either at PartyInfo level (along with a special CollaborationRole), or (2) inside each existing CollaborationRole (because the transactional parameters may be specific to each service/action, and so could be the Factory be, as not all the BTP implementations are created equal). We could also assume that a ProcessSpecification wants to specify this.

<tony>As I general rule, I suggest that we alter the existing CPP/A as a little as possible and add a new section for BTP. Will need to point to the fact that BTP is being used. Factory URL(s?) could go in the new section? May need to have the BTP role in the existing part. Yes, the Business Process specification (BPSS or other) will need to be one that uses BTP facilities.</tony>

As there will be exchanges (with the Factory, with the coordinating entity, and more generally between Tx actors) solely dedicated to the transaction control, we may consider (1) a predefined CPA for these exchanges, (2) a more dynamic CPA, to be negotiated with the BTP implementation. Indeed, it is possible that the CPA at business messaging level may be different than the CPA for transaction control (e.g. the level of security, confidentiality, may not be the same as for business sensitive messages.)

<tony>If there is a CPP/A for a system then it will need to to tackle the application flow (with BTP add ons) and BTP flow pretty much separately. It would therefore probable be better (required?) that there are two distinct CPPs and CPAs. One will be for the application flow - we could provide perhaps a set of suggested data items and values to be added to specify the addition of the BTP Contexts.

We would have a separate CPP/A for the BTP flow and I agree there could be a standard one for this (to be decided - an actual standard, or an example that could be used directly or modified to suite, or a 'template' with some parts filled in with suggested values and others just with guidance on filling.</tony>

BTP actors have roles, that are orthogonal to business collaboration roles, and relevant to their ability in controlling the transaction. E.g.: “Decider” (at the top of the Tx tree), “Terminator” (right to end a Tx), “Superior”(determines the outcome applicable to the Inferiors), “Inferior”, “Initiator”(use a factory to create a Superior…). A predefined set of Tx control operations are available to each of these roles. As this transactional role is probably specific to a Service/Action, it could be added to the CollaborationRole element of the CPP. Note: in case the role may actually be variable, or negotiable, a CPP may defines a list of possible roles it is ready to play, for a given CollaborationRole.

<tony>Yes, but see above.</tony>

All BTP messages (whether separate messages, or additions to application messages), have “Qualifiers” parameters, which define some global parameters to the Tx, to be shared generally by participants. The CPP may also define these, for a given CollaborationRole. To be more specific, each qualifier has (1) content that is specific to the transaction, (2) sub-parameters that control propagation of the qualifier to other actors, as well as requirement on their level of understanding. It could be that (1) might be described in the ProcessSpecification.

<tony>Yes, but the CPP/A only needs to specify which are agreed for use, which may be used and any that shall not be used. I think this can be for an implementation and therefore relatively static. So we may not need anything specific to a transaction - maybe for a Role. Obviously actual values will be set in the Application Context and BTP messages.</tony>

Protocol binding (this is more an MS issue than CPP): How will BTP messages be packaged as ebXML? First, that may actually not be required: the BTP exchanges may bypass the MSH. But then, there is the case where BTP messages are tied to application messages. Then they have to be packages in ebXML. BTP defines 2 SOAP bindings (SOAP, and SOAP+attachment). SOAP+attachment will then be used here. Depending whether the BTP message is bound to an application message or not, its XML content must be in the SOAP header or a SOAP body element… I see roughly two solution: one that is merging the BTP message in the ebXML SOAP envelope, as one more Header block. So a single SOAP envelope is used. But the MSH must then be aware of this. Another solution is to really treat the BTP message as an ebXML payload, with its (separate) SOAP envelope in a separate MIME part. MS spec may need to address this, at least define non-normative guidelines.

<tony>The BTP specification itself specifies a template for specifying bindings and also specifies the particular binding for SOAP (may in fact specify more than one - 1 using SOAP messages and another using SOAP RPC. So this is an issue being tackled by the BTP group and does not need to be tackled by the CPP/A or ebXML messaging groups. However, the BTP group are not currently specifying a binding to ebXML messaging (for the App or BTP messages) so the ebXML messaging group might like to correspond with the BTP group about that. The CPP will need to specify the binding(s) that are supported and the CPA will have to specify which one is to be used.</tony>

Other BTP-specific parameters will “configure” the BTP implementation. And we might consider them as part of a specific “BTP CPP”, or as part of a business CPP, as requirements for a CPA:
1. Failure recovery behaviour: degree to which an information described as “persistent” will survive failure. See “State Tables” section, and “Failure Recovery” section. An impl. should describe the level of failure that it is capable of surviving, ideally should be configurable, so relevant to CPPA.
2. Redirection mechanism (2 options available, see“Failure Recovery” section. )

<tony>See comment on paragraph 2 above. I think we will need BTP additions to the "Business CPP/A" and a separate CPP/A for the BTP flows. This latter one might cover recovery, or we might need a third one for failure recovery.</tony>

ebxml-cppa message