Microservices and SOA

At first glance microservices and SOA (service-oriented architecture) seem to have a lot in common, for both approaches focus on the modularization of large systems into services. Are SOA and microservices actually the same or are there differences? Answering this question helps us to get an in-depth understanding of microservices, and some of the concepts from the SOA field are interesting for microservice-based architectures. An SOA approach can be advantageous when migrating to microservices. It separates the functionality of the old applications into services that can then be replaced or supplemented by microservices.

Section 6.1 defines the term “SOA” as well as the term “service” within the context of SOA. Section 6.2 extends this topic by highlighting the differences between SOA and microservices.

What Is SOA?

SOA and microservices have one thing in common: neither has a clear definition. This section looks only at one possible definition. Some definitions would suggest that SOA and microservices are identical. In the end, both approaches are based on services and the distribution of applications into services.

The term “service” is central to SOA.

An SOA service should have the following characteristics:

  • • It should implement an individual piece of the domain.
  • • It should be possible to use it independently.
  • • It should be available over the network.
  • • Each service has an interface. Knowledge about the interface is sufficient to use the service.
  • • The service can be used by different programming languages and platforms.
  • • To make it easy to use, the service is registered in a directory. To locate and use the service, clients search this directory at run time.
  • • The service should be coarse grained in order to reduce dependencies. Small services can only implement useful functionality when used in conjunction with other services. Therefore, SOA focuses on larger services.

SOA services do not need to be newly implemented; they may already be present in company applications. Introducing SOA requires these services to be made available outside of those applications. Splitting applications into services means they can be used in different ways. This is supposed to improve the flexibility of the overall IT and is the goal of SOA. By splitting applications into individual services it is possible to reuse services during the implementation of business processes. This simply requires the orchestration of the individual services.

Figure 6.1 shows a possible SOA landscape. Like the previous examples this one comes from the field of e-commerce. There are different systems in the SOA landscape:

• The CRM (customer relationship management) is an application that stores essential information about customers. This information includes not only contact details but also the history of all transactions with the

Overview of an SOA Landscape

Figure 6.1 Overview of an SOA Landscape

customer—telephone calls as well as emails and orders. The CRM exposes services that, for instance, support the creation of a new customer, provide information about a customer, or generate reports for all customers.

  • • The order system is responsible for order processing. It can receive new orders, provide information about the status of an order, and cancel an order. This system provides access to the different pieces of functionality via individual services. These services may have been added as additional interfaces to the system after the first version was put into production.
  • • In the diagram the CRM and order system are the only systems. In reality there would certainly be additional systems that would, for example, provide the product catalog. However, to illustrate an SOA landscape these two systems will suffice.
  • • For the systems to be able to call each other there is an integration platform. This platform enables communication between the services. It can compose the services through orchestration. The orchestration can be controlled by a technology that models business processes and calls the individual services to execute the different processes.
  • • Therefore, orchestration is responsible for coordinating the different services. The infrastructure is intelligent and can react appropriately to different messages. It contains the model of the business processes and is therefore an important part of the business logic.
  • • The SOA system can be used via a portal. The portal is responsible for providing users with an interface for using the services. There can be different portals: one for the customers, one for the support, and one for internal employees, for instance. Also, the system can be called via rich client applications or mobile apps. From an architectural perspective this makes no difference: All such systems access the different services and make them usable for a user. They are effectively a universal UI—able to use all services in the SOA.

Each of these systems could be operated and developed by individual teams. In this example there could be one team for the CRM and another for the order system. Additional teams could be allocated for each portal, and finally one team could take care of integration and orchestration.

Figure 6.2 shows how communication is structured in an SOA architecture. Users typically work with the SOA via the portal. From here business processes can be initiated that are then implemented in the orchestration layer. These processes use the services. When migrating from a monolith to an SOA, users might still use a monolith through its own user interface. However, SOA usually aims to have a portal as the central user interface and an orchestration layer for implementing processes.

Communication in an SOA Architecture

Figure 6.2 Communication in an SOA Architecture

< Prev   CONTENTS   Source   Next >