[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-dev] ebXML registry and UDDI comparisons
Paul Denning wrote:
Toward mutual understanding ...Your first statement above is incomptable with the Beta / VHS analogy inyour last statement. I have a m,ajor comment at the end which is forward referenced using [1] and [2] in inline comments below.... [1] A very important story given the many use cases I cited (serving as a domain for guiding user input in GUIs, making sure user input uses valid taxonomy values etc.) [1] If it is not standardized it is not interoperable and therfor not worth mentioning. Anything is possible in custoim software. I could say that implementation of ebXML Registry will typically provide full support for UDDI as an option but that is neither here nor there. A major limitation since most taxonomies in real life are not flat. In ebRIM, classificationNode is a full RegistryObject.A major feature by design. This allows a classificationNode (read taxonomy value) to be access controlled, be itself categorized, independently versioned automatically by the registry when changed, related to other taxonomy values using any relationship type (e.g. EquivalentTo) even if the other taxonomy value is in another registry. Above only works if a taxonomy has its values encode the hierarchy structure (a rather rare occurance) [2] There is no API defined by UDDI for a user to add a new checked taxonomy. There is no spec defined for contract (SPI) between UDDI and and external validation service AFAIK. Correct me if I am wrong. If it is not specified normatively then it is not interoperable and not worth mentioning. [2] [1] [1], [2] [1], [2] UDDI specifies a set of findQualifiers, but allows implementations to define additional findQualifiers.Does it give an API for adding new findQualifiers and their processors? I suspect not. How is this interoperable? What exactly does UDDI do to "allow implementations to define additional findQualifiers"? What was preventing implementations to add impl specific findQulaifier before UDDI "allowed them to do so? So, it is conceivable that a findQualifer could be defined (and the associated implementation logic) that could refine the query in certain ways. It could effectively add additional keyedReferences to the requested set, then process the query with the expanded set. In this example, if the initial request wanted keyValue="11%", the registry could search for taxonomy tModels that are categorized with NAICS keyValue="11%", then add keyed references with those taxonomies and keyValue="%" (not necessarily "11%" because the extension taxonomy might not repeat the NAICS part of the code). I have seen any of this type of enhanced query and custom findQualifiers, but that is one way to do it and keep within the UDDI extension mechanisms.[1], [2] If it is not specified normatively then it is not interoperable and not worth mentioning. How can a taxonomy be checked by registry (or external service) if there is no normative way defined by UDDI to allow user to specify valid taxonomy values for their user defined taxonomy. If it is not specified normatively then it is not interoperable and not worth mentioning. How can a taxonomy be checked by registry (or external service) if there is no normative way defined by UDDI to allow user to specify valid taxonomy values for their user defined taxonomy. [1] The overviewURL of the taxonomy tModel is supposed to point to something that further describes the taxonomy. I had proposed that the target for this URL be a RDDL document, and that the RDDL document could have links to other things, and rddl:nature and rddl:purpose attributes could indicate various formats that could be downloaded to the tool. So, the tool would need to follow the links, check for a suitable rddl:nature (e.g., perhaps OWL), then retrieve the corresponding href.[2] If it is not specified normatively then it is not interoperable and not worth mentioning. [1] but yes if using the RDDL approach suggested above. There would need to be consistency between whatever the tool downloads and whatever the registry uses for checking. For example, the registry may use a proprietary XML format, but the tool may use OWL. Both the proprietary XML and the OWL should be consistent at least in terms of the keyValues allowed. The OWL version downloaded to the tool may have additional descriptions and relationships that the tool can use in the GUI, but (in general) all UDDI cares about is the keyValue.If it is not specified normatively then it is not interoperable and not worth mentioning. [1] but can be layered on top in a way that is consistent with UDDI. Publishers to UDDI do a getAuthToken, which is opaque to the publisher, but the registry may use it to lookup role or identity, then limit what taxonomies that publisher can use. The categoryBag can be used to store access control information in a way that the registry implementation understands. If you copy or replicate that entity to a different UDDI implementation, it probably would not know how to grok the ACL stuff in the categoryBag (breaking access control). There are a bunch of issues when you start federating (replicating) entries among registries.If it is not specified normatively then it is not interoperable and not worth mentioning. I am talking about registry managed version control (like CVS) not user specified version info attached to regsitered objects. The above TN does not specify how a registry would automatically version a taxonomy value if it is changed. [1], [2] The answer to all my questions above for ebXML Registry are a short, simple, unqualified YES. [1] Too simple a model. They are generic in many respects. The service entity applies to anything you might call a service, dial-in telephone, SOAP, ftp, anything. It is not restricted to only web services.I do not get your point above. ebXML Regisry ad hoc queries can fetch anything using domain specific ad hoc queries with no roundtripping. How is roundtripping a feature? [1], [2] [1] I am sure your single get/find includes something to tell the registry what you are trying to find or get.Yes it is called an adhoc query like "SELECT * FROM .... WHERE ... AND ... OR ... NOT ... LIKE.. ORDER BY..." etc. Another moot point, IMHO.Not moot at all. ebXML Registries single API never changes as user defines new types of objects. Imagine if we did things the UDDI way if user defined an object of type BPEL then we would have to add method: findBPEL getBPEL deleteBPEL instead our existing method: getObjects deleteObjects stays as constant as the Northern star. [1] The freebXML Registry project has done little performance optimizations to date and seems to be performing quite adequately for some fairly large deployments. I think the UDDI philosphy was to restrict the query language so they could get to market quicker with implementations, and they did.[1] Only if functionality is thrown in without an architecture. Not if you are based on the "few good primitives reused over and over again" principal as ebXML Registry standard is. Adhoc queries in ebXML Registry are the most frequently used feaure. This is based on data from experience of the 200+ user community of' freebXML Registry project. That is where profiles of ebXML Registry are making a huge difference. See for example, Open GIS (Geo spatial), IHE XDR (Healthcare - Electronic Patient Records) For example, what is a "slot"? Pretty generic, but what do I use it for?Indeed very generic. It represents a user define attribute that meets the common need to add any type of attribute data on any object (can UDDI do that?). The name and the concept BTW comes from the SELF Programming language. We built ebXML Registry standard based on a deep study of a welath of past experience and standards. BTW, what is a tModel? It sounds like the product Henry Ford used to say what "available in black or available in black" ;-) Then why did the UBR fail so miserably? ebXML Registry chose to be community driven and designed to solve real problems rather then be driven by some large behemoths in pursuit of their own private agendas. It is above statement that set my tone for this email. How can you say ebregreg = betamax when I have cited deployements by US Dept. of Defense, United Nations, Entire verticals? BTW did you know that IBM is now building a helathcare product based upon ebXML Registry (nay freebXML Registry)? This is after they quit ebXML Registry inprotest, 3 years ago, because we chose to support WS registry use case in version 2. http://www.eweek.com/article2/0,1759,1789867,00.asp Do you know why? Because their hand was forced by IHE XDR defining a normative profile of ebXML Registry. Do you really believe in your heart that the betamax analogy applies. I speculate not. I think this was uncalled for at best and pure FUD at worst. While we are on teh sibject of analogies let me close with one. But before I do let me now resolve the forward reference: [1] UDDI does too little [2] UDDI does that too little with too much complexity Apparently some well respected people agree with my assertions above: http://www.oreillynet.com/pub/wlg/6388 You will also find in the blog thread above that the UDDI TC Chair Luc Clemente did his best to create FUD about ebXML Registry even though it was not even the topic. So here is my analogy : There is a common problem faced by many users: How to turn on a light switch UDDI = A Rube Goldberg machine ( http://www.rube-goldberg.com/html/contest.htm ) ebXML Registry = A solid state transitor ( http://www.pbs.org/transistor/ ) ;-) -- Cheers, Farrukh Najmi Editor: ebXML Registry TC Co-chair: Semantic Content Management SC of OASIS ebXML Registry TC Co-chair: Registry SC of OASIS egov TC Lead Architect: freebXML Registry open source project (http://ebxmlrr.sourceforge.net ) Spec Lead: JAXR API Federated Information Management Architect: Sun Microsystems Coming to Java ONE 2005? If so check out Sun's Service Registry at Booth #802 in the Java ONE Pavillion. Sun's Service Registry Web Site: http://www.sun.com/products/soa/registry/ Press Release: http://www.sun.com/smi/Press/sunflash/2005-06/sunflash.20050615.1.html |
begin:vcard fn:Farrukh Najmi n:Najmi;Farrukh email;internet:farrukh.najmi@sun.com tel;work:781-442-9017 url:http://ebxmlrr.sourceforge.net/tmp/DSCN0278.JPG version:2.1 end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]