Hi Everyone, this type of discussion is very hard to resolve. The real world answer is "it depends on the customer's requirements". It's really a very interesting discussion because of the qualifications of the people talking though.
As interoperability standards, both UDDI and ebXML are important. We find a great deal of interest in SOA Governance which is not completely specified in either of these standards. We have also found through our customers that many features of the Java API for XML Registries (JAXR) and ebRIM (Registry Information Model) are useful. Other companies may have different customers, and so are entitled to different opinions. In our experience of implementing the functionality and mapping to ebXML and UDDI as we do from a normalized model, UDDI certainly has many more limitations to map to especially in the areas of a. Metamodeling options b. Access control mapping c. Arbitrary dependencies Whether ebXML is sufficient as a data model is an implementation detail dependent on the implementations out there. It is possible to implement governance and other features and map to ebRS and UDDI--and we have done so. So it does not have to be either/or. Both OASIS standards have their proponents and use cases, and we have synchronized the information models within our product. Miko --- In [email protected], Farrukh Najmi <[EMAIL PROTECTED]> wrote: > First, I want to make clear that I think UDDI is a fine standard for the > kinds of simplere problem that it was designed to address (Yellow /White > / Green pages). > Where I think UDDI is inappropriate a fit is in complex probolems such > as SOA Governance for which UDDI was not deigned for. > > To be fair, ebXML Registry was not designed for SOA Governance either. > However, it was designed from the beginning to be a generic and > extensible registry-repository that could be used in a variety of open > ended and complex use cases. > > Anne Thomas Manes wrote: > > Assuming that you are referring to UDDI implementations, I disagree > > with these assertions: > I am referring to UDDI 3 standard. Beyond what is standard in UDDI, I > agree that anything is possible in a software implementation (except > curing aids, bringing world peace and ending world hunger maybe). > Implementation specific features vary from product to product and the > larger vendors offer pretty basis UDDI implementations (not much beyond > the standard). > > I believe standards based functionality is important because there are > only two ways to achieve interop across organization boundaries: > > 1. Have same implementation on both sides (not practical unless one side > can dictate to the other) > > 2. Have standards based implementation on both sides. > > Features such as federated registries rely heavily on standards based > implementation for interop across organizational boundaries > > > > Light weight registry-only service lacks for SOA: > > > > 1. Support for SOA Governance. Can't enforce policies on SOA > > artifacts if they reside external to registry. > > 2. Ability to support artifact specific parameterized discovery queries > > 3. Fine grained custom, role based access control of artifacts > > 4. Extensible metadata and protocols > > 5. Extensible taxonomies with no need for external validation > > services to validate ussage of taxonomies > > 6. Extensible relationship between artifacts > > 7. Content based event notification using extensible artifact > > specific queries > > > > 1. Governance is a pretty broad topic, but it's all about defining > > policies and implementing procedures that verify adherence to > > those policies. Any registration process to which you can attach > > an approval workflow supports SOA governance. There's no > > requirement that the artifacts must reside in the registry in > > order to analyze and approve them. Systinet Registry provides a > > built-in customizable registration approval process--and it can > > call out to extenal validation services to check for compliance > > with WS-I Profiles, corporate namespace conventions, appropriate > > security precautions, management provisioning, etc. For folks > > using other UDDI-compliant registries, you can use an external > > governance/approval process such as WebLayers. > > > See point about "anything is possible in software" above. With ebXML > Registry the processes for publish, approval, validation, cataloging, > versioning, deprecation, undeprecation, deletion etc. are defined by a > standard. There is no vendor specific extensions needed. Each of these > can even be customized for specific verticals using vertical defined > extension profiles. > > > > 1. Although a combined registry/repository does give you more > > flexible search capabilities, UDDI does allow for powerful > > search. You can query a UDDI registry based on any information > > within the artifact that you choose to capture within the > > registry. UDDI is extensible, so you can capture pretty much > > whatever information you want to during registration -- but you > > must first define the information model for capturing the > > information, and you must use that model at registration time. > > > As you know UDDI has 4 or so pre-defined queries (findBusiness, > findService, findTmodel etc...). > Even these 4 queries do not support arbitrary disjunction and > conjunction of predicates. It is fairly > limited in practical terms. > > > > 1. > > > > > > 2. Both Systinet and SOA Software support fine-grained custom, > > role-based access control of all registration entities. The > > artifacts themselves are typically stored in separate asset > > repositories, which should provide their own security systems > > for check-in, check-out, version control, etc. > > > Fine grained custom access control is in the eye of the beholder and > there are many nuances. I will use an example > to illustrate what I mean. > > UDDI specs has the notion of "Publisher Assertions" and "Confirmation > of Publisher Assertions". The idea is that I can say that my published > BusinessEntity (organization) is a subsidiary of the > Anne's BusinessEnity. To protect against false assertions by a publisher > UDDI provides Anne the ability to confirm (or not) my assertion. In > practice this places a burden on having to confirm every such assertion > if it is true. > > ebXML Registry on the other hand can use a fine-grained access control > policy to simply say that Farrukh (or a more generic role) is not > allowed to create any references to Anne's objects. > There is no need for Anne to "confirm" any true assertions because false > assertions are just not possible. > > In fact in ebXML Registry you can be even more fine grained and say that > Farrukh is allowed to create that assertion if Anne's object's state > meets specified criteria. > > So as I said, fine grained custom access control is in the eye of the > beholder. > > > > 1. > > > > > > 2. The UDDI tModel is an extensible data entity, and it is designed > > to support extensible metadata and protocols. > > > I view the UDDI tModel essentially as a workaround for UDDI limitation > of not having a repository. A tModel instance identifies some artifact > in an external > repository or some arbitrary concept (like the number 10). It serves as > a proxy for the real artifact. > > > 1. UDDI supports extensible taxonomies and their associated valid > > value sets. Validation may be performed either internally or via > > an external validation service. (Why does it matter if it's > > internal or external?) > > > What matters is whether you are at the mercy of a product to supply > specific taxonomies and their external validators or whether any spec > compliant registry can support > any user defined or user extended taxonomy. > > This IMO is a major flaw in UDDI. > > > 1. The UDDI tModel and the categorization system can also be used > > to define extensible relationship between entities. > > > Last I checked the only means to create relationships was Publisher > Assertions (see issues with confirmation model above) and that only a > handful of pre-defined relationship could be applied to only a handful > of objects in UDDI. Does it now allow any two objects (say a > BindingTemplate and Another BindingTemplate) to be related in an > arbitrary relationship like > "DependsUpon"? > > > > 1. The UDDI Subscription API supports content-based event > > notification. You can design your registration process to > > capture artifact-specific information and generate appropriate > > events. > > > And how does one specify what events they are interested in in UDDI. > Last I checked it was by specifying ids of objects you are interested in. > In ebXML Registry the same parameterized ad hoc query that is used to > perform discovery using potentially complex queries is reused > to select events that match a subscription. > > In order for UDDI to match the functionality I had mentioned it would > have to: > > a) Support ad hoc parameterized queries capable of joining arbitrary > predicates > > b) Support use of those ad hoc parameterized queries as selector queries > in a subscription > > Does it to above? > > > > 1. > > > > > > The one indisputable advantage that ebXML has over UDDI is Farrukh's > > last point: > > > > * Federated queries able to search across multiple stores that > > contain non-overlapping data > > > UDDI distributed registry model is replication centric. AFAIK, It > replicates all data, across all registries, all the time. This > has been a difficult feature for UDDI implementations for a variety of > reasons and has scalability issues. > > ebXML Registry on the other hand is federation centric. There is no need > to replicate data though it can be replicated for fault tolerance or > performance reasons on a per datum basis. In fact the registry API gives > replication control to clients as well since they may best know > what to replicate when for app specific reasons. > > > > Personally, I don't view this advantage as sufficient cause to adopt > > ebXML over UDDI, and it certainly isn't sufficient to offset the > > advantage of using the industry's more widely adopted standard > > registry protocol. ebXML RegRep is an OASIS standard, but I have yet > > to hear any superplatform vendor (BEA, IBM, Microsoft, Oracle, or SAP) > > endorse ebXML or implement products that support the ebXML protocol. > Hmm. I guess Sun does not count in your books? That seems rather > questionable. > > Also I firmly believe that what really counts is *WHO* is deploying > implementations of the standard and what they are doing with it. > They days of *big* vendors shoving stuff down the throats of user > companies is over. In fact many of the largest entities such as > governments and United Nations have deployed open source freebXML > Registry project which is a completely grass roots effort. > > The partial list of freebXML Registry deployments are listed below: > > See [2] in http://ebxmlrr.sourceforge.net/tmp/ebXMLRegistryLinks.html > > > Also consider the list of entire verticals and standards that have > layered their own specifications on top of ebXML Registry: > > -Open GIS (geospatial) > > -IHE-XDS (healthcare - electronic patient records) > > -HL7 (healthcare conformance profiles) > > -RosettaNet (supply chain) > > -sdmx.org (track 3rd world debt stats - participants include lending > institutions such as Swiss Banks, IMF, World Bank) > > On the other hand, all 5 support UDDI. Meanwhile, vendors of dev > > tools, ESBs, EII, web service management, XML security gateways, asset > > repositories, etc, all support or plan to support UDDI. Almost none > > plans to support ebXML regRep. > Hmm. Again you seem to be over-stating your case because I am seeing > much interest of many dev tool vendors on a daily basis to discuss > support for ebXML Registry. > > I assume most list members know that before joining Burton Group you > were a UDDI author and TC member and a senior employee of Systinet: > > http://lists.oasis-open.org/archives/uddi-spec/200403/msg00050.html > > It is not surprising that you have a natural pre-disposition to > promoting UDDI > and that is why I do not recall you making similar fact finding efforts > regarding > ebXML Registry as the one below: > > http://lists.oasis-open.org/archives/uddi-spec/200409/msg00007.html > > I trust that in your role at Burton you will be able to provide fair and > balanced coverage of UDDI and ebXML Registry. > > > > I also have to point out that your metadata of record can't be managed > > and maintained in the ebXML repository. e.g., WSDL files are managed > > by their hosting platform; BPEL scripts are managed by their BPEL > > engines; XSLT scripts are managed by their ESBs, etc. The idea that > > you can have a single SOA repository is a pipe dream. > Just to be clear, I dream about federated repositories that span the > universe :-) > > Picture a birth/death federated repository that spans an entire country > (that vision is actually in the works). > > > > > > The list is quite long but here are some things that light weight > > registry-only service lacks for SOA: > > > > -Support for SOA Governance. Cant enforce policies on SOA artifacts if > > they reside external to registry. > > > > -Ability to support artoifact specific parameterized discovery > > queries > > > > -Fine grained custom, role based access control of artifacts > > > > -Extensible metadata and protocols > > > > -Extensible taxonomies with no need for external validation > > services to > > validate ussage of taxonomies > > > > -Extensible relationship between artifacts > > > > -Content based event notification using extensible artifact > > specific queries > > > > -Federated queries able to search across multiple stores that contain > > non-overlapping data > > > > For more info one may want to see the slides from the recent ebXML > > Registry 3.0 Webinar at: > > > > ebXML Registry Webinar Slides: > > http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.pdf > > > > http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.sxi > > <http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.sxi> > > > > http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.odp > > > > http://ebxmlrr.sourceforge.net/presentations/ebXML%20Registry%20webinar5.ppt > > > > > > There has been some interesting discussion on similar subject that James > Governer and I have been part of at uddi-dev list. The thread begins at: > > http://lists.oasis-open.org/archives/uddi-dev/200506/msg00005.html > > It had a funny climax at: > > http://lists.oasis-open.org/archives/uddi-dev/200506/msg00031.html > > Thank you. > -- > Regards, > Farrukh ------------------------ Yahoo! Groups Sponsor --------------------~--> Fair play? Video games influencing politics. Click and talk back! http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
