I suspect that I may not have done full justice to the other party in this matter; if so my apologies. In general it is better if people try and remain impersonal. It is easy to level accusations of bias and partiality - most people writing about an area central to their work cannot easily be impartial, nor is it inappropriate for them to present their case in a reasonable manner. The arbiter should be the facts presented in a way so that they speak for themselves.
Gervas --- In [email protected], "Gervas Douglas" <[EMAIL PROTECTED]> wrote: > I obviously need to be more vigilant as a Moderator and get out my > electronic tawse. My apologies, Anne, for letting that slip > through. Apart from basic considerations of etiquette to which I am > sure we all aspire to adhere, it is unwise to attack Anne at a > personal level as the lady has a stellar reputation, and any such > attacks are liable to backfire. > > Gervas > Moderator > > > --- 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 --------------------~--> 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/
