Re: ANN: Distributed Registry for Web Services
Chiusano Joseph wrote: Joe, > 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. Much easier than adding new methods. Other than that I have some questions about the proposal: What are the intended semantics where a resource denoted by http://www.parts-depot.com/parts has a Meta-Location: of http://www.parts-depot.com/parts and a Meta-About: of http://www.parts-depot.com/parts? One might want to declare more than one Meta-Location for a resource. How would that be handled, or is there a good reason to disallow a one to many relationship other than the fact that teeing up Meta-About with Meta-Location works well as long there's only one each? How does one determine which Meta-Location is authorative? [I'm assuming that it will be the one offered by the origin server of the resource question, but it's not stated anywhere.] What should an agent do when it only finds one header? Are the values of the headers restricted to certain schemes, or are they generic URIs? > (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? That's the advantage of using HTTP headers (a map of well known keys); it's a data driven approach that makes them extensible in a way that helps avoid breaking existing clients. What I don't like about this proposal is the use of pairwise headers - if thee headers are interdependent modelling them otherwise strikes me as mildly brittle . I would suggest using a single header instead along the lines of: <metadesc> := "Resource-Description:" (<ws>)+ <metakeys> <metakeys> := "about=" <uri> ("&location=" <uri>)+ ";" <uri> := ... <ws> := .. The proposal should clarify that these headers cannot be used in HTML markup as a trick to link to metadata about the HTML document (a representation of the resource and not the resource itself). That's the first mess I can see people getting into with this. Btw, there's no support for design goal one in this proposal, since there's no way specified to share reputations, just raw descriptions. As it happens that's a good thing - mixing up reputation management with locating metadata about resources doesn't seem like a good idea. But I suggest dropping it as a goal nonetheless. > (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. Not neccessarily. What's important are the use of URIs to identify all the resources involved, organised as key value pairs; that would be reapplicable to other protocols. > (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. (Hoping to avoid a permathread) HTTP is not a transport protocol. The proposal is an extension to the HTTP application semantics. Most web services are running over the web; it seems reasonable to start with the core protocol. > 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. [Slightly OT, message routing is not the same problem as distributing service descriptions. In any case, hard coding routing steps is a bust from where I'm standing.] Bill de hÓra -- Technical Architect Propylon Transforming Business Integration phone +35314927444; fax +35314927475 http://www.propylon.com
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