[
Lists Home |
Date Index |
Thread Index
]
Farrukh Najmi wrote:
> Typical use case we have seen is one where Service is discovered in
> the registry. I am not clear on the use case you mention where client
> knows the URL to the Service and wishes to find it in the registry.
> Can you elaborate on your thinking here.
Our thinking is that web services should be an integral part of the web.
This means that if someone puts a pointer to a service on their web
page it should be easy to exploit that information. In the days before
Google, when performing keyword searches you would often have to page
through hundreds of results to find what you wanted. Current registry
efforts feel like they have the same scaleability problem. They work ok
for now because the offerings are so paltry but if there were many,
finding the one you want could prove time consuming. We wanted to
leverage Google's PageRank(tm) reputation system to see if we could
avoid that problem from the start.
> The only feature that requires some configuration is "federated
> queries". The idea was to prevent the client from having to specify
> scope of federated query
How do federated queries work? I'm not sure I understand the mechanism
that registries discover each other to pass queries.
>> ps. Are registry entries visible to web crawlers like Google? We
>> though it was important to facilitate Google's ranking system for web
>> services.
>
>
> This is an interesting question. I am not clear on how web pages get
> indexed by crawlers like google. All registry objects (metadata) and
> repository items (content) in ebXML Registry is accessible via HTTP.
> What would need to happen to make that metadata and content be visible
> to crawlers like google?
>
Because web crawlers purposely try to avoid crawling dynamic content, it
takes some effort to make a dynamic site (e.g., a registry) present
itself as easily crawlable. It is possible though, and might be a
design consideration the ebXML working group wants to take up.
David
|
