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.)
eList eXpress LLC