For years, the industry has struggled with the emergence of the new layer of abstraction that’s been called SOA… it’s been very slow to be born
SOA evokes WB Yeats and his poem “The Second Coming”, the idea of a “Rough beast, it’s hour come round at last”.
In the enterprise, things have fallen apart. The center is not holding at all. What is the center? Enterprise Applications? SAP? Oracle? The Mainframe? IBM? The desktop? Microsoft? The data center? HP?
Java was a system at it’s core that was elegant–sure purists will attack it for all of its compromises. But it was filled with elegant compromises. I know that sounds oxymoronic, but the enterprise is by it’s nature a compromised creature. What made Java interesting is that it recognized a few things–that the sacrifice made in speed by introducing the virtual machine was made up for by creating a language that was familiar and productive to folks who previously used C and C++ syntactically. Human speed became more important than machine speed. Strong types made it reasonably conversant with enterprise structured data, while late binding enabled it to be flexible and dynamic.
But of course the market wants alternatives even to alternatives. The alternative to Java is pretty clearly .NET. But of course once the initial cracks were formed in the foundation, it invites many other alternatives. I think Bill Gates was absolutely right about “many languages” up to and including domain specific languages. Languages are part of the “user interface” and different languages are better at expressing different thoughts. But JVM bytecode is Turing Complete–so you could bring PHP, Ruby, Groovy and anything else into bytecode the way you can bring Visual Basic, C# and others into IL for the CLR.
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world,
The blood-dimmed tide is loosed, and everywhere
The ceremony of innocence is drowned;
The best lack all conviction, while the worst
Are full of passionate intensity.
Surely some revelation is at hand;
Surely the Second Coming is at hand.
The Second Coming! Hardly are those words out
When a vast image out of Spritus Mundi
Troubles my sight: somewhere in the sands of the desert
A shape with lion body and the head of a man,
A gaze blank and pitiless as the sun,
Is moving its slow thighs, while all about it
Reel shadows of the indignant desert birds.
The darkness drops again; but now I know
That twenty centuries of stony sleep
were vexed to nightmare by a rocking cradle,
And what rough beast, its hour come round at last,
Slouches towards Bethlehem to be born?
In Boston, I spoke with a SOA Naysayer, Rachel Chalmers from the 451 group. I was very sympathetic to her views because she is probably on the side of history–that technological revolution typically comes from the outside of the enterprise and goes in. Client server, the web application server, mobile technologies, social software, cloud apps, Saas, all have their revolutionary origins outside the enterprise. Why subject yourself to the complexity of SOAP when you can just build elegant web apps in the cloud? You get scalability for free. You get availability (we hope) for free. The google app outage this week shows you dont always get availability for free–but the availability is pretty darned good, certainly as good or better than most Enterprise apps.
Her objection was that SOAP was flawed from the get go, and that everyone should embrace REST. In time, perhaps this will be true. The preference of SOAP style over REST style is really based on the notion of a world where resources are limited and controlled, not a world where they are unlimited and free. On the web, the Google style is to assume that the system is always going to be scalable, always available and free.
At the heart of the Enterprise there are antiquated systems that manage financial reporting, accounting, supply chains, human resource management among other things. Some of these are packaged apps like SAP and Oracle, but others are custom apps like IBM mainframe apps. To date, efforts to rip and replace these core systems at the heart of the Enterprise have failed. The paradigm in Enterprise is fraught with requirements to secure these systems, ensure reliability, meter and regulate scalability and enforce interoperability when possible. As soon as SOAP headers appeared, all of these complex agendas that were handled by internal systems and tightly coupled legacy apps started to regurgitate themselves out into the headers and the endless spawn cycle of WS standards began.
It’s not a pretty sight, admittedly. SOAP is inelegant and you can end up with very large SOAP payloads and cumbersome headers that delivery systems dont always fully support as you go across enterprise boundaries.
But as I’ve said before, short of abandoning the core systems, Enterprise is stuck. Perhaps the tax of dragging these legacy systems is so large that large enterprise is finished and will be overwhelmed by more efficient small and midsized companies that run everything, financials, transaction processing, custom apps, business processes in the cloud. Perhaps.
But this will take time and there’s not much historical precedent (doesnt mean it wont happen). Historically, large enterprise has become larger, legacy and all.
In the meantime, SOA continues to slouch towards Bethlehem, to be born.
