Select routing or orchestration in the ESB?

Introduced

Today, the Enterprise Service Bus is a useful solution, and there is no doubt about it. Combined with a set of tools, it solves practical problems in the field of application and service integration. However, they give the user who is unfamiliar with them a slight inconvenience but the same as the toolbox. Those users who know the solution to the problem must be in the box, but do not know which is the tool to solve the problem!

From enterprise service bus to routing problem

The ESB involves multiple areas of application, including a service-oriented architecture (SOA) that implements the information systems category. But their basic purpose is to simplify the integration of applications and services-simply to let an application or service invoke another application or service. This very simple and mundane undertaking has various additional levels of complexity:

"Routing" occurs when there is more than one service, but multiple source services are invoked and multiple target services are selected;

"Protocol Bridge" occurs when a service is exposed to another protocol, belongs to another server, or even belongs to other information systems;

"Conversion" occurs when a service message does not have the same data format-this is a convention rather than an accident.

Three of them: routing, Protocol, and transformation have many close relatives, though, but the three are still considered the main ESB concepts. In this article, we will focus on the first one, and how it is associated with one of its closest relatives: allocation. Let's start with a brief description of the route, which we think is fundamentally low-level, is in or near the ESB core, and relies on technical configuration (such as a service deployment descriptor) to provide technical decisions about the destinations to which messages must be sent. Orchestration can be seen as the process of combining multiple service invocations into advanced, more useful composite services, but it is also often stamped with a "business level", which represents the abbreviation for a business-level process that combines a particular business service across applications and information systems.

Routing versus orchestration: neither "one-sided" nor "Black-and-white" world

So how do you handle allocation requirements in an ESB? It seems more logical to use a orchestration engine with a middleware solution. However, this is a complex question that cannot be easily answered. Let's consider the following example.

Displays a list of items (item)

The "Itemmanager" application is used to manage projects by creating, updating, deleting, and so on. A "Itemmanagementlistener" service is connected to this application and is responsible for issuing notifications when the project is updated.

Another application: "Hammermonitor" is a monitoring tool for displaying updated information about hammers-related items. This application exposes a "hammermonitor" service, which contains a display operation to receive these notifications.

Both of these services are exposed to an ESB. Our aim is to get hammermonitor to display the Itemmanagement application information about the hammer.

In order for Itemmanagementservice to be connected to hammermonitorservice, we need to configure several ESB connectors (connectors) (so-called "binding components"). One connector is linked to the Itemmanager application, and the other is linked to the Hammermonitor application.

In addition, connectors linked to Hammermonitor are configured to expose an endpoint (endpoint) with the name "Hammermonitorservice" inside the ESB. Thus, an easy way to achieve our goal is to configure the connector that Itemmanager links to, so that it calls the endpoint "Hammermonitorservice" within the ESB each time it receives a message from Itemmanager.

However, as is often the case in the real world, we assume that the two services have different data formats. This is not an impediment to SOA, because SOA defines a loosely coupled architecture (i.e., the service consumer does not have to conform to the service provider definition).

The Itemmanagement application provides the following message to Itemmanagementlistenerservice:

<items>
　　<item type="Hammer" name="hammer1"/>
</item>

The Itemmonitorservice display operation uses the following format:

　　

At this point, simply making the call does not link two services. The data provided by the Itemmanagement application must first be converted. This is actually a very simple, local allocation requirement that has nothing to do with the business level.

The first way to solve this problem is to use a common, well-known orchestration solution, such as mature, externally deployed, BPEL-enabled orchestration engine [2]. This is a good way to do it. But in this case, it's like overkill: either all the converted messages have to go through a centralized, remote orchestration engine that resembles an outdated hub-and-window integration architecture, or you have to deploy an orchestration engine at each node--for this simple problem, This solution is obviously too complicated.