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: RE: [ebxml-msg] Preliminary draft on pipelining capability.


From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Tuesday, January 19, 2010 9:05 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Preliminary draft on pipelining capability.

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 HTTP/1.1 with pipelining is indicated by setting PMode.MEPbinding.Pipelining to “true”. The default value for this parameter is “false”. 


<JD> could that be  PMode[1].Protocol.Pipelining

instead?  (see comment below) 


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.  


<JD> we have to be careful on he choice of the PMode parameter: these "MEP bindings" pmode parameters are about "channel-bindings", not really protocol-bindings. They are more abstract than HTTP..(e.g. "sync", "push-and-push").  The protocol in use is indicated by PMode[1].Protocol. (NOTE: indicated at MEP "leg" level - not once for the entire MEP - because the protocol could change for different MEP messages)


<JD> 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.


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