ebMS Batching
using MIME Multipart/mixed Packaging



In addition to the bundling procedure, it is possible to make use of an
alternative message assembly procedure that may be suitable for some
circumstances. 



The basic procedure is to assemble a MIME message using the
“Multipart/mixed” type, in which each part of the message is itself
a SOAP message or a SOAP message with attachments. 



Each message part MUST be to a single endpoint, and SHOULD be intended
for a single recipient whose address is provided by that endpoint.
Implementations MAY be able to process the entire message for multiple
ToParties, provided that the MSH is configured for each ToParty found in one or
more message parts.



Each SOAP message part is assembled in accordance with the P-mode and
any Agreements that govern that message part. In principle, each message part
P-mode might prescribe security, reliability, and ebMS headers that differ from
every other message part. In practice and where batching makes sense, it is
likely that these headers will have similar quality of services specified.



The message as a whole has no ebMS specified headers, nor does it have
any security or reliability P-mode that applies. The message as a whole is not
an ebMS or SOAP message. TLS or SSL security may be provided in accordance with
the URL scheme indicated for the endpoint.



In other words, the message is simply a multipart/mixed message sent to
the endpoint, where each part is a SOAP message. Each part may have a
SOAP-action header, but since within a MIME multipart, only those headers
starting with “Content-“ have significance, processing will not
depend on that header. If a SOAP-action value is to be conveyed, applications
should make use of the capabilities specified in [WS-Addressing].



Receiving Batched
Messages



The MSH receiving a batched multipart/mixed message SHOULD treat each
part independently, just as if the SOAP message had been sent in its own HTTP
envelope.



However, if a SOAP response is to be returned, there are circumstances
under which certain aggregations can be useful.



If the response uses the backchannel, a SOAP message can be assembled
that aggregates the range of sequence numbers used for reliable messaging. If
one or more ebMS errors needs to be returned, these headers may also be
included in a single SOAP response message.





If the response occurs over a separate connection, a SOAP message can
be assembled that aggregates the range of sequence numbers used for reliable
messaging. If one or more ebMS errors needs to be returned, these headers may
also be included in a single SOAP response message.



[SOAP faults?]



If message parts are such that an ebMS user message is the expected
response, and the responses are to be returned using the backchannel, a
multipart/mixed must be assembled to produce the response, with each message
part containing a response SOAP message. It is unlikely that this situation
should be handled by batching, and bundling may be a better solution for such
complex response requirements.



If the user message response parts can be sent on a separate
connection, then these responses can be assembled into a multipart/mixed and
made available for returning when all parts of the original batched message
have been processed. [Senders of batched messages MUST be able to receive
batched messages.] However, it is also permitted to return user message
responses over separate connections as simple SOAP or SOAP with attachment
messages, if responses are needed to be returned as soon as they become
available.





Batching or Bundling?



In general batching is intended for simpler situations, such as:









and not involving:



Intermediaries

Pull Mode



Etc.