[
Lists Home |
Date Index |
Thread Index
]
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
|
