OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Updated version .001 of pipelining section for ebMS 3 reflecting J. Durand's suggestions -- review Wed?

HTTP Pipeline Capability


HTTP/1.1 specifies that clients and servers may coordinate requests and responses by “pipelining” requests over a single open TCP connection subject to two basic constraints:


  • A client must be able to send multiple requests before receiving HTTP responses for those requests.
  • A server must return responses to requests in the same order that the requests have been received.


The capability to engage in a MEPbinding that uses pipelining is indicated by setting PMode.MEPbinding.Pipelining to “true”.


For MEPbindings involving HTTP 1.1, the default value for this parameter is “false.” HTTP 1.1 is currently the only protocol binding substrate supporting pipelining semantics, though other protocols may emerge with an option to support the basic constraints


ebMS MEPs and Pipelining


The HTTP/1.1 protocol session always consists of a request to apply a specific method to a URI-specified resource. A response always includes a status code. In either case, the protocol data unit (“message”) can contain various headers and a message “entity,” which has a MIME structure.


ebMS has two P-Mode parameters, the PMode.MEP and the PMode.MEPbinding. The PMode.MEPbinding value indicates how the PMode.MEP is accomplished within an application transfer protocol, such as HTTP/1.1.

When used in combnation with HTTP, the MEBbindings reflect various kinds of entities that can appear within an HTTP/1.1 request/response pair. The pull MEPbinding , http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/pull, creates the expectation that the request contains a Pull signal message and the HTTP response may contain an ebMS user message.

While pipelining might be used for any of the ebMS-specified MEPbindings, the HTTP/1.1 specification contains several cautions.

First, the specification advises “Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2).”

Most ebMS MEBbindings use HTTP POST method requests, which are not generally regarded as idempotent. However, normally each POST method request carries a distinct MIME entity. Exceptions would include retries or resending and several other situations, such as a Pull signal. A sequence of Pull signals (using the same MPC) would not be idempotent because normal operation would yield distinct results for the same Pull signal (unless the MPC is empty and they all return the error signal for an empty MPC.

For the non-idempotent cases, if they are pipelined, clients are encouraged to wait for the return of a status code before posting the next message.

A more practical limitation on pipelining pertains to the SYNC MEPbinding. Because an ebMS user message in an HTTP response may involve obtaining data from internal applications, unpredictable latencies in response time are common. For this reason, pipelining support may be withdrawn for certain MEPbindings because of end user deployment constraints, even though the capability for pipelining is present in the MSH.


HTTP Pipeline Capability v001.doc

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]