[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: LONG: RE: [regrep] Issue with UUID's for Core Components and BIE's
Michael Mealling rote 3-4 RFC's on this. He advocated a similar approach. I think this is worth more discussion. Question: What group related to ebXML should tackle this? ebSOA, Regrep or another group? Duane Matthew MacKenzie wrote: >A UUID is meant to be unique in time and space. Frankly, they are >universally adopted. With ebRS supporting a predictable URL format via its >HTTP binding, we really should be looking toward defining mechanisms for >making registry location information available such as in DNS. A ID >mechanism that embeds some prefix in it is a hokey solution, and its error >prone unless each organization manages their namespace carefully. > >One idea is to embed some more info in the urn, and use a DNS driven >approach for resolving an extended urn string to a registry object download >URL. > >We take a root domain name of 'r.ebxml.org', this is our address space. A >committee at OASIS is in charge of maintaining this namespace. > >Organization 'A'would like to register its registry, so they submit a >request to the OASIS team looking after this. The request might look like: > >"A Corp. would like to register two registry instances in the global >"directory". Instance One is called "osirus" and it is at >http://osirus.corp.com/http-binding. The second instance is called >"ogmios", and it is located at http://ogmios.corp.com/http-binding." > >Upon receiving this request, the OASIS team would register a domain name for >the organization in DNS: > >a.r.ebxml.org. In the TXT field for that domain, would be a token like: > >ORG:A Corp > >Two more subdomains would also be created: > >Osirus.a.r.ebxml.org > --> TXT field: http://osirus.corp.com/http-binding > >Ogmios.a.r.ebxml.org > --> TXT field: http://osirus.corp.com/http-binding > >Federations could be accommodated by creating further sub-domains for >"virtual" registries, e.g. ogmios.clusterA.a.r.ebxml.org. > >Now...The UUID: urn:uuid:osirus:a:UUID-7888-HHHH-UUUU > >Using standard DNS resolver libraries + that UUID, we can find out the HTTP >binding location. Since we are using DNS infrastructure, it is likely that >no special configuration will be needed, and the system is proven to be >ultra scalable. > >If I get a couple hours, I will demonstrate this technique. > >I don't think we need domain specific ID references. What we need is unique >identifiers that can always be resolved to their registry content or entries >by authorized users from anywhere. Nobody cares that the UUID is difficult >to type and remember, because these things are used by software. > >-matt > > > >-----Original Message----- >From: David RR Webber [mailto:david@drrw.info] >Sent: Friday, April 09, 2004 11:29 AM >To: Farrukh Najmi >Cc: Duane Nickull; UN/CEFACT Core Component WG; regrep@lists.oasis-open.org >Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's > >Farrukh, > >I know we've had this disagreement before. I'm not >arguing with you from the registry engineering PoV - >I understand why the registry itself needs these UUID >keys internally. > >It's the way they get used externally that frankly does >not meet the business use case of things like CCTS, >CPA, BPSS, CAM and more. > >Your point about the 16 bytes reminded me of another >big issue -using these UUIDs you also need to avoid >embedding the URL for the registry too - making this >even more ugly (what if you need to relocate your registry >to a new server?). > >Here's an example from Duanes code - I count a lot >more than 16 bytes here: > >"urn:uuid:4a593056-3509-0766-2e7b-4e154030423f" > >By comparison the UID system is available to >prevent having to do all this syntax mucky-muck. >Using the character code prefix - the Registry is >referenced via an ALIAS and therefore the >physical address location can be easily and >quickly changed by assoicating the alias to the >registry address - and the UID values themselves >can be assigned simply and easily with a code >that makes sense to the >business functional users, and can be versioned >and sub-versioned directly. > >Example UID: USPS020015 > >United States Postal Service BIE - in the 20000 >series - all of which relate to Mailing Address >structure elements, and so on. > >And then UID: USPS020015:01:03 > >is version 01, sub-version 03 - of that same BIE >structure - where say the country codes have been >updated for the new members of the EU countries. > >This is why we put the EXTERNAL ID functionality >in the Registry RIM - and that is why we should be >recommending people use it for CCTS and other >content referencing needs. It provides domain-centric >labelling of content and that is a very good thing that >we should be advertizing as an excellent feature. > >The UUID takes us backwards - that's how we >ended up with EDI in the firstplace - completely >dictated by machine level technology devices and >mechanisms - instead of business use >case needs. The whole point of CCTS is to move >beyond machine level stuff to a higher business >neutral system. Using UUIDs is like thorns on a rose >IMHO here. > >Thanks, DW > >----- Original Message ----- >From: "Farrukh Najmi" <Farrukh.Najmi@Sun.COM> >To: "David RR Webber" <david@drrw.info> >Cc: "Duane Nickull" <dnickull@adobe.com>; "UN/CEFACT Core Component WG" ><uncefact-tmg-ccwg@listman.disa.org>; <regrep@lists.oasis-open.org> >Sent: Friday, April 09, 2004 9:13 AM >Subject: Re: [regrep] Issue with UUID's for Core Components and BIE's > > > > >>David RR Webber wrote: >> >> >> >>>I hope this is the last and final time we have to have this discussion >>>around erroneous use of UUID values as external linkage identifiers >>>to registry content - they are for INTERNAL use only - and should >>>be used for such programmatic pointer uses only within the API >>>to registry. >>> >>> >>> >>I respectfully disagree. The UUID based URN (urn:uuid:....) should be >>used to >>uniquely reference an object internally or externally. I agree that for >>human >>consumption you may want some ExternalIdentifier such as a human >>friendly URN. >>But strictly for reference purposes (internal or external to registry) I >>still >>suggest using UUID based URNs. >> >> >> >>>I understand the tempatation to make your Java code >>>easier to write by burying all these UUIDs into the access method >>>to the registry - as a quick kludge - but you have to remember the >>>central tenet of computer software - its supposed to make work >>>easier for human operators - not harder! Not to mention the >>>ludicrous overhead associated with a 128 byte boat anchor to >>>what is often less than 30 bytes of information.... >>> >>> >>> >>> >>Oops, I think you meant to say a "16 byte boat anchor" not a "128 byte >>boat anchor". >>Which is definitely less than "30 bytes of information". >> >>To be clear... A UUID is 16 bytes not 128 bytes. >> >>-- >>Regards, >>Farrukh >> >> >> >>To unsubscribe from this mailing list (and be removed from the roster of >> >> >the OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup. >php. > > >> >> > > >To unsubscribe from this mailing list (and be removed from the roster of the >OASIS TC), go to >http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup. >php. > > > > -- Senior Standards Strategist Adobe Systems, Inc. http://www.adobe.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]