[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-dev] ebMS MSH and routing
William makes an excellent point. I discovered this "hole" when I was writing the ebXML mapping for the Open Travel Alliance E-Commerce spec. I ended up "creating" a URN to use within the type attribute of PartyId. Here's an example of an OTA compliant PartyId element, anyone want to guess what the urn contained in the type attribute indicates? <eb:PartyId eb:type=”urn:x12.org:I05:01”>987654321</eb:PartyId> Dick Brooks Systrends, Inc 7855 South River Parkway, Suite 111 Tempe, Arizona 85284 Web: www.systrends.com <http://www.systrends.com> Phone:480.756.6777,Mobile:205-790-1542,eFax:240-352-0714 -----Original Message----- From: William J. Kammerer [mailto:wkammerer@novannet.com] Sent: Wednesday, January 09, 2002 1:52 PM To: Anarkat, Dipan Cc: ebXML Development Subject: Re: [ebxml-dev] ebMS MSH and routing Dale Moberg agreed with Duane Nickull on the ebxml-cppa@lists.oasis-open.org mailing list that it would be good if we had an enumerated list [of PartyId types], with option to extend it. It would be good if these list values were at least standardized to URIs, probably URNs. But last time [Dale] checked, there was little agreement even on how to get an official URN for DUNS or whether it might need to get some official (read legal) approval to use it. Dale asked if there are "some candidate values that could help standardization in this area? ....what [could we] use as enumerated values?" He wants a list of all commonly used identifier schemes. Dale further suggested "we might then use an oasis urn prefix to rig up enumerated values." All URN prefixes or domains are defined at http://www.iana.org/assignments/urn-namespaces. Dun & Bradstreet still hasn't requested one since we first discussed this a year ago, and I wouldn't hold my breath waiting for this to happen at all. In the meantime, I would be quite satisfied using the OID (Object Identifier) scheme to indicate PartyId types. "urn:oid:1.3.60" uniquely says Dun & Bradstreet D-U-N-S. Use "urn:oid:1.3.60" to qualify the code 081466849, and you instantly know I'm talking about the Microsoft Corporation. As another example using the OID URN, an EAN Location Code would be qualified it with a PartyId type of "urn:oid:1.3.88". The OID structure itself is cataloged at http://www.alvestrand.no/objectid. I addressed this use of OIDs (for the PartyId type) in detail within a thread of messages to the ebXML Transport mailing list back in December 2000 and subsequent months. Our good friends, Ralph Berwanger, David Dobbing, Klaus-Dieter Naujok and Francois Vuilleumier are members of ISO/TC 154-UN/CEFACT JSWG, at http://www.gefeg.com/jswg/. They might be able to lubricate the way for ISO 9735 to define an OID structure whereby all of EDIFACT's D.E. 0007 Identification code qualifier code values could be hijacked for use. All ISO standards that have a number have an automatic assignment of an OID under the arc 1.0. So ISO 9735 (EDIFACT Syntax) already owns urn:oid:1.0.9735. It would be up to the JSWG, I guess, to decide how they would parcel out their little domain. For example, if they said the OID 1.0.9735.1.n referred to the code values for service element n, then a PartyId type of urn:oid:1.0.9735.1.7.8 could mean "UCC Communications ID (Uniform Code Council Communications Identifier)." - in that D.E. 0007 is the service element and code value 8 means UCC CommID. The latest list of EDIFACT Identification code qualifiers is at http://www.gefeg.com/jswg/cl/v4/40006/cl3.htm. This would give you full access to all the EDIFACT qualifiers, relying on diligent and conscientious maintenance to be provided free of charge by the JSWG. Likewise, using the OID arc 1.3 allows you to refer to all the ISO 6523 ICDs; see file ICD_list.htm in folder 6523-Identification-of-Organizations at http://xw2k.sdct.itl.nist.gov/l8/document-library/draft-standards/ for a list as of 5 April 2000. So, as in the examples I gave before, a PartyId type of "urn:oid:1.3.88" refers to ISO 6523 ICD 0088 (EAN Location Code). The only thing left to do would be to get an arc assigned to X12's Interchange ID Qualifier so you have full access to their comprehensive list of qualifier types. William J. Kammerer Novannet, LLC. +1 (614) 487-0320 ----- Original Message ----- From: "Anarkat, Dipan" <DAnarkat@uc-council.org> To: "Ebxml-Dev (E-mail)" <ebxml-dev@lists.ebxml.org> Sent: Wednesday, 09 January, 2002 02:21 PM Subject: [ebxml-dev] ebMS MSH and routing Hi, I am trying to uderstand how the #1. eb:MessageHeader/eb:PartyId #2. eb:MessageHeader/eb:PartyId/@eb:type entities are used in the routing process for an ebMS message . The specification says that the value of #2 has to be agreed upon b/w the 'ToParty' and the 'FromParty'. How does this ensure message delivery in a multi-hop scenario with intermediaries ? Drawing an analogy with the IP addressing and routing scheme : # should'nt there be a standard for the value contained in #2 so that the message can be interpreted and routed to the appropriate MSH / SOAP node ? # can an ebMS MSH node be mapped to multiple 'PartyId' 's , similiar to an multi-homed IP node with multiple IP addresses ? # shouldnt there be a naming / registry system like DNS for mapping 'PartyId' 's to MSH nodes ? # how does an MSH node know the physical location ( IP address ) of the next MSH ? The spec recommends that the the value of #2 be standard codes taken from EDIRA (ISO6523), EDIFACT ISO 9735 or ANSI ASC X12 I05 registries. Can someone explain how this facilitates ebMS messaging ? A few examples with actual codes for the above would be helpful . <eb:MessageHeader> <eb:To> <eb:PartyId eb:type="GLN">0614141000012</eb:PartyId> </eb:To> <eb:From> <eb:PartyId eb:type="DUNS">0060189737810</eb:PartyId> </eb:From> </eb:MessageHeader> Considering the example above in an multi-hop scenario, # how are the values contained in #1 and #2 used by the 'ToParty' and intermediary MSH nodes actually used for routing ? # how does an intermediary MSH node select the next MSH node and consequently its physical (IP) location based on #1 and #2 ? # Couldnt there be a situation that an intermediary MSH may not understand the value contained in #2 as #2 is not constrained by the specification ?How does the routing work then ? The specification also specifies that if #2 is not used , then the content of #1 should ne a URI. In that case how does routing take place if the content of #1 is say : #URL : <eb:PartyId >http://www.mycompany.com/service/Order </eb:PartyId> #email : <eb:PartyId >mailto:somebody@mycompany.com </eb:PartyId> Thanks Dipan Anarkat EC Systems Analyst Uniform Code Council, Inc. Tel: (609)-620-4509 http://www.uc-council.org/ ---------------------------------------------------------------- The ebxml-dev list is sponsored by OASIS. To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.ebxml.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC