[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: > >... > > And you insist that HTTP is the application. (application protocol) > ... That may be sufficient when you > are just shunting documents back and forth across the network -- or when the > work that you do is to implement network protocol stacks. But when a complex > system is developed that has to do sophisticated processing, and HTTP is > employed by it as simply a communications gateway, such a conception is > utterly useless. Barring firewalls, I've never seen a network that was more efficient at transmitting HTTP than TCP or UDP. So why would you use it as a gateway? (the firewall excuse is pretty bizarre to me for reasons that most people are familiar with already) Nobody every claimed that HTTP is the only possible application protocol you could ever have. HTTP is an application protocol. If you're going to design another one, I'd suggest you differentiate it from HTTP rather than reinvent the wheel (as UDDI and .NET My Services did). > ... What is difficult to understand about this? What happens > when I take my system and switch it to receive messages from an MQSeries > queue rather than an HTTP server. Are you going to tell me that there is no > application, now, since HTTP is out of the picture? No, MQSeries has replaced some layer in the middle of the stack (probably TCP). You've probably got some application protocol running on top of it, maybe HTTP. Or maybe you've invented your own application protocol as most people do. This is somewhat like inventing your own markup language to replace XML but somehow people don't understand how difficult it is to do this (harder, even, with HTTP than XML) and so they waste their time. As long as it's *their* time... > ... Or is MQSeries now the > application, and my system is just an extension of it? Your system is the application protocol. > You are clinging to a reified notion of "application" rooted in one > particular protocol stack that -- as I said before -- is *not* the center of > the universe. Our integration system can receive messages over HTTP, from > email, from the filesystem. How can you argue, then, that it is just an HTTP > extension? HTTP is orthogonal to its functionality! Okay, fine, you are tunneling. I've mentioned this possibility on several occasions! There's no law against it. It's pretty inefficient to abuse HTTP in that way but if it's easier to implement than using TCP sockets then go ahead. Just be clear that you aren't using HTTP as it was meant to be used and you should expect a performance penalty for adding a superfluous layer into your app. > ... When you construct a > UNIX pipeline, would you argue that the first command in the pipeline is the > application, and everything else that follows is just an extension of it? Not even roughly analogous. After all, "IP" would be the first command. HTTP would be analogous to the last command. When you use HTTP as a transport, it is like piping your output to Emacs but then deciding that that isn't the final command, but rather just a filter on the way to "grep". You can do it but it is inefficient and why are you really using Emacs instead of directly piping to grep? > I have built many systems that use HTTP, and in each one, HTTP represented > about 1-5% percent of the design and implementation work I've had to do. And > you are telling me that I must subscribe to a conceptual model as I am doing > my design and implementation that views that 1% as having 7 layers, and that > 99% of what I am doing is just an extension of the top of that 1% (and 6 of > the layers in there I don't even need to know about to do my work). I don't > care if this is the OSI model. It is a totally useless model when you are > building enterprise software that solves real business problems. I cannot understand th paragraph above, other than the last sentence. Nevertheless, I think you should provide some evidence of the last sentence. Describe a business problem that cannot be implemented in a reasonable fashion with HTTP and a few extensions. > It is so absurd to contend that the model that suits the design of network > protocol stacks is the one and only authoritative model that all software > design -- regardless of its domain -- must adhere to. I didn't know we were talking about software design. I thought we were talking about networking protocols! I don't write OO programs using network resource modeling. But then I don't write networking protocols using OO. Luckily, someone tried that before me. > ... With all due respect, > you simply have blinders on, and this debate has degenerated into one that > has the character of trying to determine how many angels can dance on the > head of a pin. You think I'm the one with blinders on but I'm asking you for an empirical example of a networking problem that can't be solved in a URI-centric manner with a small set of methods such as the ones in HTTP. You keep claiming that such a problem exists but I can't get you to provide it. You are standing in a small house, looking out the front door > and thinking that everything you see out there is just "the outside -- just > an extension of my house". You think that all that matters is the stuff in > your house. There are others outside looking back at your house and seeing > it as just one of many houses in a big, expansive world that even has many > things other than houses in it. Not every bit of software people write is > primarily concerned with how to shunt bits across the network. It should be > pretty obvious that an architectural model that focuses on this and stops at > the boundary where business logic starts is going to be pretty useless to > someone who is focusing on designing and implementing business logic. Why are we talking about designing and implementing business logic? Maybe the right tool for that is J2EE or Prolog or Visual Basic. What does it have to do with the particular protocol you use to move bits across a network. I didn't propose any model for how you should organize your *code*. I just said that your interface to the network can almost always (modulo performance) be standardized as HTTP just as your interface to structured cross-platform data can almost always (modulo performance) be XML. > As I said in a previous post, if a conceptual model cannot adequately > address real world problems, it is not the problems that are wrong. When > 100%, or 90% or 80% of what you need to design and implement is addressed by > that model, then fine, use it. But when that model is only capable of > addressing 1-5% of what must be designed and implemented, anyone with common > sense can understand that such a conceptual model -- that insists that only > the bottom 1% of the architecture is all that matters, and is the only part > that can be layered, and that the upper 99% is "just an extension" of one > thin top layer in that bottom 1% -- is a totally useless model. You're putting words into my mouth left, right and center. SQL works by SELECTing, UPDATEing, INSERTing and DELETEing. If we had this argument in the 1970s, you would be a hierarchical data programmer telling me that there is no way that any real-world problem could be solved with those primitives (let's ignore the limitations of the table data structure for now!). You'd be telling me that there is no way you could organize your application around those primitives when they are such a small part of your problem. But I haven't said either thing. When you're accessing a relational database, I would strongly advise you use those standardized methods. When you're accessing a network service, I would suggest you use GET, PUT, POST and DELETE. When you're representing structured data, I would suggest you use angle-brackets, elements, attributes and content. I can't stop you from re-inventing the wheel. I can't claim that your project will fail if you do. It may well succeed if you do a good job. > If you want to call what I am doing "tunnelling", then fine. I won't argue > that. Yes, it is tunnelling. But don't tell me that the tunnelling is all > that matters and where all of the architectural focus must be placed. Please give me a quote that lead you to believe that I said anything like this! If you don't want to talk about networking technology, then just say so. But I have no idea why you're indirecting the conversation to "architectural focus" or "conceptual modeling." I'm trying to go back to talking about networking protocols and messaging. 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
|