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

+1

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Vinoski, Stephen
> Sent: Thursday, March 14, 2002 4:36 PM
> To: Anne Thomas Manes
> Cc: www-ws-arch@w3.org
> Subject: RE: Reliable Messaging and Business Requirements - [Was DAG006]
> 
> 
> I agree with Anne's second paragraph, but with respect to the first, we
> certainly have customers who today rely on SOAP with Attachments. IMO we
> therefore can't really limit it one way or another, which I believe is
> in essence Anne's point, and of course there's also the issue of DIME as
> well.
> 
> --steve
> 
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:anne@manes.net]
> > Sent: Thursday, March 14, 2002 3:30 PM
> > To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
> > Subject: RE: Reliable Messaging and Business Requirements - 
> > [Was DAG006]
> > 
> > 
> > The challenge I see with referencing the ebXML MS is that it 
> > only supports
> > SOAP messaging with attachments (the payload always goes as 
> > an attachment
> > and never in the SOAP Body). From my experience, lots of 
> > people are using
> > SOAP RPC, and even document style messages usually include 
> > the payload in
> > the SOAP Body.
> > 
> > Perhaps we might want to coordinate with the OASIS ebXML MS 
> > team, but I
> > don't think we can just refer to ebXML MS as the way to 
> > support reliability,
> > security, routing, and transactions.
> > 
> > Anne
> > 
> > > -----Original Message-----
> > > From: www-ws-arch-request@w3.org 
> > [mailto:www-ws-arch-request@w3.org]On
> > > Behalf Of Cutler, Roger (RogerCutler)
> > > Sent: Thursday, March 14, 2002 1:37 PM
> > > To: 'Damodaran, Suresh'; 'Anne Thomas Manes'; Munter, Joel D;
> > > www-ws-arch@w3.org
> > > Subject: 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 16:46:18 UTC