RE: [Requirements] Non-requirement for MEPs

+1
David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Wednesday, March 19, 2003 3:55 AM
To: edwink@collaxa.com; '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, Edwin:

 

5a is a very interesting part of the choreography specification:

 

1)       one could argue that there is little difference at the choreography
specification level whether the response is positive or negative, the
choreography definition will have n paths associated with each response type
whether they are positive or negative. Probably the real difference is at
the business level whereby a negative message (out of widgets) could imply
that a commitment or a fulfillment cannot be made.

 

2)       there seem to be requirements in the real world for unsolicited
business exceptions whereby a given service component could send this type
of message at any point of the collaboration rather than just as part of a
response to a request. Typically this type of message exchange is harder to
model within the main flow of the choreography.

 

It there an agreement that all the other exceptions can be conveyed via the
use of "fixed format" messages that could be part of the specification (e.g.
at the message exchange pattern level)?

 

JJ-

 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Edwin Khodabakchian
Sent: Wednesday, March 19, 2003 12:28 AM
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,

 

This list covers all the use cases I have seen. 

 

One of the other pieces of feedback we have been collecting is that there is
a gap between how 5a process errors are defined and managed based on if the
interaction is synchronous or asynchronous. 

 

In BPEL,

Synchronous: <invoke>, fault and <faultHandler> (explicit error semantic)

Asynchronous: <pick> and normal containers (implicit error semantic).

 

Although this is not a hurdle for developers, it make management by
introspection more difficult.

 

I am not sure that there is anything that can be done here but I think that
the lesson here is that looking at operation tasks is an important aspect of
creating a viable standard.

 

Edwin

 

-----Original Message-----
From: public-ws-chor-request@w3.org [mailto:public-ws-chor-request@w3.org]
On Behalf Of Burdett, David
Sent: Tuesday, March 18, 2003 12:36 PM
To: edwink@collaxa.com; '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

Edwin

 

Good points. Here's my complete "stack" of different types of errors that
can occur - they all have an impact on choreographies ...

 

1. Transmission error. - The message was never sent. This is a send side
error, the rest below are receive side.

2. Delivery Failure - The message was sent but was (probably) not received -
this is the WS-RM domain

3. Message format error - the components of the message were not validly
constructed. If this is really bad, you might not be able to work out who
sent the message and therefore can't send an error back.

4. Message Content structure error. These are errors where one of the parts
of the message is not valid. This splits into several different lower level
variations:

  a) Not well formed - e.g it's not well formed XML, or its a MS Word doc
that can't be read

  b) Invalid - it's well formed but does not conform to its rules, e.g it
does not conform to the schema

  c) Integrity error - for example the total amount on the Invoice does not
equal the sum of the individual line items

  d) Reference error - for example the part number on a line item is not
recognized by the receiver

5. Process error. This also has a number of lower level variations:

  a) Process failure. For example, you wanted to order 10 widgets, but they
were out of stock. You could argue this is a normal business response and
not actually an error.

  b) Process abort. For some reason the processing of the message started
but crashed part way through. The resultant state may not be known.

 

However from a choreography perspective you can simplify this to:

1. Transmission error - 1 above

2. Delivery failure - 2 above

3. Message not processed (3 & 4 above)

4. Process Failure - 5a above

5. Process Abort - 5b above

 

Thoughts?

 

David

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