- From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
- Date: Fri, 30 Aug 2002 15:02:04 -0700
- 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 problems. 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 f2f. 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 Services 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 ones. ---------------------- 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 straight-jacket ----------------- 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 D-AC009) 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 transactions: 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