[
Lists Home |
Date Index |
Thread Index
]
First off, I should note a caveat. I have only a cursory knowledge of
the workings of an ebXML Registry (I'm trying to come up to speed).
There were a number of issues we were trying to avoid with our
proposal. We wanted to minimize the work required for setting up and
advertising a web service and maximize our leverage of existing web
technologies.
With respect to these goals an ebXML Registry seems to require yet
another piece of server software to be installed and maintained. This
means increased chances for security holes and more work for system
admnistrators. It is also another authentication/authorization base to
maintain. It also means that clients not only need to understand HTTP
but also SOAP (although I see from your message that they are working on
a more RESTful HTTP access). Lastly, it seems to have the problem, that
if given a URL of a web service how do you know which registry to query
or which set of federated registries to query (or are all registries
automatically federated with each other?). I admit this problem may
just be my misunderstanding of how registry discovery (as opposed to
query) takes place.
Thanks for your comments. If an ebXML registry turns out to be more
lightweight than I expected, then it becomes a lot more interesting.
David
ps. Are registry entries visible to web crawlers like Google? We
though it was important to facilitate Google's ranking system for web
services.
Farrukh Najmi wrote:
> Hi Roger,
>
> The ebXML Registry V3 is defined as an open standard by the OASIS
> ebXMl Registry TC [1]. It supports a loosely couple distributed model
> where registries are peers and do not require any prior contract. The
> following distributed registry features are supported:
>
> -Inter-registry object references
>
> -Registry federations
>
> -Federated queries using SQL 92 and XML filter query syntax
>
> -Inter-registry object relocation
>
> In addition features the following features make the registry
> attractive as a general purpose content management solution:
>
> -Handles arbitrary content (Any type of Service description and
> anything else is supported)
>
> -Automatically validates and catalogs arbitrary content upon
> submission in a content specific manner
>
> -Allows discovery of content using ad hoc queries in SQL 92 and XML
> Filter query syntax
>
> The registry has a long list of additional features. Details are
> available from the specifications [2] and also from a recent slide
> presentation [3] in html form. Finally, an open source implementation
> named ebxmlrr [4] is available with a active and healthy user
> community. This includes a standard Java API for XML Registries called
> JAXR [5].
>
> ebXML Registry is being used for a variety of purposes in a variety of
> verticals including healthcare, eGov, Automotive, Travel etc. Version
> 3 is adding distributed capabilities as well as Content-based Event
> notification and a pure HTTP interface that strives towards REST.
>
> We would like to invite you and your project to consider ebXML
> Registry and help identify limitations it may have in meeting your use
> case. We could work together in the ebXMl Registry TC [1] to address
> any such limitations with the next version of the OASIS ebXML Registry
> Standard.
>
> [1] OASIS ebXML Registry TC
> http://www.oasis-open.org/committees/regrep/
>
> [2] Latest versions of ebXML Registry V3 specs directly from CVS:
> Registry Services spec:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/doc/ebRS.doc
>
> Registry Information Model spec:
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/ebxmlrr/ebxmlrr-spec/doc/ebRIM.doc
>
>
> [3] Slide Presentation on ebXML Registry V3
>
> http://ebxmlrr.sourceforge.net/ebxmlrr-spec/ebxmlrrOverview/siframes.html
>
> [4] Open Source Implementation of ebXML Registry and JAXR API
> http://ebxmlrr.sourceforge.net
>
> [5] Java API for XML Registry 1.0 (JAXR)
> http://jcp.org/en/jsr/detail?id=093
>
|
