RE: Proposed text on reliability in the web services architecture

>>That's a bad proposition. I would like to receive at some point (say 8
>>hours
>>later) a message confirming whether the delivery would be made or not.
>>That's how I achieve reliablity of the application, and I cannot think
of
>>any other way.
[JJ] So let's say that your message gets there and that you forgot to
upgrade your system on your supplier's notice and the message format is
now invalid. The application in charge of the business logic will never
get the message and will never be able to send an ack PO. At this point
it is hard to avoid having a confirmation that your message was valid
and that it passed all the business rules of the application in charge
of processing it. Unless, ah yes, you could retry n times, and if it
failed after n times, you could conclude that the message had something
wrong, oh, unless it is the partner system which is down. What you need
is called guaranteed message delivery at the business application level
as opposed to the transport level. Transactional web services (as
opposed to data rich or computational web services) require a business
protocol on top of SOAP, there is simply no way out of it.

>>- My proposal is only to allow this layer to exist through an abstract
>>interface which allows the application to exert some control (e.g. try
>>once/do your best, only deliver within 8 hours) and allows the layer
to
>>elect whichever strategy works best (depending on protocol) and allows
two
>>RMs to exchange acks to *improve* overall reliability
[JJ] In ebXML this layer is called the BSI. There are clearly two levels
of reliability:
- the message got there
- the receiver was able to process it

Overall it is fairly sad that all these discussions are going on as if
nobody had worked on it in the past 3-4 years. The exact same
discussions they have been taken place more than 2 years ago and
solutions -that could always be improved- have been provided (RN, UMM,
ebXML). It is of course always easier to re-invent the wheel. In case
you are not aware you can find ebXML the specifications at
www.ebxml.org. You might want to take a look at ebXML BPSS
specification...

JJ-
>>
>>arkin
>>
>>
>>> -----Original Message-----
>>> From: www-ws-arch-request@w3.org
[mailto:www-ws-arch-request@w3.org]On
>>> Behalf Of Miles Sabin
>>> Sent: Wednesday, January 22, 2003 5:54 AM
>>> To: www-ws-arch@w3.org
>>> Subject: Re: Proposed text on reliability in the web services
>>> architecture
>>>
>>>
>>>
>>> Assaf Arkin wrote,
>>> > Miles Sabin wrote,
>>> > > So there's a gap between the parties which are making the
visible
>>> > > commitments (the WS adapters) and the parties which are
ultimately
>>> > > responsible for meeting them (the endpoints). Whether that gap
is
>>> > > narrow and/or easily bridged, or an all consuming abyss is
likely
>>> > > to vary on a case-by-case basis. I'm sure many of us on this
list
>>> > > have experienced both.
>>> >
>>> > You have to decide what is the service and what is the
application.
>>> > If you have a message handler there that allows your application
to
>>> > receive messages over HTTP, the message handler is not the
service.
>>> > It's a proxy that takes care of the HTTP/SOAP/etc details on
behalf
>>> > of the actual service.
>>>
>>> That's the ideal, certainly.
>>>
>>> But the reality is that this is often very hard to do. In a not
>>> completely implausible senario we might have, say, seven largely
>>> independent organizations involved: the legacy system vendor, the
two
>>> sites which deploy that system, two consultancies providing the WS
>>> gateways (one at each site), each using a WS toolkit from a
different
>>> WS tool vendor.
>>>
>>> In such circumstances clarity on the boundary between service and
>>> application is going to take a lot of work. If differences of
opinion
>>> or outlook, or miscommunication, show through in the protocol or the
>>> way the protocol is used, then RM is likely to be the least of
anyone's
>>> worries.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Miles

Received on Thursday, 23 January 2003 11:13:16 UTC