Re: Revised: Mission Statement

Given the heated discussion last night I must concur fully with Nick. 
Furthermore I think the correct approach is to take the work done at 
the F2F as the mission statement for this group and revisit it as and 
when we need to. We can add additional paragraphs clarifying the terms 
used (like semantics) and we can clarify the approach we are taking 
(i.e. being fairly practical and being delivery focussed on behalf of 
users of this technology and vendors who will build products based on 
this technology).

I humbly suggest that the mission statement  from the F2F is *only* 
tidied up and then put into the requirements document.

Cheers

Steve T

On Wednesday, July 2, 2003, at 03:40  am, Nickolas Kavantzas wrote:

>
> During the Chicago F2F, the W3C Choreography Group agreed and later 
> presented to the BPEL TC chairs its mission statement.
> This statement was presented by the BPEL TC chairs to the BPEL TC 
> members, in last week's BPEL TC conf-call.
>
> I think we may want to revisit it only when we have a better 
> understanding on the use cases and requirements, and have made some 
> progress on the harvesting fronts. Then questions like 'what semantics 
> of web services really means' will become more easier for us to > answer.
>
> "Cummins, Fred A" wrote:
>
>> Martin, et al,
>>
>> Try this approach:
>>
>> The mission of the W3C Web Services Choreography Working Group is to 
>> define
>> a choreography language for specification of the acceptable sequences 
>> of
>> exchange of messages by participants as they attempt to achieve a 
>> desired
>> business transaction.  The language must be expressed in XML.  A
>> choreography specification must complement the WSDL service 
>> specifications
>> of participants.  The choreography language should be able to express 
>> the
>> composition of more complex exchanges from simpler exchanges or 
>> subordinate
>> services.
>>
>> A choreography specification should enable each participant to 
>> determine
>> alternative message types that the participant may send as the 
>> exchange
>> progresses as well as the alternative message types it should be 
>> prepared to
>> receive from other participant(s).
>>
>> Fred
>>
>>> -----Original Message-----
>>> From: Martin Chapman [mailto:martin.chapman@oracle.com]
>>> Sent: Tuesday, July 01, 2003 3:28 PM
>>> To: Steve Ross-Talbot; Yaron Y. Goland
>>> Cc: public-ws-chor@w3.org
>>> Subject: RE: Revised: Mission Statement
>>>
>>>
>>>
>>> I thought by our discussion at the F2F that the "in the
>>> middle of all of
>>> them" is not what we are after, and in effect equates to the
>>> O word. So I
>>> would be interested in a better understanding of what
>>> composition means,
>>> given that this approach would not really support a wrapper
>>> wsdl. I'm not
>>> arguing against composition here, just asking for some clarity.
>>>
>>> Martin.
>>>
>>>> -----Original Message-----
>>>> From: public-ws-chor-request@w3.org
>>>> [mailto:public-ws-chor-request@w3.org]On Behalf Of Steve Ross-Talbot
>>>> Sent: Tuesday, July 01, 2003 10:52 AM
>>>> To: Yaron Y. Goland
>>>> Cc: public-ws-chor@w3.org
>>>> Subject: Re: Revised: Mission Statement
>>>>
>>>>
>>>>
>>>> +1
>>>>
>>>> Having some understanding of the achitecture of this thing
>>> that we are
>>>> doing
>>>> would help us stay on the same page.
>>>>
>>>> If we have a global model then where does it sit with
>>> respect to any N
>>>> participants.
>>>> Is it in the middle of all of them?
>>>> Is it at each one's site?
>>>> Is it a proxy sort of thing?
>>>> Is it a web service itself?
>>>>
>>>> What happens when we have two of them and we wish to compose?
>>>> What happens to the originals?
>>>> Where does the new one reside?
>>>>
>>>> I could go on. It would just be nice to get a common
>>> understanding. I
>>>> have mine
>>>> but I'm not sure it's the same as other peoples.
>>>>
>>>> Cheers
>>>>
>>>> Steve T
>>>>
>>>> On Tuesday, July 1, 2003, at 06:33  pm, Yaron Y. Goland wrote:
>>>>
>>>>>
>>>>> The key issue for me is what does it mean to compose a
>>> web service?
>>>>> Does
>>>>> this mean a new WSDL with some computer behind it that
>>> then forwards
>>>>> requests to existing web services? Does this mean that a client is
>>>>> expected
>>>>> to send messages to different WS who all have some kind of
>>>>> relationship with
>>>>> each other? It's so vague that I'm not sure what scope we would be
>>>>> signing
>>>>> up for.
>>>>>
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Monica J. Martin [mailto:monica.martin@sun.com]
>>>>>> Sent: Monday, June 30, 2003 2:22 PM
>>>>>> To: Yaron Y. Goland
>>>>>> Cc: Francis McCabe; Burdett, David; Bonneau, Richard;
>>> Assaf Arkin;
>>>>>> Jean-Jacques Dubray; public-ws-chor@w3.org
>>>>>> Subject: Re: Revised: Mission Statement
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Goland: I don't understand what the terms service composition
>>>>>> and service semantics
>>>>>>> mean. Could someone please define them? Monica provides
>>> a whole mess
>>>>>>> of
>>>>>>> definitions but having 10 definitions is just as bad as
>>> having none.
>>>>>>>
>>>>>>> mm1:  The definitions were a compilation on various types of
>>>>>> composition from the team.  We have not settled on one
>>>>>> definition, although I have provided one below that seems
>>>>>> appropriate here for consideration.  The definitions provided
>>>>>> span different areas of composition, and whether the team agrees
>>>>>> they are all the same, I can not speculate on.  I think it
>>>>>> evidences the multiple levels of discussions that are occurring.
>>>>>> Don't shoot the messenger. I would propose: **A service
>>>>>> composition is a composition of services that results in a new
>>>>>> service. The new service can be the combination of distinct parts
>>>>>> to form a whole of the same generic type. The web services could
>>>>>> be combined to achieve a specific goal.*  *This integrates parts
>>>>>> of the definitions of recursive, web service and choreography
>>>>>> composition.
>>>>>>>  Monica
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>
>
> 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 Wednesday, 2 July 2003 06:26:07 UTC