Enterprise Service Bus (ESB)

Thinking:

What is the definition of 1.ESB? Is it a product or an architectural model?

What is the practical use of 2.ESB?

Defining an ESB

For enterprise Service Bus, there is currently no accepted definition, depending on the vendor and source, there are a number of different definitions, including the following definitions:

An integrated architecture style that enables communication between providers and service users through a common communication bus consisting of a variety of point-to-point connections "

"The infrastructure that the enterprise uses to integrate services in an application environment. ”

"An architectural pattern that uses service-oriented support for interoperability between heterogeneous environments. "(Fig. 1)

Figure 1:esb The architecture pattern into these major system architectures

The ESB is used for service virtualization, which typically manages a larger set of services and is located inside the intranet.

When to use an ESB?

There are no best practices for determining when an ESB implementation should be used, and you might consider using an ESB when you need to integrate three or more applications or services. Point-to-point integration is simple and cost-effective when connecting two of applications. You might also consider using an ESB if you want to get services from an external service provider that your business cannot control. The ESB can then be used to monitor service level agreements guaranteed by the external provider. You can further control the impact of service contract adjustments to a minimum, because the ESB will continue to provide a stable interface while making the necessary changes to the message.

If you use many different protocols (if: HTTP, SQAP, and FTP) and standardize them into a single protocol (such as soap), the ESB can perform the necessary protocol conversions. Using an ESB is also appropriate if you always need to combine services into one schema to receive, process, and generate messages. If you need access to a set of predefined components and adapters, the ESB is also used, which will support the standardized integration of protocols and legacy applications. If you need to handle messages securely and reliably, the ESB can simplify the implementation of transactional message flows between two heterogeneous transactional data sources.

If you need to send large amounts of data over the bus as a large number of independent messages, there may be some problems with using an ESB. An ESB should never replace traditional data integration, such as ETC tools. When copying data from one database to another, it can be more efficient to use data integration because it only unnecessarily increases the burden on the ESB.

If you need to implement long-term business processes, the ESB should support stateless message flows. Long-running business processes are stateful, preferably using BPEL and/or BPMN implementations. These processes are often not implemented through the ESB, but can be implemented through the Business Process Management System (BPMS).

ESB Blueprint

The ESB market is quite chaotic due to lack of standardization. Many of the products claim to be ESBs, but the solutions offered are quite different and are based on various architectures. To evaluate ESB products more effectively, we have organized the various functions assigned to the ESB into a blueprint (Figure 2).

Figure 2: Enterprise Service Bus Blueprint

The ESB blueprint does not include "orchestration" or "process orchestration" components, as this is considered part of the BPMS category. They provide a dedicated runtime environment for long-running, stateful business processes that are optimized to support languages such as BPMN or BPEL. The ESB should be stateless and should be configured to process messages as efficiently as possible.

Operations and Management Modules

The following functional components in the module support reliable Enterprise service bus operations and management. Statistics and Status provides the ESB statistics for the service, such as the number of errors, minimum and maximum response times, and the number of messages processed. Alerts provide a mechanism for sending alert messages that can be sent through various channels, so they can also be integrated into an existing monitoring environment. SLA rules are rules that are defined on the basis of information about the statistics and status functional components. Supports metrics and monitoring SLAs. You can use the alert component to notify any SLA infringement.

Message Tracking makes it easy to track messages in the ESB and should be activated when needed to minimize related overhead. message re-delivery ensures that messages that are not processed in a timely manner are automatically resent after a predefined time. You can configure the number of attempts and the time interval between them. This component is primarily intended for technical errors that persist for a period of time, such as temporary network outages. endpoint Failover You can specify an alternate service provider that is called automatically when the primary service provider is unavailable.

load Balancing can list several service endpoints for a logical service provider endpoint. It uses a redundant service implementation that alternately invokes each request according to a defined policy, can be called cyclically, or can be invoked based on message priority and load dependency.

message Throttling can define the maximum number of messages per unit of time that should be sent to service endpoints of the service provider. It prevents service providers from overloading during peak hours by buffering messages that exceed the threshold range in the ESB queue. message throttling also supports message prioritization, which ensures that high-priority messages are always processed first. Records and reports support logging messages for easy display later. It also provides functional audits.

Configuration Management supports the secure tuning of the ESB configuration on the operating system while maintaining the integrity of the configuration at all times. Components and properties can be adjusted and replaced during the operation. You can also save the change history so that the ESB service can roll back to an earlier state at any time. The Service registry can register and manage services on the ESB. High Availability ensures that the services provided by the ESB are fail-safe, regardless of the state of the server on which the services are running.

The wrong hospital is the destination of messages that have been repeatedly re-routed and cannot be processed, and can be viewed, corrected (if needed), and re-processed. deployment can automatically install services on the ESB. An environment-specific parameter, such as an endpoint URI, is typically overridden by that component. service Usage supports logging of service usage and charging users for fees.

Adjustment module

The tuning module contains the functional components used to implement the ESB service message flow. Message routing supports the forwarding of messages to a specific service endpoint based on the content of the message. If you use a protocol or message format that supports message header areas that are not related to the message body, the forwarding criteria may originate from the message body or the message header.

Routing based on the message header can be an attractive choice to improve service performance and scalability because direct access to the message header is more efficient than parsing the routing information from the message body. This is especially important for large messages.

message Transformation supports converting from one message format to another for text and binary message formats and XML formats. In addition, you can convert from text (such as CSV format) to XML, or from XML to text (such as CSV format). XML transformations use the well-known XSLT standard, XSLT supports declarative descriptions of transformations, and has graphical resources with drag-and-drop capabilities for creation purposes.

The main disadvantage of XSLT transformations is that if you work with large documents, memory usage is too high, which can limit the scalability of your solution. It would be much better if the ESB provided the option to support XML stream transformations (for example, through XQuery).

Service Recall can access other services in the message flow in the ESB, such as enhancing a message. The service may be a WEB service, but the ESB can support directly invoking program code (such as Java class methods) that are installed locally in the ESB, as you wish. Reliable Messaging supports the reliable delivery of messages using queues or ws* standards, such as ws-reliablemessaging.

protocol Conversions mean that you can switch from one communication protocol to another, such as switching from TCP/IP to HTTP, without any programming effort. message Validation ensures that the message is valid. In XML, this means that the message contains the XML defined by the specification and corresponds to a specific XML schema or WSDL. However, the ESB also provides additional validation methods, such as Schematron or the rule engine.

message Exchange Mode (MEP) supports message exchange patterns such as synchronous and asynchronous request/reply, one-way invocation, and publish/subscribe. The result cache can hold service invocation results in the cache, so subsequent calls that return the same result can be answered from the cache without having to invoke the service again. This is especially true if the data is static or requires sporadic or minor changes. This can greatly reduce the overhead of operations such as accessing legacy systems.

transaction Support the ESB provides transactional integrity through message processing. The persistent queue that the ESB uses to support reliable messaging is often used as a transactional data source, so it can participate in heterogeneous transactions. In addition, the ESB provides a distributed transaction manager that can coordinate distributed transactions through heterogeneous data sources using the two-phase commit protocol.

message reordering makes a message flow that belongs to a whole but that is not in sequence can be reordered. In a message-oriented solution that processes messages in parallel, the order in which messages enter the ESB may be lost. If the order is important for the service provider, the message reordering can be combined into the message flow. The reorder contains an internal buffer that processes the message until the sort is complete and can be sent.

pass-through messaging enables an ESB to efficiently forward ESB messages. This is useful if you want to use the ESB for service virtualization and forward the message from the service consumer to the service provider as it is. In this case, if the ESB does not touch the message, it is simply passed as is, and the functionality is well-suited.

Safety Modules

The module supports transport-level and message-level security with a large number of components. When a service consumer accesses a service in the ESB, authentication verifies its identity and verifies the ESB authentication against the service provider. Authorization provides a licensing system for services that can typically be configured by XACML to be assigned to users or roles.

Security Tuning supports interaction by converting the credentials of one domain to the corresponding credentials in another domain to communicate outside the security domain. encryption/Decryption supports the encryption and decryption of message content.

Adapter/Transmission Module

The module includes adapters that connect to the services provided by the ESB through the service hosting module. Assuming an ESB provides a set of adapters from scratch, customers or third-party developers can also develop additional adapters to meet specific user needs.

Service Hosting Module

The module supports the installation and operation of services directly on the ESB, which is usually required if the ESB is based on an application server. A service container provides one or more containers in which to install services and manage lifecycles. It provides access to technical cross-sectional functions such as transactions and security.

The component Model provides an abstract component model, such as Java EJB, Java Spring Framework, or Microsoft COM +, on which to create the service.

Real-world Scenarios for ESBs

The symbols shown in Figure 3 are used to graphically describe a variety of scenarios without reference to a product or tool. These symbols are derived from [1] and are constantly added according to the ESB functionality.

Figure 3:esb Symbol Scenario 1-Service Virtualization

Service users tend to prefer hard connections to actual service endpoints, especially in BPEL processes, because the tools provided are easy to execute. However, changes to the server address at run time will never produce changes that need to be redeployed at the service client. A very good solution to this problem is to use the ESB virtualization endpoint. Figure 4 illustrates this scenario where the service provider's Web service interface is no longer used directly by the consumer, but by the ESB. An ESB can provide an interface exactly as it would provide an interface for a potential service consumer.

Figure 4: Using the additional Monitoring Interceptor virtualization service

Any changes that need to be made to the endpoint address can be easily implemented during the ESB configuration process, so the service consumer can continue to run as before. However, the ESB needs to be able to merge into an existing message flow. Service virtualization also supports the use of ESB monitoring capabilities that extend to service statistics to check SLA compliance and, if not, configure the appropriate actions. Service virtualization can be performed if the service provider has made changes to the service contract but does not want to affect the service consumer. In this case, a simple conversion of the exchanged message resolves the problem.

Scenario 2-Service Support

When incorporating services with functional interfaces, it typically occurs when service consumer and service provider use different languages at the protocol level. Figure 5 shows two service providers, technically they provide the same service, one provides the SQL interface, and the other provides the FTP interface. You can use the Enterprise Service Bus as a protocol converter to keep the interface intact, because it provides methods to ensure that the defined interfaces are used.

Figure 5: Service Support

Similar to Scenario 1, if the communication protocol changes in the future, the ESB ensures that the service consumer or service provider side does not need to make subsequent changes.

Scenario 3-Secure message Handling

The ESB can also support traditional integration scenarios, with the primary purpose of forwarding messages from one system to another. In the scenario shown in Figure 6, the ESB enriches these messages with a message from an external queue, using a service call to a WEB service, and then sends the message to the target system through the database adapter.

Figure 6: Secure Message Processing

Processing in the ESB is transactional, meaning that the message flow is configured to participate in distributed XA transactions like other contributors. A transaction is started when a message in the queue is used, and the transaction also contains database operations performed by the database adapter. If the message flow completes successfully, the distributed transaction is committed immediately thereafter.

Scenario 4-Service version control

Services tend to change over time and often require the introduction of a new incompatible version. In these cases, you can use the ESB to perform transformations from the "old" interface to the "new" interface. In the scenario shown in Figure 7, the service provider introduced the 2.0 version of the service, and service consumer B installed the version immediately. Service consumer A has been using interface 1.0 and does not want to switch to version 2.0 because it does not bring any added value to the business. However, the service provider does not want these two versions to run in parallel. Running two interfaces at the same time can be difficult, even technically infeasible, and can lead to unnecessary resource consumption.

Figure 7: Service version control

If the ESB provides 2.0 versions directly through pass-through delivery (similar to Scenario 1), the situation may be relatively straightforward. At the same time, you must provide version 1.0 of the interface while adapting to the existing message flow, so that the 1.0 version will no longer be called from the service provider. Instead, the message is converted from version 1.0 to 2.0 and then sent to the new service. This conversion can be relatively complex, depending on how large the differences between the two versions are. In order to provide all the information required to invoke version 2.0, additional 1.0 version messages may be required.

Transformations and Interface 1.0 in the ESB need to be maintained until no service consumer uses the old interface. This conversion is performed in the ESB instead of being mapped from version 1.0 to 2.0 in the service provider, for the following reasons:

• Mapping is a technical issue and is not relevant to business-related issues
• does not affect external service providers.
• The ESB makes the use of the old interface transparent.
• When all service users switch to Interface 2.0, there is no need to change the service provider.

Summarize

An ESB is a middleware solution that uses a service-oriented model to facilitate and support interoperability between heterogeneous environments. No specification defines exactly what an ESB is or what functionality it should provide. Although the ESB is primarily related to concepts such as "tuning" and "integration," it is also suitable as a platform to serve as an application server-like approach. The ESB represents the consolidation of product categories known as "Integration" and "Application server."

One of the key features of an ESB is service virtualization. The ESB blueprint presented in this paper provides an orderly arrangement of various functions and forms the basis for evaluating ESB products.

Points

• An enterprise service bus should be treated as an architectural style or pattern, not a product.
• The ESB does not have a definition or specification, so there is no standard.
• The ESB helps to achieve loose coupling between systems.
• The service on the ESB is stateless. Long-running processes are not part of the ESB, but are supported in BPM systems that use languages such as BPEL and BPMN.
• The "misuse" of an ESB to perform batching should be exercised with caution, as it may adversely affect performance.

Resources

[REF-1] Http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html

　　

Enterprise Service Bus (ESB)