- From: Jim Hendler <hendler@cs.umd.edu>
- Date: Tue, 13 May 2003 11:14:29 -0400
- To: Steve Ross-Talbot <steve@enigmatec.net>
- Cc: public-ws-chor@w3.org
At 10:21 +0100 5/13/03, Steve Ross-Talbot wrote: ><x-flowed>Jim, > >you make a good point and I admit to being deliberately vague about >what "validated" might mean. I think I would prefer to change that part >to the following: > >... whereby each participants involvement can be validated where >validated means checked for compatibility and verified for conformance >to the defined observable behaviour where possible .... > >Or something like that. I'm concerned at one level not to promise >things that are totally academic and not practicable and on the other >hand set a bar high enough that we have to stretch to get there. It's a >case of what could we do today vs what could we reasonably be expected >to do tomorrow and ensuring that success can be measured in either >dimension. I think this is a helpful change - what I was really getting at was that we need some way to make it clear we are talking about "online" behavior, rather than off. What I mean is that when I order a part from Daniel's company, I would want the choreography to have a validatible part where they promise to get me an "acknowledgement" - I'm not sure whether in the choreography it should say that that part will arrive at my lab three days later, but I would definitely not expect the choreography to contain some sort of statement that the "choreography inspector" will come to my lab three days later to validate the physical arrival of the book... I suspect no one here things of "validate" as referring to these "side effects" of the transaction, but I thought the mission/vision statements need to make that clear... > >So in a nutshell I want a mission statement that is achievable at one >end of the spectrum and visionary (but not out of reach) at the other >end and so would require a stretch. If we meet the minimum then we can >tick the initiative as being successfull and if we manage to stretch we >can look back and say wow! > >Cheers > >Steve T absolutely +1 to that goal! > >On Tuesday, May 13, 2003, at 12:21 am, Jim Hendler wrote: > >> >> 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 >> >> 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 Tuesday, 13 May 2003 11:15:14 UTC