[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Re[2]: Trading Partner Logical Identification based on EDIFA
Quite a flurry of postings! I just got caught up on it. I sense a great deal of violent agreement on the identifier subject. I agree with Mark Nobles' last posting and Dave Webber's agreement with it. Here are a few summary points: There should be no need for both parties to use the same registry type. They do have to record in the TPA which type each is using, so that routing will work for each partner. Specifying a set of registry types in the messaging spec will provide a valuable assistance to vendors of the messaging run-time since it will tell them which registry types are the most important to support. Actually, if the TPA specifies the registry type and ID for each partner, it isn't even clear that the registry is much involved in the runtime since from a messaging perspective, the important point is that the combination of registry type code and partner ID for each partner is unique within the TPA. This combination plus the TPA ID and conversation ID provides the needed routing information at the message level. Each partner also provides its communication address(s) (Domain name, URL, or whatever) in the TPA, which enables the message to be put on the wire and get to the destination. There should be no reason to restrict the partners to using registry types defined in the standard. They should be able to invent their own registry IDs and partner IDs. Again, it is the combination of registry ID, partner ID, TPA ID, and conversation ID that does the routing. Should there be any need for run-time software to recognize the registry IDs, then the run-time implementations should provide the capability to use plug-ins to support registry types or invented types not listed in the messaging specification. Question: Has anyone yet worried about the uniqueness of the TPA ID? To make routing work based on the TPA ID, the TPA has to be unique at least within the run-time that is being used by each partner. To avoid the need to require uniqueness across both partners, the TPA ID could have a separate subelement for each partner. Alternatively, it could be required that the TPA be stored in one registry that both partners accept. This would also guarantee a unique identifier. 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 RR Webber <Gnosis_@compuserve.com>@compuserve.com> on 08/15/2000 04:18:00 PM To: Mark NOBLES <MNOBLES@lmi.org> cc: ebXML-Transport@lists.ebxml.org Subject: Re[2]: Trading Partner Logical Identification based on EDIFA Message text written by Mark NOBLES > If ebXML provides for a method to identify a registry type and the unique corporate identifier within that registry, then companies will have the flexibility they need to tailor their trading partner agreements. Mark Nobles LMI <<<<<<<<< Mark - thank you very much - that's EXACTLY what I'm proposing. Now you can all hold the collective RegRep feet to tthe fire to deliver.... Thanks, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC