Re: [ebxml-msg-as4] incremental update of MEP draft

[Timothy Bennett <timothy@drummondgroup.com>]

During last week's AS4 call, we discussed at length (from Section 5 of the ebMSv3 spec) about Message Bundling and it role (if any) in the AS4 profile.  The main criticism(s) to message bundling (piggybacking) is the added complexity of implementations being able to package and de-package bundled messages.

Previous AS4 discussion around the three (3) message exchange patterns have confirmed the followingin AS4 support MEPs: One-Way/Push (w/sync Receipt), One-Way/Push (w/callback Receipt), and One-Way/Pull (w/Receipt).  During these discussions, Jacques has generated a document that describes the uses cases and messaging choreography for the AS4 supported MEPs.

If I can direct your attention to Use Case 3(a), you will notice that the eb:Receipt for the previous *pulled* business document is piggybacked onto the eb:PullRequest for the next queued business document.  So, in principal, as a group we have been working off the idea of supporting Messaging Bundling for the One-Way/Pull MEP.  But, given some of the concerns during the last call, I wanted to see if Jacques' proposal for piggybacking the eb:Receipt ont a PullRequest was still our first choice, or if AS4 should profile a different way for the Non-Addressable Receiver to return eb:Receipt(s) -- perhaps as a separate Signal Message on a different HTTP connection.

Think about it before the call, and let's continue the discussion.  Chime in here on the list if you can't make the call.

Thanks,
Timothy

Durand, Jacques R. wrote:

Rev 3: mostly incremental.

 

- added P-Mode parameter:

Security.ReceiptSemantics:  determines the expected semantics for Receipts: on_delivery, on_reception, on_validation

(other? should it be determined by the profile?)

 

- completed the "non-RM" column of the Pull MEP (case 3a)

 

- Security.SendReceipt.ReplyPattern: added a new value: "Callback_or_Pullrequest", for controlling (or allowing) piggybacking of Receipts on Pull signals.

 

 

Maybe in a next version we want to more clearly separate two sections: (1) without RM, (2) with RM.

 

Jacques

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

PMode-and-MEPdetails-rev3.doc