RE: D-AG0017 - Business Infrastructure

I do not know the answers to ANY of your questions.  However, I would be
very unhappy to see some sort of dichotomy between "business" and "semantic
web".  It seems to me that business functions are just another use for the
web.  As with any user community, there may be special needs and a
particular point of view, particularly about priorities.
 
-----Original Message-----
From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com] 
Sent: Thursday, March 14, 2002 6:10 PM
To: 'Cutler, Roger (RogerCutler)'; www-ws-arch@w3.org
Subject: RE: D-AG0017 - Business Infrastructure


Business infrastructure is *much* broader than SOAP extensions (which covers
just the message layer extensions/attributes. SOAP extensions (or SOAP
bubbles as somebody referred to it)
are pieces of technology that don't solve any particular business problem by
themselves.
Are there use cases within XMLP that help identify the basic interoperable
features in SOAP extensions? 
Do these use cases solve business problems? 
Can these features be useful for Semantic Web community?
Are there core features of SOAP extensions that apply to both business and
semantic communities?
Or should we split WS-A into WS-A-B  (Business) and WS-A-SW (Semantic Web)?
Is it even important to ask these questions?
 
Sorry to bother you with so many questions. I  am hoping somebody will know
the answers.
 
Cheers,
-Suresh

-----Original Message-----
From: Cutler, Roger (RogerCutler) [mailto:RogerCutler@ChevronTexaco.com]
Sent: Thursday, March 14, 2002 3:58 PM
To: www-ws-arch@w3.org
Subject: D-AG0017 - Business Infrastructure



OK, here's a shot at it.  I am calling this "Business Infrastructure"
because that is what is motivating me to care about these issues, but
perhaps that is not appropriate?  Anne may have suggested "SOAP Extensions"?


The reference architecture should provide guidance for the development 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? 
Is there a standard way to uniquely identify and order messages involved
with a web service? 

Note that some of these issues are being addressed, at least to some degree,
in the OASIS ebXML Messaging Services TC (
<http://www.oasis-open.org/committees/ebxml-msg/>
http://www.oasis-open.org/committees/ebxml-msg/).  There may be some
questions, however, about whether this work conforms to the W3C vision of
web architecture (Mark Baker has indicated this but has not specified
exactly what the issues are) or of completeness.

Following is a more detailed statement that I posted previously of what I
see as the drivers: 

	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.