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 ]

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 

Thanks again for your time and comments!

Chiusano Joseph wrote:

>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
>- 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
>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@yahoogroups.com
>>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.
>>           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>


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

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