Enterprise Integration Patterns

Enterprise Integration Patterns 12, 13 offer an inspiration for possible integrations of legacy applications and microservices:

  • Message Router describes that certain messages go to another service. For example, a microservice can select some messages that are processed then by the microservice instead of by the legacy application. In this way, the microservice-based architecture does not have to newly implement the entire logic at once but can at first select some parts.
  • • A special router is the Content Based Router. It determines based on the content of a message where the message is supposed to be sent. This enables the sending of specific messages to a specific microservice—even if the message differs only in one field.
  • • The Message Filter avoids uninteresting messages that a microservice receives. For that it just filters out all messages the microservice is not supposed to get.
  • • A Message Translator translates a message into another format. Therefore, the microservices architecture can use other data formats and does not necessarily have to employ the formats used by the legacy application. [1] [2]
  • • The Content Enricher can supplement data in the messages. If a microservice requires supplementary information in addition to the data of the legacy application, the Content Enricher can add this information without the legacy application or the microservice noticing anything.
  • • The Content Filter achieves the opposite: Certain data are removed from the messages so that the microservice obtains only the information relevant for it.

Figure 7.9 shows a simple example. A Message Router takes calls and sends them to a microservice or the legacy system. This enables implementation of certain functionalities in microservices. These functionalities are also still present in the legacy system but are not used there anymore. In this way the microservices are largely independent of the structures within the legacy system. For instance, microservices can start off with processing orders for certain customers or certain items. Because their scope is limited, they do not have to implement all special cases.

The patterns can serve as inspiration for how a legacy application can be supplemented by microservices. There are numerous additional patterns—the list provides only a glimpse of the entire catalog. As in other cases the patterns can be implemented in different ways: actually, they focus on messaging systems. However, it is possible to implement them with synchronous communication mechanisms, though less elegant. For instance, a REST service can take a POST message, supplement it with additional data, and finally send it to another microservice. That would then be a Content Enricher.

To implement such patterns, the sender has to be uncoupled from the recipient. This enables the integration of additional steps into the processing of requests without the sender noticing anything. In case of a messaging approach, this is easily possible, as the sender knows only one queue in which he/she places the messages. The sender does not know who fetches the messages. However, in the case of synchronous communication via REST or SOAP, the message is sent directly to the

Supplementing Legacy Applications by a Message Router recipient

Figure 7.9 Supplementing Legacy Applications by a Message Router recipient. Only by Service Discovery (see section 7.11) the sender gets uncoupled from the recipient. Then one service can be replaced by another service without need to change the senders. This enables an easier implementation of the patterns. When the legacy application is supplemented by a Content Enricher, this Content Enricher, instead of the legacy application, is registered in the Service Discovery, but no sender has to be modified. To introduce Service Discovery can therefore be a first step towards a microservices architecture since it enables supplementation or replacement of individual services of the legacy application without having to modify the users of the legacy application.

  • [1] http://www.eaipatterns.com/toc.html
  • [2] Gregor Hohpe, Bobby Woolf. 2003. Enterprise Integration Patterns: Designing, Building, andDeploying Messaging Solutions. Boston: Addison-Wesley.
 
Source
< Prev   CONTENTS   Source   Next >