RE: [ebxml-msg] Preliminary draft on pipelining capability.

From: Moberg Dale [mailto:] 

Sent: Tuesday, January 19, 2010 9:05 AM
To: 

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.