Congratulations to Farrukh and Sun.
Farrukh, just to clarify, so that I can represent this product correctly
in conversations within my company and in the US federal government
space: Am I correct in saying that (in the simplest terms) this is
essentially a dual ebXML/UDDI registry product?
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Farrukh Najmi [mailto:]
> Sent: Wednesday, June 15, 2005 1:39 PM
> To:
> Subject: Re: [regrep] [Ann] Sun announces ebXML Registry product
>
> Farrukh Najmi wrote:
>
> > Hi Paul,
> >
> > Thank you for your thoughtful comments. Please see responses inline
> > below...
> >
> > Paul Denning wrote:
> >
> >> At 11:55 AM 2005-06-15, Farrukh Najmi wrote:
> >>
> >>> Dear ebXML Registry colleagues,
> >>>
> >>> I am pleased to share the following announcement of a new ebXML
> >>> Registry product by Sun:
> >>> ...
> >>> http://www.sun.com/products/soa/registry
> >>
> >>
> >>
> >> From the link above...
> >> <q>
> >> ... but SOA projects generate a broader array of service-related
> >> metadata and artifacts than just WSDL's. These include XML
> schemas,
> >> BPEL descriptions, XSLT transforms, and many others. Such
> artifacts
> >> also need to be centrally accessible to promote the
> benefits of reuse
> >> and control, and standard ways of storing and retrieving them,
> >> capabilities that aren't addressed by UDDI.
> >> </q>
> >>
> >> I disagree that UDDI does not address access to XSD, BPEL,
> XSLT, and
> >> other things. I agree that UDDI does not provide a repository for
> >> these things, but there are plenty of content management solutions
> >> available to manage these things, and UDDI can point to them.
> >
> >
> > UDDI does not provide an integrated reporsitory which means that it
> > lacks " control, and standard ways of storing and retrieving them".
> > So for example it does not provide end-to-end lifecycle
> management of
> > these artefacts. This includes publish, update, validation,
> approval,
> > deprecation, undeprecation, cataloging, versioning, access
> control and
> > event notification of these artefacts. What it provides is
> a sub-set
> > of said capabilities for the metadata for these artifacts.
> >
> > Indeed there are plenty of content management solutions
> available to
> > manage these things but they do not do so in a standard way
> > facilitating federation and interop across these content management
> > solutions.
> >
> > Also you find the following useful:
> >
> > [8] LDAP, UDDI and ebXML Registry feature comparison matrix
> > http://ebxmlrr.sourceforge.net/tmp/Registry_Capability_Matrix.html
> >
> >> TN/BP are needed so industry can agree on how to publish
> UDDI tModels
> >> that point to these things. Does ebXML need similar TN/BP
> to define
> >> how to publish these things in an ebXML regrep?
> >
> >
> > ebXML Registry has an approved TN on publishing Web Services in an
> > ebXML Registry. We are in the process of updating that document for
> > version 3.
> >
> > [11] Registering Web Services in an ebXML Registry
> >
> http://www.oasis-open.org/committees/download.php/11907/regrep
> -webservices-tn-10.pdf
> >
> >
> > I am also proposing that we define a WS Profile for ebXML
> Registry 3.0.
> >
> >>
> >> <q>
> >> Another standard in this area that accommodates these
> needs is ebXML
> >> Registry. ...Functions include those for federated web
> service asset
> >> management across multiple repositories. ...
> >> </q>
> >>
> >> I am very interested to learn more about ebXML support for
> federation
> >> across multiple repositories (or registries?)
> >
> >
> > Our specs provide an ability for any spec compliant ebXML
> Registry to
> > organically federate with any other spec compliant ebXML Registry.
> >
> > Please see:
> >
> > [6] Web Content Management using ebXML Registry (XML Europe 2004):
> >
> >
> http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/xml
> Europe2004-webcm-ebxmlrr.ppt
> > (presentation in ppt format)
> >
> http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/xml
> Europe2004-webcm-ebxmlrr.sxi
> > (presentation in Open Office format)
> >
> http://ebxmlrr.sourceforge.net/presentations/xmlEurope2004/04-
> 02-02.pdf
> > (paper)
> >
> > and see details for federation features in ebRS and ebRIM in:
> >
> > ebRS: 9 Cooperating Registries Support
> > ebRIM: 8 Cooperating Registries Information Model
> >
> > [4] ebXML Registry 3.0 Specifications Bundle (OASIS
> Approved Standard)
> > http://www.oasis-open.org/committees/document.php?document_id=12049
> > (the specifications)
> >
> <http://www.oasis-open.org/apps/org/workgroup/regrep/download.
> php/12049/regrep-3.0-cd-02.zip>http://xml.coverpages.org/ni200
> 5-02-14-a.html
> > (Cover pages article detailing new functionality in version 3.0)
> >
> >
> >>
> >> <q>
> >> In addition to integrating this implementation into the Sun
> >> environment, Sun has also added support for UDDI (3.0),
> providing a
> >> service discovery interface for queries made using this protocol.
> >> </q>
> >>
> >> Does the Sun registry support UDDI v3 subscription API?
> >>
> > No it does not. This feature is optional in UDDI 3.0. We do however
> > support the ebXML Registry 3.0 Content-Based Event Notification
> > feature which is much more powerful than the UDDI v3
> subscription API
> > because it allows domain/application specific queries to be used to
> > subscribe to precisely those event of interest to a party.
> >
> > For example with the ebXML Registry Content-Based Event
> Notification
> > feature, you can subscribe to any GIF image being submitted
> that is in
> > Color and has a specified minimum dimension and is classified by
> > Geography of Istanbul.
>
> I should have used a WS example above. How about this next example
> instead...
>
> For example with the ebXML Registry Content-Based Event Notification
> feature, you can subscribe to any WSDL file being
> submitted/updated/versioned etc. that uses a name space that
> matches a
> specified pattern that imports a specified XML schema, that has a
> binding whose name matches a specified pattern and is classified as a
> "GIS Service".
>
> >
> > We made the assumptions that customers do not care what API is used
> > under the hood as long as it is based on an open standard and meets
> > their needs.
> >
> > Thanks again for your valuable comments.
> >
>
>
