- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Fri, 30 Aug 2002 15:58:49 -0700
- To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>
- Cc: www-ws-arch@w3.org, "'Champion, Mike'" <Mike.Champion@SoftwareAG-USA.com>
Roger: I do appreciate your comments. I think that you are right, and yet ... For the most part, the CSFs associated with the business goal are assumed to build on top of what is already in the requirements document. However, with the uncertain state of D-AC017 I can see the need to add another CSF to AG007: secure and reliable communication. There are multiple time spans that the WSA must operate over: next week, next year and next decade. We have to survive all those time-scales to be effective. (I.e., we can't survive next year if we can't survive this week, and surviving this week is not a guarantee that we have enough to survive the next 5 years.) I do take issue with the caviar reference. There is no caviar in the goals & requirements. As a software engineer, I have seen too many times `weak technology' being applied to `hard problems' with the resulting waste of resources and disappointments. The back-office stove-pipe represents a legitimate challenge to web services; and one that is at least being taken seriously. (Today's hot technology is tomorrow's legacy system and next year's stove-pipe). I do not believe that it is necessary to replace back-office systems with shiny new web services. Rather, it may become very important to expose those systems to at least the Enterprise Intranet and the public Internet. There is not really that much difference between the Internet and the Intranet: consider the fate of Digital: it was competing with Compaq, then expected to be part of Compaq and then again part of HP. You can be sure that it takes longer to modify the software systems than signing the closure documents on the M&A. Even within one corporation, it is not unknown for sales representatives to be jealous of their data - to the point of refusing to share contact information with colleagues. A proper accounting of relationships would make it easier to handle that kind of rivalry. In summary, I would support adding a modified AC017 to AG007: D-AC017 The WSA must facilitate secure and reliable communication between peers. Frank McCabe On Friday, August 30, 2002, at 03:02 PM, Cutler, Roger (RogerCutler) wrote: > > 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 19:01:26 UTC