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