[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 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.
|
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
|