- From: Patil, Sanjaykumar <sanjay.patil@iona.com>
- Date: Tue, 18 Mar 2003 12:16:58 -0800
- To: <public-ws-chor@w3.org>
- Message-ID: <EA3ECEFACBE7674789ADE4D9E3ABB6B0104BA7@AMERWEST-EMS1.IONAGLOBAL.COM>
I wanted to add a bit more to the topic of signals. Specifically, I would like throw in my comment on why I think certain signals fall within the scope of our WG.
I am using the term "application" in my following description (basically to avoid interfering with the discussion of the terms "orchestration" and "choreography", which is happening on a parallel thread).
Let us say an application A sends an Order message X to application B.
Application B may then receive any of the several different types of responses :-
a> Order Acceptance or Order Denial, based on the business logic of application B and the content of the message X.
b> An error message indicating failure in structural or content validation of the message X by the application B.
c> An error message indicating failure in delivery of the message X to application B. Note that the protocol between the messaging agents for guaranteeing delivery may involve exchange of additional control messages that are hidden from the application layers.
Implicit in the above description is a model where the application B performs structural validation, content validation, etc. The model also assumes reliable messaging. In general, there are a set of such commonly useful functionalities, which if included in the model, the model needs to clearly support handling the positive and negative use cases invoking those functionalities.
A simplified abstract model of choreography may chose to ignore these functionalities and limit the model to only message exchange patterns and a set of flow constructs to coordinate the message exchanges. Arguably, such a language will have a wider applicability, as its design is not governed by any domain specific model/functionalities. However, in order to promote interoperability in a particular domain without, a first class support for the domain specific functionalities is necessary. For example, a business process language would support for message content validation, reliable messaging, security, content based routing, etc.
Supporting these functionalities does not necessarily mean fully defining all the bits here. With a modular design, it should be possible to use other specs. However, whether the choreography model itself defines the functionality or not, certain interfaces of the functionalities involves exchanging messages that are not defined by the application layer (signal messages!)
I guess we need to first pick and chose these functionalities and then in spelling out support for them, we may have to define/borrow the signal messages, etc.
As I said before, a simplest model may ignore all of these functionalities and therefore remain indifferent to the semantics of positive and negative messages defined by these functionalities. I am for including a certain minimum set of useful functionalities- the ones defined in the BPSS would be a good starting point.
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: Edwin Khodabakchian [mailto:edwink@collaxa.com]
Sent: Monday, March 17, 2003 11:19 PM
To: 'Burdett, David'; 'Assaf Arkin'; Patil, Sanjaykumar; 'Fletcher, Tony'; ChBussler@aol.com; steve@enigmatec.net; public-ws-chor@w3.org
Subject: RE: [Requirements] Non-requirement for MEPs
David,
If you look at BPEL today, you will see that there are 2 types of errors: (1) errors that are described as part of the WSDL of the service (business errors like Insuficient Credit, Invalid Part Number, etc...) and (2) errors that are caused by SOAP "remoting" stack (equivalent of RemoteException in Java like IO exception, version mismatch exception etc...).
Both kind of error need to be handled and manage by the orchestration layer and therefore defined in the choreography layer.
BPEL4WS v1 forgot to standardize (2) which is a problem with regard to portability across BPEL4WS engine.
Edwin
-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org] On Behalf Of Burdett, David
Sent: Monday, March 17, 2003 10:44 PM
To: 'Assaf Arkin'; Patil, Sanjaykumar; Fletcher, Tony; ChBussler@aol.com; steve@enigmatec.net; public-ws-chor@w3.org
Subject: RE: [Requirements] Non-requirement for MEPs
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) 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 (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
----------------------------------------------------------------------------------------------------------
Received on Tuesday, 18 March 2003 15:17:23 UTC