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



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. 

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.

 




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.