- From: <david.burdett@commerceone.com>
- Date: Tue, 20 Jul 2004 10:05:44 -0700
- To: <steve@enigmatec.net>, <jeanjadu@Attachmate.com>
- Cc: <yoshida@doc.ic.ac.uk>, <tony.fletcher@choreology.com>, <kohei@dcs.qmul.ac.uk>, <gary@enigmatec.net>, <public-ws-chor@w3.org>, <Robin.Milner@cl.cam.ac.uk>
- Message-ID: <975D1A379F57F34995874608D9FE8C915FDA23@C1SCAMSG05.commerceone.com>
Steve
Apart from determining what "standard signals" are required, I think it is useful, because they will also be generally applicable, to think about what could go wrong when sending a message as these errors could affect the behavior of the choreogrpahy. Here's a list that I've developed in the past that describes some (I'm sure they're not all) of the errors that could occur.
Comments welcome.
David
PS. Do we want to develop a similar list for standard signals?
=============================================
STANDARD ERROR LIST
In the table below:
* Level is an arbitrary number that roughly indicates when an error is likely to occur. Low numbers would start early in the process of sending a message, higher numbers later.
* Name is a description for a set of related errors.
* Response Msg Required. If set to "yes" then the only way the sender of a message can discover that the problem has occurred, is if the recipient of the message returns a message that indicates the error.
* Examples. These are specific examples of the different types of errors that can be received.
Level Name
Response Msg Required
Example(s)
1. Send Error No
1. Internet connection not available
2. MOM (e.g. Websphere MQ) channel not available
2. Timeout Error No
1. HTTP Response not received within required time. Note that the HTTP Post/Put may still have been received and processed
2. Message sent but acknowledgement message not received within required time
3. Message sent but business response message not received within required time
4. Acknowledgement message received but after timeout triggered
5. Business response received but after timeout triggered
6. Message received with an "expiry date" before the current date
3. Addressing Error Yes
1. Destination URL not available, or other HTTP server failure
2. Address information in a SOAP header not recognized or invalid
4. Envelope Error Yes Message sent but message envelope (e.g. MIME/SOAP) is malformed or in error
5. Sequence Error Yes
1. Set of numbered messages sent out of sequence. Can be recoverable if out of sequence messages received within buffer capacity.
2. One or more messages in a set of numbered messages not received, or at least not within buffer capacity.
6. Security Error Yes
1. HTTPS security negotiation failed
2. Message received but digital signature invalid
3. Message received but could not be decrypted
4. Message received, but sender not authenticated, e.g. user id, or certificate not recognized
5. Message received, but not authorized, e.g. sender recognized but not authorized to send such a message
7. Message Structure Error Yes
1. Required Parts of a message are missing, e.g. a JPEG as an attachment to an Order
2. Message contains parts that should not be there
3. Messages parts in the wrong place, e.g. in an Attachment rather than the SOAP body
8. Document Error Yes
1. Document does not conform to its schema or other structure definition
2. Content of elements/attributes do not conform to rules, e.g. is not within a enumeration, is out of range, etc.
3. Data in the document is inconsistent. For example, sum of line item amounts does not agree with the Order total
4. Data in the document is inconsistent with data stored elsewhere, e.g. Product Code invalid, Order No on a Change Order not recognized
9. Choreography Error Yes A correct document has been received but the message does not occur in the sequence defined by the choreography definition
10. Process Error Yes
1. Data is not acceptable for business reasons, e.g. total Order Value over limit so requires a different process to be followed
2. Process that was handling a message failed
-----Original Message-----
From: Steve Ross-Talbot [mailto:steve@enigmatec.net]
Sent: Tuesday, July 20, 2004 9:27 AM
To: Jean-Jacques Dubray
Cc: yoshida@doc.ic.ac.uk; tony.fletcher@choreology.com; Burdett, David; kohei@dcs.qmul.ac.uk; gary@enigmatec.net; public-ws-chor@w3.org; Robin.Milner@cl.cam.ac.uk
Subject: Re: State Alignment and Standard Signals
If we were to support signals of any sort, and I view this is named message types, then we need to be sure that they have general applicability in all domains of interest. If we cannot then we would need to consider an ontological approach in which the ontology of the domain is loaded and that is what provides the definitions of the named message types. This approach would obviate the need to define "built-in" named message types and retain all of the expressiveness that they provide but rooting it in the applicable domains.
Cheers
Steve T
On 19 Jul 2004, at 20:56, Jean-Jacques Dubray wrote:
David:
Yes, I think this is exactly what I am saying, the coupling is at the state level not at the message level (type of messages, choreography of the protocol, … all this is “context” specific (not just implementation specific)).
JJ-
From: david.burdett@commerceone.com [mailto:david.burdett@commerceone.com]
Sent: Monday, July 19, 2004 12:39 PM
To: Jean-Jacques Dubray; gary@enigmatec.net; tony.fletcher@choreology.com; public-ws-chor@w3.org
Cc: Robin.Milner@cl.cam.ac.uk; kohei@dcs.qmul.ac.uk; yoshida@doc.ic.ac.uk
Subject: RE: State Alignment and Standard Signals
JJ
You said ...
>>>
and leave the protocol detail to the implementation –
<JJ> This is unfortunately not possible, because there is a coupling between the states of the protocol and the choreography definition, otherwise it does not make any sense to use a protocol</JJ>
<<<
Couldn't you have different protocols that could result in the same end state? Also, I think that you could have different messages, with different representations, binding to transport protocols, etc, that had the same semantic.
David
-----Original Message-----
From: Jean-Jacques Dubray [mailto:jeanjadu@Attachmate.com]
Sent: Monday, July 19, 2004 10:27 AM
To: Gary Brown; Burdett, David; tony.fletcher@choreology.com; public-ws-chor@w3.org
Cc: Robin.Milner@cl.cam.ac.uk; kohei@dcs.qmul.ac.uk; yoshida@doc.ic.ac.uk
Subject: RE: State Alignment and Standard Signals
Gary:
I don’t think that the “re-use” is in this dimension. For instance, either a choreography requires state alignment or it does not. The proposal I made allows for the state alignment protocol to be changed independently of the choreography definition, therefore allowing it to be reused in widely different contexts (ebXML, RN, …). A particular protocol can be used, provided that the protocol you use yield the same “states” (this is the only level of coupling required between the protocol and the choreography).
From a business perspective, it would be nice to be able to simply specify the business protocol as,
<interaction request />
......
<interaction response />
OR
<interaction request-response /> - if synchronous
<JJ> I thought this was precisely the proposal I made, because you can define an interaction template with an embedded protocol, the resulting usage of that template looks exactly like the statements above. It simply means that a few more messages are exchanged as part of the interaction. Did you take a look at BPSS and the concept of Business Transaction and Business Transaction Activities (usage of a business transaction in a collaboration definition)? </JJ>
and leave the protocol detail to the implementation –
<JJ> This is unfortunately not possible, because there is a coupling between the states of the protocol and the choreography definition, otherwise it does not make any sense to use a protocol</JJ>
i.e. this information would then only be required by an endpoint generation tool, to ensure that the endpoint used the correct protocol, or an endpoint monitoring tool to ensure that it interprets the correct set of "on the wire" messages as an interaction.
The problem (you might reply) is that this does not enable us to do different paths depending on whether the acknowledgement failed, or the acceptance was negative. However, if we look at how a BPSS endpoint might react in this situation, possibly this could be viewed as a exception path in CDL? This may enable us to define the relevant alternate paths, without having to make the different stages of the protocol explicit in the choreography?
<JJ>The question is on what basis you take the decision to enter an exception path? Only a protocol failure can do that, hence the coupling with protocol states (not protocol message interchanges)</JJ>
Again, the proposal I made is for CDL not to define a specific protocol but rather allow us to define interaction templates that include a protocol message interchange and resulting states. Such choreography could then be used, say in a BPSS context, where the protocol specific messages are the BPSS signals bound to the choreography protocol states.
Jean-Jacques
----- Original Message -----
From: Jean-Jacques Dubray
To: Gary Brown ; david.burdett@commerceone.com ; tony.fletcher@choreology.com ; public-ws-chor@w3.org
Cc: Robin.Milner@cl.cam.ac.uk ; kohei@dcs.qmul.ac.uk ; yoshida@doc.ic.ac.uk
Sent: Friday, July 16, 2004 5:02 PM
Subject: RE: State Alignment and Standard Signals
This is how I would approach the problem.
I would create a construct called Protocol. A protocol is itself a choreography, and more precisely a choreography template. This choreography is of course performed between abstract roles (let’s call them initiating role and responding role).
Initiating Responding
--- Request ---> Abstract message
<---- Receipt --- (concrete) signal
<---- Acceptance--- (concrete) signal
<---- Response --- Abstract message
--- Receipt ---> (concrete) signal
--- Acceptance---> (concrete) signal
When this template is used, every abstract message must be associated to a concrete message.
In addition I should be able to associate “states” to this choreography, e.g.
-
RequestAccepted = positive request Acceptance signal received,
-
ResponseAccepted = positive Response Acceptance signal received.
“Positive” acceptance/response represents an XPath expression on a message.
In a choreography, I should be able to specify (apologies, I don’t know the syntax by heart):
<choreography … >
<interaction type=”procotol”>
<protocol ref=”myProtocol”>
<message name=”Request” type=”ProcessPO”/>
<message name=”Response” type=”AckPO”/>
<state name=”OrderProcessed” boundTo=”RequestAccepted”/>
<state name=”OrderAccepted” boundTo=”ResponseAccepted” conditionExpression=”//PO/@accepted=”true”/>
</protocol>
</interaction>
<choice>
<switch value=”OrderAccepted”>
<case value=”true”>
<interaction type=”Request/Response”>
… process payment …
</interaction>
</case>
<case value=”false”>
… choreography ends …
</case>
</switch>
</choice>
</choregraphy>
I promised David that I will make a formal proposal, I hope within the next couple of weeks. Is this kind of approach acceptable?
Jean-Jacques
From: Gary Brown [mailto:gary@enigmatec.net]
Sent: Friday, July 16, 2004 8:25 AM
To: Jean-Jacques Dubray; david.burdett@commerceone.com; tony.fletcher@choreology.com; public-ws-chor@w3.org
Cc: Robin.Milner@cl.cam.ac.uk; kohei@dcs.qmul.ac.uk; yoshida@doc.ic.ac.uk
Subject: Re: State Alignment and Standard Signals
Hi
Do you have an example of how the CDL would look in order to represent this state alignment (e.g. as you have described in your article), in such a manner that the interactions are protocol independent? Would you see a "state aligned" interaction only completing after the second (acceptance) signal in the BPSS case?
For example,
<interaction A->B />
would only be deemed to have completed once B had sent the acceptance message to A?
Curious to know how such a state alignment protocol could be modelled in CDL in an abstract manner that is decoupled from a particular binding........
Regards
Gary
Received on Tuesday, 20 July 2004 13:06:22 UTC