[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<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.
|
