W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

RE: Reliable Messaging and Business Requirements - [Was DAG006]

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Wed, 13 Mar 2002 11:04:06 -0800
Message-ID: <3B286631A9CFD1118D0700805F6F9F5A09D09CA5@hou281-msx1.chevron.com>
To: "'Anne Thomas Manes'" <anne@manes.net>, www-ws-arch@w3.org
It may be outside our scope to design a transaction system, but in my
opinion it is certainly not outside our scope to make sure that the web
service architecture will support such a system.  

My real objective here is very simple:  it is to ensure that web services
will be able to support mainline business transactions.  These are supposed
to be things that happen between back office systems running in different
companies, and I think that this certainly fits into our definition of web
services since this is applications talking to applications over the web via
XML protocols and with well defined interfaces.  You will recall that there
was a lot of hype a few years ago about how B2B was going to have trillions
of $'s flowing through XML real soon -- but in fact the takeup has been
slower than expected.  I have talked at some length to people in our company
who are involved in this sort of thing, and I think that some of the reasons
for the "delay" are clearly in the scope of the W3C and, I think, in that of
the WS Arch WG.

Certainly the security part of this WG addresses some of the issues.  But
there are other serious lacks that I think are inhibiting this use of the
web going forward.  One of them is a standard way of implementing reliable
messaging.  There are probably others, some of them perhaps linked.  Maybe
sequencing.  That is, the requirement that a message has a unique ID and
that these ID's be ordered (so you can say that one message precedes
another).  I think that there might be more requirements around this area,
but that's what I know right now.

Of course, one can try to handle these issues in the payloads.  However, if
possible I think that everyone would be better off if they were handled at
the envelope level in a standardized way, so that we can try to get away
from proprietary, noninteroperable systems.

I repeat my concern that the goals of this WG do not yet seem to reflect
these needs.

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net] 
Sent: Wednesday, March 13, 2002 10:40 AM
To: Joseph Hui; www-ws-arch@w3.org
Subject: RE: D-AG006 Security


We're getting way off topic for security, but ...

Reprising a theme I just used in the D-AG0016 thread, it's not within our
scope to design a web services transaction system, but we might want to
reference the OASIS BTP work. And what we (in a WG yet to be formed) ought
to do is design a standard SOAP extension (headers) that can be used to
convey BTP transaction context in SOAP messages.

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Joseph Hui
> Sent: Wednesday, March 13, 2002 10:36 AM
> To: www-ws-arch@w3.org
> Subject: RE: D-AG006 Security
>
>
> > From: David Orchard [mailto:david.orchard@bea.com]
> [snip]
> > Joe,
> >
> > Do I understand correctly that you believe that the web services 
> > architecture should define something in the area of two phase commit 
> > for web services as a goal?
>
> Dave,
>
> No, heck no.  2PC is a mechanism for TP, and it's not
> even for sure that TP should be in our WS-Arch.
> (Recall we don't mechanisms.  They'll be left to
> the implementers.)
>
> BTW, The TP was a "while at it, ..." sidebar in my response to Roger 
> on RM in security.  (I snipped out that part of the text while trying 
> to keep the message more readable.  Perhaps I should have kept the 
> text to keep more context for the readers.) Anyway, I'm not even 
> championing for TP to be in.  But if someone else chooses to champion 
> for it, then that's fine with me. I'm easy about this one (and RM as 
> well).
>
> Cheers,
>
> Joe Hui
> Exodus, a Cable & Wireless service 
> ===================================================
>
> >
> > Cheers,
> > Dave
> >
> > > -----Original Message-----
> > > From: www-ws-arch-request@w3.org
> > [mailto:www-ws-arch-request@w3.org]On
> > > Behalf Of Joseph Hui
> > > Sent: Tuesday, March 12, 2002 3:49 PM
> > > To: www-ws-arch@w3.org
> > > Subject: RE: D-AG006 Security
> > >
> > >
> > > > -----Original Message-----
> > > [snip]
> > > > Or are you talking about the idea of "rolling
> > > > back" a transaction if it fails ...
> > >
> > > This type of course -- one atomic operation, do all or
> > > do none -- the type that generally employs 2-phase-commit 
> > > algorithms.
> > >
> > > Joe Hui
> > > Exodus, a Cable & Wireless service 
> > > =========================================
> > > >
> > > > -----Original Message-----
> > > > From: Joseph Hui [mailto:jhui@digisle.net]
> > > > Sent: Tuesday, March 12, 2002 4:14 PM
> > > > To: Cutler, Roger (RogerCutler); Krishna Sankar;
> > www-ws-arch@w3.org
> > > > Subject: RE: D-AG006 Security
> > > >
> > > >
> > > > > -----Original Message-----
> > > > [snip]
> > > > > Could we possibly consider putting reliable messaging into the 
> > > > > security bucket?
> > > >
> > > > I don't think so.  There's no security primitives that would fit 
> > > > the bill of reliable messaging (RM), which I sometimes 
> > > > characterize as "layer-7 TCP" where a session between two 
> > > > endpoints may span over several time-serialized connections, 
> > > > disconnections, reconnections.
> > > > AG006 may include securing RM, but not RM per se.
> > > >
> > > > While at it, let me mention that if you want to include RM in 
> > > > WS-Arch, then you may as well not leave out transaction 
> > > > processing.
> > > >
> > > > [snip]
> > > > > it is a natural
> > > > > progression of thought:  "I'm worried about who the author of 
> > > > > the message is, whether it is distorted, and that IT ACTUALLY 
> > > > > GETS THERE".
> > > >
> > > > ^^^^^^^^^^^^^^^^^^^^^^ There no
> > > > security primitives that can guarantee data arrival.
> > > >
> > > > Joe Hui
> > > > Exodus, a Cable & Wireless service
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Received on Wednesday, 13 March 2002 14:04:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:24:56 GMT