Subject: Re: Registry Services, TPA formation,and TPA-Registry Responsibiliti es.
Dale, You are raising a good set of issues to consider. I have a few off the cuff observations. I view the TPF process as fundamentally outside the registry. The repository holds TPPs and TPAs. A TPA can be created fromTTPs and stored back in the repository via the registry. TPF might be an optional service that some registries might wish to offer but it should not be required that all TPF take place in a registry service. I consider that using a single ebXMLspec independently of the others is still a valid and important objective. You are quite right that the TPF process cannot be totally mechanical. It has to include interaction with the individual parties for some of the reasons you suggest. Of course, that interaction must be built into the TPF process whether it is part of ther registry or external to it. I also suggest that we consider that TPF is a subject for a later stage of ebXML and for the time being, focus on the contents of the TPP and TPA as static entities. When we later start to consider TPF, we might discover the need for additional tags to control the TPF process (i.e. automated negotation) but these can be added as an enhancement - or we might decide that they belong in an associated document rather than in the TPP itself. 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 ************************************************************************************* "Moberg, Dale" <Dale_Moberg@stercomm.com> on 09/12/2000 11:39:44 AM To: Martin W Sachs/Watson/IBM@IBMUS cc: ebxml-tp@lists.ebxml.org Subject: Registry Services, TPA formation, and TPA-Registry Responsibiliti es. I have now read the "Objectives and Scope" for the TP team, the Registry Services drafts from Farrukh, the Registry "Business Domain" draft, and wish to raise a question: Let TPP= trading-partner/party-profile. Let TPA= trading-partner/party-agreement. Let TPF= Bilateral TPA formation process from TPPs. Should there be a TPF that is _independent_ of the Registry? In the "Objectives and Scope" document, point 16 says that the spec "Harmonizes with other ebXML specifications while being able to be used independently of them." If this is still an objective, I think we need to consider more use cases and also reconsider what is needed for the service layer(s) in TPF. I previously supplied some use cases, at least one of which does not require registry services, except maybe to register/retrieve TPPs. Closely related to this issue is whether we have both negotiation and discovery based TPFs. Business rules applied when negotiating TPAs may not be information that users wish to export to a registry. I get the impression that the TPF process is to be carried out by processes within the registry. This would be ok if there are no "choices" involved (that is the TPA is some purely mechanical merge of TPPs-- a macro subsititution of roles to TP ids, for example). But when there are, for example, multiple delivery channels, business policies may apply to the choice among channels and may be based on outside information about the proposed TP. For example, a company may do a look up on DUNS number of its proposed Trading Party to find the company's credit worthiness and then select what channel is to be used. (Small volume, SMTP; large volume, set up an account, password and directory for FTP, and so on.)
Powered by
eList eXpress LLC