Remember the waterfall? In 1970 W.W.Royce wrote an article describing a sequential development process that works like a waterfall. He argued against sequential development as being risky and inviting failure, and proposed instead an iterative model with each phase influencing the previous ones.Now most people don’t read technical articles, but they like imagery and free association. So they remembered the waterfall. And it’s written about, so it must be good, right? Ironically that article lead to people promoting the same methodology it argued against. The Big Design Upfront.
Both diagrams show two decisions I’ve made for the book: first, we draw a distinction between Resource-Oriented and Service-Oriented architectures. Second, we define HTTP+POX as a hybrid of the two architectures. The former because it’s not useful to pit a technology against an architecture (as in “SOAP vs. REST”).
I like searching for answers online, I like buying things online, and as much as I hate doing my taxes, it’s easier when some magical service does all the mind-bending calculations for me. In short, I like services, especially online services. They’re a future I can’t imagine living without, and I’m passsionate about doing more with them.
Now when it comes to choosing technology …
You see, the moment you divide the world into services and non-services, those non-services no longer matter. I’ll trade you one good online service for all the Resource-Oriented things in the world. I don’t know what that means anyway, so I don’t care.
The moment you fit a service fence around SOAP, you’ve sealed the fate of any other technology. Sure you can argue implementation details, but people don’t care beyond the simple question: is it a service or not?
Let’s try a different take on names.
Let’s have a category of services that we call Resource-Based and implement the REST way. And a category of services that we call XML-Focused that we implement with XML/HTTP, only because it differs from REST in being “XML Strict†and damn the other principles. We can add another category of services, and I’ll call it Simplicity-Driven, to describe things like JSON and AJAH. Anything based on the “simplest thing that works†goes in that category. And last, but not least, we have a category of services we call Object-Access implemented using SOAP and sons.
You do remember SOAP stands for Object Access, right?
I like this naming convention better. It leaves REST in the neutral category, you can’t argue that Resource-Based is good or evil. AJAH gets on our good side, after all who can argue with simplicity? XML/HTTP is for people devoted to their angle brackets, so we can safely ignore them. And as for SOAP … anyone care to admit they want to do remote object access over the Web?
I thought so.
Names deserve more credit than we give them. When you choose to put a value system behind a technology, choose wisely. Because anything higher up than lines of code has sort attention span, free association and sticks to catchy names like superglue.
This is all to say, great book idea, but please reconsider the ROA vs SOA distinction.