[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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”. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]