OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC