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