I was working with some colleagues on the UK version of Oracles Service Oriented Architecture Developer Day. As we reviewed the slides it struck me how the slides haven't changed much, only the titles have changed. 8 years ago I was making similar presentations about the value of what was then called an Object Oriented Architecture with Service Level abstractions. So what has changed and why do I think that SOA will really take off in its current incarnation.
There are several reasons.
"What's in a name? That which we call a rose By any other word would smell as sweet." --From Romeo and Juliet (II, ii, 1-2)
Names have a great deal of power, and many a great idea has been sunk by poor naming and marketing. Service Oriented Architecture is a great name as it sums up what we are trying to do - build flexible composite applications from a selection of re-usable services. Names like "Distributed Objects", "Object Web", "DNA" "Web Services" just fail to convey what is being done, even though they are basically all very similar to SOA. Beside which SOA allows us to have SODA (Service Oriented Development Architecture", and who can be against that!
So basically SOA tells you what it is about.
Although SOA is a way of building applications, rather than a specific technology, and as such a SOA solution could be built using pure Java, or .net or CORBA. However in practice most people are looking at using Web Services to build their SOA systems. This allows them to build heterogenous systems today. Web Service standards are rapidly maturing to the point where they can do most of what is asked of them. The basic invocation standards are well understood and agreed, thanks to the work of WS-I on web services inter-operability.
This use of standards based web services makes it much easier to construct service oriented architectures without worrying about the underlying implementation technology. Some services may be heavily data-centric and would best be imokemented as SQL and PL/SQL in the database. No problem, just expose them as PL/SQL web services. Other services have complicated business logic and transactional co-ordination required. Just implement them as Java and expose them as Java Web Services. Need to accecss these services from a .Net application, no problem, just call them directly using .Net support for web services.
The ready availability of Web Service standards on all major platforms makes them a ready lingua fracas for SOA applications.
The previous two points on their own are not enough to explain why I think SOA will work this time around. In the past COM/CORBA bridges sort of worked and a mixture of DCOM and CORBA could have been cobbled together to produce SOA applications. But it was all a lot of work and very low level.
A much better approach is to have a standardised way of scripting services together to create either whole business processes or new composite services. With the Business Process Execution Language (BPEL) I believe that we have a killer tool to turn SOA from an interesting architectural approach to a realistic business focussed tool for improving busininess responsiveness in a rapidly changing economy.
Oracles newly acquired BPEL solution provides a graphical design tool that allows business process to be discussed with business analysts in a way that make communication easy. The crucial thing though is that the agreed business process is then executed directly by the BPEL process manager, rather than being thrown over to room full of bearded 3GL programmers to interpret. This is important because it means that was is discussed with the business is what actually gets interpreted, not some translation of the intent.
I hope the above explains why I am so excited about SOA and BPEL, together I think they are a winning combination. This is a topic I will prbably return to in the future.