[
Lists Home |
Date Index |
Thread Index
]
David Jacobs wrote:
> 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.
If your focus is Web Service advertising with minimal infrastructure
then I agree with Joe that WSIL may fit your needs better. An ebXML
Registry provides may indeed be overkill for that focused use case.
ebXML Registry becomes interesting when you want to manage arbitrary
content with validation, cataloging and ad hoc query needs.
> 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 are correct that the ebXML Registry's HTTP interface can be used by
clients instead of SOAP so client infrastructure requirements could be
limited to the ability to make an HTTP request and be able to generate
and consume XML request/response documents.
> 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.
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.
Most of the various distributed registry features do not require
registries to be federated (or they are implicitly federated as you put it):
-Inter-registry object references are handled without any federation
configuration
-Object replication from one registry to another is handled without any
federation configuration
-Object relocation from one registry to another is handled without any
federation configuration
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
>
> 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.
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?
--
Regards,
Farrukh
|
