07/27/08 :: [SOA] What the remoting bunch will never understand [permalink]
The remoting bunch assumed all their lives a single thread of control be it RPC, CORBA/DCOM/RMI or HTTP.
Their code in "the consumer" "calls" "the provider" as needed and then continues about its business assuming all went well.
So when they see a picture like this one:
They interpret it in their little mind as:
// I am doing a bunch of stuff
[ provider doSomethingForMe: withThatStuff ];
//I just can't stop doing stuff
This is what a sequential programming model does, nothing else nothing more. All they'll ever need is a synchronous client/server middleware. That's why they love HTTP nowadays. They can do anything they want with anyone, without setting up a bunch of things. They can claim they are much more productive than anyone because HTTP is global and its DNS mechanism is a lot easier to use than your typical JNDI service. HTTP is also implemented by Web Servers which offer an outstanding activation model they could only dream of when they were romantically remoting with CORBA or DCOM. So they are ready to trade code generation for these capabilities. To a certain extend this argument is unbeatable.
Make no mistake, the little code snippet I showed you above is all they have in their mind. They don't care about "Resource Orientation". HATEOS is just the "magic powder" that they sprinkle on their arguments to confuse you and make you believe that this is new and improved middleware. Really. they have been building "distributed" systems using this remoting paradigm for ever and that's all they do.
SOA was the victory of the message (i.e. the interaction) over the method (I wrote about it many times in the past). They want to bring us back forty years. They can't think and will never be able to think in any other way, they are afterall the remoting bunch.
So when you show them a picture like this one, they are clueless.
What they don't understand is when you are building a connected information system, the code is not "sequential". Most of the code is dedicated to align the states between the business information entities. You don't just CREATE, UPDATE, DELETE or GET a business information entity you make sure it transition appropriately from one state to another and these states are aligned with the states of the related business entities.
This is where loose coupling is critical because it is not about remoting, it is about inter-acting, and inter-acting with the goal of aligning states between business information entities.
It is easy to claim that you don't need any kind of loose coupling when all you are doing is asking: provider.doSomethingForMe(withThatStuff), it is a complete different ball game to have multiple business entities interacting with each other (please consider the exceptions too).
What the remoting bunch is not telling you is that HTTP is going to make your life a lot more complicated in a multi-business information entity scenarios. And frankly there are not a lot of business scenarios which are not multiparty. A procurement scenario is going to involve at a minimum: customer, purchase order, item, invoice, payment, shipment and return. Yeah, you get a sense of the complexity of using a sequential programming model and a synchronous client/server middleware approach (do not forget exception handling).
As a matter of fact, the VERY RESON WHY SILOS EXIST IS BECAUSE A SYNCHRONOUS CRUD-ORIENTED CLIENT/SERVER PROGRAMMING MODEL DOES NOT HAVE THE CAPABILITIES TO CREATE AUTONOMOUS BUSINESS INFORMATION ENTITIES THAT COULD BE COMPOSED IN DIFFERENT SOLUTIONS. In a traditional programming model all this business logic CRUDs its way into putting the entire system (customer, purchase order, item, invoice, payment, shipment and return) in a particular state regardless of business information entities and their lifecycle. Silos can't be easily changed or reused because there are no natural boundaries. It does not matter that much whether you use RPC, HTTP or anything else as long as you are using it to CRUD around. As long as people will not surface the states, interactions and events we will remain in this silo mentality. And of course once you created a silos, the next time around you will create another and you will happily have to integrate them. This is what the remoting bunch is incapable of understanding and they will never understand that.
If you look at the picture above you see immediately that you need:
a) bidirectional interfaces which support inter-actions, events and queries
b) an orchestration based programming model which knows how to "wait"
c) an assembly mechanism (possibly leveraging choreography concepts)
d) loose coupling capabilities, because when your PO lifecycle service is participating into a multi-party collaboration with other service lifecycles and somebody comes around and ask for some changes both in the message types and the business protocol, you'd be stuck in concrete if you did not have loose-coupling capabilities.
A RESTful HTTP-based approach cannot provide any of these.
Today, we have an extraordinary opportunity to dramatically simplify the way we build information systems and build them from reusable entities. We have a mechanism to define bidirectional interfaces which support forward compatible mechanisms, orchestration languages and even an assembly technology. I agree it is not perfect, but it is there.
We can go back to the stone-age of computing (synchronous client/server) or we can move forward into the modern world of Service Oriented Architectures which (finally) offer technologies and programming models that are well suited to building complex information systems.
It is your choice to make, because all the pieces are here.
So, if, in the end, the (other) REST community would leave us a lone, I frankly don't care what they do, we live in a free society. But when you spread the kind of bullshit you are spreading across the industry showing simply how ignorant you are of information system architecture and construction, I feel compelled to respond, because it is actually affecting my day-to-day job (and I am not kidding).