RE: Straw-man Proposal for our mission statement

I like Steve's proposed mission statement but I would like to suggest some
wordsmithing:

"The mission of the W3C Web Services Choreography working group is to define
a language complementary to WSDL 1.2
   * that enables the description of the global view of a business process's
message choreography
   * such that it is possible to automatically validate a participant's
compliance with the message choreography required of their roles and
responsibilities in the business process via automated observation of their
messaging behavior."

In editing the mission statement I am only aware of having made three
substantive changes from the original:

I specified WSDL 1.2 rather than just WSDL
I tried to clarify what the terms automate and validate meant
I removed the reference to long/short live processes

The term 'compose' in the focus statement is causing me some discomfort. In
the BPEL sense 'composing a web service' means creating a new web service by
gluing together existing web services. The new web service will have its own
WSDL and so far as anyone interacting with it need be concerned it's a web
service like any other. I don't believe that use case should be in scope for
WS-Chor. While I could readily imagine WS-Chor providing a definition of the
message choreography used to enable the composed web service this is a far
cry from defining the actual logic needed to make the composed webservice
operate. That is a job for a programming language like BPEL. I would be
comfortable seeing the focus section removed entirely.


	Just my 2 euros,

		Yaron


> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Steve Ross-Talbot
> Sent: Monday, May 12, 2003 10:47 AM
> To: public-ws-chor@w3.org
> Subject: 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, 19 May 2003 18:44:32 UTC