SOA and Object Orientation: the power of abstraction.
Object Orientation (OO) was a very important contribution to the history of software development. It introduced a deep change of focus regarding the traditional way of designing software, even analyzing reality to model it into software designs. Ability of abstraction, which had always been a desirable feature for software to be clean, readable, orderly, and therefore maintainable, stepped forward to become an essential skill for a correct class design. Service Orientation (SOA) inherits this role of abstraction as a key tool for a successful execution of the strategy, but it is not the only thing that SOA and OO have in common. Let’s see it.
A first similarity between SOA and OO is in the concept of instance. As you know, once you have defined a class, you instantiate it to create objects. Each object, which is an instance of that class, is different from the rest of objects that instantiate that same class, because each has its own attribute values and therefore have characteristics that differentiate them even if they behave in the same way. Exactly like two different people, although similar in their “modeling” and behavior, present characteristics (attributes or properties) that make them different. Although they respond to the same pattern, they are different objects.
Something similar happens with services. The definition of a business service in SOA is unique. And then that business service is deployed in different contexts, in which the configuration values, or the data that resolve the routing rules, or some configurable data that affects the business rules that orchestrate the process, usually vary. From this point of view, each deployment of the same service in each environment becomes an instance of that service.
Another reasonable resemblance between SOA and OO is found in the concealment of its internal logic, what we know as encapsulation. Just as an object behaves like a black box for the outside, and it simply offers a number of methods to be invoked, an SOA business service also responds to the same approach: what it does internally is totally transparent to its consumers. Here is a small nuance: in an SOA service the encapsulation takes place on two levels: on the one hand, the service consumer simply receives the message of the business event to which it was subscribed, and knows nothing of how or where it was generated (this is known as dislocation, another important concept that will be discussed later). At the same time, the ESB receives the message of the business event provided by the provider system, and does not know or care about how that information system generated that message. This is also true when we talk about synchronous request-response services (the least recommended as we will see later when we talk about EDA).
Another aspect in which OO and SOA go hand in hand is reuse. One of the great achievements of OO was the ability to design software optimally, modeling reality by encapsulating the behavior of objects and their states (methods and attributes) into a single definition that could be reused as often as needed, since modeling was focused not on the concrete functional problem of the particular requirement of a particular information system, but on the object itself. And that object would be the same in all contexts in which it appeared. So, once you have defined a class named “Class”, with its attributes and methods, you do not have to redefine it for other information systems that must deal with the object “client”. We simply reuse the class we already have. At most, we can inherit another class to create a specific client class, but little else.
With SOA services something similar happens, although in this case the reuse is more pure. A service is reused as it is as many times as necessary. And not only in different ESB, or different areas, where the business processes to be solved are the same, but we can also reuse them as pieces to solve services of higher level of complexity, by participating in broader orchestrations of events. It all depends on the patterns of business processes that we are implementing in the services and the events that participate in them.
But the feature that most links SOA and OO from my point of view is abstraction.
In the same way that a class represents an abstract pattern of encapsulated, self-contained attributes and methods that conceal its behavior from the outside, a service is also an abstraction of a pattern of encapsulated, self-contained events, rules, and data that hide its internal behavior.
In SOA, abstraction has a specific weight at least as important as in OO. Whether we are in a top-down approach, that is, discovering services from the analysis of business processes, as if we are in a bottom-up approach, that is, identifying services from the study of existing information systems and the way in which they have implemented their integration solutions, it is always necessary to maintain a constant revision exercise similar to zooming in and zooming out on a map. We must move our level of abstraction from top to bottom to make sure we find the right point of granularity in the definition of our services.
A service too abstract causes over-reuse, a lack of ambiguity in its semantics, difficulties in managing its life cycle, or its security, and ultimately a degradation of the ability to efficiently monitor the business.
A service with lack of abstraction causes a very low reuse, the excessive proliferation of very similar services, and a very poor improvement of the coupling between information systems.
In SOA, therefore, it is essential to manage a very powerful and agile abstraction capability. It can greatly facilitate things to have well-trained abstraction capability to make a successful business services analysis and design. And as we have seen, there are many other similarities between Service Orientation and Object Orientation.
For all this I always recommend, as someone did with me in the past, to ensure a complete and deep understanding of OO before fully immersing in SOA.