- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Mon, 12 May 2003 19:21:52 -0400
- To: Steve Ross-Talbot <steve@enigmatec.net>, public-ws-chor@w3.org
At 18:46 +0100 5/12/03, Steve Ross-Talbot wrote: ><x-flowed> >Having seen Kick and Daniel's contributions and other comments, how >does this sound: > >Mission Statement >The mission of the W3C Web Services Choreography working group is to >define a language complementary to WSDL such that a common view (global >view) of business process interactions where roles and responsibilities >are clearly defined in a way that is automatable for each participant, >machine readable and in a manner whereby each participants involvement >can be validated and such that the life cycle of those interactions may >be short and/or long lived. with due respect, there's some sort of problem in the above from a parsing viewpoint - there seems to be something dangling clause-wise, other than that, I like it, except I'm a bit puzzled on the "validated" part - what does it mean that an involvement can be validated -- if I buy a book from WebServ1 does that mean I can check to see if the book arrived? > >Focus >Our focus will be that part of interaction that is externally visible >as opposed to any internal private behaviour. Our aim is to capture >this externally visible behaviour and to provide the means to compose >web services or support the composition of new web services from >existing web services such that these services can also provide an >externally visible behavioural description, can participate in further >composition and be validated against any subsequent interaction. > I like this >Approach >The approach that we intend to take is based on the capture of use >cases reflecting our mission statement and our focus in parallel with >CSF analysis to underpin the continued and future business relevance >of our efforts. > +1 here also >Thanks to Daniel and Nick upon who's contributions I have drawn. > >Cheers > >Steve T > > >On Friday, May 9, 2003, at 06:00 pm, Daniel_Austin@grainger.com wrote: > >> >> Hi, >> >> Here is a proposed mission statement for our working group. This >> is >> intended as a device to initiate discussion within the group. Our >> mission >> statement is the first step toward our CSF analysis. >> >> Please keep in mind that this statement is subject to change >> based on >> your input - it is by no means final or even close to what we will end >> up >> with. It's only Daniel's $0.02. >> >> Let's start this conversation by looking at your Charter [1]. The >> most relevant text I could find was this: >> >> <our charter wording="creative-ambiguity-style> >> The Web Services Choreography Working Group...is chartered to create >> the >> definition of a choreography, language(s) for describing a >> choreography, as >> well as the rules for composition of, and interaction among, such >> choreographed Web services. >> </our charter> >> >> At first blush, we might think that this is a good candidate for >> a >> mission statement. Modify the working a little and go...right? >> Unfortunately, I don't think so, for these three reasons: >> a) The text above makes a serious mistake in its direction to the >> group. >> The problem is what I call "presupposing the solution" and it's very >> common. Instead of posing a problem to be solved and saying "go forth >> and >> solve this problem" the text doesn't bother to explain the problem in >> any >> detail, but it tells us what the solution is already! This artifact- >> and >> deliverable-centric approach isn't likely to produce a good solution. >> >> b) It's begging the question - do we really need Yet Another Markup >> Language (YAML)? Sez who? To do what? What is the problem we want YAML >> to >> solve? The world doesn't necessarily need YAML; it needs a solution to >> the >> choreography problem, and while that may or may not result in YAML, we >> don't need to constrain ourselves by thinking about the problem in >> these >> terms. Not yet anyhow. >> >> c) It's circular - apparently we need a choreography language to >> choreograph Web Services. The logic isn't exactly clear. >> >> Based on this thinking, I decided that I'd like our mission >> statement >> for this group to have the following features: >> 1) It must clearly set forth the problem to be solved, including an >> indication of the overall scope of the problem. >> 2) It must not presuppose any solution in advance of the problem >> analysis. >> 3) It must be clear and in the imperative case, so that a reader can >> easily >> tell if the problem they have falls under our area of effort. >> 4) It must be contextually-driven, taking into account the current >> state of >> affairs as we know it. When the charter was originally written, we >> didn't >> know about the OASIS fiasco, for example, and our mission certainly >> has to >> take these things into account if we intend to accomplish our goals. >> 5) It has to be reasonable - the problem to be solved has to be scoped >> in a >> way that allows us to actually have a fighting chance of success. >> >> Let's ask ourselves "What problem is it that we are trying to >> solve?" >> If I had to put it simply, I would say that we want to solve the >> problem of >> interoperability among Web Services and other systems. We want all our >> Web >> Services to come home with report cards that say "plays well with >> others". >> That's it. But that's a huge issue...and we cannot (and aren't charged >> with) solving the whole problem, just a part of it. Which part? The >> part >> that concerns interactions between one or more Web Services and any >> external systems. More specifically, we are concerned with the rules >> and >> constraints that a Web Service has to follow in order to interoperate >> reliably with the rest of the world. We can exclude the definitions of >> the >> interface of any given Web Service - WSDL group is doing that. We can >> also >> exclude questions of underlying low-level protocols, because we want to >> leave this deliberately unspecified. The content and packaging of Web >> Services messages are largely being handled by the SOAP WG. That >> leaves us >> with a set of constraints on the sequencing (the ordering of events in >> time) and composition (the patterns of message and response among one >> or >> more Web Services and one or more external systems, which may or may >> not be >> other Web Services, human beings, non-Web Service services, or >> something >> else altogether. >> >> So...after saying that, here is what I've come up with. YMMV. >> >> <mission statement group = "ws-chor" type="CSF level 0"> >> The mission of the Web Services Choreography Working Group at W3C is to >> specify the means by which Web Services may collaborate with >> external >> systems, specifically in the composition of multiple services and the >> sequencing of messages among them. >> </mission statement> >> >> Regards, >> >> D- >> >> ************************************************* >> Dr. Daniel Austin >> Sr. Technical Architect / Architecture Team Lead >> daniel_austin@notes.grainger.com <----- Note change! >> 847 793 5044 >> Visit http://www.grainger.com >> >> "If I get a little money, I buy books. If there is anything left over, >> I >> buy clothing and food." >> -Erasmus >> >> >> This email is confidential and may be protected by legal privilege. If >> you are not the intended recipient, please do not copy or disclose >> its content but delete the email and contact the sender immediately. >> Whilst we run antivirus software on all internet emails we are not >> liable for any loss or damage. The recipient is advised to run their >> own antivirus software. >> > >This email is confidential and may be protected by legal privilege. >If you are not the intended recipient, please do not copy or >disclose its content but delete the email and contact the sender >immediately. Whilst we run antivirus software on all internet emails >we are not liable for any loss or damage. The recipient is advised >to run their own antivirus software. > ></x-flowed> -- Professor James Hendler hendler@cs.umd.edu Director, Semantic Web and Agent Technologies 301-405-2696 Maryland Information and Network Dynamics Lab. 301-405-6707 (Fax) Univ of Maryland, College Park, MD 20742 240-731-3822 (Cell) http://www.cs.umd.edu/users/hendler
Received on Monday, 12 May 2003 19:22:03 UTC