RE: Proposed text on reliability in the web services architecture [lo ng]

Very helpful summary.

I still hold the difference between reliable messaging and "higher level"
reliability is largely
just a question of what the receiving party has agreed to - in other words
that it depends on
the over-arching contract.


> But in the case of reliable messaging, it seems that you should be able to
> use, for example, SOAP over HTTPR on one hop, and SOAP over JMS
> on the next
> hop, and still be able to support reliable messaging end-to-end. (The
> message goes reliably from A to C iff it goes reliably from A to
> B and from
> B to C - for example, B waits until it gets the transport-level ack from C
> before sending its transport-level ack to A).
> In fact, I think this was the rationale when IBM designed HTTPR,
> so that you
> could go from Internet to intranet (and vice versa), using SOAP over HTTPR
> on the Internet, and then switching to SOAP over MQSeries (or other MOM)
> once inside the intranet.

Would it have been acceptable for B to (reliably) store and then forward to
C later ?
Would A be expected to be able to tell ? It really depends on the A:B
contract (which
may be expressed in various ways). And the A:B contract could equally insist
that B doesn't
give an acknowledgement until there is assurance that C (or D) has found the
syntax acceptable;
or the goods are unambigously identified; or that they are in stock and will
be delivered to A.


The comparison with TCP is interesting, but there some points that weren't
mentioned the first time - in
particular that TCP "reliablity" is constrained to the epoch of the
connection - which has to be
established before any application data flows, and which provides a
numberspace for identifying the
messages. End-system crash invariably (afaik) causes connection termination.
To do the equivalent
with higher reliability (surviving system crash etc) requires various rules
about identifiers and their persistence which are essentially similar
whatever the acknowledgement of receipt means.

> RESTful Application-Level Protocols in lieu of RM
>
> To some extent, the absence of a reliable messaging layer in the
> infrastructure can be alleviated or superceded by employing
> application-level protocols that are designed to work with an unreliable
> substrate.

Which would also describe a BTP-style approach

>              REST is the obvious example here: to the extent that one can
> model a web service using the resource/representation framework,
> design the
> interaction pattern so that retrievals are "safe" (having no side effects)
> and storage operations are "idempotent" (they can be repeated
> multiple times
> without changing the state of the resource being updated), then an
> application can simply repeat an operation that fails or whose status is
> uncertain.
>
> [elaboration by a RESTifarian is solicited]

Yes please.  If Mike's description here of the approach is on the right
lines, it would seem
to run the risk of holding the form of REST but denying the substance. There
could be more
statefulness here, and held for longer than in the other approaches. Making
a URI-distinguished
resource to hold what is really session state (relevant only to the
particular client that requested
the update) doesn't seem to gain much in reality.

> While these are good points to make in the WSA document, there are some
> downsides that must be noted:
>
> * It's not clear how this would work in an environment where messages span
> different protocols, which may not have the fine-grained and well-defined
> error reporting and redirection features of HTTP.
>
> * It requires the web service system to be designed from the
> ground up to be
> RESTful; it's hard to see how legacy procedural code can, in general, be
> wrapped up in a layer that exposes it using the resource/representation
> framework, makes updates idempotent, etc.
>
> * It forces application developers to think about transport
> issues much more
> than they generally want to.  There's a middle ground between hiding the
> unreliable infrastructure behind "magic" IDEs and protocols and making
> application developers be aware of all the complex issues involved in
> distributed computing. 

It ought to be possible to confine the awareness to just
reversing/undoing/not finalising
the might-have-been changes at this end (for either end) when the
failure/cancellation
is reported. The magic has to give clear signals, and the application
respond appropriately (for
its sense of appropriately)

Peter

------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd

   Cohesions 1.0 (TM)
   Business transaction management software for application coordination

web: http://www.choreology.com
email:  peter.furniss@choreology.com
phone:  +44 20 7670 1679
direct: +44 20 7670 1783
mobile: +44 7951 536168
13 Austin Friars, London EC2N 2JX

Received on Thursday, 9 January 2003 10:13:20 UTC