Re: [Requirements] Non-requirement for MEPs

I also agree and disagree with Assaf. Oops that's me ;-)

I do think there is utility in expressing various protocols, WS-RM (pick 
either one) not withstanding. However, I would like to avoid this 
discussion for two reasons:

1. Scope. The process calculus model can definitely achieve this task 
and quite trivially, but actually writing such MEPs is beyond the scope 
of this working group. However, it may be of interest to other working 
groups to use our deliverable for their work (hot potato?).

2. Simplicity. Describing a MEP using WS-Chor as part of some other 
specification (e.g. WS-MEP or WS-RM) is easy. It's also possible to 
break a MEP into activities then describe all these activities as part 
of the choreography. That only leads to really complicated 
choreographies and is not very useful. It also creates a dependency 
between the choreography and the protocol, since different protocols may 
use different MEPs.

So I would like to see WS-Chor be defined in terms of WSDL operations 
using the standard MEPs, and later on see WS-MEP be used to describe MEP 
that are used to implement these WSDL operations, some of which are 
abstract and some of which are protocol dependent, where WS-MEP* could 
easily be a derived subset of WS-Chor.

arkin

* In the unlikely event that this week will pass without the publication 
of yet another WS specification, perhaps we could convene during our 
lunch hour this Friday and publish WS-MEP.


Steve Ross-Talbot wrote:

> I agree and disagree with Assaf. Given the two year timeframe we need 
> to concentrate on core material. That is without doubt stating the 
> obvious. Therefore concentrating on, that is having a primary focus 
> on, Choreographing Web Services seems logical. However the fact that, 
> at the face to face at least, we may based our formal model around the 
> pi-calculus does lend itself to a wider scope.
>
> So I would also say that we should remain aware of the possible 
> extra-curricula use to which our work may be put.
>
> There seems to be a general movement towards this focus. I think only 
> a few people (myself included) have suggested that the work may be 
> more general. And I think it right to point this out. What has not 
> been said is that we change our focus. I think it is a recognition 
> that the work we embark upon has wider applicability and not a request 
> to change the focus.
>
> Cheers
>
> Steve T
>
> On Tuesday, March 18, 2003, at 06:44 AM, Burdett, David wrote:
>
>     I tend to agree with Assaf.
>      
>     I think that WS-Chor should focus on describing exchanges of
>     information that change the state of the process. For example if a
>     buyer sends an order to a supplier the message sent in return is
>     often an order response that indicates the extent to which the
>     supplier can (or can't) satisfy the order.
>      
>     However other "errors" can occur as a reysult of sending the order
>     which are detected at different levels in the stack:
>     1. Delivery errors - for example the message could not be
>     delivered. This is typically WS-RM function to detect
>     2. Message structure errors - this means tha the order could not
>     be unpacked from its (SOAP ) envelope at its destination - this is
>     a messaging error
>     3. Document structure errors - e.g. the structure of the document
>     was not valid. If bad enough this can prevent the generation of
>     the "business level" order response.
>      
>     Any of these errors can be sufficient to stop the conversation
>     (i.e. an instance of the choreography) from completing and
>     therefore the idea of an "error" as the result of sending a
>     message in a choreography is definitely part of the choreography.
>     However, how the error is detected, is not, IMO, particularly
>     relevant. So in this case this choreography should say, for
>     example ...
>      
>         "Send Order, from Buyer to Supplier"
>      
>     ... and the valid responses could be ...
>      
>        "Send "OrderError" from Supplier to Buyer", or
>        "Send "OrderResponse" from Supplier to Buyer.
>      
>     ... where "Order Error" could be any of the errors described above.
>      
>     Thoughts?
>      
>     David
>      
>
>     -----Original Message-----
>     *From:* Assaf Arkin [mailto:arkin@intalio.com]
>     *Sent:* Monday, March 17, 2003 5:38 PM
>     *To:* Patil, Sanjaykumar; Fletcher, Tony; ChBussler@aol.com;
>     steve@enigmatec.net; public-ws-chor@w3.org
>     *Subject:* RE: [Requirements] Non-requirement for MEPs
>
>     I'm going to do the "hot potato" thing and suggest that we leave
>     those issues that are not specific to choreography to other
>     working groups.
>      
>     For example, signals. How do you represent the fact that a message
>     must be acknowledged? Let's say WS-Chor comes up with a solution.
>     Can you use it with a service that it no used in the context of
>     any defined choreography? Or do we have one way to do it in
>     WS-Chor and another in WSD?
>      
>     What about WS-RM (1 and 2) which already deal with that issue. Do
>     we come up with yet another solution for sending/receiving acks?
>     Do we try to model their approach with WS-Chor? Did anyone
>     identify the need to use WS-Chor to define these acks?
>      
>     Try as I may I only found one sequence set that is parameterized
>     by the QoS requested. So we can exchange different sequences, but
>     it appears to me that just exchanging different QoS policies would
>     be easier (to write, validate and process). This seems more of a
>     problem for WS-Policy to provide the framework, and WSD to allow
>     these patterns to occur within the operation (so not to affect
>     it's abstract definition).
>      
>     arkin
>      
>
>     -----Original Message-----
>     *From:* public-ws-chor-request@w3.org
>     [mailto:public-ws-chor-request@w3.org]*On Behalf Of *Patil,
>     Sanjaykumar
>     *Sent:* Monday, March 17, 2003 11:05 AM
>     *To:* Fletcher, Tony; ChBussler@aol.com; steve@enigmatec.net;
>     public-ws-chor@w3.org
>     *Subject:* RE: [Requirements] Non-requirement for MEPs
>
>      
>     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) receiptAcknowledgementfrom '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_     (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
>     _To:_Tony.Fletcher@choreology.com_, _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_     (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
>     ----------------------------------------------------------------------------------------------------------
>
>
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 18 March 2003 04:18:33 UTC