[
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
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@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.
>>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>
>>
|
