|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: ANN: Distributed Registry for Web Services
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||

Cart








