Comments on Overview and Requirementsm 5/26/00

[mwsachs@us.ibm.com]

COMMENTS ON TRP OVERVIEW & REQ, VER. 0-96, 26 MAY 2000


3. RELATIONSHIPS WITH OTHER EBXML ACTIVITIES

The paragraph beginning with line 40 seems to say that the message header
etc. could be rendered in more than one language.  How do two partners
come to agreement on which rendering to use? It could be via the
electronic TPA but how do they agree on what language to express the TPA
in?

     Why not just standardize on one language - XML?

     Too much flexibility of format could lead to a situation where a
     partner can't talk to the integration system repository, message
     policy repository, etc.  (How do a partner and the repository
     come to agreement on the language?)

5.1.16 MULTIPLE ROUND TRIP DOCUMENT EXCHANGE

The intermediate Exchange Messages are application to application. Why
is this in the province of TRP?  This should be a BP function.  The TRP's
only concern here should be to provide a conversation identifier that
ties the messages in the set to a single BP unit of business - and
perhaps to label a message as request, exchange, or response.  Is this
what is intended?

5.2.4  SUB-SERVICE CHOREOGRAPHY

Why are services, subservices, and subservice choreography defined in
TRP? These would seem to belong in BP.  The existence of these concepts
in TRP suggests that the Business Protocol section of the tpaML TPA
belongs in TRP.  Is this what is intended?

Are the subservices an abstraction of RosettaNet PIPs?

5.2.6  MESSAGE SET

Footnote 11: Please delete the discussion of ACID transactions.  ACID
transactions across two partners do not belong in tpaML.  ACID
transactions represent very tight coupling of the two partners including
allowing one partner to lock resources at the other partner.  That
should not be allowed or encouraged.  A given partner may be using ACID
transactions within its local processes but that is outside the scope of
ebXML.

An alternate definition of "Message Set" is the set of messages which
comprise a single unit of business between the two partners (e.g. a
conversation as defined in tpaML).

5.3  MISCELLANEOUS

(1) I infer that a session is a request with a response returned on the
same
connection as is usually the case with HTTP. If the term "session"
is intended to have a broader definition, the definition should be either
stated or referenced here.

(2) In correspondence to (1), I sugggest stating that a long term message
set is always asynchronous.

Regards,
Marty