Re: ANN: Distributed Registry for Web Services
Thanks for your time and thoughtful comments! With respect to the difficulty of adding the headers. From the client side, it is a non issue because IE, Netscape and Mozilla simply ignore headers they don't understand (much like user mail agents ignore SMTP headers they don't understand). From the server side, it is not that difficult to serve up additional headers. Probably, the hardest part is deciding how to store the information on your file system so that the web server can serve it up properly. That addresses the technical issues. Of course there is still the political issue of adoption. We see (at least) two strategies for getting this technology adopted: 1. The standards route 2. A compelling application The standards route would be to work with the HTTP working group to get the two new HTTP headers adopted. Alternatively, if we were to create an application that demonstrated in a compelling way the utility of this approach , then that would lead to a nice "grass roots" adoption. We are planning on working both routes. [we are searching for ideas for a compelling application. Any thoughts ... anyone?] With respect to support for other transports there are two issues. The Meta-About header does not cause a problem because it can point to non HTTP resources. In the case of Meta-Location you are correct, that this extension only supports the HTTP protocol. This does leave SOAP running on other transports out in the cold. However, the alternative of adding this information to the SOAP header as in the WS-ROUTING specification would be a SOAP only solution and not helpful for classic RESTful services. Our feeling was that supporting HTTP based SOAP and RESTful services was where the majority of action was happening. Our architecture also allows metadata to be associated with any web resource not just web services. Of course, it would be easy to also add the meta-location tag to the SOAP header to bring non HTTP SOAP services into the fold. I hope this explanation helps. From your comments, you seem to be coming from the SOAP centric perspective, where as we were focused on the web resource/service perspective which is heavily linked to the HTTP protocol. Thanks again for your time and comments! David Chiusano Joseph wrote: >Hi, > >I just finished reviewing the Proposed Architecture on your site, and >there is a lot of good information here. I wanted to provide feedback >without subscribing to the group (I hope it's ok that I do so here). > >The biggest question I have is: why are new HTTP headers being proposed? >I ask for several reasons: > >(1) It seems to me that it might be difficult (logistically, >politically) to add new headers to the HTTP protocol, although I may be >very wrong on this. > >(2) From a technical standpoint, if new HTTP headers are added, how will >existing implementations of HTTP servers and clients be affected? Will >the new headers be "transparent" to them? Or, will there be adverse >effects unless the implementations are updated to "recognize" (even if >they ignore) these new headers? > >(3) Adding new HTTP headers means that Web services that are transported >over other protocols (UDP, BEEP, TCP/IP, to name a few) will not benefit >from this approach. > >(4) I believe the Web services world (partly for the reason in #3 above) >is moving away from relying on the underlying transport mechanism for >specific functionality, and is instead specifying this functionality in >the Web services specifications themselves. For example, in WS-Routing >(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-routing.asp >- part of the Microsoft Global XML Web Services Architecture initiative, >or GXA), the placement of destination addresses for a Web services >message route is specified in the SOAP header, because HTTP cannot >provide this level of routing capability. WS-Routing also makes SOAP >more protocol-independent by specifying placement of destination >addresses in the message header to create a route for the message to >take. > >Kind Regards, >Joe Chiusano >Booz | Allen | Hamilton > > >"Roger L. Costello" wrote: > > >>Hi Folks, >> >>You are invited to participate in the collaborative development of a >>distributed registry technology. >> >>We have created a list (distributed-registry) for discussion of this >>topic. To subscribe to the list send an empty email to: >> >> distributed-registry-subscribe@y... >> >>Here is a description of the purpose of a distributed registry: >> >>A Web service registry provides information about what services do, and >>how they are used. Today's Web service registries (e.g., UDDI and ebXML) >>are implemented as centralized repositories. That is, all services store >>their service descriptions within a single, or a small number of >>registries. The purpose of this effort is to develop a concrete, >>implementable architecture for a highly distributed registry. The notion >>is that each Web service defines their own registry - comprised of the >>collection of documents that describes the service. >> >>We have created a Web page which >> - lists the design goals for a distributed registry, and >> - proposes an architecture >> >>Here's the URL to the Web page: >> >> http://www.xfront.com/dist-reg/distributed-registry.html >> >>We invite you to participate in the development of this technology. >>Thanks! >> >> Roger L. Costello and David B. Jacobs >> >>----------------------------------------------------------------- >>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an >>initiative of OASIS <http://www.oasis-open.org> >> >>The list archives are at http://lists.xml.org/archives/xml-dev/ >> >>To subscribe or unsubscribe from this list use the subscription >>manager: <http://lists.xml.org/ob/adm.pl> >>
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