Re: [ebxml-cppa] Comments on action & ActionContext

["Monica J. Martin" <Monica.Martin@Sun.COM>]

> Moberg:.....
>
>   1.
>    2. I do agree that we need to rethink how BPSS, CPPA, and ebMS
>       should realign their concepts of service, action, actioncontext,
>       role, etc. The UMM did not really have much to say about these
>       notions in a direct way IMO. Mainly ebMS required Service and
>       Action and BPSS had Role. EbMS added Role values to its header,
>       and CPPA had to struggle to say how values from BPSS mapped into
>       ebMS values. The use of the BPSS uuid attribute for a service
>       value will probably need to be abandoned because a choreography
>       can weave together more than one service, and can even tie
>       services in narrow senses (query-response) with “services”
>       following other patterns, such as notification/event or business
>       data exchange processes. I am hoping that eventually exploring
>       design patterns for distributed processes will result in
>       clarifying the situation. At the present it is all fairly murky
>       and muddy. The ebSOA initiative may be useful. The w3c WS
>       architecture was OK but with limited scope. If you have a model
>       for us to consider, and you think it would help us enhance the
>       current somewhat clunky alignment, by all means send it out.
>
mm1: Dale, I had asked earlier this week if we could coordinate a joint 
CPPA-ebBP session in your regular CPPA call (or after it) 12 Nov. Can 
that be arranged? Thanks.

> Capell: One of the things that I thought was confusing / wrong in the 
> 2.0 spec was the mapping of action and action context in the 
> <ThisPartyActionBinding> element. These elements / attributes are 
> supposed to map to elements in a bpss schema - which, in turn, carries 
> the semantics of the UMM model from which schema have been generated. 
> That being the case, these values should map to fields of type ID (in 
> the referenced BPSS) so that there can be no ambiguity. If you look at 
> the bpss specification (v1.1 and draft 2.0), each element 
> binaryCollaboration / Transaction / activity / etc element carries 
> both name and nameID attributes. Name is just an xsd string whilst 
> nameId is of type ID (ie must be unique in the namespace of the bpss 
> instance).
>
> So the CPA action and ActionContext elements and attributes really 
> should of type QName and should map to the nameID elements in the 
> corresponding bpss. The example instance on page 26 has values for 
> these key reference fields that are clearly just meaningless strings 
> (from a machine readability perspective):
>
> <tp:ActionContext
>
> tp:binaryCollaboration="Request Purchase Order"
>
> tp:businessTransactionActivity="Request Purchase Order"
>
> tp:requestOrResponseAction="Purchase Order Request Action"/>
>
> I'd suggest that the cpa should have a namespace declaration at the 
> top that defines the namespace of the bpss instance (eg 
> xmlns:bp=rosettanet-org:processes.3A4.bpss) and then the action 
> attribute and each actionContext attribute should be a QName that 
> links to the corresponding nameId field in the bpss instance. 
> Something like:
>
> BPSS INSTANCE
> ********************
>
> <ProcessSpecification
>
> targetNamespace=rosettanet-org:processes.pip3A4
>
> xmlns:tns=rosettanet-org:processes.pip3A4
>
> ......
>
> <BinaryCollaboration
>
> name="Request Purchase Order"
>
> nameId="order.request"
>
> CPA INSTANCE
>
> *******************
>
> <tp:CollaborationProtocolAgreement
>
> xmlns:bp=rosettanet-org:processes.pip3A4
>
> ....
>
> <tp:ActionContext
>
> tp:binaryCollaboration="bp:order.request"
>
> etc...
>
> Without this level of precision, the architecure begins to crumble....
>