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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] ANN: Distributed Registry for Web Services

[ Lists Home | Date Index | Thread Index ]

Farrukh Najmi wrote:

> My experience with google is that you still have to page through 
> hundreds of entries. It is just that it is better than the old days. 
> What is really needed is an ability to do semantic queries to find 
> what you are looking for more precisely. ebXML Registry supports 
> advanced query capabilities that make it possible to define more 
> precisely what you are looking for/

>
> Federation is nothing more than a collection of registries that have a 
> common purpose. Someone needs to track the Federation and its 
> membership. This is called Federation metadata and it can reside in 
> any ebXML Registry (usually one of the members but does not have to 
> be). A client issues a federated query to any  federation member 
> without needing to know of or specify the members. The federation 
> member dispatches the query as a parallel distributed query across all 
> reachable Federation members and then awaits the responses. It then 
> joins the responses in a unified response and return it to the client. 
> Partial results are handled as warnings.
>
This is still pretty heavyweight.  It requires setting up a registry 
server or being given access to someone else's registry server.  And it 
still does not solve the problem, that if I have been given the URL of a 
service (not the URL to the meta data) and I don't know the location of 
the right ebXML registry I can't find the meta data.

With respect to Google not having the semantic acumen that you would 
wish, I would agree.  But I don't think declaring a particular query 
capability "solves this problem" gets us there either.  There needs to 
be a separation of metadata and the things that operate on the metadata. 
 With repositories like ebXML, they encapsulate the data and how to 
search it and if you don't like either, well, that is just too bad.  I 
would much rather use the standard web mechanisms to publish metadata 
and have separate services fight out the best way to compile and search 
that information.  This allows different factions to promote different 
forms of metadata and different methods for searching the metadata. 
 With the result (I hope) of having the best solutions rise to the top.

Again, for web services to really take off, the barrier to entry needs 
to be very low and increased functionality should only come with small 
additions of complexity.  Our architecture does not require publishers 
setting up a new server (separate from the service).  It makes it 
instantly searchable by the world without users having to "buy-in" to 
your solution, while still making it simple for groups to experiment 
with different metadata representations and searching techniques to 
expand capabilities.

Does that make it clearer what we are shooting for?
David






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS