[ebxml-msg] Role/@name, Role/@href, and new requirements.

[Dale Moberg <dmoberg@cyclonecommerce.com>]

Hi (long message warning),

Jeff T. explained a little more to me why and where the "unique" value requirement
is coming from, and I will first explain my understanding of its rationale
and then discuss what we might do about it.

The CPPA group had a goal to align BPSS, CPPA, and Messaging so that in the
event people used all three together, they work together harmoniously.
The addition of a normative appendix tried to explain to CPPA users
how CPA information items mapped to Messaging items in the SOAP envelope
header blocks as well as for operational parameters (for example,
for reliable messaging retry counts...).

Also, text is provided for CPPA information items saying what BPSS information
items are the sources of data for Messaging items.

So far, only what we have
said for Role has created a problem. Apparently we left it insufficiently clear
in the Appendix (and text) just what information item is used to populate
the Role element in the Messaging header. There are two choices that have
been made-- use the value in cppa:Role/@name or cppa:Role/@href. My recollection
was that the value should come from cppa:Role/@name. Enter into detailed mode.

A BPSS instance can have several places that have a role element and the name
attribute can have the same value depending on the specific business
process. The nameId value, because it is type ID,
must be unique in the document. If we had several CollaborationRole elements
in a CPA, that each have their own Role element, then the href value could have
different #ID-values to reference the different BPSS locations. This feature
supports linking CPA back to BPSS. In general, I do not believe we would commonly,
in a CPA, have CollaborationRole elements with the same Role/@name values for
the same BinaryCollaboration. If this did occur, the lexically later element
would have to be an alternative subordinate DeliveryChannel
binding possibly used for failover. At any rate it would be an exotic case.

Now it is my understanding that we are to consider distinct CollaborationRole
elements in a CPA that pertain to different Actions, that have the same
Role/@name values but that have different Role/@href values (reflecting
different binary collaborations). In this case, the href allows pointing
into the different Role elements in the BPSS instance. The issue Hima
raised is this: how upon receiving a Message with a Role value, could
I go from that value to the right "CollaborationRole" element (or its database
image)? After all, the @name value is potentially shared by a first request,
and also a second request in a second binary collaboration.
If, however, I had used the href value, I could go from the "Role" element
information in the SOAP header, to the right place in the choreography.

I agree with Hima that this would be an advantage. We could offload maintaining state
within the MSH (that I have received the first request in a choreographed chain of requests) to
a message value, and let href values for Role track our path through choreographies.

However, this functionality really represents new functionality for supporting
more complex choreographies, that I do not recall being raised as a requirement
for Messaging or BPSS alignment. I think that we should proceed by asking:

1. whether Messaging wishes to support the ability to map back into constituent binary
collaborations in complex choreographies. 2. Messaging wishes to use the Role
value to do this, rather than some other more specific backpointer value that
more directly accomplishes this.

I personally would prefer to see a new (optional) header
element with dedicated semantics
for the above problem added to the MessageHeader
that would provide backpointers to BPSS (or other)
defined stages (binary collaborations)
in a complex choreography. That is, I prefer this if we add new functionality.

 It would be possible to use the Role/@:xlink:href
to get at that functionality, but it is a bit of a reach.
I think overloading Role in this way also
muddies the semantics of Role, one of whose
original intents was to allow two parties to each be buyers
and sellers in a given process specification, and yet have
different CPA configurations for those distinct roles.

Anyway, I am really persuaded that Hima has raised a new
bit of functionality, beyond version 2 in Messaging or CPPA.
I think we should consider how best to do it. CPPA can then
take this as an issue, and perhaps document both using @xlink:href
and @name as potential values for Roles if the overloaded Role
element is the way Messaging wants to handle the backpointers
to complex choreographies.


Dale Moberg

However,