[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:
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]