The concept of SOA (Service Oriented Architecture) can be illustrated by leveraging commonly understood concepts of object-oriented programming. Services comply with many of the standard principles that form the bedrock of object-oriented programming. However, SOA provides benefits at a much higher level of the IT value chain as discussed below.

In the object-oriented world, a class is the core concept that represents an abstraction of a real-world entity or concept with an object being a physical implementation of that class. Let us revisit some of the benefits that may be available by applying the basic principles of OO, namely encapsulation, inheritance, polymorphism etc.

Encapsulation allows a system to insulate and manage all the data and behavior associated with a specific entity. Inheritance allows us to define specialized entities that build on certain core entities that do not need to be redefined repeatedly. In other words it provides reuse of common data and logic. Polymorphism allows us to dynamically allow certain entities to have different behavior based on their runtime context.

Given the reference frame of these definitions, let us examine a formal definition for a service. A Service encapsulates business domain specific logic and is exposed through an open standards based interface. It provides contractually defined behavior; the service interface is independent of the underlying implementation platform.

Now based on the OO concepts we revisited above, the details of how a specific object will fulfill our requirements will be hidden to us through encapsulation. Similarly, the object may delegate implementation of said functionality to an inherited class and that is something that we don’t care about. The criteria stated in the definition of a service are present in the object-oriented world as well.

The key differentiator can be explained as follows - if we had been working in a Java world, for example, we would have invoked a collaborating target object using a technique that is intimately tied with the rules and syntax of the Java platform. This will create a tight coupling apart from limiting us to a specific platform and its release cycles.

The usage of object oriented computing is a big leap over previous paradigms that may have involved implementing functionality from scratch or reinventing the wheel. However, as business grows and looks to change, we would want to focus a higher and higher percentage of our IT resources only on the core areas of expertise without worrying about specific technology constraints or the availability and functionality of collaborating business components.

It is important to examine the differences between these two approaches from a business standpoint. Ultimately applications are intended to fulfill and support specific functional requirements. These requirements can be on the business fulfillment side or on the infrastructure side.

The consumer of an application, whether it is a client user, an internal user or another system expects the fulfillment of a certain contract from the target application. This contract is not limited to functionality but also implicitly relates to the level of performance, quality of service as well as the presence of a consistent interface. An implementer of such a contract would constitute a service.

Note that most modern day systems do provide all of the above for end users by engineering their internal systems appropriately. Therefore from a business standpoint, we can consider services to be closely aligned with business processes and to programmatically fulfill requirements specified in the form of a service contract, thereby shielding the consumer completely from any implementation considerations.

Objects and OOP were never considered to be for modeling business activity at a process level, rather they are intended to provide implementations at a system level where peer systems can use other objects in their community without regard for their internals.

The introduction of services provides business users with a technology that can be profitably used to communicate and align more effectively with IT. Some critical business benefits that may be obtained by migrating to SOA are as follows: Flexibility and insulation from change, Minimizing TCO and risk, Leverage best-of-breed implementations.

We traversed the bridge between two fundamental concepts in the world of enterprise software applications, OOP and SOA. We examined the governing principles of a service and mapped it back to fundamental OO concepts. We came to the conclusion that SOA builds upon the basic tenets of OOP and solves business problems at a much higher level.

The implementation components of a SOA will involve objects; the units of a SOA represent business activities that are at a much coarser level than objects. Despite the fact that OOP is in itself a universal, platform independent paradigm, SOA provides a level of independence from technologies and platforms that are not a part of the implementation of the object-oriented paradigm.

About the author

Dr. Sriram Anand is a Principal Researcher at Infosys Technologies, Bangalore. Prior to joining Infosys, he worked in IT consulting as well as product engineering in the US for over 12 years. His interests include enterprise architecture, service-oriented architecture, and legacy integration and software engineering methodologies. Dr. Sriram is experienced in designing enterprise architectural strategy for leading U.S. companies in the financial services, retail and pharmaceutical domains. He holds a Bachelor’s degree from IIT-Madras with a Ph. D. from SUNY-Buffalo, USA.