[
Lists Home |
Date Index |
Thread Index
]
> From: Paul Prescod [mailto:paul@prescod.net]
<snip/>
> 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.
No, I am not muddying anything. You are the one taking terms with specific
meanings within one abstract model that is applicable to one domain and
proclaiming it to be a universal truth applicable to all domains. The OSI
model and REST does not help design business logic in a CRM system, or a SFA
system, or a system managing clinical trial data, or a hotel reservation
system, all things that I have worked on in my career.
It is terribly narrow-minded and arrogant for someone who works entirely
within one domain to lecture those working in other domains that the
principles of design and architecture they work with are irrelevant, and
that only the models that serve their own domain are the things that any
software developer need worry about.
This is deja vu to me. I heard the same sorts of things from those working
in dotcoms who used to lecture me when things were booming that I was the
one that didn't get it, that the old rules of software engineering and OO
architectures no longer mattered; the web "changed everything" and the old
rules no longer apply. I tried to tell them otherwise, but they wouldn't
listen. I had a manager try to lecture me about what a misguided risk I was
taking resigning from a successful company that prospering helping companies
establish their "web presence" and shaping their "branding strategies" for
the web. I told them they were the ones making a serious mistake, and things
were going to end badly. Everyone I knew there has long since lost their
jobs. Many of them are having difficulty finding new ones. Yet even in these
difficult economic times, I get unsolicited email messages from headhunters
and HR staffers desperate for people who understand enterprise software.
So when I hear folks lecturing those designing web services, telling them
that all they need to know is REST and the OSI model, all I hear is people
who want to lead developers to the unemployment line. Deja vu all over
again.
When business developers start implementing real world web services, they
will need to understand the software development lifecycle. They will need
to understand the same old software engineering principles that applied
before the web. They will need to learn the same design patterns that
emerged in the OO world, because they are still just as applicable. The OSI
model and REST won't help, here. And those preaching REST as the only thing
a developer must know about designing web services are just being
narrow-minded and arrogant. When you have built a complex ERP or CRM system
using nothing but REST principles, then you might find a more receptive ear
from me. Right now, you are just preaching religion, and I can't solve
business problems with religion.
And by the way, if you really want to insist that the OSI model has somehow
laid some exclusive claim on the words "application" or "protocol", I
suggest you look those terms up in the dictionary.
> [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."
Oh, I see you have looked it up in the dictionary. Yet you live in denial
and choose to engage in some creative editing here. Let's be honest:
From http://www.dictionary.com/cgi-bin/dict.pl?term=protocol&r=67:
pro.to.col (prt-kol, -kl, -kl)
n.
1. a. The forms of ceremony and etiquette observed by diplomats and heads
of state.
b. A code of correct conduct: safety protocols; academic protocol.
2. The first copy of a treaty or other such document before its
ratification.
3. A preliminary draft or record of a transaction.
4. The plan for a course of medical treatment or for a scientific
experiment.
5. Computer Science. A standard procedure for regulating data transmission
between computers.
I count 6 definitions, there.
Now let's look up REST
(http://www.dictionary.com/cgi-bin/dict.pl?term=REST):
rest2 (rst)
n.
1. The part that is left over after something has been removed; remainder.
2. That or those remaining: The beginning was boring, but the rest was
interesting. The rest are arriving later.
Uh, oh. We have a problem. Looks like your REST principles don't actually
exist. Why are you muddying the waters redefining terms, here?
Well, maybe we can salvage this. Let's look up "web service". Whoops! It
tells me "No entry found for web service in the dictionary". Now we have a
real problem. It looks like there is no such thing as web services, too.
Your dogma unravels even with the reference you offer to try to prop it up.
<snip/>
> > 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?
You and Mark did when you insisted that the only "intent" in the message is
POST. As far as the application that actually processes the order, POST has
nothing to do with the intent. And it is terribly narrow-minded and arrogant
to lecture the developer who has to implement that application that the only
application, here, is HTTP and the logic he had to implement is just an HTTP
extension.
<snip/>
> 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?
Of course not, and I have never contended otherwise. You are the one
contending that when I implement an SFA system, or a CRM system, or a hotel
reservation system, that all of the business logic I am writing needs no
architectural model other than that which tells me that everything I am
writing is just an extension of one thin layer in the OSI model of a
protocol stack. How terribly arrogant and narrow-minded, Paul. When I am
implementing a system with complex business logic, architecture is important
-- but not archtecture that belittles the domain in which I am working and
tells me the problem I have to solve is not what is important. REST and the
OSI model will not help me with that business logic.
|
