Hello everyone, In the heated debate between ebXML vs UDDI, several out-of-date statements were made about X-Registry. To set the record straight: X- Registry... * Does support fine-grained access control using standard UDDI extension points * Can be accessed using any standard UDDI compliant SDK including v2 and v3 * Does support a substantial number of pre-built taxonomies and validation routines including industry specific taxonomies. * Is compliant with UDDI v2 and v3 * Is not based on freebXML but a normalized data model which interoperates fully with UDDI and ebRIM
This disconnect is probably because this research is about a year old--I know the last time Burton group looked at X-Registry was about 11 months ago. The research is not current in other respects as well. I don't think Systinet would pre-announce the bundling of a Repository into their upcoming "Blizzard" platform if they had so effectively demonstrated: "...how well-suited a UDDI compliant registry (without an associated repository) can be for supporting SOA Governance." Thanks, Jim Bole, VP of Products, Infravio --- In [email protected], Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Farrukh, > > I would appreciate it if you would refrained from making > personal integrity attacks on this list. You and I have had > this conversation before, and I've repeatedly supplied proof > to you that your assessment of UDDI is off the mark. Note that > I am not refuting any of your claims about ebXML RegRep. But I > am refuting your misleading claims about the limitations of > UDDI. > > In the spirit of full disclosure, I offer this disclaimer: > > I am a vice president and research director with Burton Group. > (See http://www.burtongroup.com.) I've been with Burton Group > for almost 3 years, and I lead the Application Platform > Strategies (APS) service. The APS target audience is the > application architect. Burton Group's client base is made up > mostly of Global 1000 companies. Approximately 80% of our > clients are end-user organizations, and 20% are vendors or > systems integrators. Burton Group prides itself on its > vendor-independence. We do not produce any vendor-sponsored > research. Our goal is to cut through vendor hype and provide > an independent assessment of products and technology and to > deliver guidance and best practices. > > Each Burton Group research report is divided into two sections: > Analysis and Details. The Analysis section represents our > opinion. The Details section attempts to present facts with as > little bias as possible. The reports are technical and indepth > -- typically 40+ pages long. All APS research is vetted by my > entire team (8 people), and when appropriate, we also request > a review from our other research groups (networking, security, > and identity management). All published research represents > our consensus. > > When I contribute to this discussion list, I offer *my* > opinion rather than Burton Group's opinion, but keep in mind > that my opinion is honed by interactions with my colleagues. > > I completed a research report on the registry market in Q1 of > this year, and as part of that research I conducted a very > thorough analysis of the leading registry products (IBM, > Microsoft, Systinet, SOA Software, Infravio, and Blue Titan), > and I read the latest ebXML RegRep and UDDI specs, technical > notes, and profiles. I've also spoken with about three dozen > customers that use or plan to use a registry product to learn > more about their requirements. Based on this research, I can > unequivocally recommend Systinet Registry above all others as > a foundation for SOA governance, although for those that prefer > to do their own product comparisons, I also recommend looking at > Infravio X-registry and SOA Software Registry. I have not done > an analysis of Sun's registry (it wasn't available when I was > doing my research), so I can't give an informed assessment of > this product. Based on the basic information that Sun > supplied to me when it was announced, though, I recommend some > caution regarding this product, because it does not provide > 100% support for the UDDI protocol, which I view as a critical > requirement for a registry product. Many products need to > interact with a registry, therefore support for the standard > protocol is necessary. > > In most areas, I can't make such a strong recommendation of one > product over the competition because in most circumstances, all > products have a lot of similarities, and the areas of > differentiation are a lot more subtle. In most circumstances, > product selection is very much dependent on project or > corporate requirements. But in this case, Systinet stands > head and shoulders above the competition. The only reason why > I might suggest using a registry other than Systinet's is if a > company has made a decision that it will only use ebXML to > implement web services (in which case I would suggest evaluating > Infravio and Sun). > > At the time I did my analysis, Systinet and SOA Software > registries provided 100% support for the UDDI v2 and v3 > protocols. Systinet also supported UDDI v1. Infravio supported > the UDDI v3 Inquiry API only. Since then Infravio informs me > that they have implemented 100% support for the UDDI Inquiry > and Publish APIs, although I have not personally confirmed it > by installing and testing the product. Outstanding questions > that I have include whether or not it supports the UDDI v2 > APIs and the UDDI V3 Subscription API. > (Miko -- would you care to comment?) > > As I've told this list before, I used to work for Systinet as > CTO. I terminated my employment with Systinet in August 2002. > I was a member of UDDI.org when I worked for Sun (2000-2001) > and was one of the contributors to the UDDI v2 spec. I was > also a voting member of the OASIS UDDI-spec technical > committee (TC) while I worked for Systinet (2001-2002), and I > contributed to the UDDI v3 spec. I was one of the editors of the > "Using WSDL in a UDDI Registry V2" technical note. For the past > three years I have been an observer of both the UDDI-spec TC and > the ebXML RegRep TC. I am much more familiar with the UDDI spec > than I am with the RegRep spec. Considering its limited adoption > in the industry, though, I don't feel it's necessary for me to > study the ebXML RegRep spec in exacting detail. I have read the > entire spec, though, and I do believe that I know more about > ebXML RegRep than most (any?) other analysts in the industry. > > Now, in response to Farrukh's challenges... > > Farrukh wrote: > > First, I want to make clear that I think UDDI is a fine standard > > for the kinds of simpler problem that it was designed to address > > (Yellow /White/ Green pages). Where I think UDDI is inappropriate > > a fit is in complex problems 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. > > UDDI was designed from the beginning to be a generic and extensible > service registry (not a repository) that could be used in a variety > of open-ended and complex use cases. The "green pages" features > (implemented via tModels, bindingTemplates, and keyedReferences) in > UDDI was designed to support registration of any kind of metadata. > Also UDDI v3 was designed to support a foundation for SOA governance. > That's why it supports complex queries, grouped categorizations, > extensible policies, external validation processes, and a > subscription API. The enhancements defined in the UDDI v3 spec were > in response to user requirements based on extensive experience using > v2 (which has been widely implemented since 2001). > > Systinet has demonstrated quite effectively how well-suited a > UDDI-compliant registry (without an associated repository) can be > for supporting SOA governance. And as I said, Systinet's registry is > 100% compliant with the UDDI specification. It doesn't implement any > proprietary extensions to the UDDI data model or the UDDI protocols. > It does make use of the many standard UDDI extension points -- it > uses tModels and category groups, and it uses external validation > routines. It also implements fine-grained access control using > standard UDDI extension points. Systinet also pre-populates the > registry with a number of categorization schemes, and it provides > a number of pre-built SOA governance applications (business > oriented browsers, registration utilities, customizable approval > processes, validation routines, and lifecycle management services). > The Systinet registry is also integrated with web services > management (WSM) products, such as Actional, Amberpoint, HP, and > Reactivity. Systinet is driving a joint vendor effort with about > a dozen other companies called the Governance Interoperality > Framework (GIF) with a goal to define standard UDDI and policy > models for SOA governance. This group has yet to define a standard > charter or bylaws, or to publish any deliverables. Although I'd > prefer to see this group become more formal, I'm pleased to see > some effort happening in this area -- even if it does use a > behind-closed-doors process. > > SOA Software's registry doesn't offer quite as comprehensive a SOA > governance solution as Systinet's, but it does support useful > SOA governance features such as contract management, lifecycle > management, performance monitoring, and security, all based on a > 100% compliant UDDI v3 implementation. > > Infravio's registry also supports useful SOA governance applications, > such as business-oriented browsing, contract management, and > lifecycle management. It's based on the freebXML open source > registry/repository, but Infravio tells me that it also supports > the full UDDI protocols. > > In my opinion (and this is also the vetted advice that Burton Group > gives to our clients), a registry-only solution is *more* appropriate > for SOA governance than a registry/repository combination. As I said > in my last post, it's inappropriate to think that you will be able to > consolidate all service metadata into a single repository -- or even > into a federated set of ebXML repositories. Metadata will be managed > and maintained in many different kinds of repositories throughout the > environment. ebXML RegRep supports federation of registries and > repositories, but that won't help consolidate all your service > metadata. A lot of "system of record" metadata (WSDLs, BPEL, > WS-Policy, etc) can't be stored in an ebXML repository. They must > be stored in web services platforms, in orchestration engines, in > ESBs, in WSM policy repositories, etc. On the other hand, a registry > provides a single point of reference (an index) for all metadata > within the environment, regardless of where the metadata reside. A > registry ought to be able to support rich query cabailities without > a dependency on hosting the actual metadata. This is the fundamental > design center behind UDDI. > > Farrukh also wrote: > > 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). > > While I agree that IBM, Microsoft, and SAP provide pretty basic > UDDI implementations, BEA and Oracle both distribute the Systinet > Registry, which provides rich SOA governance applications built > on top of a UDDI implementation. > > In my past post, when I was describing UDDI capabilities, I was > also referring to the UDDI v3 standard. The only feature mentioned > that is implementation-specific is fine-grained access control, > which is supported by both the Systinet and SOA Software products. > Each product implements access control using its own mechanism, but > both permit you to use role-based access control to access, insert, > modify, or delete any entity within the registry. Note that the > actual mechanisms used to implement access control are irrelavent > to a consumer of the registry service. Consumers simply need to > authenticate to the registry. The registry manages access control > automatically and transparently behind the scenes -- just as a > consumer of a stock quote service doesn't need to be concerned > about how acess control is implemented. > > As I said above, both products provide access control using standard > extension points in the UDDI specification, and they don't rely on > proprietary extensions to the data model or the protocol. A UDDI > registry can support authentication using the UDDI Security API > (get_AuthToken) or using any of the myriad forms of authentication > supported by web services (HTTP Auth, SSL auth, WS-Security, etc). > The specific authentication policies supported by a UDDI registry > instance is a decision left to the organization that operates the > registry. (That's one of the *features* of UDDI -- it lets the > service provider define its own security policies.) > > I've previously supplied you (on the ebXML discussion list) with > example UDDI entity definitions and queries using UDDI standard > protocols that demonstrate all the features that I described in > my last post. Paul Denning has also responded with examples of > how UDDI supports these features. > > Farrukh continued: > > 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. > > Note that Systinet Registry supports the UDDI v1, v2, and v3 > protocols, and you can access it using any UDDI-compliant SDK, > such as JAXR or the Microsoft UDDI SDK. The SOA Software Registry > supports the UDDI v2 and v3 protocols, and it can also be accessed > using any standard UDDI SDK. UDDI interoperability just works. A > UDDI-compliant registry is a web service defined via WSDL. If you > don't have a UDDI-compliant SDK, you can always create your own > interface using the UDDI WSDL and your favorite web services > client tool (e.g., .NET or JAX-RPC). Note that JAX-RPC has > difficulty working with some standard schema constructs, such as > <choice>, which the UDDI schema uses, so the the UDDI-spec TC > defined a simpler version of the schema for use with JAX-RPC. > This simpler schema is specified in a technical note called > "Generating a JAX-RPC Client for UDDI 3.0.2". (See > http://www.oasis-open.org/committees/uddi- spec/doc/tns.htm#jaxrpc11) > Also note that Visual Studio, Eclispe, JBuilder, JDeveloper, > WebLogic Workshop, NetBeans, etc, all include UDDI browsing tools. > Also, all J2EE 1.4-compatible application servers include an > implementation of the JAXR level 0 (UDDI v2 support) API. How > many of these tools and app servers include support for the ebXML > protocol? > > Farrukh continued: > > Features such as federated registries rely heavily on standards > > based implementation for interop across organizational boundaries > > As I acknowledged before, UDDI does not define a protocol that > supports federated queries. It does support references across > registries, though, which some folks might think of as federation. > But as I mentioned above, I'm not convinced that federated > queries across ebXML RegRep instances offers enough value to > offset UDDI's advantages -- especially since a lot of metadata > won't be stored in ebXML repositories. > > <snip> > > A bit further on Farrukh said: > > 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. > > The UDDI protocol defines standard operations to register > information in the registry using the extensible registry data > model. The UDDI-spec TC has also published a number of > Technical Notes that specify recommended models for mapping WSDL, > BPEL, WSRP, and other metadata into the registry. Enterprises are > also free to design new models for capturing additional information > in whatever way best suits their needs. > > When I refer to models, I'm talking about a defined set of > taxonomies which are used to capture metadata information. As an > example of how to capture metadata using a taxonomy model, I > suggest you read the "Using WSDL in a UDDI Registry v2" technical > note. (See > http://www.oasis-open.org/committees/uddi- spec/doc/tns.htm#WSDLTNV2) > > Systinet provides a number of pre-populated taxonomy models to help > organizations get started -- these models are based on their > experience working with customers. UDDI also provides standard > extension points that the registry operator can use to implement > approval and validation routines. Each organization is likely to > want to define its own validation and approval processes, so I > don't think it's appropriate for the UDDI-spec TC to specify > these processes. (Systinet provides a number of pre-defined > customizable processes that organizations can use to get started.) > > Note that UDDI is not a repository, therefore it isn't > approriate for UDDI to define content management processes. > > <snip> > > Farrukh continued: > > 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. > > In UDDI v3, all find operations support complex queries with > nested predicates. I disagree with your assessment that the > query capabilities are limited in practical terms. Assuming that > you have the appropriate taxonomy models in place, you can search > for a service that exchanges messages from a specific namespace, > that supports an acceptable security policy, that provides an > agreeable service level, and that uses a compatible chargeback > mechanism. > > <snip> > > Farrukh continued: > > I view the UDDI tModel essentially as a workaround for UDDI's > > 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. > > But that's the whole point -- UDDI is a general-purpose registry, > not a general-purpose repository. It works on the assumption that > metadata will be stored in their domain-specific repositories. > tModels, as extensible proxies that can represent any kind of > metadata or technical model, are incredibly powerful. > > Farrukh continued, quoting me: > > Anne said: > > > 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. > > I think perhaps you don't understand how UDDI taxonomies work. > In UDDI you are not "at the mercy of a product" to supply > taxonomies. All UDDI registries come pre-populated with a set > of taxonomies that are defined in the UDDI specifications and > technical notes. (Most technical notes define mapping models that > define a set of taxonomies for capturing metadata information.) > These predefined taxonomies are quite generic, and it's assumed > that user organizations will define additional taxonomies that > allow them to capture domain-specific information such as > service status, service level objectives, security policies, > billing or chargeback policies, etc. I expect the GIF group to > define a bunch of recommended taxonomies for many of these issues. > > Some vendors pre-populate the registry with additional taxonomies > as a convenience for users, but users aren't required to use these > taxonomies if they don't want to. The valid value set for a > taxonomy can be loaded into the registry, or it can be managed > externally using an external validation routine. External > validation routines offer a lot more flexibility, because you can > use them to perform validation of the metadata being registered, > not just the registration itself. For example, you can use a > validation routine to check a WSDL for WS-I compliance. (You > can't do that using an internally stored value set.) Whether or > not a vendor provides these types of pre-built taxonomies and > validation routines is an opportunity for competitive advantage -- > snd it's one of the primary reasons that Systinet is so far ahead > of its competition. But regardless of whether or not the taxonomy > and validation routines are pre-built and supplied by the vendor > or developed by the user organization, any spec-compliant registry > *can* support any user defined taxonomy. A taxonomy is represented > by a tModel, and how you use a taxonomy (attach a property to a > UDDI entity using a keyedReference) is explicitly specificed in > the spec. > > Farrukh continues: > > > 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"? > > A Publisher Assertion is the only type of relationship that is > predefined by the specification, but you can also use taxonomies > to define arbitrary relationships. For example, you can define a > tModel that represents the "DependsUpon" relationship. If > bindingTemplate A depends on bindingTemplate B, then you add this > keyedReference to bindingTemplate A's categoryBag: > > <keyedReference > tModelKey="uddi:example:depends-upon" > keyValue="[bindingKey-for-bindingTemplate-B]" /> > > I recommend you read the "Using WSDL in a UDDI Registry" technical > note to get a better sense of how you can use UDDI taxonomies. > > Farrukh continued, again quoting me: > > Anne said: > > > 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 > > 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 > > queriesin a subscription > > > Does it do above? > > Yes. > > > 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. > > You've accurately described the UDDI Replication API, which is > used by the "public" registry nodes (the UBR - operated by IBM, > Microsoft, SAP, and NTT). But I know of no end user companies > that use the Replication API. In fact, I know of no UDDI product > implementations that support the Replication API. (Oracle used to, > but starting with Oracle 10g R3, they will distribute Systinet's > registry instead their older v2 implementation.) User organizations > can use the Subscription API to create replicas and subsets of > registries. If users are concerned about fault tolerance, they often > use database replication techniques. > > <snip> > > Farrukh continued, again quoting me: > > Anne said: > > > 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. > > Burton Group defines three requirements for acceptance into the > superplatform club: > > 1. An extremely broad, feature-rich application platform suite. > 2. A cohesive solution with unified development, security, and > management infrastructure. > 3. Enough market share to have a significant influence on the > market. > > Sun doesn't qualify for the club because it misses the third > requirement. According to all the quantitative analyst firms out > there (IDC, BZ Research, Dataquest, etc), Sun doesn't even appear > on the radar -- the leading J2EE-based vendors are IBM, BEA, Oracle, > and JBoss. Burton Group doesn't currently include JBoss in the > superplatform category because it doesn't have a broad enough > application platform suite yet. (BEA just barely qualifies these > days.) > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/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/
