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.