OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [uddi-dev] ebXML registry and UDDI comparisons


One of the areas that I've been looking at recently is the implications of centralized control of a lot of the metadata listed in Farrrukh's note below.  Useful results from queries on the information beyond what is part of a standardized (generated) index will only be achieved if service metadata is committed to the centralized repository as a natural part of both the service development process and service deployment to the runtime environment.  Regardless of the underlying registry standard, be it UDDI or ebXML, there is still more work required in the standards arena to best enable the connection to development and deployment process without placing an unnatural and unnecessary burden on the developers and deployers of services.  So to your original question, of whether the solution from vendors will be based on adding ebXML repository support to the UDDI registries, I think it will depend largely on whether that is the most straightforward and obvious solution to a capturing development/deployment artifacts relating to services.  There are a number of other data models and content management APIs that also warrant consideration since they may already be associated with modeling, development and deployment tooling, such as RAS from OMG, WebDAV, JSR168 from the Java process and others.  In the short term, I don't believe we've hit the limitations of either registry data model and our time is probably best spent investigating whether it is more natural to store or reference different types of metadata produced by the tools used by different people at different stages in the lifecycle of a service.  I think the UDDI registry approach of a standardized centralized registry index over several existing repositories and remote documents has signifcant merit and value for the time being.  Over time some compelling use cases will likely emerge that would justify some binding and constraining of the repository implementation to a model related a registry index standard.

Although some of the responses in the thread below were unrelated to your original question, I have some concerns on some of the query patterns Farrukh mentioned below, such as restricting queries for services by underlying implementation.  While it may be useful to track such information in a cenrtralized location for systems management tools, providing a general query framework and solution outside of careful evaluation of the use case and context for such information may only provide a fast path to lock-in or fragile integration.  An application that uses some of these queries as selection criteria may violate a key principle of using standards for integration which is independence of implementation between the message consumer and message sender.

If you have a set of use cases or tasks where you have a short term need to identify the capabilities and differences provided by the standard, I've rarely seen unbiased evaluations, but the closest thing I've seen was in a September 2002 email comparing tasks between UDDI V3 and ebXML v2 (first link is the document, second link is the email message it was attached on):



Obviously these are a bit dated and it might be useful to reevaluate against both real implementations as well as just the specifications, but the document is a use case driven evaluation as opposed to a marketing driven feature list that makes one technology have more checkmarks on the list than the other.


Andrew Hately
IBM Software Group, Emerging Technologies
email: hately@us.ibm.com

Farrukh Najmi <Farrukh.Najmi@Sun.COM>

06/22/2005 09:54 AM

Jørgen Thyme <jt@globeteam.com>
Re: [uddi-dev] ebXML registry and UDDI comparisons

Farrukh Najmi wrote:

> Jørgen Thyme wrote:
>> I have looked at the specs for v3 for the ebXML registry.
> I am very glad that you took the time to do so. Others with less
> patience may find it easier to read link [6] in following:
> http://ebxmlrr.sourceforge.net/tmp/ebXMLRegistryLinks.html
>> Although the information model looks more detailed than in UDDI my
>> immediate thinking was that adding my taxonomies in UDDI I can
>> achieve a lot.
> As far as I know, adding new taxonomies (complete with taxonomy
> values) is quite vendor specific in UDDI 3. Also there is no standard
> way to extend values for standard/checked taxonomies for domain
> specific profiles.
> Also as you hinted at there are many additional features in ebXML
> Registry. See link [8] in following:
> http://ebxmlrr.sourceforge.net/tmp/ebXMLRegistryLinks.html
> The big difference is that ebXML Registry has a standard repository
> where things like WSDL, Schema, BPEL etc. can be published, versioned,
> governed, discovered, reused  etc.

Subtle but important point is that what gets published to the ebXML
Registry is not just pointers to above artifacts but the actual  
artifact. Pointers to externally managed artifacts are also supported
but then you cannot  benefit from many of the lifecycle management and
governance features of the ebXML Registry for these artifacts.

> This allows things like fine grained access control of such artifacts.
> A key feature is our content validation and cataloging services. We
> will be showing at JavaONE 2005 (June 26-June 30) at booth #802, how
> simply publishing a WSDL (the actual WSDL not just some pointer to it)
> to the registry results in a WSDL cataloging service to be invoked  
> that generates all the metadata for the WSDL based on  processing of
> the WSDLs. We then show how custom WSDL specific queries can be used
> to do discovery queries like:
> -Find all WSDL doc that use a specified namespace patter
> -Find all Bindings or Services that have a certain text pattern in
> their documentation
> -Find all Bindings that are SOAP bindings AND use DOC Literal style
> AND do not use HTTP  as transport

While the list of WSDL related queries being defined by the WS profile
for ebXML Registry is still growing I neglected to mention a couple of
other important queries supported:

-Find all WSDLs with Service implementations that use specified
implementation platform (J2EE, .Net, ...)

-Find all WSDLs with Service implementations that use specified platform
resources (Database, JMS, JAXR...)

> The discovery queries are open ended and can be defined in a standard
> manner by verticals, administrators and even end users fully supported
> by the standard.
> Finally, the ebXML Registry TC is working on defining a series of
> "Profiles" of ebXML Registry usage for various verticals and domains
> specific use cases.
> One key profile is a WS profile which will standardize how WSDL is
> managed in an ebXML Registry.
> Imagine now, given that any two ebXML Registries can organically
> federate together and a user can query the federation of registries as
> if it were a single registry,
> that our WSDL Discovery queries can now search for WSDL across any
> number of registries and return a unified result. And all this with
> very fine grained ability to do access control.
> In a nut-shell, ebXML Registry is about "Enabling, Secure, Federated
> Information Management".
>> And there are several implementations of UDDI.
> As there are of ebXML Registry. These include Sun, Adobe, ebXMLSoft,
> Infravio, KTNET and several others.
>> What are your thoughts? Will vendors of UDDI registries add ebXML
>> registry functionality to their existing products? Or will there be a
>> complete new set of registry products coming?
> For my thoughts on the future of registry standards see:
> http://sourceforge.net/mailarchive/forum.php?thread_id=6572826&forum_id=8944
> Lastly, I request that people avoid flaming me for this email. I do
> not say anything negative about UDDI but only state facts about unique
> features of ebXML Registry. Thanks you.
> --
> Regards,
> 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 )
> Federated Information Management Architect: Sun Microsystems
>To unsubscribe, e-mail: uddi-dev-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: uddi-dev-help@lists.oasis-open.org

To unsubscribe, e-mail: uddi-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: uddi-dev-help@lists.oasis-open.org


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]