[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Categories of Web Service messages: data-oriented v
Michael Brennan wrote: > >... > > Sorry. I disagree. The protocol layers are not intrinsically capped. You are > just imposing the perspective of one protocol layer and declaring it as > absolute. HTTP is not the center of the computing universe. I could just as > well argue that TCP is the top level protocol and HTTP is just tunnelling. As far as I know, HTTP respects *all* of the semantics of the TCP protocol. In fact, the binding between HTTP and TCP is very clean and natural. But HTTP is not an extension of TCP because it depends on a minimal number of services from TCP -- just a streaming, bidirectional connection. > Indeed, terms evolve and change their definition over time. Thinking that > you can freeze vocabularies and cast them in stone forever is terribly > naive. The terms are extremely expressive as they are. You want to make them muddy by using an application protocol as a transport protocol. I think that the burden is upon you to argue why that change in terminology and model is virtuous. > ... Web services have opened up the possibilities of layering new > protocols upon HTTP in rich ways -- and in ways such that these higher level > protocols are not dependent upon whether they are operating over HTTP, or > SMTP, or some other transport (and from the perspective of these layers, > HTTP is transport, not the application layer). This is the faith. A protocol is a definition of how to move bits around. Does it actually make sense to define a protocol that doesn't care about how the bits are *actually* being moved around, whether they are being moved around reliably or unreliably, synchronously or asynchronously. > ... The protocols are based on > the correlation of message structures between requests and responses. So > where is the metaphysical law that declares that such a formulation cannot > be considered a protocol? Sure, you can tunnel a protocol on top of a protocol. Nobody said otherwise! You could run IP over SOAP...or over pigeons for that matter. You haven't yet made a case that infinite the tower of protocols buys you any power. I'm asking for a technical argument instead of an assertion. It would be easy to prove me wrong. Describe a web service that requires a nine-layer stack and cannot be implemented through HTTP and semantically-compatible extensions. > ... The view you put forth is very narrow and biased, > and it simply denies innovation and the evolution of technologies. I would > argue that your definition of "protocol" is just too narrow to be useful to > web services. You've asserted that. Please demonstrate it. > > That is not true. SOAP authentication will be an extension of > > SOAP. > > Oh really? So when I send a PDF document over HTTP, does that mean PDF is > just an extension of HTTP? No, because the PDF document will have no knowledge that it is being embedded in HTTP. It has no integration with HTTP semantics. Similarly, HTTP does not really know about TCP other than that it is a stream-oriented, connection-based reliable data protocol. On the other hand, SOAP authentication is called SOAP authentication because it is explicitly designed to integrate into, and build upon, the SOAP model. It isn't called "protocol authentication" because it is explicitly tied to SOAP. It is an extension of SOAP. But in fact, SOAP authentication is neither a protocol nor (AFAIK) does it claim to be one. > ... Some of the arguments that get advanced, here, > really baffle me. Just look at SAML[1], or DSML[2]. These provide SOAP > bindings of their structures, but also allow bindings to other "protocols" > (and, yes, dammit! I am using the word "protocol", here). How would you > argue, then, that SAML or DSML are just SOAP extensions? (AFAIK) SAML and DSML do not claim to be protocols[1]. That's why they end in "ML", not "P". They do not define standards for the transmission of data across networks. They don't say which actors speak in which order. I would say that they are more like data formats than protocols. So we come back to your question: is sending PDF over HTTP a "new protocol?" [1] http://www.dictionary.com/cgi-bin/dict.pl?term=protocol&r=67 "A set of formal rules describing how to transmit data, especially across a network." > It is interesting that on the one hand folks would argue that actions and > data should not be coupled, but on the other hand any modular vocabulary > ever employed within a SOAP envelope must be viewed as just an extension of > SOAP. I'm struggling to see any relationship between the discussions. > <snip/> > > > It is provably the case that POST is sufficient for the operation > > because you are doing it. > > Bullshit. POST is simply sufficient to get the body of the message to the > application that will process it. Fine. POST is doing the job of a protocol. Getting data across the network from the process that generated it to the application that will process it. Thanks to URIs, you know what the POST's more precise semantics are. There is no need to put behaviour in the content of the message. >... > Yup. If you hack an HTML form and change it to send up parameters of your > choosing, do you seriously expect that the receiving application can make > use of them? No. If you send the wrong data through a protocol then you are going to break your application. If I send a string through an XML-RPC method and someone else sends an integer, do we have two different protocols? > .. The application serves up a form with specific parameters to > the client, and it expects those paramters -- and no others -- to come back > to it. You want to attach another name to this? Fine. I call it a protocol. I don't want to attach a name to it. Why bother? Everybody understands that HTTP is the protocol! Maybe I'd call it a "web app." It certainly isn't a protocol. > But certainly it is ridiculous to maintain that that data is meaningless and > has no relevance to the interpretation of the message. Who said either thing? The data has meaning. But it is different than the protocol. Consider the following Java code: class foo{ void doit(String action, Object arg1, Object arg2, Object arg3, ...){ if(action="calculate_factorial"){ return factorial((Integer)arg1); }else if(action="calculate_sum"){ return (Integer)arg1+(Integer)arg2; } } } (let's pretend that Java was a Real Language, had varargs and could add Integers) Now if you were taught to program in this style, you might think it odd when someone told you that there was really no need to dispatch on a name passed as data. In fact you could move that out to the method name (or in the case of the Web, to the URI/method combination). >... > Are you seriously contending that we now have all of the protocols we will > ever need to do whatever we want in the computing world? We are all done and > can all go home now? Do we have all of the extensible, generalized markup languages that we need? Are you spending significant amounts of your time researching YAML, LaTeX and S-expressions? A markup language is a way for expressing attributed trees. Once you've done it once, the best you can hope for are incremental improvements in performance or simplicity. IMHO, your time is better spent building layers upon it. (call them vocabularies, dialects, extensions, whatever) An application language is a way for moving data from place to place and saying what to do with it. Once you've done it once, the best you can hope for are incremental improvements in performance or simplicity. Your time is better spent building layers upon it. (call them extensions, dialects, protocols, whatever) Of course there are performance reasons to bypass XML sometimes, and the same goes for HTTP. But in my opinion, it would be insane and strictly speaking incorrect to claim that XML is not sophisticated enough to represent some sophisticated data, or the lambda calculus is not sophisticated enough to represent some computation or that HTTP is not sophisticated enough to represent some application's network requirements. > And all those J2EE servers being deployed could be replaced with servers > that simply understand HTTP GET and POST? J2EE is not a protocol. HTTP is most often the protocol that is used with it. >... > Please don't start throwing titles at me. Titles don't impress me. My point was just that Mark's job for the last several years has been applying protocols to real-world problems. Your inference was that you have Real Problems and that he is just a theorist. My claim is that he has bet at least one, and probably two businesses on *software* that implements this "theory" to solve real-world problems. You'll notice that the chairman of the Apache foundation is also in the business of solving real-world problems with HTTP. So is Rohit Khare, an extremely smart ex-W3C employee. Another ex-W3C employee (Henrik Nielson) is at Microsoft and perhaps coincidentally (I really don't know) their .NET My Services protocol has only a very few methods that map essentially to the HTTP methods (query, insert, replace, update, delete). It isn't called HTTP because that wouldn't be cool but it is essentially a variant of it reimplemented on SOAP. So they've added two layers to the protocol stack to get back to the same place. As I've demonstrated, UDDI did the same. Watching for this pattern in the future.... >... I am just viewing this as > a rather spirited debate, though I'll confess to some frustration trying to > converse with folks who seem to think that rich distributed systems can be > constructed using purely the semantics of GET and POST. The simple fact is, > that is too constraining. Actually, we advise using GET, POST, PUT and DELETE. As I've said, those map to .NET My Services (which is intended to be a universal personal data management protocol) but they also map to SQL's SELECT, INSERT, UPDATE, DELETE. Is SQL too weak for real work because of its paucity of methods? The Unix shell has >,<, >> and rm. The DOM has childNodes[x], insertChild, replaceChild and removeChild. UDDI has get_*, delete_* and save_* (it uses one less method...). I don't think that this pattern is being copied from place to place. I think it is a reflection of some fundamental laws of the universe. HTTP is merely one expression. But I don't want to focus too much on the methods to the exclusion of the URIs. The URIs are as, if not more, important. It is the combination that allows you to use generic methods and separate protocol and data. Paul Prescod
|
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
|