Prasad's comments

[john_ibbotson@uk.ibm.com]

Prasad,
I've added my comments following your points below.

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.
<JI> I agree that Transport is an overloaded term but I do think there are
more layers than simply transport (in the HTTP, SMTP sense) and
application. Whether those layers are as cleanly separated in the current
document as they could be is a point for discussion. I certainly believe
that there is a role for an ebXML services layer between the low level
transport and the ultimate business application simply because defining
what services can be reused in that layer removes the need for applications
to repeatedly implement their own versions which are (nearly) similar. For
an ebXML layer to be efficient it must be able to unpack (de-envelope,
unwrap ....) the message and have well known places and structures to look
for information. Assuming that, I'll try and address your other points
using references to David's "Header Version April 12, 2000" document header
elements. </JI>


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


<JI> The message is unwrapped and the addresses are extracted from the
Message Routing Info Response Addresses optional fields</JI>
    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?


<JI> We should expect some default addresses for error conditions. These
are not part of the sent message but could be set up as part of the
business relationship between B2B partners. </JI>
    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?


<JI> We do assume the message has been looked into at this time</JI>
    d. Does it make sense to "Save" messages that may not be structurally
sound, as that check is done later?


<JI> We have to save the message before sending an Acknowledgement to the
sender. As you say, checking the message occurs later so we do not want the
sender to wait around for the checking. We're simply saying that the
message has arrived and is hardened. This is required from a
non-repudiation point of view </JI>
    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").


<JI> That's what the Acknowledgement from "Save Message" is for.</JI>


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.


<JI> If we take assume the Mailroom analogy for this from the Orlando
meeting, the Transport and Message layers in the diagram are doing the
mailroom checks. That the message is structurally OK by checking at the
MIME/Header?Manifest level. The mailroom may then distribute the different
payloads to different backend applications which then check the business
content of the payload according to their own rules and generate
acknowledgements accordingly. It does allow the ebXML services to provide a
common amount of checking which takes the burden off the applications.
</JI>
    b. Are authentication and authorization checks performed in  "Check
PayLoad" stage?


<JI>Some of the checks for receipt of the message will be carried out by
the ebXML services. However, that doesn't stop the applications carrying
out their own checks at the business process level.</JI>


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?


<JI> Not sure on this one David ????????</JI>


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.


<JI> Cancel is an interesting one and chould lead to some usefull
discussions :-) One approach says that we could include it as a
semantically separate type of message which an ebXML compliant service can
support. Another approach yould be to say that it is only valid as part of
a higher level business process and therefore it is up to the end
application (given a payload containing Cancel information) to process. In
the second case, it is simply a Request/Response type of message at the
ebXML layer. Comments ??????????? </JI>


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?


<JI> This (and point 7. below) take the discussions into a separate
business process choreography discussion. My own point of view is that the
business process choreography is a separate issue which the message
structures we are defining are an intimate part. Hence my interest in
trading partner agreements which provide such a definition. </JI>


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



Hope this provides some background to the document,


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