What is the Strangler Design Pattern

Application Integration Patterns in Enterprise Web Applications

In my master’s thesis, which I wrote as a practical partner with Zweag, application integration patterns were examined as tried and tested concepts for overcoming these challenges. The topic was dealt with in the context of a two-day project in which a monolithic legacy ERP system is being replaced by an architecture of web-based applications.

Structure of the work

in the first part During the work, the project team was interviewed in a focus group interview, which was then analyzed using Mayring's qualitative content analysis. Based on the analysis results, the structure of the project, the current use of application integration patterns, and the potential for the further use of patterns could be worked out.

in the second part During the work, one of the patterns, which turned out to be potentially interesting for the project in the first part, was checked for its concrete suitability. For this purpose, an example architecture representative of the project was implemented, which implements the pattern. In the following I would like to deal with the first part of my work. The second part will be the subject of another blog post.

What are application integration patterns?

Generally speaking, every pattern relates to a problem that occurs again and again in our environment. The pattern describe the core of a solution approach to this problem, so that this approach can be used again and again. [AIS77]

Patterns are derived from solutions that have already successfully resolved the problem in practice and can therefore be viewed as a well-founded approach to the problem [Fo02, p. 10] [HW03, p. 34].

There are a large number of patterns in software development, but many of them are only relevant for a special purpose or a special software division [Fo02, p. 2]. Application integration patterns are one such type of pattern. They enable efficient, reliable and secure data exchange between several enterprise applications.

Integrated enterprise web applications in practice

As part of the project mentioned, a monolithic ERP application implemented in COBOL will be gradually replaced.

Here, sub-areas from the legacy system are gradually converted into individual web applications (for example, article master, customer master, order management) and again integrated with the old system. The range of functions used in the old system is gradually reduced until the point is finally reached at which the old system can be switched off. This procedure is also known as a strangler pattern.

Advantages of the strangler pattern

The associated distribution of functionality over several integrated applications has a number of advantages.

  • The functionalities of the overall system can be separated on the basis of their topics. If this is strictly implemented, each application has only one point of integration with the other applications. The customer base application, for example, specializes in managing customer data. No other data is saved, and there is no further logic to other parts of the system in the application. The application therefore only offers one interface for calling up and changing customer data.
  • The parallel work on several sub-areas of the application is simplified.
  • The formation of another monolith is prevented.
  • Project participants who join the project team at a later point in time can find their way into the project more easily. Familiarization can also be limited to the partial application of the project that is relevant to the work.

Challenges in the development process

However, distributing the functionality to several applications also creates new challenges in the development process.

  • Since the functionality of individual applications also depends on the interaction with other applications, it must be partially covered by cross-application integration tests. Testing in an isolated environment is not always enough.
  • Since the old system is gradually being replaced, the parts of the system that are still productive have to be integrated into the new architecture. Since the legacy system should remain functional at all times during the implementation of the project, each new application is integrated directly with the relevant part of the legacy system. There is no dependency on a central integration point, but this procedure also affects the size of the applications.

The architecture of the project

From the analysis results of the focus group interview, a section of the architecture of the project was developed.

This excerpt only shows applications that were implemented in the course of the project, not the old systems integrated into the architecture.

The applications access the data of other applications via REST APIs. Each application can keep a cache with the previously requested data from other applications. This can be seen in a request from order management to the article master. The response resulting from the request is stored in the order management cache and reused if the request is identical.

If the relevant data is now updated in the article master, the application informs the message-oriented middleware of this by means of a message. This in turn distributes the message to all applications that consume this API, which then invalidate their cache for the resource concerned. With the next request you will receive the updated data. This procedure is described in more detail in the article AMQP in a rest scenario.

The portal, which can also be seen in the figure, manages information about the APIs available in the project and serves as a central point of contact for all applications that consume APIs within the project.

Use of application integration patterns in the project

Patterns from three different literature sources were used as the basis for the search:

  • "Patterns of Enterprise Application Architecture" Fowler, 2002 [Fo02]
  • "Enterprise Integration Patterns" Hohpe and Wolf, 2003 [HW03]
  • "Service Design Patterns" Daigneau, 2011 [Da11]

Since application integration patterns are derived from the architecture and applications of successful projects, they ultimately go back to the personal experience of the authors. Therefore, the list of patterns resulting from the literature sources is not to be understood as complete. The patterns identified in the project are by no means a complete list of the patterns contained in the project. Specifically identified were:

Service layer

The service layer [Fo02, p. 133] comprises all services (APIs) provided within the project. Operations provided by a service often encapsulate complex actions within an application in an understandable and manageable form. The service layer creates a view of the overall project that is optimized for interaction. In this specific case, the APIs form this layer.

Service Connector

This pattern [Da11, p. 168] encapsulates the code necessary for an interaction with a service in a module. Since this module can be reused in several applications, duplicates of the code are avoided. In this way, the code that is required for consuming the APIs is reused in the project.

Service registry

Information about the services contained in the project is stored in a service registry [Da11, p. 220]. This supports the uniform use and reuse of the services. The portal application is such a service registry.

Message translator

With the Message Translator Pattern [HW03, p. 96], applications that send messages in different formats can be integrated with one another. Here it is used specifically to integrate the legacy system into the project by translating its messages into a format that the message-oriented middleware can understand.

Gateway

A gateway [Fo02, p. 466] is also an approach to integrate an old system into a newer architecture. However, his approach is more generic and not only applicable to messaging systems, since it provides an interface for the legacy system, which is designed like an interface for the newly added applications. With the help of this pattern, COBOL data files, among other things, are made readable for the web applications in the project.

Combine the message, message channel, publish-subscribe channel and message router pattern to distribute messages

The patterns publish-subscribe channel [HW03, p. 113], message [HW03, p. 81-83], message channel [HW03, p. 76-81] and message router [HW03, p. 92] are used together and thus map the functionality of the message-oriented middleware. A lot of subscribers subscribe to news on a specific topic. Publishers now send messages to the middleware, which decides on the basis of certain criteria which topic the message is assigned to and thus forwarded to the relevant subscriber.

Such a middleware mainly consists of three components:

  • Message channelsto which the publishing applications can send their messages. The message-oriented middleware RabbitMQ used in the project calls this component "Exchanges".
  • Message routerwho decide how the messages are forwarded. In the context of RabbitMQ “Routes”.
  • Publish-subscribe channelsto which the middleware sends the forwarded messages and from which subscribing subscribers receive the messages. With RabbitMQ, a separate “queue” is created for each subscriber into which the message is forwarded.

The combination of these patterns, as used in the project, results in the following construction:

The message published by the publisher in the message channel is consumed by the message router (here a content-based router). Based on the presence of individual fields in the message and their content, the latter can decide where the message is to be forwarded to [HW03, p. 213]. In the example, this means that the message is only forwarded to the upper publish-subscribe channel. Since this in turn was only subscribed to by the two upper subscribers, but not by the lower one, only they receive the message.

Potential to implement further patterns in the project

It was also possible to find potential for the integration of further patterns in the project. These include the Message Store [Fo02, p. 487] and the Linked Service [DA11, p. 77] pattern.

By the Message store pattern it is possible to hold sent messages centrally instead of deleting them after successful delivery and processing. In this way, applications added in the further course of the project can subsequently consume the missed messages in order to achieve a consistent status. This could be implemented, for example, by using Apache Kafka as message-oriented middleware.

The Linked service pattern describes how the consumer of a service can only discover other services and possible inquiries within the current service on the basis of the responses received. In doing so, it is resistant to changes in the structure of the service or its URLs. This pattern is implemented as an example in the second part of the work, within the framework of an architecture made up of hypermedia APIs. Another blog post will describe the pattern and the example architecture in more detail.

In summary, it can be said that the relevance of application integration patterns for web applications has been confirmed. Parts of the examined project were deliberately built on the basis of different patterns, while other parts developed analogously to existing patterns.

swell

[AIS77]
Christopher Alexander et al A Pattern Language: Towns, Buildings, Construction. Oxford University Press, 1977. ISBN: 9780195019193
[Fo02]
Martin Fowler: Patterns of Enterprise Application Architecture. 1st edition. Addison-Wesley Professional, Nov. 2002. ISBN: 9780321127426
[HW03]
Gregor Hohpe and Bobby Woolf: Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. 1st edition. Addison-Wesley Professional, Oct. 2003. ISBN: 9780321200686
[Da11]
Robert Daigneau: Service Design Patterns: Fundamental Design Solutions for SOAP / WSDL and RESTful Web Services. 1st edition. Addison-Wesley Professional, Nov. 2011. ISBN: 9780321544209