follow-up on header packaging

[Jacques Durand <JDurand@us.fujitsu.com>]

Title: follow-up on header packaging

Proposal we started to discuss (item #2 in the packaging proposal doc):

Assuming we have an eb:Message (or whatever name) single header container for ebMS under SOAP:Header:

Distinguish more clearly (i.e. at schema level, as opposed to special values in Service/Action) signal messages (ebMS signals) from "user messages" (messages intended to or generated by parties, see these definitions in the previously proposed "Messaging Model" section). That would translate into the use of a "container" element, child of the ebMS header:

/SOAP:Header/eb:Message/eb:<signalname>
/SOAP:Header/eb:Message/eb:UserMessage

Outline of header for signal message:
        <SOAP:Header>
                <eb:Message>
                        <eb:PullRequest>
                        ...(elements specific to Pull)
                                </eb:PullRequest>              
                </eb:Message>
        </SOAP:Header>

Outline of header for user message:
        <SOAP:Header>
                <eb:Message>
                        <eb:UserMessage>
                        ...(header elements of ebMS user messages)
                                </eb:UserMessage>              
                </eb:Message>
        </SOAP:Header>

Note: both types of messages still use a MessageID, assumed here to be represented using ws-addressing header.

Benefit: 
- Signal messages (Pull, status, ...) require a very different processing from regular messages. Their header infoset has no reason to be same as for regular messages (meaning they need different header sub-elements). Trying to fit all message types  in the same infoset is contrived.  Service/Action would be absent from signal messages, only used by user messages for user-defined back-end binding, no overloaded semantics, no reserved values. Each eb:<signalname> element has its own schema.

Potential benefit:
- This schema design will allow for a backward compatible upgrade in a future release where bundling several user messages in the same eb:Message element (and SOAP envelope) is allowed. (alternative: authorize several eb:Message headers in the SOAP header, though less control on the ordering.)

- For example, several Pulls can be bundled (unless we have a Pull(N) option), and the synchronous response would be a set of bundled ebMS messages wrapped in the same SOAP and MIME envelope.

- It will also allow to bundle both user and signal messages within the same eb:Message element, e.g. an "interleave" pattern (relax-ng).

-------------------------

Example of proposed header packaging for a "user message":

<SOAP:Header ...>

--------- wsa headers: (example of a response message)

<wsa:MessageId>UUID-2@example.com</wsa:MessageId>
<wsa:RelatesTo type="ebms3">UUID-1@example.com</ wsa:RelatesTo>

---------- ebMS header

<eb:Message  eb:version="3.0" SOAP:mustUnderstand="1" >
<eb:timestamp>2000-07-25T12:19:05</eb:timestamp> (could that be an attribute of eb:Message?)

<eb:UserMessage eb:syncrep="no"> 
 
<eb:From> (no change beside renaming)
<eb:PartyId>uri:example.com</eb:PartyId>
<eb:Role>http://rosettanet.org/roles/Buyer</eb:Role>
</eb:From>

<eb:To> (no change beside renaming)
<eb:PartyId eb:type="someType">QRS543</eb:PartyId>
<eb:Role>http://rosettanet.org/roles/Seller</eb:Role>
</eb:To>

<eb:CollaborationInfo>
        <eb:AgreementRef> http://www.oasis-open.org/cpa/123456</eb:AgreementRef>
        <eb:Service> QuoteToCollect </eb:Service>
        <eb:Action> NewPurchaseOrder </eb:Action>
        <eb:ConversationID>4321</ eb:ConversationID>
</eb:CollaborationInfo >

<eb:UserProperties>
<eb:property name="ProcessInstance">PurchaseOrder:123456 </ eb:property>
<eb:property name="ContextID"> 987654321</ eb:property>
</eb:UserProperties >

<eb:PayloadInfo> (same as before)
...
</eb:PayloadInfo>
</eb:UserMessage> 
</eb:Message>
</SOAP:Header>