RE: Comments on Overview and Requirementsm 5/26/00

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

Marty

See comments inline below.

David

-----Original Message-----
From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
Sent: Tuesday, August 08, 2000 10:24 PM
To: ebxml-transport@lists.ebxml.org
Subject: Comments on Overview and Requirementsm 5/26/00


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?)
<db>The idea of a syntax neutral rendition was initially building on ideas
from Core Components that there is benefit in focusing on WHAT data or
information is required before specifying HOW that data is represented.
Putting this into a TPA context means IMO that we should focus first on WHAT
information should go inside a TPA and then decide on its representation. In
practice though the TPA (as you said in your talk today) can have many
representations:
1. An internal representation where the data will typically be recorded in a
database, and
2. An external representation where the data is expressed as XML.

I think that in practice there will be as many different internal
representations as there are implementations of ebXML. On the other hand
only a single external representation is useful if you want to have
interoperability. This should, of course, be XML.

On the other hand, if we develop a "service interface" that describes how an
application might interact with with ebXML TRP aware software, then this
could be usefully implemented in several different languages such as Java,
Corba, C++ etc.
</db>

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?

<db>When I first wrote this spec (7 months ago!!) it was building on many of
the ideas in IOTP which includes the concept of a multiple round trip
document exchange. The idea was that there is benefit to business process
designers if there are "document exchange templates" that can be used as
building blocks to develop business processes. My view has now changed and
think it is probably more in the domain of the Business Process group to
develop document exchange templates rather than TRP. However I don't think
that the BP group has identified this as a requirement. This means that we
(i.e. the TRP) group need to decide whether or not we should take on the
work. If we ignore it then it might just get completely forgotten. Either
way we need to work, perhaps more closely, with the BP group on this. </db>

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?

<db>Services, subservices etc, are all originally taken from IOTP and
therefore the same response as for the previous question applies.</db>

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.  
<db>The spec is an overview & requirements for TRP and NOT, specifically,
tpaML. In this case positioning TRP with ACID transactions could be useful.
Do you agree.</db>
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.  
<db>I totally agree.</db>
A given partner may be using ACID
transactions within its local processes but that is outside the scope of
ebXML.
<db>I also totally agree.</db>

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).
<db>I think that a Message Set (we're now calling it a Conversation) is more
widely applicable than the definition you provide. I would prefer to say "An
example of a message set is the set of messages which comprise a single unit
of a business between two partners, eg a conversation as defined in
tpaML".</db>

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. 
<db>You're right, if it was HTTP then the response would be on the same
connection. However I didn't want to preclude the response coming back on
another connection synchronously and therefore did not specifically mention
connection.</db>
If the term "session"
is intended to have a broader definition, the definition should be either
stated or referenced here.
<db>Any thoughts on what the definition should be ;-)</db>

(2) In correspondence to (1), I sugggest stating that a long term message
set is always asynchronous.
<db>Perhaps we should define synchronous and asynchronous as well as
session. Thoughts?</db>


Regards,
Marty