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

[Andrew Hately <hately@us.ibm.com>]

Jørgen,

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):

http://www.oasis-open.org/archives/uddi-spec/200209/doc00006.doc

http://www.oasis-open.org/archives/uddi-spec/200209/msg00056.html

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.

Regards,


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

Farrukh Najmi <Farrukh.Najmi@Sun.COM>

06/22/2005 09:54 AM

To	Jørgen Thyme <jt@globeteam.com>
cc	uddi-dev@lists.oasis-open.org
Subject	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

farrukh.najmi.vcf