Re: Message Type Description

[Prasad Yendluri <pyendluri@vitria.com>]

Hi,

I have some comments listed below later but, since this document is also specifying the message acknowledgment /error-reporting / response semantics for different types of messages, I thought the work RosettaNet had done in this area might be of interest and serve as a reference to compare with.

I am sure David Burdett has seen the RosettaNet's document due to his active participation in the on going RosettaNet efforts also but, I am attaching it here to help put some of my comments in perspective. I will give a brief description RN way of doing first,  to help my comments later.

RosettaNet has two types of (positive) acknowledgment messages and four types of error messages (also called exceptions) in addition to the MessageResponse itself.

Acks:  MessageReceiptAcknowledgement        => Message is received O.K. and structurally sound
          MessageAcceptanceAcknowledgement  => Message Accepted for processing

Exceptions:  MessageReceiptException           => Message received but structurally bad
                   MessageAcceptanceException      => Message can not be accepted for processing
                   PerformanceException                 => Something went wrong during processing
                   GeneralException                         => General Catch all Error message

An incoming message goes through three types of validation. "Grammar/Structural/Schema" validation, "Message Sequence" Validation and "Business Content" Validation.

The "Grammar/Structural/Schema" validation step makes sure the MIME message is well formed, the XML header and payload parts are structurally sound (i.e. conform to the DTD etc.). If a message passes this validation step a "MessageReceiptAcknowledgement" is sent. If the message fails the validation (any part of it) and enough information regarding message originator is present, a -ve response (MessageReceiptException) is sent (pls see also attached message). If there isn't enough information we just timeout for a resend of the message. This step performs the "Sequence Validation" also, which is to make sure the message is in the correct sequence in a well-defined-sequnec of messages for a business process (PIP).

The "ContentValidation" validates the message-payload primarily for business content (e.g. a part number in a PO is a valid one). Additionally other checks like message authentication and autherization are performed in this step. If the message passes business content validation, a +ve "MessageAcceptanceAcknowledgement" is sent. If the validation fails a -ve "MessageAcceptanceException" is sent.

The "MessageReceiptAcknowledgement" is usually mandatory (specified in the PIP) whereas "MessageAcceptanceAcknowledgement" is optional.

Message is also saved after structural validation for non-repudiation of orgin and content.

Acknowledgements contain the digest of the original message for non-repudiation of recipt (both messages and acks can contain digital signatures)

Which acknowlegements are sent is predetermined by a business process (PIP) based on the business needs. For example a purchase order would need an acknowledgement whereas a notification of a new entry to product catalog may not.

There is also a Failure Notification mechanism to notify of errors that can not be notified through the usual channels. E.g. when the communication channel used to exchange the messages itself is down.

Based on the above here are my comments:

1. I am not sure if there really are three different Layers "Transport",  "Message" and "Application".  I see transport as the entity that is responsible for delivery of the message. Beyond that it is all "Application". Everything being done there seems to be application level processing. The terms might lead to confusion later on.

2.  Transport-Layer:
    a. How can one "Get Response Address(es)", withought unwrapping the message?
        This is defined to be done in the "Message Layer".
    b. If "Get Response Address(es)" fails, it shows "Error" going back. Where is this error sent since we don't
        know where to send?
    c. The "Acknowledgement" sent after the "Save Message" step is supposed to provide evidence to the sender of a message that it has been received. When we have not looked into the message yet, how do you identify the "particular" message received to the sender? How does this provide the evidence?
    d. Does it make sense to "Save" messages that may not be structurally sound, as that check is done later?
    e. Should  a non-repudiable positive Ack of receipt be provided to the originator prior to even making sure the message is structurally sound? (See first bullet in "Save").

3. Message-Layer and Application-Layer:
    a. Do we really need Acks that say Headers are O.K., PayLoad is O.k? Or does it make sense to tell if the whole message is structurally OK/Bad and BusinessConent is Good/Bad and provide information on what is Bad when things are Bad.
    b. Are authentication and authorization checks performed in  "Check PayLoad" stage?

4.  Would letting one specify where to send responses to, in the message header be a potential security hole? Can one generate traffic on someone else's site?

5. Do we really need a Cancel message? The sematics of it seem dangerous and subject to legal problems to me. Should it be just another "Request" message guided by business rules? For example can one send purchase order request and cancel it by simply sending a Cancel message? Timing of delays involved in receiving the acks etc. will be an issue.

6. Does it make sense to make the requesting of acknowledgements dynamic on a per message basis or do they need to be driven by the "Business Process" set forth by the "Business Process" Team?

7. Should the timeout value and the number of times a message is retried (in case an Ack does not comeback) be arbitrarily decided by the message sender or should they have well defined guidelines (again from Business Process)?

That is all I have.

Thanks, Prasad.

john_ibbotson@uk.ibm.com wrote:

Here is a copy of David's Message Type Description document as discussed in
yesterdays conference call.
(See attached file: ebXML Message Header Message Types v0-0.doc)
John

MQSeries Technical Strategy & Planning,
IBM UK Ltd, Hursley Park,
Winchester, SO21 2JN

Tel: +44 (0)1962 815188
Fax: +44 (0)1962 816898
Notes Id: John Ibbotson/UK/IBM
email: john_ibbotson@uk.ibm.com
 
 

ebXML Message Header Message Types v0-0.doc

ExceptionHandling.pdf