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

ebXML is not doing ANYTHING!  It does not exist any more.

OASIS and UN/CEFACT have taken on some of the carryons from ebXML.  I do not
believe that this includes reliable messaging, or routing/intermediaries,
although as covered in other recent notes it does seem to include
transactions.  About transactions, however, we are told that there are
serious inconsistencies with web architecture as defined by W3C.  Should
not, then, the W3C become involved in trying to iron out those
inconsistencies?  Is it not plausible that the subject would reasonably be
part of web services architecture even if another group (OASIS) is working
on it?

-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] 
Sent: Thursday, March 14, 2002 12:08 PM
To: 'Anne Thomas Manes'; Munter, Joel D; www-ws-arch@w3.org
Subject: RE: Reliable Messaging and Business Requirements - [Was DAG006]


Anne,

I empathize with the sentiment that it took 9 months for the WS Activity to
take shape after the WS workshop in April. But, on the bright side, it did
happen!

Re: SOAP header extensions, if those extensions are for supporting B2B
commerce/transactions, since ebXML is doing the best it can on that side, I
would not rush into creating new working groups - rather liaison with ebXML
TCs. If there are requirements that ebXML is not stated to cover, then
perhaps we should consider those, and at least think about those.

On the other hand, if these extensions are sufficiently generic and can be
applied widely in other scenarios, some thoughts on what minimal extensions
would be appropriate. I am ambivalent about starting another WG for this
express purpose.

Cheers,
-Suresh


-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Thursday, March 14, 2002 11:47 AM
To: Munter, Joel D; www-ws-arch@w3.org
Subject: 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 13:37:26 UTC