Re: [Requirements] Non-requirement for MEPs

Yes, I think WSDL will provide only a subset of the MEPs you will need. 
The MEPs that WSDL is likely to provide are described here [1]. This is 
work in progress and should be considered as such.

BTW, I have been somewhat puzzled by messages in this thread saying the 
WG is not going to use MEPs or WSDL -when I expected it would. Is this 
the WG's opinion? Have I missed something?

Regards,

Jean-Jacques.

[1] 
<http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html>

Patil, Sanjaykumar wrote:
>  
> Agree, except that perhaps we should keep the two issues (supporting MEP 
> and supporting signals) separate.
>  
> Regarding MEP, I guess WSDL may not define all the MEPs for us, 
> specifically the ones that have additional semantics in the context 
> WS-choreography and which in the context of a single WSDL may map to one 
> of the pre-defined MEP. For example, a multi-cast MEP in the context of 
> a choreography that sends a request for quote to multiple parties may be 
> perceived as a simple notification MEP by the individual services of the 
> recipient parties.
>  
> Basically, I think, we can expect WSDL to define only a set of basic 
> MEPs, that are meaningful in the context of individual services. We, the 
> WS-chor group may define the additional complex MEPs and perhaps we 
> (along with the WSDL working group) should ensure that the the WS-chor 
> defined MEPs can be decomposed into the WSDL defined basic MEPs.
>  
> The issue of signals on the other hand is orthogonal to the WSDL defined 
> MEP. I guess, the signals will be defined by the WS-chor (and perhaps 
> some other specifications) and their transmittal can be mapped to a 
> pre-defined MEP. For example, the receival of a business message 
> and sending an acknowledgement signal can be mapped to a 
> request-response MEP.
>  
> On a side note, I would however like to raise an issue related to the 
> proper  scoping of the signals, whenever we define them. In some of the 
> previous business process related work (such as RosettaNet), signals 
> were used to represent simultaneously different meanings such as a 
> notification of the status of the delivery of message and also the 
> notification of the outcome of the business level content validation, 
> etc. Although it was not a blocker issue, this overloading of the 
> semantics of signals had kind of intermixed the different functional 
> layers, making it harder to provide for exceptional handling, etc.
>  
> We should perhaps identify clearly the signals that map to the WS 
> infrastructure stack such as the message delivery guarantee and the ones 
> that have application semantics such as business 
> content-validation. With this, we would also be able to reuse support 
> for the infrastructural signals from other specifications such as 
> WS-reliability (whatever and wherever this spec is today!), etc and 
> focus only on the business process level signals.
>  
> thanks,
> Sanjay Patil
> Distinguished Engineer
> sanjay.patil@iona.com
> -------------------------------------------------------
> IONA Technologies
> 2350 Mission College Blvd. Suite 650
> Santa Clara, CA 95054
> Tel: (408) 350 9619
> Fax: (408) 350 9501
> -------------------------------------------------------
> Making Software Work Together TM
> 
>     -----Original Message-----
>     *From:* Fletcher, Tony [mailto:Tony.Fletcher@choreology.com]
>     *Sent:* Monday, March 17, 2003 8:22 AM
>     *To:* ChBussler@aol.com; steve@enigmatec.net; public-ws-chor@w3.org
>     *Subject:* RE: [Requirements] Non-requirement for MEPs
> 
>     Dear Colleagues,
>      
>     I should make it clear that I was not thinking in terms of WSDL at
>     all.  (I guess that by its nature this group will have to map onto
>     WSDL as a 'lower' thing and so hopefully we can make use of WSDL's
>     basic MEPs - we may just need a simple 'send' and 'receive' at the
>     WSDL level (i.e. only 2 of its current 4 / 7 patterns) and we
>     compose those at will to make other patterns at the WS-Chor spec level).
>      
>     I was thinking in terms of the message pattern that is built into
>     BPSS.  This called a Business Transaction and is a Request ( only
>     mandatory part) from 'Requester' to 'Responder' followed by an
>     (optional) receiptAcknowledgement from 'Responder' to 'Requester' 
>     followed by an (optional) acceptenceAcknowledgement from 'Responder'
>     to 'Requester' followed by an (optional) Response from 'Responder'
>     to 'Requester'  followed by an (optional) receiptAcknowledgement
>     from 'Requester' to 'Responder' .  The Request and Response are
>     messages compiled by the driving application (/process).  The
>     Acknowledgements are pre-defined messages structures were only the
>     values are supplied on the fly.
>      
>     So in BPSS a Business Transaction (that which I was meaning as a
>     MEP) is the lowest layer of message sequencing.  Business
>     transactions can be composed into sets known as binary
>     collaborations (which will have a particular purpose) and can be
>     built into higher level binary collaborations (with a wider purpose)
>     and so on.  The highest layer of BPSS adds in multiple roles and the
>     sequencing of the binary collaborations into a complete multi role
>     collaboration.
>      
>     The folks who designed BPSS believe that the Business Transaction
>     message exchange pattern is all that is required to provide any
>     *business* message exchange and are thus prepared to live with its
>     restriction.  They may be correct, but personally I am not sure and
>     feel that it may be safer to allow the users of the WS-Chor language
>     to have freedom to design their own business message exchange patterns.
>      
>     I do think that specifying some standard 'messages' (the things that
>     BPSS calls signals) that users of the language can readily call up
>     and invoke would be useful and should be added to the requirements
>      
>     Best Regards     Tony
>     A M Fletcher
>      
>     Cohesions 1.0 (TM)
>      
>     Business transaction management software for application coordination
>      
>     Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>     Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44
>     (0) 7801 948219
>     tony.fletcher@choreology.com
>     <mailto:tony.fletcher@choreology.com>     (Home: amfletcher@iee.org)
> 
>         -----Original Message-----
>         *From:* public-ws-chor-request@w3.org
>         [mailto:public-ws-chor-request@w3.org] *On Behalf Of
>         *ChBussler@aol.com
>         *Sent:* 17 March 2003 15:38
>         *To:* steve@enigmatec.net; Fletcher, Tony; public-ws-chor@w3.org
>         *Cc:* ChBussler@aol.com
>         *Subject:* Re: [Requirements] Non-requirement for MEPs
> 
>         Hi,
> 
>         I think it is preferrable not to be restricted to WSDL, but also
>         allow for the inclusion of other definitions/mechanisms.
> 
>         Christoph
> 
>         In a message dated 3/17/03 7:04:24 AM Pacific Standard Time,
>         steve@enigmatec.net writes:
> 
> 
>>         Subj:*RE: [Requirements] Non-requirement for MEPs *
>>         Date:3/17/03 7:04:24 AM Pacific Standard Time
>>         From:steve@enigmatec.net <mailto:steve@enigmatec.net>
>>         To:Tony.Fletcher@choreology.com
>>         <mailto:Tony.Fletcher@choreology.com>, public-ws-chor@w3.org
>>         <mailto:public-ws-chor@w3.org>
>>         /Sent from the Internet /
>>
>>
>>
>>         Tony,
>>
>>         I think that there is an implication of this exclusion. It is
>>         that the choreography would be tied to WSDL based MEP's. If
>>         however we make MEP's part of the scope then we could extend
>>         the reach of the groups
>>         work to include non-WSDL based formalisms.
>>
>>         Cheers
>>
>>         Steve T
>>
>>>         -----Original Message-----
>>>         *From:* public-ws-chor-request@w3.org
>>>         [mailto:public-ws-chor-request@w3.org]*On Behalf Of
>>>         *Fletcher, Tony
>>>         *Sent:* 17 March 2003 13:26
>>>         *To:* public-ws-chor@w3.org
>>>         *Subject:* [Requirements] Non-requirement for MEPs
>>>
>>>
>>>         Dear Colleagues,
>>>
>>>         Just to put in a message what I stated at the inaugural F2F.
>>>
>>>         Non- requirement for MEPs:
>>>         It presently seems to me that it is a 'non-requirement' to
>>>         standards message exchange patterns (MEP) as part of the
>>>         WS-Chor work.  MEPs act as a constraint on what you can do,
>>>         so if one, or more, are defined we will have to be very sure
>>>         that users of the technique can live within that set of
>>>         constraints without having to 'jump through hoops' such as
>>>         extending the standard MEPs or having to chain them together
>>>         to get the pattern they actually need.
>>>
>>>         Requirements:
>>>         We certainly need to specify the 'construct'  for sending a
>>>         single message so that should be added to the requirements list.
>>>
>>>         We may also wish to standardise as part of the specification
>>>         (in a normative appendix perhaps) some standard business
>>>         messages, such as a generic error reporting message and an
>>>         acknowledgement message
>>>
>>>         Best Regards     Tony
>>>         A M Fletcher
>>>
>>>         Cohesions 1.0 (TM)
>>>
>>>         Business transaction management software for application
>>>         coordination
>>>
>>>         Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK
>>>         Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile:
>>>         +44 (0) 7801 948219
>>>         tony.fletcher@choreology.com
>>>         <mailto:tony.fletcher@choreology.com>     (Home:
>>>         amfletcher@iee.org)
>>>
>>>
>>
> 
> 
> 
>         ---------------------------------------------------------------------------------------------------------
>         Christoph Bussler
>         ChBussler@aol.com
>         hometown.aol.com/ChBussler/
>         www.google.com/search?q=bussler
>         www.google.com/search?hl=en&q=bussler&btnI=I%27m+Feeling+Lucky
>         ----------------------------------------------------------------------------------------------------------
>

Received on Tuesday, 18 March 2003 09:18:34 UTC