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 --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/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/
begin:vcard fn:Farrukh Najmi n:Najmi;Farrukh email;internet:[EMAIL PROTECTED] tel;work:781-442-9017 url:http://ebxmlrr.sourceforge.net/tmp/farrukhRacePointIcon.jpg version:2.1 end:vcard
