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

[mwsachs@us.ibm.com]

Resending because of some kind of mail delivery failure

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

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
*************************************************************************************
---------------------- Forwarded by Martin W Sachs/Watson/IBM on 08/13/2000
11:52 PM ---------------------------

Martin W Sachs
08/11/2000 11:27 PM

To:   David Burdett <david.burdett@commerceone.com>
cc:   ebxml-transport@lists.ebxml.org
From: Martin W Sachs/Watson/IBM@IBMUS
Subject:  RE: Comments on Overview and Requirementsm 5/26/00  (Document
      link: Martin W. Sachs)

David,

We continue to be on the same wavelength on all of this stuff.

My rejoinders in line in red.

Regards,
Marty

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

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
*************************************************************************************



David Burdett <david.burdett@commerceone.com> on 08/10/2000 10:36:07 AM

To:   Martin W Sachs/Watson/IBM@IBMUS, ebxml-transport@lists.ebxml.org
cc:
Subject:  RE: Comments on Overview and Requirementsm 5/26/00



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>
MWS:  OK with regard to the representation. Your comments are in accord
with our agreements this week. We will attempt a UML model which generates
XMI, eventually leading to an XML document.  There is no "if" on the
service interface.  It should be an ebXML goal to define a conceptual
service interface between BP and TRP.  It should describe the interface
functions but must be implemenation neutral.  At the appropriate time, I
can supply an example, a conceptual service interface go the ANSI Fibre
Channel physical and signalling layer.

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>
MWS:  I agree.  If BP isn't interested, we can unilaterally insert it into
the TPA spec.  IBM's tpaML already has this concept, formalized by
permitting the definition of multiple sequential response messages in an
action definition.  Since the response message is an action request in the
other direction, the TPA can specify the  function equivalent to the
exchange messages or a richer version of it.

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>
MWS:   ... and the same rejoinder applies as for the previous question.

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>
MWS:  I mostly don't agree.  Based on the current state of the art, ACID
transactions between independent businesses is a bad idea.  One way it
might be useful is if we consider parts of the same business communicating
over a LAN with ebXML messaging.  I have some charts which mention the use
of TPA and BPF within an enterprise for integrating otherwise incompatible
systems.
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>
MWS:  and I agree with your agreement :-)

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>
MWS:  fine.

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>
MWS:  For the most part, the tpaML grammar permits a synchronous response
on a different connection.  Really, I think that this amounts to the
recipient of the response "imitating" synchronous by blocking until the
response arrives. The people in my group who built and are continuing to
work with the prototype run-time (BPF) believe that that kind of
synchronous response is hard to implement and not terribly useful, so we
changed the text in ver. 1.0.6 to restrict synchronous to HTTP single
connections.
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>
MWS:  One thought is that the session is the logical connection between the
two partners that exists for the duration of a conversation.  In a later
posting tonight, I will propose an improvement to conversationID that will
cause it to start smelling like a communications session identifier.

(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>
MWS:  See tpaML ver. 1.0.6, sections 2.9.15 and 2.9.16 for definitions of
synchronous and asynchronous.


Regards,
Marty