Preparing for SOA

Some vendors are touting that the benefits of SOA will initially be seen internally through better component reuse. I don’t buy that. There are plenty of component reuse models already: COM, Corba, EJBs, and message queues. Internal software development are in a good shape to consume their own components.

The notion of SOA is meant to extend the component reuse to third parties. Or, more likely, initially consuming service from third parties. So do you drop developing COM, Corba, EJB and start chasing the SOA nirvana by building web services instead? Or do you develop your components in such a way that they can be easily wrapped into SOA services?

Let’s say you pursue the latter. Here’s the pain: There are some assumptions that no longer hold when one consumes or develops SOA components.

a) No longer true: Transactions are going to be completed in a finite time
b) No longer true: The service is going to be up when you need it
c) No longer true: Your service is gong to be up when the service is ready to respond to it
d) No longer true: Exceptions are synchronous

This shift is going to be a bit hard for developers to swallow. Programming patterns and component design will have to undergo a change similar to the time when people stopped writing terminal apps and start writing event-driven programs. Collaxa (now owned by Oracle) had a pretty clever model where Java programs orchestrating web services are transformed into coroutine-like long-running processes.

Provocative question: Is SOAP a tacit recognition that Web Services is not the be all and end all of SOA? This is why HTTP headers did not figure in it’s specifications. That in fact message queues are the order of the day when it comes to integrating disparate services?