Architecture Design: Inter-system Communication (35)-The deified ESB (bottom)

(Next: Architecture Design: Inter-system Communication (34)-The deified ESB (UP))

2-4. ESB and version control

The process of system integration in enterprises, there are many non-technical factors caused by the change. It is possible that a call function A, which has been able to function normally, is suddenly not available on one day. The technical team and the business team have been troubleshooting for a long time to discover that the calling interface to a business system in feature A has been changed privately (perhaps by simply passing a parameter, or by reducing the delivery of one parameter). This situation often occurs in the real world, it may be that the business unit for self-interest to shield the interface, or the technician in the interface changes, forget that the interface and external systems for use.

The versioning capabilities provided by ESB Middleware can help us solve this problem. The versioning feature here is not a version management for the entire project like git, but rather a refinement of versioning to the service interface level. The following shows the reader how versioning functionality works in the ESB:

, the key function for versioning is the registry module in the ESB. It manages the interface definition and interface version information that each business system has registered with the ESB bus to provide business services. When the ESB bus is in service orchestration, it can only use the business interfaces and the corresponding versions that have been registered with the registry .

This mechanism ensures that the business system can register a new interface version with the registry after the new version is ready. Prior to this, no matter how the modules of the business system changed, as long as the original interface definition registered in the registry did not change, it can ensure that the functions of the integration of the various business systems work properly. when the registry is offline for a version of the service, it detects if there is a business function that has a call relationship to the service and version , and if the check discovers that the service dependency is still present, the downline operation is not allowed. The registry can also batch upgrade older versions of existing orchestration logic after the new version of the service is registered.

It is important to note thatthe registry module in the ESB is not a prerequisite for ESB technology, as is the Protocol transformation feature . However, the ESB implementation with the registry and version management mechanism can guarantee the stable operation of the business functions on the bus.

2-5. ESB and Monitoring

Although there is no requirement that monitoring is a necessary part of the ESB-defined features, the current ESB middleware software is large and often plays an important role in enterprise system integration. So most ESB software comes with a monitoring module. The monitoring here is not a business-level monitoring, but a monitoring of non-business metrics:

• Monitor the health of atomic Service units:

  To ensure that the service routes provided by the ESB can be correctly invoked, ESB middleware needs to monitor the availability of atomic services provided by each business system. This is to ensure that after integration services, if one of the atomic services is in trouble the technical team/business team is able to be aware of the situation at the first time and can resolve it immediately. If there is a problem with the atomic service, it is likely that there may be a problem with the service orchestration being involved with the Atomic Service (which, of course, depends on the message routing conditions set).

• Monitoring the invocation of atomic services:

  The number of times, frequency, single execution time, peak access time of the atomic service provided by each business system on the ESB bus can reflect the importance of the atomic service and the performance of the atomic service itself. So the ESB monitoring subsystem needs to capture these metrics, indirectly helping the technical team/business team to optimize the non-operational metrics of the atomic service. For example: increase the compute nodes of a business system, expand the hardware performance of a single node, and even refactor atomic services.

• Monitoring of new business invocation scenarios after integration:

  In ESB middleware, the integration services built on multiple atomic services include the number of times the integration service is invoked, the total single execution time of the integration service, which atomic service in the integration service is the most time consuming, and which atomic service executes the most times. The protocol standard and message format used to invoke the atomic service, and so on, are the key data that the monitoring subsystem needs to collect.

• Monitor the health of the ESB middleware itself:

  The health metrics of the ESB middleware itself need to include, at a minimum, the CPU usage of each subsystem of the ESB, memory usage, network usage, thread performance, disk I/O usage, the currently active node in the cluster (and the node that failed), and so on. It should be noted that monitoring the health status and performance status of each business system is not the work of the monitoring subsystem of the ESB middleware , and if the latter has functions related to the former, it only monitors the health status of the atomic services provided by each business system.

3, Common ESB products 3-1, commercial (pay) with (fee) ESB Products

• IBM ESB family of products.

IBM offers two of pure software ESB Products: IBM WebSphere ESB and IBM WebSphere Message Broker (WMB). The latter is an upgraded version (or advanced version) of the former, which supports a wider range of transport protocols and message formats.

(This image is from the network)

The WebSphere Message Broker product is a fully distributed ESB product that uses multiple message broker instances to handle different business orchestration, message transformation work, respectively. These brokers are managed uniformly using the message Broker Explorer and message broker Toolkit (Eclipse-plugin-based developer tools).

• Oracle ESB Products
  Oracle Service Bus (OSB) is a paid product for Oracle:

From the OSB website document (https://docs.oracle.com/cd/E29542_01/doc.1111/e15020/introduction.htm#OSBCA117), the basic function of OSB is shown. Like WMB, OSB is also a fully distributed ESB product, and the tools provided to developers are based on Eclipse-plugin. Note that the idea of OSB and WMB for business orchestration is consistent: The ESB base layer provides only message translation and protocol translation actions, while service orchestration and routing rules are handled by a specific upper-level component (Message Broker/service virtualization). And these components can be flexibly deployed.

However, I do not see from the official documents of the two that these two paid ESB products support some of the currently popular transport protocols and message formats, such as support for PROTOBUF, support for Netty4, support for Avro, and so on.

• Primeton ESB Products

The Primeton ESB product is a relatively representative and useful self-owned ESB product (I did not suppress other ESB products in China):

From the official white paper of the Putin yuan. Primeton's ESB middleware system has been built and upgraded for many years, which is quite complete in domestic commercial ESB middleware. In addition to the necessary message transformations, message routing, Protocol transformations, service orchestration capabilities including ESB technology, there are many accessibility features, such as the editing management tools available to developers in ESB Studio, as well as a separate service registration snap-in, and monitoring subsystem functions such as the ESB middleware monitoring platform.

It seems that the Meta ESB Middleware has a community version that can be downloaded and used by developers. But the functional aspect certainly is not as comprehensive as the paid version.

3-2, Total (free) to enjoy (fee) ESB Products

• Mule ESB

Mule ESB is one of the products of integration service provider Mulesoft (official website: https://www.mulesoft.com/). This company also has a lot of interesting products, such as: AnyPoint MQ.

The Mule ESB is built primarily on the Java language, supports multiple transport protocols (FILE,FTP,UDP,TCP,EMAIL,HTTP,SOAP,JMS, etc.), and has independent tools for developers to use: Mule Studio. In terms of message format conversion, the Mule ESB provides a number of ready-made components that enable developers to easily implement message transformations within orchestrated services, and of course developers can define their own message format transformations in accordance with the specifications of the Mule ESB.

(from the network)

Enterprise Integration Mode (Enterprises integration Patterns is actually a book title), which is devoted to the integration of various business systems within the enterprise. The integration of business services in the Mule ESB is based on the EIP idea.

The Mule ESB has two versions, Community Edition and Enterprise Edition. The former is the version used by most developers, and the latter is paid for, but more powerful.

• ServiceMix

  Want to talk about Apache ServiceMix, finally think about it or forget it. Speaking of this open source ESB middleware, it hurts. If you want to use Apache ServiceMix, it is recommended to use the latest 5.6+ version. A reminder: You'd better figure out some basic knowledge of OSGi and use it to avoid detours.

• Apache Camel

A top-level open source project under the Apache Foundation, which provides a set of message routing rules and message transformation engines. But he doesn't have a ready-made message conversion component, and the technician needs to implement the message transformation itself (you can implement a message transformation and then reuse it in each route definition) in accordance with Camel's definition rules. Apache Camel support Domain Specific language (DSL), here we do not need to put this knowledge point out, for example:

//Orchestration Business process process  {//inbound  Procurement {Item_code =  "123456        " name = " item Name " Numner = 12  time  =  "2016-09-08 18:30:01" } //departure  Sendcar {car_code = " 098765 " plate =  "Beijing axxxxx"  time  =  "2016-09-09 19:37:00 " driver = " Wang Lao Five "}}  

The above DSL examples are implemented using the groovy language, although business people in the logistics industry do not understand programming, but they can also read the business process described in the examples above, and even adapt it. This is a domain-specific language-a language that is specifically used to describe business rules in a particular industry or domain. Apache Camel enables business people to use the Java language to describe rules in the area of business integration . Still don't understand? It's okay. Our next article will begin with a more detailed introduction to Apache camel usage, which will also be mentioned.

strictly speaking, Apache Camel does not count as an ESB middleware service, but developers can use it to get complete protocol conversions, message routing, and service orchestration capabilities . Then, you can integrate it into versioning, service registration, running monitoring, and so on, and use some way to get those services up and running . That is, we can use Apache camel to develop our own ESB middleware services that meet our business requirements.

4, the following text trailer

Through these two articles, the author did not use the Enterprise/Product preaching form, with many tall words to the reader to describe the ESB technology. Does this depend on the reader's perception that ESB technology is not so hard to understand? In fact, if you generalize the ESB technology in the simplest terms, then the most iconic generalization is: transformation and Integration . Conversion refers to the conversion protocol and message format, which means that the atomic service is threaded in a regular way as required.

Starting with the next article, we will introduce the Apache Camel component to the reader. The component service developer has the basic ability to transform and integrate, but to publish it as a usable ESB middleware, there is a lot of design and development work to do. Finally, we show you how to design an ESB middleware product that meets your business needs based on Apache Camel.

Architecture Design: Inter-system Communication (35)-The deified ESB (bottom)