SOA's beginning to feel a lot like CORBA

If you ever visit my garage, you'll find a couple of book shelves out there. On the shelves are an array of computer books, on all sorts of topics. I'll sometimes buy books at garage sales, at the GoodWill store, or especially off Amazon from the 'used' section. Most of the books I buy are cheap-- I'll buy 2 or 3 books off Amazon for a few bucks each plus shipping. I like books better than online reading because I can mark them up and take them with me wherever I go. (Sorry, a Kindle just doesn't seem the same. I ease my conscience by telling myself I'm buying used, so I'm not really causing any new trees to be felled.) A few of the books I've bought this way are terrible, but most have at least a few good chapters and a couple have been really good. I'm able to get more perspectives on a topic by buying in quantity rather than spending more money for quality. (By the way, I keep a few books inside the house-- any 'high dollar' new books, or any books that have my name inside them for some reason. By keeping only a subset of my books inside the house, I've found my married life is much happier!) Among my 'outside' books you'll find a couple of volumes on CORBA.

We still use CORBA in places where I work. Mostly we make use of the 'Naming Service' and the data-marshalling capabilities (which we find to be very performant, BTW). The 'Naming Service' is a sort of registry for CORBA services. When my service comes up, it uses a well-known (that is, hard-coded and shared by other services) address to reach out to the Naming Service. My service then registers itself with the Naming Service by supplying a name for itself and the address of the machine it's running on. (So my service might pick the name /Persistence/Sharding/ShardLocator.) Then whenever a client wants to use my ShardLocator service, it uses the same well-known address to get to the Naming Service, and it asks it where it can find /Persistence/Sharding/ShardLocator. The Naming Service will pick either my service or another machine that hosts this service and tells the client that's where the service can be found. When my service shuts down, it is obligated to un-register with the Naming Service so the registry in theory contains only 'live' service instances. (Note to newbies: This is done so clients don't have to hard-code the location of servers they need to talk to. Then when a machine fails or you add a new server instance, it's easier.)

If I look through one of my ancient CORBA books, I see great tales of what CORBA should be used for. There are distributed transactions, mechanisms for dynamically finding and invoking methods, a query mechanism, etc. etc. But as I said, we make use of only a few simple services. I think this is common-- I bet most people that still use CORBA only use a few parts of the whole spec.

Lately, I've been working on a team charged with architecting a sizeable new greenfield application. We're considering different SOA components to use-- an ESB, an orchestration engine, maybe some other parts. If you look at SOA suites offered by big vendors, you'll see quite a laundry list of components-- Governance helpers, Business Rules Engines, Complex event processing, etc. (By the way, the open source guys offer these too.) But I'm not sure we'll be using all that stuff, probably just the parts we really need. The whole thing is beginning to feel vaguely like CORBA.

CORBA and SOA are also similar in that they were largely spec-driven efforts that tried to answer all the problems the industry was trying to solve. I think it's widely accepted that the reason they didn't realise full potential was that the specs grew too complicated (WS-* anyone?) and the vendor implementations didn't really interoperate.

It's been over a year now since a prominent industry analyst proclaimed "SOA is Dead". (Google that one, you'll find plenty.) So it looks to me like SOA has roughly followed the same lifecycle CORBA did:

CORBA was lively from roughly 1990 - 2000
SOA was lively from roughly 2000 - 2010

Cloud, to me, is a lot like SOA re-packaged with some machine requisition thrown in.

I'm left pondering a few questions:
- How will we look back at SOA a few years from now?
- Will we have another tech stack arise for the next decade? What will it be?

Thanks for reading, and Happy Coding!