RE: [ebxml-bp] Roberts 2/16/2004: [RSD] #0028 Provide Example Text from CPPA onMapping

["Dale Moberg" <dmoberg@cyclonecommerce.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;
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)

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.

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.

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