Re: [ebxml-bp] CPPA 2.1 proposed changes to align with BPSS 2.0

["David Webber \(XML\)" <david@drrw.info>]

Dale,

 

Yikes I'd missed that aspect of CPPA - because in reality I see vendors,

implementers using a text string or a logical ID name here

(including Cyclone!).

 

I can see both sides of this issue.  The UUID is precise - but a bugger to use

in reality - and also to version.

 

I'm of course thinking that a logical ID value should be an acceptable alternate

to use too.  This allows versioning to be handled in a way that will self

adapt to the latest version - or can be made explicit as the implementers

need.  I hate things that can break and be a bear to debug already for

the end users, or be difficult for implementers to lookup in their systems

too.

 

So in the same way as we allowed a unique ID value to key off in the BPSS,

then the CPPA should also permit unique IDs too that are not restricted to

just the UUID format.

 

Thanks, DW

 

----- Original Message -----

From: Dale Moberg

To: ebxml-cppa@lists.oasis-open.org ; BPSS ebXML

Sent: Monday, January 10, 2005 2:53 PM

Subject: [ebxml-bp] CPPA 2.1 proposed changes to align with BPSS 2.0

Hi

 

Hima, Monica, and I formulated some draft proposals on changes that might be made (with both TC’s consensus) to specify how BPSS and CPPA align on getting values for Service, Action, and ActionContext. [We will need to get around to Role values eventually, but we did not do that Monday, and it will mainly be of interest to the CPPA TC members.]

 

Here is what the CPPA 2.0 alignment involved:

 

1. When using BPSS 1.x as a process specification, use the @uuid value on ProcessSpecification as the value of Service. [ Proposed to be changed for BPSS 2 alignment]

 

2. When using BPSS 1.x, the @name values for RequestingBusinessActivity and RespondingBusinessActivity are default values for Actions. These values can, however,  be manually overridden in a CPPA.

 

[In other words, for the automatic generation of Action values in CPPs, use the @name attribute values. However, allow these values to be edited to be different strings in distributed CPPs or CPA templates, or within final CPAs.]

 

3. The ActionContext serves to provide the definitive information that allows programs to find the right BT in the intended choreographic context of the referring BTA.

 

 

The major difference proposed in aligning CPPA 2.1 with BPSS 2.0  is to permit a single BPSS instance to specify more than one service value. The initial proposal is to allow each toplevel business collaboration choreography to supply a value for the ebXML Service.

 

That means that

 

1-new. When using BPSS 2.x, the @name attribute on a toplevel BinaryCollaboration, BusinessCollaboration or MultiPartyCollaboration provides Service values for use with CPPA and ebMS.

 

[ It would probably be feasible to relax the “toplevel” restriction if some important use cases supported it. We would, however, need to explain how a convention can be formulated that can be used for the automatic (default) generation of Service values in CPPs that are constructed for a given BPSS instance.)

 

The bpss:ProcessSpecification/@uuid value would still be used to identify the BPSS instance within the CPA.

 

There will need to be some changes in how ActionContext works and these will be proposed by Hima.

 

What we have not yet proposed is any standard or default convention that relates the ebXML Service value to the wsdl:service/@name value.

 

 If anyone has a proposal to make in this area that works smoothly with BPSS 2.0 and CPPA 2.1 or above, please make it known as soon as possible.

 

Please look at the new bpss:OperationMapping element and also look at the proposed support for WSDL under DocExchange in the 2.1 CPPA schema and editor’s draft.