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

OK, I'm going to give this a shot, but I don't expect it to be very good:

The reference architecture should provide guidance for developing the web
services infrastructure needed for implementing common business functions.  

Measurements:
Is there a standard mechanism for implementing reliable messaging?
Transaction processing?  Routing and intermediaries.

It seems to me that a working group is needed to cover essentially the same
ground as the ebXML Messaging Service specification,
http://www.oasis-open.org/committees/ebxml-msg/, in a manner properly
integrated with W3C architecture, plus other issues as indicated above.  It
also seems to me that if the OASIS TC is developing a sped that is seriously
incompatible with the W3C vision of web architecture that some working group
of the W3C should be doing something about trying to influence or coordinate
that.


-----Original Message-----
From: Munter, Joel D [mailto:joel.d.munter@intel.com] 
Sent: Thursday, March 14, 2002 10: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 13:47:48 UTC