Re: Message Type Description

[Christopher Ferris <chris.ferris@east.sun.com>]

Prasad/All,
My comments below avec <CBF>.

Chris

Prasad writes:
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.

<CBF>
I tend to agree, although technically, there is a distinction between
the transport and message handling. One would be transport specific
SPI (SMTP, HTTP, FTP, whatever) versus the common processing
of all messages received over whichever transport layer.
</CBF>

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?

<CBF>
I think it does, but an Ack should be deferred until the message has
been validated.
</CBF>

    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").

<CBF>
No, but an Ack at the "transport" layer might be called for. I believe
that these are distinct from business level Acks.
</CBF>

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.

<CBF>
good question!
</CBF>

    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?

<CBF>
I favor an approach which has these captured in the TPA, not in
the messages themselves for this very reason as well as for keeping
the message size down.
</CBF>

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.

<CBF>
I'm with you on this one. This will lead to all sorts of complications!
This sort of thing needs to be explicitly called for in the business level
TPA. (eg. the processing message X may be cancelled at the
sender's request through the sending of message Y).
</CBF>

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?

<CBF>
Again, I would prefer the latter.
</CBF>

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

<CBF>
These too should be explicitly called for in the TPA.
</CBF>

That is all I have.

Thanks, Prasad.