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


Feel free to flame me if you don't like the args... ;-)



-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@Sun.COM] 
Sent: 22 June 2005 15:54
To: Jørgen Thyme
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
>  
>



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