Post: ESB topology Solution

Author Adrien Louis Translator Hu Jian Summary

When implementing SOA, infrastructure such as the Enterprise Service Bus (ESB) is very popular. In an enterprise, there are at least two different implementation ideas for this infrastructure: using multiple ESB servers in the company, each server solves special integration problems for a specific department; or use an ESB that covers the entire company. It is responsible for linking all parts of the information system together. This article will discuss the two methods in the architecture andManagementIssues.

Different infrastructure

Over the past five years, ESB has been a buzzword in the basic aspect of SOA. The concept of ESB was proposed by David Chappell, but it is still not properly defined today. Indeed, every ESB vendor advocates their own visions, and there are also different implementation methods at the infrastructure level. Each method has its own advantages and disadvantages.

The first approach is to allow various departments to manage their own SOA with their own ESB implementation. It manages Application Integration and business process development. By using a scattered and independent ESB, each department can freely implement the solution it wants. However, when you need to communicate with other partners, the Department's ESB must use a standard "bridging" technology (such as Web Services) to access and provide some business services. In this case, communication can depend on protocols such as HTTP, while service quality (such as reliability or security) must be achieved manually.

The second method regards the SOA infrastructure as an overall view, where the ESB is unified throughout the company. This type of ESB is deployed on servers in various departments to ensure communication between them. It is very easy to call the services provided by another department, because the way the consumer communicates with the ESB is different from the way it calls the local service.

In this view, the ESB is actually considered as a backbone infrastructure, just like an Ethernet. In fact, an ESB is a collection of inherently interconnected nodes. A node is the connection point of a service consumer or provider.

Note: an ESB node is actually an ESB server that has network capabilities and can be interconnected with other instances.

The ESB covering the entire company's network is not a big brother.

The Chief Information Officer may say, "Oh, no! I don't want a 'ubiquitous 'tool that allows anyone to browse and access anything in the company. administrators may say, "How do I manage and supervise ?", "Other administrators can modify things on my servers. This is impossible," or "What should we do with security ?", And so on ......

Obviously, a general ESB won't allow everything. It simplifies the communication of the entire network and provides the quality of service for a group of networks in a simplified way.

Unify the domain in the ESB)

The domain and subdomain define the boundary between objects. In this way, each ESB "Node" can only be managed by the subdomain administrator. The subdomain Administrator is the only person who can start, stop, install connectors, and deploy services. The subdomain administrator manages the ports used by the ESB nodes in the domain, you can also set a proxy or firewall to protect these ports.

Business services deployed on nodes in a domain can be public or private. That is to say, in registration, a private service is only visible to consumers in the same domain. Moreover, private services can only be accessed by consumers in the same domain.

Note: unless explicitly stated, private services will not be discussed in the following sections.

Service and Process Monitoring can only display information about the current domain or public information about other domains, but cannot see the process or service statistics of other private domains.

Now that we have cleared several potential misunderstandings about what unified ESB is, let's take a look at its advantages.

Registration Center

In a non-interconnected ESB environment, services in other domains can access the service only when a bridge is explicitly created between the ESB of the two domains for the service. For example, if a service in a domain is exposed as a classic web service, another ESB must know the URL before calling it. To reference all such Web Services, a company-wide registration center is required. In this case, the managers of each domain must publish the web services of this domain to the Registration Center of this company. These web services can be considered a company's "public" services because they are visible to all consumers.

In a unified ESB, the business service registration center itself is unified. The Registration Center of each ESB instance is synchronized with the Registration Center of other ESB instances. A consumer or service browser connects to an ESB in one of the domains to view all services on the bus. Every time a new service is exposed to an ESB, all consumers on each ESB instance can immediately discover and access it, regardless of the physical location of this ESB. All services are accessed in the same way; they are "ESB services ". No matter how they are implemented or what protocols are used.

Editing

There are two solutions for deploying services on multiple non-interconnected ESB. One solution is to place the BPEL engine outside the ESB environment, for example, to use it as a Web Service BPEL engine. In this way, the process designer must understand all the services in each domain. In addition, these services may have to be integrated into Web Services for access. During running, the BPEL engine must establish an HTTP connection on the entire network to access these services.

Another solution is to integrate the BPEL engine into the ESB and call the services available in the local environment. When it needs to access services in other domains, it must first access the peer's ESB through bridging (such as a web service call) and then call the peer service.

For a unified ESB, the "internal" registration center contains all the services and descriptions on the bus. You can easily design a process by connecting the BPEL designer to the ESB registration center. The process design only involves the ESB service. You can retrieve all available services in the Unified Registration Center and integrate them directly into the process. At runtime, the issue of transactions and compensation is also easy to solve because there is no bridge between the BPEL engine and the service.

Reliability

In an integrated environment like SOA, there is basically a lot of communication between applications. They are spread across different servers, and information is transmitted through the network in large quantities. To avoid information loss, the infrastructure transport layer should be as robust as possible. The ESB transport layer often provides message reliability, but the reliability of the bridge between the ESB and the application depends on the capabilities of the underlying protocols (such as Web Services, FTP, JMS, and RMI.

For non-interconnected ESB instances, it is also necessary to ensure the reliability of messages between instances. A reliable communication must be configured for each service located on another ESB instance. Configuring a JMS queue for each service can solve this problem. In addition, the communication between the sender's ESB, the JMS queue, and the receiver's ESB may need to support transactions. This work becomes very difficult when you need to access services in other domains in large quantities.

When using a unified ESB, you can install an ESB instance on each physical server that acts as the integrated application host. In this case, a Web service call or an FTP connection is still on that server. A network crash does not affect the communication between applications and ESB nodes. Network Communication is completed through an ESB node. Reliability is ensured by the transmission layer of the node (usually based on a JMS mom (Message Oriented Middleware )).

Of course, it is ideal to install an ESB node on the host server of each application. Applications that do not require perfect reliability can connect to a remote ESB node that is stored on a separate server. Likewise, in a secure network environment, the ESB server may be shared by several applications. This depends on administrator resources and costs.

Service governance

In a non-interconnected environment, it is not easy to manage Service lifecycles and versions. Whenever a new service is exposed to an ESB instance, the connector must be configured to allow consumers of other instances to access it so that the service can be exposed to other instances. When a new version of this service is available, each connector must be updated to ensure that it is consistent with the new version. In addition, if the company-wide registration center that does not reference all ESB instance services, consumers from other ESB instances will never know that some services exist on one instance.

In a unified ESB, because each instance is inherently interconnected internally, services deployed on one instance can be immediately used by consumers on other instances. You can see this service in the Registration Center of each instance. When this service changes, every consumer can benefit from this new version.

Management

Most of the time, administrators in non-interconnected ESB environments (who are responsible for connector installation, service deployment, and other lifecycle management) have to connect to each ESB Management Console in the domain to complete management tasks. The administrator configures the behavior of each ESB instance separately.

With the unified ESB, the domain administrator can use a single console to manage all nodes in the domain. On this console, the administrator can view all the topology structures. The main advantage of this method is that the administrator can view all instance activities in the domain (resource consumption, service call statistics, etc.) and manage the behavior of the ESB. For example, if a service (such as the XSL conversion service) is over-used, the administrator can instantiate a copy of the conversion service and deploy it on other instances, then define a Server Load balancer rule to distribute requests. This cannot be done in a non-interconnected ESB environment (even if it can, it is very difficult ).

Business monitoring

Business activity monitoring is one of the most interesting features that the SOA infrastructure brings to Operation managers. Service statistics can be obtained in real time; business processes can be monitored and optimized; when exceptions occur, an alarm is sent by email ......

In a non-interconnected ESB environment, it is not easy to collect Key Performance Indicators (KPIs. KPIs of each ESB instance must be collected separately, and communication between two instances (such as one web service call) is also difficult to monitor. All data must be correlated before it can be read by the monitoring tool.

The unified ESB simplifies the collection of KPIs in the domain. Because there is no unmatched protocol between instances, the life cycle of an exchange from the consumer to the provider can also be monitored, even if they are not hosted by the same ESB instance. The monitoring console can connect to any instance of the domain and display the statistical results of the domain.

Summary

Each ESB provides a set of functions and tools for integrating applications. Using a set of connectors and services (such as conversion or configuration) makes application integration easy.

For a given integration problem, people can use a "central" ESB, some connectors, and use it to become glue between two or three applications. Most of the time, this "point-to-point" method is simple and can be quickly installed without the need for business service definitions (such as WSDL ). As in this articleArticleAs you can see in, this "integration" view may be enough for simple scenarios, but it is not enough for a true "service platform" (ESB must be the backbone of an enterprise's SOA.

Selecting an ESB that allows real network communication is the key to implementing the "service platform" in the enterprise. It allows us to view all activities and services in the information system in a global view, and enhances its mobility, because every service in the entire enterprise can be conveniently used in the way of business steps.

Author Profile

Adrien Louis is the chief architect of EBM websourcing. He has 8 years of experience using Java EE technology. Currently, he is working to solve the problem of enterprise integration. Adrien is an SOA consultant and an architect of the petals open-source project. Petals provides a leading Open-Source ESB supporting SOA and is committed to becoming a lightweight, highly distributed and scalable platform for both A2a and B2B. Thanks to its special distributed architecture and tools, petals provides a very competitive integration solution that supports a wide range of protocols, formats, and integration features.