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

Back at the Web Services Workshop last April, we identified an immediate
need for the description group and the architecture group. (It only took 9
months to address this "immediate need".) We also discussed the need for an
number of additional groups to address the "higher layers of the stack" --
particularly reliability, security, transactions, and
routing/intermediaries. We agreed that these higher layers could wait a
little while, although I think that that "little while" has passed. I'm not
convinced that we need to have four more working groups, but I think it
might be useful to set up one working group that deals exclusively with
defining standard SOAP extensions (headers) to convey the information needed
by these higher layers. A number of SOAP implementations are starting to
implement these higher functions, and without standards, we'll break any
chance we have to enable interoperability.

There was also some discussion about addressing workflow, but I believe this
topic can still be put off for a "little while".

Anne

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Munter, Joel D
> Sent: Thursday, March 14, 2002 11:38 AM
> To: www-ws-arch@w3.org
> Subject: RE: Reliable Messaging and Business Requirements - [Was DAG006]
>
>
>
> I have to agree with Roger.  I just spoke with some folks here at
> Intel who
> are dealing with the support of systems that are handling M's of messages
> involving $B of transactions.  I am attempting to influence them to design
> their next evolution of solutions towards a completely standards-based
> stack.  This is difficult because the actual tools that they will
> use 1, 2,
> and 3 years out will be based on what we take on now.  If we
> ignore some of
> this, the tools may/will be limited, leading to the additional
> capabilities
> being designed in proprietary layers.  Today's eCommerce is with solutions
> that include combinations of proprietary and standards-based elements.
>
> Roger, could you be more specific with your suggestions.  What specific
> goals/requirements do you feel that we should be considering that we are
> not.  I also appreciate Anne's remarks below in this thread.
> What specific
> WG's could you conceive of that are not already operating?
>
> Joel
>
> -----Original Message-----
> From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@chevrontexaco.com]
> Sent: Wednesday, March 13, 2002 12:04 PM
> To: 'Anne Thomas Manes'; www-ws-arch@w3.org
> Subject: RE: Reliable Messaging and Business Requirements - [Was DAG006]
>
>
> 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 Thursday, 14 March 2002 12:46:41 UTC