#0028 Provide Example Text from CPPA on Mapping

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Title: Message

Discussion|Oasis.ebBP.ebCPPA ebMS mappings;

Topic|ebCPPA version 2.0 texts pertaining to ebBP and supported mappings to ebMS

Point|Texts from CPPA discussing mappings between ebBP ebCPPA and ebMS;

dwm@

Summary: There are four critical information items in CPPA that provide mapping between ebBP and ebMS so that users of both specifications have agreed upon ways to make use of information. These four items are Service, action, Role, and ActionContext. The uuid attribute of ebBP's instance is used to identify the unique ProcessSpecification being used between parties.It is also used currently as the value for Service. The action attribute value supplies a value for ebMS action, and is related via the ActionContext contstruct to a BT in the BPSS instance.

 

Appendix F is added here though it is more relevant to ebMS. It shows how information items in the ebCPPA pertain either to ebMS header information items or to the interface contract agreements governing the collaboration protocol used between parties.

8.4.4.5 uuid attribute
The IMPLIED uuid attribute uniquely identifies the ProcessSpecification. If the Process-Specification document is defined by the ebXML Business Process specification [ebBPSS], then this attribute MUST be set to the uuid for the corresponding ProcessSpecification element within the business process specification instance.

8.4.9 Service element
The value of the Service element is a string that SHALL be used as the value of the Service element in the ebXML Message Header[ebMS] or a similar element in the Message Header of an alternative message service. The Service element has an IMPLIED type attribute.
If the Process-Specification document is defined by the ebXML Business Process Specification Schema[ebBPSS], then the value of the Service element MUST be the uuid (URI) attribute specified for the ProcessSpecification element in the Business Process Specification Schema instance document.

8.4.12.1 action attribute
The value of the REQUIRED action attribute is a string that identifies the business document exchange to be associated with the DeliveryChannel identified by the ChannelId sub-elements. The value of the action attribute SHALL be used as the value of the Action element in the ebXML Message Header[ebMS] or a similar element in the Message Header of an alternative message service. The purpose of the action attribute is to provide a mapping between the hierarchical naming associated with a Business Process/Application and the Action element in the ebXML Message Header[ebMS]. This mapping MAY be implemented by using the ActionContext element. See NOTE in Section 8.4.4 regarding alternative Business Collaboration descriptions.

8.4.16 ActionContext element
The ActionContext element provides a mapping from the action attribute in the ThisPartyActionBinding element to the corresponding Business Process implementation-specific naming strategy, if any. If the Process-Specification document is defined by the ebXML Business Process Specification Schema[ebBPSS], the ActionContext element MUST be present.
Any business process/application implementation can use a combination of information in the action attribute and the ActionContext elements to make message routing decisions. If using alternative Business-Collaboration description schemas, the action attribute of the parent ThisPartyActionBinding element and/or the [XMLSCHEMA-1] wildcard element within the ActionContext element MAY be used to make routing decisions above the level of the Message Service Handler.
The ActionContext element has the following elements:
• zero or one CollaborationActivity element,
• zero or more [XML SCHEMA-1] wildcard elements.
The ActionContext element also has the following attributes:
• a REQUIRED binaryCollaboration attribute,
• a REQUIRED businessTransactionActivity attribute,
• a REQUIRED requestOrResponseAction attribute.
8.4.16.1 binaryCollaboration attribute
The REQUIRED binaryCollaboration attribute is a string that identifies the BinaryCollaboration for which the parent ThisPartyActionBinding is defined. If the Process-Specification document is defined by the ebXML Business Process Specification Schema[ebBPSS], then the value of the binaryCollaboration attribute MUST match the value of the name attribute of the BinaryCollaboration element as defined in the ebXML Business Process Specification Schema[ebBPSS].
8.4.16.2 businessTransactionActivity attribute
The REQUIRED businessTransactionActivity attribute is a string that identifies the Business Transaction for which the parent ThisPartyActionBinding is defined. If the Process-Specification document is defined by the ebXML Business Process Specification Schema[ebBPSS], the value of the businessTransactionActivity attribute MUST match the value of the name attribute of the BusinessTransactionActivity element, whose parent is the
BinaryCollaboration referred to by the binaryCollaboration attribute.
8.4.16.3 requestOrResponseAction attribute
The REQUIRED requestOrResponseAction attribute is a string that identifies either the Requesting or Responding Business Activity for which the parent ThisPartyActionBinding is defined. For a ThisPartyActionBinding defined for the request side of a message exchange, if the Process-Specification document is defined by the ebXML Business Process Specification Schema [ebBPSS], the value of the requestOrResponseAction attribute MUST match the value

of the name attribute of the RequestingBusinessActivity element corresponding to the Business Transaction specified in the businessTransactionActivity attribute. Similarly, for the response side of a message exchange, the value of the requestOrResponseAction attribute MUST match the value of the name attribute of the RespondingBusinessActivity element corresponding to the Business Transaction specified in the businessTransactionActivity attribute, as defined in the ebXML Business Process Specification Schema[ebBPSS].
8.4.17 CollaborationActivity element
The CollaborationActivity element supports the ActionContext element by providing the ability to map any nested BinaryCollaborations as defined in the ebXML Business Process Specification Schema[ebBPSS] to the action attribute. The CollaborationActivity element MUST be present when the BinaryCollaboration referred to by the binaryCollaboration attribute has a CollaborationActivity defined in the business process definition.
An example of the CollaborationActivity element is:
<tp:CollaborationActivity
tp:name="Credit Check"/>
The CollaborationActivity element has zero or one child CollaborationActivity element to indicate further nesting of BinaryCollaborations.
The CollaborationActivity element also has one attribute:
• a REQUIRED name attribute.
8.4.17.1 name attribute
The REQUIRED name attribute is a string that identifies the CollaborationActivity included in the BinaryCollaboration. If the Process-Specification document is defined by the ebXML Business Process Specification Schema[ebBPSS], the value of the name attribute MUST match the value of the name attribute of the CollaborationActivity within the BinaryCollaboration, as defined in the ebXML Business Process Specification Schema


[Errata on this clarifies that Role/@name is the value used in ebMS.]
8.4.5 Role element
The REQUIRED Role element identifies which role in the Process Specification the Party is capable of supporting via the ServiceBinding element(s) siblings within this CollaborationRole element.
The Role element has the following attributes:
• a REQUIRED name attribute,
• a FIXED xlink:type attribute,
• a REQUIRED xlink:href attribute.
8.4.5.1 name attribute
The REQUIRED name attribute is a string that gives a name to the Role. Its value is taken from a name attribute of one of a BinaryCollaboration’s Role elements described in the Process Specification[ebBPSS].
See NOTE in Section 8.4.4 regarding alternative Business-Collaboration descriptions.
8.4.5.2 xlink:type attribute
The xlink:type attribute has a FIXED value of "simple". This identifies the element as being an [XLINK] simple link.



Appendix F Correspondence Between CPA and ebXML Messaging Parameters (Normative)
The following table shows the correspondence between elements used in the ebXML Messaging Service message header and their counterparts in the CPA.

 

Message Header Element / Attribute	Corresponding CPA Element / Attribute
PartyId element	PartyId element; if multiple PartyID elements occur under the same PartyInfo element in the CPA, all of them MUST be included in the Message Header
Role element	Role element
CPAId element	cpaid attribute in CollaborationProtocolAgreement element
ConversationId element	No equivalent; SHOULD be generated by software above the Message Service Interface (MSI)
Service element	Service element
Action element	action attribute in ThisPartyActionBinding element
TimeToLive element	Computed as the sum of Timestamp (in message header) + PersistDuration (under DocExchange/ebXMLReceiverBinding)
MessageId element	No equivalent; generated by the MSH per message
Timestamp element	No equivalent; generated by the MSH per message
RefToMessageId element	No equivalent; usually passed in by the application where applicable; SHOULD be used for correlating response messages with request messages
SyncReply element	syncReplyMode attribute in MessagingCharacteristics element; the SyncReply element is included if and only if the syncReplyMode attribute is not “none”
DuplicateElimination element	duplicateElimination attribute in MessagingCharacteristics element; the DuplicateElimination element is included if the duplicateElimination attribute under MessagingCharacteristics is set to “always”, or if it is set to “perMessage” and the application indicates to the MSH that duplicate elimination is desired
Manifest element	Packaging element; each Reference element under Manifest SHOULD correspond to a SimplePart that is referenced from one of the CompositeList elements under Packaging
xlink:role attribute in Reference element	xlink:role attribute in SimplePart element
AckRequested element	ackRequested attribute in MessagingCharacteristics element; an AckRequested element is included in the SOAP Header if the ackRequested attribute is set to “always”; if it is set to “perMessage”, input passed to the MSI is to be used to determine if an AckRequested element needs to be included; likewise, the signed attribute under AckRequested will be appropriately set based on the ackSignatureRequested attribute and possibly determined by input passed to the MSI
MessageOrder element	messageOrderSemantics attribute in ReliableMessaging element; the MessageOrder element will be present if the AckRequested element is present, and if the messageOrderSemantics attibute in the ReliableMessaging element is set to "Guaranteed"
ds:Signature element	ds:Signature will be present in the SOAP Header if the isNonRepudiationRequired attribute in the BusinessTransactionCharacterisitcs element is set to “true”; the relevant parameters for constructing the signature can be obtained from the SenderNonRepudiation and ReceiverNonRepudiation elements

 

The following table shows the implicit parameters employed by the ebXML Messaging Service that are not included in the message header and how those parameters can be obtained from the CPA.

 

Implicit Messaging Parameters	Corresponding CPA Element / Attribute
Retries (not in Message Header) but used to govern Reliable Messaging behavior in sender	Retries element (under ReliableMessaging element)
RetryInterval (not in Message Header) but used to govern Reliable Messaging behavior in sender	RetryInterval element (under ReliableMessaging element)
PersistDuration (not in Message Header) but used to govern Reliable Messaging behavior in receiver	PersistDuration element (under ebXMLReceiverBinding element)
Endpoint (not in Message Header) but used for sending SOAP message	Endpoint element (under TransportReceiver); the type of message being sent MUST be passed in to the MSI; an appropriate endpoint can then be selected from among the Endpoints included under the TransportReceiver element
Use Service & Action to determine the corresponding DeliveryChannel	DeliveryChannel
Use ReceiverDigitalEnvelope to determine the encryption algorithm and key	ReceiverDigitalEnvelope
Use SenderNonRepudiation to determine signing certificate(s) and ReceiverNonRepudiation to determine the trust anchors and security policy to apply to the signing certificate	SenderNonRepudiation and ReceiverNonRepudiation
Use Packaging to determine how payload containers ought to be encapsulated. Also use Packaging to determine how an individual SimplePart ought to be extracted and validated against its schema	Packaging
Use TransportClientSecurity and TransportServerSecurity to determine certificates to be used by server and client for authentication purposes	TransportClientSecurity and TransportServerSecurity
Use the DeliveryChannel identified by defaultMshChannelId for standalone MSH level messages like Acknowledgment, Error, StatusRequest, StatusResponse, Ping, Pong, unless overridden by OverrideMshActionBinding	defaultMshChannelId attribute in PartyInfo element, and OverrideMshActionBinding

 

dwm@