Subject: Re: comment on TA specification
Duane,
This is the TA comment set that I sent to Klaus on Monday. Please forward
it to the team if Klaus hasn't already done so.
Regards,
Marty
Martin W Sachs
01/15/2001 11:02 PM
To: Klaus-Dieter Naujok <knaujok@home.com>
cc:
From: Martin W Sachs/Watson/IBM@IBMUS
Subject: Re: ebXML ebXML Technical Architecture Specification v1.0 now
available for review (Document link: Martin W. Sachs)
Comments on TA Spec. V1.0 from TP Team Lead:
Lines 502-505: Please delete this sentence. It duplicates the first
sentence of the previous paragraph.
Lines 506-507: Please replace this sentence by:
In order to be able to execute electronic-business transactiosn with
each other, businesses require the ability to reach agreement on
technology specifications and to document that agreement in the form of
a Collaboration Protocol Agreement (CPA).
(The original sentence stated that the CPA relates to publishing
information about an agreement, which is incorrect - that's what the CPP is
for.)
Line 558: Please delete "Business Process:" It is a superfluous in-line
subhead.
Lines 562-563: Please delete this sentence. There is no technical reason
for the CPP to reference a CPA. Furthermore, since is stated elsewhere in
the section that a business has only one CPP in the registry, it would be
impossible for the CPP to reference a CPA. There could be thousands of
CPAs derived from the one CPP. There is no reasonable way to accomplish
referencing thousands of CPAs from one CPP, and there is no reason to do
so.
Lines 567-569: As indicated in one of the QR comments, this paragraph
seems to imply that the CPP has to describe the binding details used to
convey that CPP in a message. That is wrong. A given CPP describes the
technology capabilities to execute specified business transactions with
that business. That CPP cannot be sent as part of one of those
transactions because the technology for executing those transactions cannot
be set up until the CPP has been exchanged. Furthermore, since a CPP is an
XML document, it can obviously be carried as payload in an ebXML message,
so this does not have to be said. I suggest replacing the paragraph by:
A CPP shall (not "may") describe the binding details that are required
to send messages using the ebXML Messaging Service, including some of
the information in the message header.
Lines 567-568: Further discussion (see above): Because the TA specification
limits each business to one CPP that covers all business processes, setting
up a negotiation CPA that includes exchanging CPPs in messages is an
interesting question. The negotiation transaction cannot be defined in the
business's CPP since that CPP cannot be exchanged between parties until the
negotiation process has been set up; hence the negotiation process itself
cannot be negotiated. One possibility is a negotiation service that is
provided as part of the Registry. The negotiation service's technology
specifications can be made available to all users of the registry, thus
allowing an implicit CPA for negotiation to exist. I believe that this
issue is far beyond the ver. 1.0 specifications. As noted above, the
question of carrying CPPs in messages does not have to be explicitly
addressed since the CPPs are XML documents. I suggest not mentioning this
point.
Lines 573-574. Please delete. It is not clear what that software
component does and what is intended by this sentence. The only software
component the CPA has an interface to is the business process, which is
covered in lines 581-582. There is also an implicit interface to B2B
middleware, but that is outside the scope of any of the ebXML
specifications at this time.
Lines 576-579: There is no interface between the CPP and CPA. None is
required. Please replace this paragraph by:
A CPA is created by composing it from the CPPs of the two businesses.
The composition process is based on computing the intersection between
the two CPPs. In other words, the CPA consists of those capabilities
that are in common to the two CPPs and hence describes whtat the two
Trading Partners "will" do. Following the composition process, a
further negotiation process may be required to obtain agreement on which
of possibly several business processes will be controlled by this CPA,
as well as to obtain agreement on variable parameters such as timeouts.
It should be noted that the resulting CPA contains all of the information
necessary to set up and execute the business process between the two
partners, hence there is no need for linkages to the original CPP. In
fact, such linkages are very undesirable. Given that each business is
allowed to have only one CPP, such an interface to the CPPs would mean that
replacement of that CPP by a modified version would require termination and
renegotiation of all existing CPAs. However modifying the CPP does not
necessarily affect the existing CPAs since it is likely that the
modification consists of adding capabilities useful for new business
relationships while the existing CPAs can continue to function.
Lines 581-582: This sentence is not very understandable. I believe that
the correct statement is:
A CPA includes a link to an XML document that defines the collaboration
protocol between the two businesses. This document conforms to the
ebXML Business Process Specification Schema specification (or whatever
the final name of that specification will be).
Lines 584-585: This statement is correct as long as it continues to say
"may be". However it is not clear that this is an important point since a
CPA is really a private matter between the two businesses, so that it is
unlikely that a CPA would be kept in a public registry.
Lines 591-593: This statement is normative. It should not be in a
paragraph labelled non-normative.
Line 1102 and following: This appendix makes frequent use of the term TPP
(Trading Partner Profile). The TA specification does not define the
difference between a TPP and a CPP and the TP team is not defining such a
(presumably higher level) document. Please change TPP to CPP throughout
this appendix.
Line 1142: As noted above, the CPA does not reference the relevant TPPs
(i.e. CPPs). Please delete this line.
Line 1143: Please delete this line. The CPA does not reference legal
terms and conditions in any architecturally meaningful way. It may provide
a #PCDATA field for recording the ID of an associated legal contract, but
that is all.
Line 1144-1158: These bullets relate to implementation, not to what the
TPP (CPP) defines. Please start a new "subhead" about implementation.
Line 1145 and elsewhere: Please delete this line and other references to
Business Service Interface. I can't find a definition of such a construct.
It probably refers to the B2B middleware. Perhaps one could say "obtains
the necssary middleware".
Line 1174-1175: This statement appears to say that each trading partner is
fully aware of the state of the entire process. That is not correct. At
this stage of the development of the CPA and its support software, each
partner is only aware of the state of its interactions with the other
partner in the CPA. In this case, TP 1 knows only about the state with
respect to TP2, TP3 only knows about the state with respect to TP2, and
only TP2 is aware of the total state of the three parties.
Line 1201: As noted above, the CPA does not reference the relevant TPPs
(i.e. CPPs). Please delete this line.
Terminology: After extensive discussions, the TP team is consistently
using the term "Party" to denote the owner of a CPP and a participant in a
CPA. the TA team may wish to update the architecture document to agree.
Regards,
Marty
*************************************************************************************
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
*************************************************************************************
Powered by
eList eXpress LLC