Sketchy draft of batch variation on bundling

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

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.