Moberg/Mukkamala 2/22/2004: [RSD] Example CPPA Mappings for BPSSAlignment WI #28

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

Discussion|Oasis.ebBP.ebCPPA ebMS mappings;
Topic|ebCPPA version 2.0 texts pertaining to ebBP and supported mappings
to ebMS;
Point|Integrating mappings for ebBP ebCPPA and ebMS into ebBP technical
specification;

||See inline for my comments - mm1

dwm@
The version 2.0 alignment documented in the text examples was worked out
during the 1.04 to 1.05 BPSS period. Arvola, Hima, Pallavi, Brian and
others were the main contributors.

The version 2.0 CPPA spec. is an OASIS ratified spec so the
uuid-to-service alignment is how BPSS and CPPA currently align. That
does not mean it has to stay that way, but that is what was the
consensus view, and what we published. BPSS participants, for various
reasons, have not published a consensus view since 1.01. As far as which
transaction is addressed (point 1), the solution is in ActionContext.
Hima can elaborate this in detail, and I can at least handle an
introductory version.

The action attribute can be a short name and does not have to appear in
the BPSS. This allows distinct names to be used for the same BT when
referenced by distinct ActionContexts, and 
in general, it allows action naming conventions in ebMS to differ from
those in BPSS. This 
was partly because the long names (composed from Xpath-like expressions)
were not liked, especially by ebMS participants. (Remember the alignment
has to try to get 3 TC groups into a consensus view. I can testify that
this is not always simple. Many ebMS-ers have historicallly not been
very interested in the "upper" layers of ebXML. 

On point 2, I think the clarity of our text needs improvement.  However,
I will let Hima address this question. Basically recall that when using
BPSS, the action attribute (which becomes the ebMS Action value), is not
necessarily a name value occurring in the BPSS (this is because we could
not reach full agreement on naming conventions and uniqueness
constraints satisfying ebMS and ebBP contributors). I would like to do
so by version 3! (Maybe even by ebCPPA v 2.1 and ebBP 2.0)

mm1@
|| POINT ON WORK ITEM #28

First, sorry I missed your reply Dale from 16 Feb 2004.
Dale and Hima, this should be an included clarification in the specification.

@mm1

On ActionContext, Hima is the expert. I again will provide introductory
explanations. Perhaps a special session where Hima can attend would help
on these issues.

mm1@
Hima, do you think we could set up a special session in March to address this?
Thanks.
@mm1

The main reason I think we CPPAers have wanted BinaryCollaborations as a
restriction within BPSS, is that otherwise we cannot see which Roles map
to what final Requesting/Responding Activities. I think if we manage to
straighten out the Role "binding" problem, we will largely not have to
worry about CPPA needing BinaryCollaborations. It might resurface,
however, if the BusinessTransaction extensions involve primitives that
are multiparty/multirole.

We ebMS and ebCPPA mainly need 4 clear points of alignment: Service
values Action values Role values Instance identifiers (allowing for
shallow test for equality, and not deep equality by some infoset
structure matching approach).

Also, a way of mapping all the BPSS nesting/hierarchy onto "short"
names.

An agreement on naming conventions and uniqueness would be a very big
nice-to-have.

mm1@
This could part of the discussion with a coordinated call re: mappings with a short-ebMS-CPPA-ebBP call.
@mm1

I represent these groups unofficially, of course, but that is basically
what historically the groups have sought in alignming with ebBP


mmer@

Dale,
    I am puzzled by this on three fronts (is that alround?):
    1) we have BPSS with multiple BinaryCollaborations and had always 
assumed the Service was the name of the BinaryConversations and not the 
UUID.  For example the same transaction could be implemented by main BTA

in multiple BinaryCollabs.  How do you know which one you are
addressing?
 
    2) I could not work out from the text of the message below what the 
Action actually pointed to.  If this is the BTA name this would mean 
that the BTA name would have to be unique across all BinaryCollabs 
within a BPSS?  I did not think this was the case.
 
    3) ActionContext is also something that I do not clearly see what in

the BPSS implements this?
 
 
    In my simple mind the CPP/A needs to point at four things for each 
BPPS:
    1) the ProcessSpecification [uuid]
    2) the BinaryCollab that implements a BusinesTransactionActivity
    3) the BusinessTransactionActivty so you could amend its details TTP
    4) the underlying BusinessTransaction that is used by the BTA so you

can change its criteria.
    ( of course there is the roles )
 
    The reason for the Four levels is a partner may not implement all of

the Binary Collabs specified in a BPSS and so you need to be able to 
know which BC they are allowed to use.  3 and 4 are just to enable the 
properties to be amended.  ( I presume the CPP/A allows this? )
 
    For messaging under the control of a BPSS you need the following:
    1) The processSpecification [uuid]
    2) The BinaryCollaboration - that represents a description of the 
conversation that should/could take place
    3) the BTA that is being invoked.
 
    The reason for all three is these are all needed to uniquely 
identify the BTA that is being invoked.  I am concerned that this is not

currently supported and therefore our BPSS spec would have to make BTA 
names unique across all BinaryCollaborations in a BPSS.  This to me in 
not acceptable as a you may choose to use one BPSS to escribe two very 
similar but different processes where the BTA occurs in more than one
BC.
 
/ Martin Roberts /
xml designer,
BT Exact
* e-mail: * martin.me.roberts@bt.com
* tel: * +44(0) 1473 609785   clickdial 
<http://clickdial.bt.co.uk/clickdial?001609785.cld>
* fax: * +44(0) 1473 609834
* Intranet Site : * http://twiki.btlabs.bt.co.uk/twiki

@mmer

mm1@
Just sending with RSD thanks. Monica
@mm1
@dwm