SOA this, SOA that. Some SOA fun!
To me, service orientation is all about identifying the right abstraction and achieving the right kind of system decomposition.
A bit of history. Object Orientation was the silver bullet to overcome the software crisis. The objective of this methodology was to hide complexity and promote reuse - creating the software industry.
In the object oriented world there are objects. Objects that possess an Id, encapsulate data and provide some behavior. The system is decomposed into a set of objects. OO enables the software industry overcoming the limitation of procedural programming. The concept of object being an abstraction of a real world entity allows managing complexity. Along with that, inheritance and polymorphism enable reuse ultimately enabling apps to grow large.
But still system boundaries are more or less defined by the host process. Inter Process Communication helps move the boundaries to include multiple processes or threads but has its own limitations and complexities for the developer. It is the object oriented RPC that is the primary enabler of distributed systems. CORBA is the industrial standard in heterogeneous OO RPC. Given the wide spread acceptance, there are lots of great distributed systems built using it. Still, CORBA is not for the weak-hearted and invariably results in tight coupling and inflexible systems.
A couple of points with wrong projections of oo.
First: Consider the case of a homogeneous system that needs to scale; take the Java EE model. I see this as basically an object oriented architecture and its accompanying fine grained interaction between objects. A location transparency model that really leaks. This in fact results in more complexity, more interfaces and more glue layers like the session facade, Business delegate etc. All these layers are bound by object oriented contracts with the resultant tight coupling and inflexibility. Coming to EJB, though greatly simplified from the first version but still complicated, tried to address horizontal scaling for transactional systems and intends to provide transparent persistence, transactions and security with object orientation. The EJB component model directly follows design patterns from the CORBA world and its resultant accidental complexity. None of the intended transparency models really hide complexity. Real world applications have other NFR concerns that the application containers try to address. That's an additional black box. Add to this, the need to manage and replicate state on the server cluster. Achieving a cluster configuration to scale specific desired functionality can be quite tricky. But can be solved by a combination of hardware and software. The real difficulty is in evolving the system. Any change requires a wave of refactoring across the layers. The number of layers, tight coupling, complex fine grained interactions and ineffective separation of concerns from a functional abstraction point make the system less agile from a business stand point.
Second: Heterogeneity and diversity needs to be addressed within and out of the enterprise for business agility. When it comes to integrating the enterprise within and out, object oriented RPC is too tightly coupled and too complicated and a real misfit.
What is a Service?
A service is a relatively coarse grained abstraction and exposes a well defined behavior, backed by an OO implementation. And unlike an object, does not hold state. Services are essentially stateless and loosely coupled and does not depend on the context of other services (and a lot more). In the service oriented world there are services: just behavior on request. A system composed of service abstractions addresses the technical and functional separation of concerns well. Service orientation is the way to address the above OO rooted shortcomings.
A very useful article on service orientation by a distributed computing specialist, Steve Vinoski.
Inversion of control, dependency injection, Aspect oriented programming and the service abstraction enable building a Service Oriented system. A good introduction on these by Rod Johnson. The first one I looked at was the jboss server implementation. These principles enable loose coupling. Services are broadly classified as technical and business services. These re-purposed abstractions and with the above mentioned SOA enablers make building flexible systems possible. Functionalities are achieved by composing loosely coupled services and individual services can be scaled separately. With a flexible system that is easier to evolve and extend helps achieve business goals.
