RE: Message Type Description

[David Burdett <david.burdett@Commerceone.com>]

Comments Inline.

-----Original Message-----
From: Prasad Yendluri [mailto:pyendluri@vitria.com]
Sent: Friday, April 14, 2000 3:45 PM
Cc: ebXML-Transport@lists.oasis-open.org
Subject: Re: Message Type Description


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.   


>>>I agree that conventionally there is the Transport layer and an
Application layer. However, I thin there is benefit in have a middle
"message handling" layer between the Transport and Application layer as it
can then remove the for each application to carry out the same work.
Examples of what the message handling layer can do include: reliable
messaging (e.g. once only message delivery), proof of receipt, recovery from
failure, authentication of sender.<<< 


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".  
>>>The message may be invalid, but, the response address part of the message
is OK. By *just* getting the response addresses first (if they are there)
then you can report to error to the correct destination. You can also do a
simple serial (or SAX) scan of the header to find the response addresses.
The other alternatives when an error occurs are: do nothing; send an error
back to the sender (which only works if the message is synchronous)<<<
    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?  >>>You may be able to correctly identify the
error return location but detect other errors in the message while doing it.
This is error is designed to let you report the other errors.<<< 
    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?  >>>You'd need find the
MessageId of the message<<< How does this provide the evidence?  >>>The
response would probably also need to be digitally signed. In many ways this
is a "mail room" receipt of the message rather than a
business/functional/application level receipt<<<
    d. Does it make sense to "Save" messages that may not be structurally
sound, as that check is done later?  >>>It dependes on whether you want to
report a single error or multiple errors<<<. 
    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").  >>>It depends on your definition of what the
message ack means. As currently defined it means: "I've got it, I haven't
fully checked it yet, but I won't lose it". The benefit is that on some
systems, fully checking the message might take hours or longer as it has to
go through a legacy batch system.<<< 


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. >>> What you suggest is what I was thinking before the F2F
in Dallas last week. Perhaps we should review it some more<<< 
    b. Are authentication and authorization checks performed in  "Check
PayLoad" stage?  >>>It dependes, if authentication is done via signatures in
an ebXML standard way, then it could be done by the Message handling
layer<<<  


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?  >>>Yes. But ... 1. if the message is signed you can check that
the data has not changed, and 2. you can set policies (contract) between
parties that does not allow response message destinations to change.<<< 


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.  >>>One way of doing reliable
messaging is to say that if you send a request and don't get a response
within the anticipated time, then resend the message. The Message Handling
layer can do this by examining the MessageType and making a note of the
MessageId as it is sending it. However, if a Cancel is not made visible at
the Message Handling layer, then the Message Handling level may still be
expecting a response when none will come. On the question of security, I
think it is just as insecure to send a normal request since really it can be
just as easily be spoofed as a cancel message. Either way you need to use
signatures or security of some kind to stop this type of attack. I also
don't understand what the legal problems are.<<< 


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?  >>>I would anticipate that the
Business Process layer would specify whether or not acknowledgements are
required.<<<  


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)?
>>>I would normally expect the receiver of a message to specify the timeouts
that apply. However allowing to put the information on the header is a way
of the sender requesting a faster response if the receiver allows it.<<< 


SOME REALLY GOOD QUESTIONS 


DAVID  


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