Service Oriented Architecture (SOA)

Service-oriented architecture (SOA) was invented in the late 1980s. It originates in the ideas set forth in CORBA, DCOM, DCE, and other documents. Much has been written about SOA, there are several implementations of it. But, in fact, SOA can be reduced to several ideas, and the architecture does not dictate the ways of their implementation:

• Compatibility of user-oriented applications.
• Reuse of business services.
• Independence from a set of technologies.
• Autonomy (independent evolution, scalability and deployment).

SOA is a set of architectural principles that are independent of technology and products, just like polymorphism or encapsulation.

In this article, I will look at the following patterns related to SOA:

• Common Object Request Broker Architecture (CORBA).
• Web services.
• Message queue
• Service Bus Enterprise (ESB).
• Microservices.

Common Object Request Broker Architecture (CORBA)

In the 1980s, active use of corporate networks and client-server architecture began. There was a need for a standard way of interaction between applications that are created using different technologies, are executed on different computers and under different operating systems. For this, CORBA was developed. This is one of the standards of distributed computing, which originated in the 1980s and flourished by 1991.

The CORBA standard has been implemented by several vendors. It provides:

• Platform-independent remote procedure calls.
• Transactions (including deleted!).
• Security.
• Developments.
• Independence from the choice of programming language.
• Independence on the choice of OS.
• Independence from the choice of equipment.
• Independence from data transmission / communication features.
• Data collection through interface description language (Interface Definition Language, IDL).

Today, CORBA is still used for heterogeneous computing. For example, it is still part of Java EE , although starting with Java 9 it will be delivered as a separate module .

I want to note that I do not consider CORBA as an SOA pattern (although I attribute both CORBA and SOA-patterns to the sphere of distributed computing). I talk about it here, because I consider the weaknesses of the CORBA to be one of the causes of SOA.

Principle of operation

First we need to get an Object Request Broker (ORB) broker that conforms to the CORBA specification. It is provided by the vendor and uses language converters (language mappers) to generate stubs (stubs) and skeletons (skeleton) in the languages ​​of the client code. Using this ORB and interface definitions that use IDL (similar to WSDL), you can generate remotely called stub classes on the basis of real classes in the client. And on the server, you can generate skeleton classes that process incoming requests and call real targets.

The caller calls the local procedure implemented by the stub.

1. The stub checks the call, creates the request message and sends it to the ORB.
2. The client ORB sends a message over the network to the server and blocks the current thread of execution.
3. The server ORB receives a request message and creates an instance of the skeleton.
4. The skeleton executes the procedure in the callee.
5. The callee performs the calculations and returns the result.
6. The skeleton packs the output arguments into the reply message and passes it to the ORB.
7. ORB sends a message over the network to the client.
8. The client ORB receives the message, unpacks and transmits the information to the stub.
9. The stub passes the output arguments to the caller, unblocks the execution thread, and the caller continues its work.

Virtues

• Independence from selected technologies (apart from the ORB implementation).
• Independence from data transmission / communication features.

disadvantages

• Location independence : client code has no idea whether the call is local or remote. It sounds good, but the duration of the delay and the types of failures can vary greatly. If we don’t know what a call we have, then the application cannot choose the appropriate strategy for handling method calls, and therefore generate remote calls within the loop. As a result, the entire system is slower.
• Difficult, bloated and ambiguous specification : it was assembled from several versions of specifications from different vendors, so (at that time) it was bloated, ambiguous and difficult to implement.
• Blocked communication pipes : specific protocols are used on top of TCP / IP, as well as specific ports (or even random ports). But corporate security rules and firewalls often allow HTTP connections only through port 80, blocking CORBA data exchanges.

Web services

Although today you can find an application for CORBA, but we know that it was necessary to reduce the number of remote calls in order to improve system performance. It also required a reliable communication channel and a simpler messaging specification .

And to solve these problems, web services began to appear in the late 1990s.

• A reliable communication channel was needed , therefore:
  
  • HTTP was the default to work on port 80.
  • They began using a platform-independent language (like XML or JSON) for messaging.
• It was necessary to reduce the number of remote hits , so:
  
  • Remote connections have become explicit, so now we always know when a remote call is being made.
  • Instead of numerous remote calls of objects, we turn to remote services, but much less often.
• It was necessary to simplify the messaging specification , therefore:
  
  • The first draft of SOAP appeared in 1998, became a recommendation of the W3C in 2003, after which it became a standard. SOAP has incorporated some of the CORBA ideas, such as the messaging layer and the “document” that defines the interface using the Web Services Description Language (WSDL ).
  • Roy Fielding in 2000 described REST in his dissertation, " Architectural Design and Network-based Software Architectures ." Its specification turned out to be much simpler than SOAP, so soon REST overtook SOAP in popularity.
  • Facebook developed GraphQL in 2012, and released the public release in 2015. This is the request language for the API, which allows the client to strictly determine what data the server should send to him, no more and no less.

[Web-based] services can be published, found and used in a standard way, regardless of technology.
- Microsoft 2004, Understanding Service-Oriented Architecture

Thanks to microservices, we have moved in the SOA paradigm from remote invocation of object methods (CORBA) to the transfer of messages between services.

But you need to understand that within the framework of SOA, web services are not just general-purpose APIs, just providing CRUD access to the database via HTTP. In some cases, this implementation may be useful, but for the sake of the integrity of your data, it is necessary that users understand the underlying model of the implementation and follow the business rules . SOA implies that web services are limited to business subdomain contexts (business sub-domain) and separates the implementation from tasks solved by web services.

From the point of view of SOA technologies, it’s not just a service architecture, but a set of policies, methods and frameworks, thanks to which we provide and receive the necessary services.
- Microsoft 2004, Understanding Service-Oriented Architecture

Virtues

• The independence of a set of technologies, deployment and scalability of services.
• Standard, simple and reliable communication channel (text transmission via HTTP through port 80).
• Optimized messaging.
• Stable messaging specification.
• Isolation of contexts of domains (Domain contexts).

disadvantages

• Different web services are difficult to integrate due to differences in messaging languages. For example, two web services using different JSON representations of the same concept.
• Synchronous messaging can overload systems.

Message queue

We have several applications that asynchronously communicate with each other using platform-independent messages. Message Queuing improves scalability and increases application isolation. They do not need to know where other applications are located, how many of them, and even what they are. However, all these applications must use the same messaging language, that is, a predefined text-based presentation format.

The message queue uses the program message broker (RabbitMQ, Beanstalkd, Kafka, etc.) as an infrastructure component. To implement communication between applications, you can configure the queue in different ways:

• Request / Reply

  
  
  • The client sends a message to the queue, including a link to the "conversation" (reference) reference . A message arrives at a special node that responds to the sender with another message, which refers to the same conversation , so the recipient knows which conversation the message refers to and can continue to act. This is very useful for business processes of medium and long duration (chains of events, sagas ).
  
  
• Publish / Subscribe
  
  • By lists
    The queue maintains lists of published topics of subscriptions (topics) and their subscribers. When the queue receives a message for a topic, it places it in the appropriate list. A message is matched to a topic by message type or by a predetermined set of criteria, including the content of the message.
  • Based on broadcast
    When a queue receives a message, it broadcasts it to all nodes listening on the queue. Nodes should filter the data themselves and process only messages of interest.

All these patterns can be attributed to either a pull- (polling) or a push approach:

• In a pull script, the client polls the queue with a certain frequency. The client controls his load, but there may be a delay: the message is already in the queue, and the client is not processing it yet, because the time for the next poll of the queue has not come.
• In a push script, the queue immediately gives customers messages as they arrive. There is no delay, but customers do not manage their load.

Virtues

• The independence of a set of technologies, deployment and scalability of services.
• Standard, simple and reliable communication channel (text transmission via HTTP through port 80).
• Optimized messaging.
• Stable messaging specification.
• Domain contexts isolation.
• Easy to connect and disconnect services.
• Asynchronous messaging helps manage system load.

disadvantages

• Different web services are difficult to integrate due to differences in messaging languages. For example, two web services using different JSON representations of the same concept.

Service Bus Enterprise (ESB)

The company's service bus used web services already in the 1990s, when they were first developed (perhaps some implementations first used CORBA?).

The ESB came into being at a time when companies had separate applications. For example, one for working with finance, the other for personnel accounting, the third for warehouse management, etc., and they needed to be somehow connected with each other, somehow integrated. But all these applications were created without integration, there was no standard language for application interaction (as it is today). Therefore, application developers provided endpoints for sending and receiving data in a specific format. The client companies then integrated the applications, establishing communication channels between them and transforming messages from one application language into another.

A message queue can simplify the interaction of applications, but it is not able to solve the problem of different language formats. However, an attempt was made to turn the message queue from a simple communication channel into an intermediary, delivering messages and transforming them into the necessary formats / languages. ESB was the next step in the natural evolution of a simple message queue.

This architecture uses a modular application (composite application), usually user-oriented, which communicates with web services to perform some operations. In turn, these web services can also communicate with other web services, subsequently returning some data to the application. But neither the application nor the back-end services know anything about each other, including the location and communication protocols. They know only what service they want to contact and where the service bus is located.

The client (service or modular application) sends a request to the service bus, which converts the message to the format supported at the destination, and forwards the request to it. All interaction goes through the service bus, so if it falls, then all the other systems fall with it. That is, the ESB is a key intermediary, a very complex component of the system.

This is a very simplified description of the ESB architecture. Moreover, while the ESB is the main component of the architecture, other components can be used in the system, such as Domain Brokers, Data Services, Process Orchestration Services and Rules Engine. The same pattern can use an integrated architecture (federated design): the system is divided into business domains with its ESBs, and all the ESBs are connected to each other. Such a scheme has higher performance and there is no single point of failure: if some ESB falls, only its business domain will suffer.

ESB main responsibilities:

• Track and route messaging between services.
• Convert messages between communicating service components.
• Manage the deployment and versioning of services.
• Manage the use of redundant services.
• Provide standard event processing, data conversion and mapping services, message and event queue services, security or exception handling services, protocol conversion services and ensuring the required quality of communication.

Creating structures of communication between different processes, we saw a lot of products and approaches, which use highly developed communication mechanisms. A good example is enterprise service buses, often incorporating sophisticated message routing, choreography, transformation, and business rule enforcement.
- Martin Fowler 2014, Microservices

This architectural pattern has positive sides. However, I find it particularly useful in cases where we do not “own” web services and we need an intermediary for translating messages between services, for orchestrating business processes using several web services, and other tasks.

I also recommend not to forget that ESB implementations are already quite developed and in most cases allow using a user interface with drag & drop support for their configuration.

Virtues

• The independence of a set of technologies, deployment and scalability of services.
• Standard, simple and reliable communication channel (text transmission via HTTP through port 80).
• Optimized messaging.
• Stable messaging specification.
• Domain contexts isolation.
• Easy to connect and disconnect services.
• Asynchronous messaging helps manage system load.
• A single point to control versioning and conversion.

disadvantages

• Lower communication speed, especially between already compatible services.
• Centralized logic:
  
  • A single point of failure that can bring down the communications systems of the entire company.
  • Greater complexity of configuration and support.
  • Over time, you can come to storage in the ESB business rules.
  • The bus is so complex that you need a whole team to control it.
  • High dependence of services on ESB.

Microservices

At the heart of the microservice architecture are the concepts of SOA. Its purpose is the same as that of the ESB: create a single, common corporate application from several specialized business domain applications.

The main difference between microservices and buses is that the ESB was created in the context of integrating individual applications so that a single corporate distributed application is obtained. And the microservice architecture was created in the context of rapidly and constantly changing businesses, which (mostly) build their own cloud applications from scratch.

That is, in the case of the ESB, we already had applications that we do not “own” , and therefore we could not change them. And in the case of microservices, we completely control the applications (at the same time, third-party web services can be used in the system).

The nature of building / designing microservices does not require deep integration. Microservices must comply with the business concept, limited context. They must maintain their state, be independent of other microservices, and therefore they need less integration. That is, low interdependence and high connectivity have led to a remarkable side effect - reducing the need for integration.

[Microservices are] small autonomous services that work together and are designed around a business domain.
- Sam Newman 2015, Principles Of Microservices

The main drawback of the ESB architecture was a very complex centralized application, on which all other applications depended. And in the microservice architecture, this application is almost completely removed.

There are still elements that permeate the entire ecosystem of microservices. But they have far fewer tasks compared to ESB. For example, a message queue is still used for asynchronous communication between microservices, but this is only a channel for transmitting messages, nothing more. Or you can recall the microservice ecosystem gateway, through which all external data exchange passes.

Sam Newman, author of Building Microservices , outlines eight principles of microservice architecture. It:

• Designing services around business domains
  This can give us stable interfaces, highly interconnected and little-dependent code modules, as well as well-defined demarcated contexts.
• Automation culture
  This will give us much more freedom, we will be able to deploy more modules.
• Hiding implementation details
  This allows services to evolve independently of each other.
• Full decentralization
  Decentralize decision making and architectural concepts, provide teams with autonomy so that the company itself becomes a complex adaptive system capable of quickly adapting to change.
• Independent deployment
  You can deploy a new version of the service without changing anything else.
• First consumer
  The service should be easy to use, including other services.
• Fault Isolation
  If one service falls, others continue to work, it makes the whole system resilient to failure.
• Easy monitoring
  There are many components in the system, so it is difficult to keep track of everything that happens in it. We need sophisticated monitoring tools to look into every corner of the system and track any chain of events.

The community prefers a different approach: smart endpoints and stupid channels . Microservices from which applications are assembled should depend as little as possible from each other and at the same time be very closely connected - they contain their own domain logic and work more like filters from the point of view of classic Unix: they receive requests, apply logic and generate responses. They are orchestrated using simple REST-like protocols, rather than complex protocols like WS-Choreography or BPEL or some kind of centralized tool.
- Martin Fowler 2014, Microservices

Virtues

• The independence of a set of technologies, deployment and scalability of services.
• Standard, simple and reliable communication channel (text transmission via HTTP through port 80).
• Optimized messaging.
• Stable messaging specification.
• Domain contexts isolation.
• Easy to connect and disconnect services.
• Asynchronous messaging helps manage system load.
• Synchronous messaging helps manage system performance.
• Fully independent and autonomous services.
• Business logic is stored only in services.
• Allow the company to turn into a complex adaptive system consisting of several small autonomous parts / teams that can quickly adapt to change.

disadvantages

• High complexity of operation:
  
  • You need to invest a lot in a strong DevOps culture.
  • The use of numerous technologies and libraries can get out of control.
  • You need to carefully manage the input / output API changes, because many of the applications will use these interfaces.
  • The use of “eventual consistency” can lead to serious consequences that need to be considered when developing an application, from backend to UX.
  • Testing is complicated because changes in the interface can unpredictably affect other services.

Antipattern: Ravioli Architecture (Ravioli Architecture)

The architecture of ravioli is usually called the anti-pattern microservice architecture. Ravioli are obtained, if there are too many microservices, they are too small and do not reflect domain concepts.

Conclusion

In recent decades, SOA has evolved greatly. Due to the inefficiency of previous solutions and the development of technology, today we have come to a microservice architecture.

Evolution went along the classical path: complex problems were broken up into smaller, simpler ones to solve.

The problem of code complexity can be solved just as we break a monolithic application into separate domain components (delineated contexts). But with the growth of teams and code base, the need for independent development, scaling and deployment increases. SOA helps achieve this independence by strengthening the boundaries of contexts.

I repeat that the whole thing is a weak interdependence and high connectivity, and the size of the components must be greater than the former. You need to pragmatically assess your needs: use SOA only when necessary, because it greatly increases the complexity. And if in fact you can do without SOA, then it is better to choose microservices of the appropriate size and quantity, no more and no less.

Sources

1997 - Steve Vinoski - CORBA: Integrating Diverse Applications Within Distributed Heterogeneous Environments
2000 - Roy Fielding - Network-based Software Architects
2004 - Microsoft - Message Bus
2004 - Microsoft - Understanding Service-Oriented Architecture
2011 - Chris Ostrowski - Understanding Oracle SOA - Part 1 - Architecture
2011 - Chris Ostrowski - Understanding Oracle SOA - Part 2 - Technologies
2011 - Chris Ostrowski - Understanding Oracle SOA - Part 3 - Development
2011 - Chris Ostrowski - Understanding Oracle SOA - Part 4 - Business Benefits
2012 - Prabhu - Service Oriented Architecture - SOA
2014 - Martin Fowler - Microservices
2014 - PWC - Agile coding in enterprise IT: Code small and local
2015 - Udi Dahan - Messaging Architecture and Services Bus
2015 - Sam Newman - Principles Of Microservices
2016 - Kai Wähner - Microservices: Death of the Enterprise Service Bus?
2016 - Abraham Marín Pérez - Java 9 Will Remove CORBA from Default Classpath
2016 - Oracle - CORBA Technology and the Java Platform Standard Edition
2017 - Wikipedia - Distributed object communication
2017 - Wikipedia - CORBA
2017 - Wikipedia - Enterprise Service Tire
2017 - Wikipedia - REST
2017 - Wikipedia - SOAP
2017 - Wikipedia - Service Oriented Architecture
2017 - Microsoft - Enterprise Architecture: SOA in the real world