RE: Technical Architecture TR&P section - REISSUE

[mwsachs@us.ibm.com]

Dick,

My responses embedded below, labelled MWS:

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Dick Brooks" <dick@8760.com> on 08/27/2000 05:43:41 PM

Please respond to <dick@8760.com>

To:   Martin W Sachs/Watson/IBM@IBMUS
cc:   "Ebxml" <ebxml-transport@lists.ebxml.org>
Subject:  RE: Technical Architecture TR&P section - REISSUE



Marty, see responses inline.

> Section 3.1, Messaging Service Description
>
> Line 5:  Please say that the abstract interface is between the message
> service and the application, with some mention of BP here.  In
> the abstract
> specifications sense, that interface is really between the messaging
> service spec and the BP spec.
>
> Line 33: Figure on page 3:  Should add a box at the top showing either
> application or BP or both
>

Section 3.1 of the technical architecture focuses on the messaging service
"piece of the puzzle" only. To see the "big picture" (including how BP fits
with the MS) one must put section 3.1 into context with the other "pieces".
Please take a look at the other sections of the TA document and see if that
clears up the two concerns above. Let me know if it doesn't and I'll notify
the TA folks. Thanks.

> Line 70: Please add a new bullet after the first bullet:  Routing of
> messages to the destination based on TPAId, ConversationId, and Action.
>

We tried to be somewhat abstract given that this is the architecture
document. Are TPAId, ConversationId and Action considered implementation
specifications of the Messaging Service or do you see these as
architectural
in nature?

MWS:  TPAId, ConversationID, and Action are routing information in the
message header,

>
> Line  90:  At-most-once delivery should be a sub-bullet under Reliable
> Delivery.  It is one of at least two possibilities.
>

I'll pass this suggestion to the TA group.

> Line 93:  Please put in a few words on the meaning of "fire and forget".
> IP could be viewed as a "fire and forget" since it is unacknowledged and
> totally unreliable.  I believe that your intent is a mode which is so
> reliable that it has no need for ACKs.

Actually fire'n'forget is meant to indicate a very reliable transport lies
beneath (e.g. MQSeries).
I'll ask the TA folks to add some words to clear this up. Thanks.

> Line 124 (figure on page 2):  Please add message routing and application
> support services to this figure.
>

Could you explain what is meant by "message routing" and "application
support services"? Does message routing refer to the function performed by
intermediaries or does this refer to the function performed by an
E-Comemrce
server when sending or receiving a message?

MWS:  In the context of the TRP specifications, message routing is the
process of getting a received message to the appropriate "port" (Action) at
the specific instance of the application (TPAId and ConversationId).

MWS: Application support services is probably a representation of services
that a product would provide as an adjunct to its message service
implementation.  Some services might be
   Checking TPA Sequencing Rules
   Conversion of action names in messages to actual method calls at the
   receiving party
   Business document generation and parsing
   Security
   Correlation of conversations
   Logging
   Recovery
On thinking about the above after I sent the posting, I think that from the
viewpoint of the set of ebXML specifications, application support services
probably should be viewed as part of the application layer.

Thanks,

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions