Re: Straw-man Proposal for our mission statement

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.

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.

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.

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.

Received on Monday, 12 May 2003 13:47:32 UTC