W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2002

RE: Business Goals and CSFs / F2F topics

From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
Date: Fri, 30 Aug 2002 15:02:04 -0700
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E2EAECE@bocnte2k3.boc.chevrontexaco.net>
To: "'Francis McCabe'" <fgm@fla.fujitsu.com>, www-ws-arch@w3.org
cc: "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>

I am honestly very confused by these goals that you are presenting as "needs
of businesses".  The reason for my confusion is that just about nothing you
mention is on the list of "must haves" or even "very desirables" of the
business people with whom I am familiar.  This leads me to wonder who you
perceive the stakeholders to be here.  I'm perfectly willing to entertain
the idea that "business" is a big elephant and I'm viewing a different
portion of the animal. But if that's the case, I'd really like to understand
what portion of "business" you are looking at.

My understanding of business needs is reflected in the EDI-like usage case
that I contributed to the WG -- and also in D-AC017, for that matter.  I
believe that these reflect accurately the dominant concerns that I am aware
of in my corner of the business community.  That is, there is already
significant practical experience using EDI, and the expectation is very
strongly that web services should be able to support the practical needs of
this community as defined by real experience. These needs are prosaic, well
understood, and in my view not trivial in a web environment.  There is also
a huge potential market that is waiting for reliable solutions to these

The priorities of the business people with whom I am familiar are predicated
to a great extent on the present reality of the business landscape.  For
example, most businesses have sunk a very considerable investment into back
office systems which are different in different companies, and there is very
little perceived benefit in replacing these back office systems with
standards-based web solutions.  This means that functions which are commonly
handled by back office systems tend, in my observation, to be of little
interest to the business community as web service functions.  Basic
messaging requirements, such as security, reliable messaging and
"reconciliation" (as discussed in the EDI-like usage case) are, however, of
tremendous concern.  My observation is that the business community requires
the bread and butter before the caviar -- and that it is QUITE skeptical of
the ability of web services, or any web-based architecture, to deliver the
bread and butter reliably.

I would be very happy to make a brief presentation at the F2F on what I see
as dominant concerns for business use of web services if people think that
would be useful.

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: Friday, August 30, 2002 3:09 PM
To: www-ws-arch@w3.org
Subject: Business Goals and CSFs

Even though its still August, I felt that it is appropriate and timely 
to publish these proposals for the requirements document.

They are similar in tone to some goals and CSFs that I sent on the list 
a couple of months ago; but have been considerably cleaned up on and 
tightened up.

IMPORTANT: This message `counts as' a request for discussion and 
closure also. It may be that final closure will have to wait for the 

We have one new goal, that captures the fundamental intention to be 
business friendly:


AG007 Business Friendly
The Web Services Architecture must provide a framework which reflects 
the evolving needs of businesses as they conduct business using Web 
Critical success factors:
AC023 Peer-to-Peer Interoperability
AC024 Multi-party Interactions
AC025 Service Re-use
AC026 Semantic Descriptions
AC027 Relationships

There may be other CSFs that relate to this goal, I simply list the new 

The first new CSF relates to peer-to-peer interoperability: AC023
Peer-to-Peer Interoperability The Web Services Architecture must support
interoperability between 
peers as well as client-server interactions
AR023.1: The WSA must permit a rich range of MEPs, including patterns 
such as request-response, publish-subscribe, forwarding, proxy-ing and 
event notification
AR023.2: It must be possible for peers to have persistent identities 
that are distinguished from any other attribute - such as their 
location or type
AR023.3: It must be possible for peers to interact without the required 
presence of any third party intermediary
AR023.4: It must be possible for peers to discover each other

The fundamental issue here is that business is naturally a peer-to-peer 
kind of activity and that the WSA must support the way business is 
conducted rather than force everything into a client-server 

AC024 Multi-Party Interactions
Web Services must be able to support N party interactions, such as 
auctions, escrow services, proxy services, broker services
AR024.1: It must be possible to quote, verbatim and modified, messages 
within top-level messages, to an arbitrary depth
AR024.2: It must be possible for web services to support interactions 
where one of more parties of the interaction are anonymous
AR024.3: It must be possible to express multiple receivers and to 
express 'wait' points in service orchestration

This CSF and its associated requirements reflects the fact that 
business is not always 1-1 but often involves many parties.


AC025 Service Re-use
The Web Services Architecture must provide a framework for the 
effective re-use and composition of services
AC025.1: It must be possible to compose services dynamically, on the 
fly, as well as statically
AR025.2: The service composition model must permit the expression of 
and the evolution of composed relationships
AR025.3: It must be possible to express sequencing and nesting of 
services, and the flow of information between services
AR025.4: It must be possible for third parties to verify performance of 
services (where performance includes results as well as timeliness)

This CSF is an attempt to crystallize some of the composability 
requirements which are currently somewhat scattered.

AC026 Semantic Descriptions
It must be possible to characterize a Web Service so that its semantics 
are clear to an automatic system
AR026.1: The Web Services Architecture should be aligned, where 
appropriate and possible with the Semantic Web. This may require some 
modification of current technology choices. (This is a version of 
AR026.2: It must be possible to publish references to an ontology in a 
Web Service description
AR026.3: It must be possible to characterize a service using purely 
publicly observable semantics:
The semantic description of a Web Service should rely on public 
explicit agreements
The descriptions should be based purely on observable characteristics 
of services and principals

This is a critical CSF; since it targets directly the needs of an 
automatic system as opposed a human guided system. Chris Ferris has 
talked about the difference that a human can make when navigating the 
web; this CSF focuses on what is needed to permit automatic navigation.


AC027 Relationships
It must be possible to model the identities, roles and relationships of 
principals involved in a Web Service
AR027.1: There must be proper separation of roles and identity in 
AR027.2.1 Choreography and orchestration must be role-oriented AR027.2.2 It
should be possible to identify and authenticate a 
principal acting in a given role
AR027.2: Account for the many different time-scales over which 
relationships must be supported:
AR027.3.1 It must be possible for relationships to persist across 
changes in the environment
AR027.3.2 Temporal characteristics of relationships must be explicitly 
documented in Web Service descriptions

This too is a critical CSF (is that tautologous?) since it targets the 
foundations for security; which is itself critical to foster confidence 
in the use of web services.
Received on Friday, 30 August 2002 18:03:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:37 UTC