Re: [Requirements] Non-requirement for MEPs

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
> ----------------------------------------------------------------------- 
> -----------------------------------
>