Cart
|
[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
 > From: Paul Prescod [mailto:paul@p...] <snip/> > The OSI model has claimed that they are for years. There are up to 7 > layers (sometimes merged). The application is at the top. You can > redefine terminology if you wish but I think it is better to use the > historical terminology unless there is something wrong with it. And you insist that HTTP is the application. 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. 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? Or is MQSeries now the application, and my system is just an extension of it? What if the system is changed to read files out of the filesystem? Is the filesystem the application? 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! 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? 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. 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. 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 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. 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. 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. Anyone who has had to write any real-world application with any degree of complexity in workflow or business logic can understand this point. Anyone who has written such an application can understand the need for a layered architecture in the design to manage complexity. If someone cannot understand this point, I would have to question whether they have ever written such an application. I really need to bow out of this particular debate at this point. I'm too busy for this and we are just running around in circles. 
|
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
|
|||||||||
