Bundling/batching options, discussion chart

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

ebMS participants,

 

I would like to find if there are any modifications needed to the following assessments of kinds of batching/bundling under consideration for part 2.

 

I am working on a basic MIME Bundling, which we might also call MIME batching, and want to see if the basic trade-offs outlined below seem roughly accurate to everyone.

 

Thanks

Dale Moberg

 

 

Batching/Bundling Approaches

 

Transport Bundling: specify how HTTP 1.1 pipelines can on a single connection transfer many SOAP messages, even when responses are made on the same connection (such as for “pull”)

 

Pro: Low level batch solution that probably leaves all P-mode processing “as-is” in constructing message streams. Synchronous responses might be possible. Agreements on quality of service remain unchanged.

 

Con Not particulary “intermediary-friendly.” Efficiency questioned.

MIME Bundling: Specify how many SOAP messages can be conveyed in one MIME multipart/mixed, and how responses would be made to such a message. Each message would retain its SOAP headers for security, reliability, ebMS. SOAP with attachments would be a multipart within the MIME multipart container.

 

Pro: The multipart is pulled apart and each part can have its own SOAP and ebMS processing. Reliability can be merged into one ack range. ebMS, errors reports can be generated if needed. In principle, a single SOAP response message could cover batch, and could be returned synchronously, although with considerable latency.

 

Whether those responses themselves should be separated, when differing MEPs required it, and whether to support separate bundles of synchronous and asynchronous responses would need some clarification.

 

Con:  Not a top-level SOAP message. No SOAP reliability defined for message as a whole. No SOAP security defined for message as a whole. Not SOAP intermediary friendly.

 

SOAP-with-Attachments: Specify how SOAP with attachments can provide a container for multiple SOAP messages, but with only one security and reliability header for the SwA message “bundle”.

 

Pro: Can leverage SOAP/WS-* reliability and security for the bundle message itself. Can bundle either SwA or SOAP messages.  All SOAP headers in one message part. Generalizes SwA from simply carrying attachments to carrying separate SOAP messages.

 

Con: Can ignore specifics of some P-mode parameters defined for message. ebMS message header elements need to create and resolve numerous CID URIs to enable association of ebMS metadata with SOAP “bodies”.

 

SOAP-with-attachments Build on ebMS3 Core 4.1.2 distinctions. And provide no bundle specific features (derive from parts of a selected P-mode of a message in the bundle, whose ebMS header is the first ebMS header in document order).

 

Pro: Current proposal written up in considerable detail and generality. Is independently useful as a completion to Core in specifying how to include multiple user messages in one SOAP-with-attachment.

 

Con:  Is agreement about quality of service really retained? No separate ack for messages with exactly once, at most once, at least once delivery assurances.