ESB Enterprise Service Bus

Original article link

ESB is the abbreviation of enterprise service bus. It is the product of the combination of middleware technology and Web Service technology, and is also the core infrastructure of SOA systems. An ESB is a service intermediary that forms a biological chain of service users-> ESB Service proxy-> service providers. The role of the intermediary varies in different applications:

• Decoupling mediation: the customer does not know or care about the identity, physical location, transmission protocol, and interface definition of the actual service provider. The interactive integration code is extracted from the business logic, the ESB platform implements central declarative definition. The ESB platform implements protocol conversion (WebService, HTTP, JMS ...), message conversion (conversion, enrichment, filtering), message routing (synchronous/asynchronous, publishing/subscription, content-based routing, branch and aggregation ...).
• Service intermediary: the ESB platform serves as an intermediary to provide basic services in service interaction. The ESB platform implements SLA (reliability assurance, Server Load balancer, traffic control, cache, transaction control, encrypted transmission), service management monitoring (Exception Handling, service calls, and message data records, system and service status monitoring, ESB Configuration Management), unified security management (this is a bit idealistic ).
• Service orchestration: orchestrate multiple services to form new services. ESB allows you to define a new service Combination Process (workflow, BPEL, or code-level orchestration) in an intuitive way ).

From the above, we can see that the basic functions of ESB are data transmission, message protocol conversion, and routing. With these three core functions, we can see that the ESB provides these functions as needed when integrating heterogeneous systems. SOA can be implemented without an ESB. For example, it is difficult to implement message protocol conversion and dynamic routing when SOA is implemented using SCA and BPEL.

In the development process, ESB has been transformed from the original message middleware to the ESB product. Such message middleware and Data Bus products are widely used in the original EAI enterprise application integration. SOA emphasizes service-based integration and uses Web Service as the basic management unit. The positioning of a service is about how to express the business logic as a set of independent, self-described and interoperable entities.

SOA focuses on the full lifecycle of services and business value through services. While ESB focuses on the integration of service mediation and services, and is the infrastructure of SOA. SOA has two core components: one is ESB, the other is BPEL, while the ESB is infrastructure, and the other is service integration and integration driven by business processes. Without SOA, the ESB will lose the services it connects to, instead of just a bus, it will also become worthless. Bobby makes a metaphor: A path has no value unless you use it to move one thing from one place to another. Without SOA, ESB is like a road that nobody uses.

Do not create a big and comprehensive ESB first when doing SOA. Instead, focus on your business problems and find solutions to business needs using SOA, in the process of solving this problem, you will see a series of business services. These business services produce business value. It can be flexibly assembled to dynamically solve your changing business needs. This is its value. Only in this way can you make your business agile and respond as needed. In the process of service assembly, you should consider using ESB to connect them.

 

ESB needs some form of service routing directory to route service requests. However, SOA may have a separate business service directory. The most basic form of SOA may be the service directory during design, it is used to reuse services throughout the development activities of an organization. Web Service vision has a UDDI directory in the service directory and service routing directory, so that you can dynamically discover and call services. Such a directory can be considered a part of the ESB; however, before such a solution becomes prevalent, the business service directory may be separated from the ESB.

 

Many of the above functions can be implemented either using proprietary technologies or using open standards. However, using different technologies to implement an ESB may significantly differ in their performance, scalability, and reliability. At the same time, the ESB functions are different from the supported open standards. For these reasons, coupled with the recently developed and emerging standards, many key decisions for implementing ESB today involve the trade-off between mature proprietary technologies and immature open standards.

Support the implementation of ESB with the lowest SOA functionality

If only a portion of the previously defined functions are related to most SOA scenarios, we may ask: what constitutes the minimum set of functions required to implement an ESB? To this end, consider the principle of the most universally recognized ESB definition:

• An ESB is a logical architecture component that provides an integrated infrastructure consistent with the principles of SOA.
• SOA principles require the use of implementation-independent interfaces, communication protocols that emphasize location transparency and interoperability, service definitions that are relatively coarse-grained and encapsulate reusable functions.
• ESB can be implemented as a distributed heterogeneous infrastructure.
• ESB provides methods for managing the service infrastructure and functions for operations in distributed heterogeneous environments.

 

 

 

Note that these minimum features do not require special technologies, such as EAI middleware, web services, J2EE, or XML. The use of these technologies is very similar and meets the requirements, but they do not have to be mandatory. On the contrary, the lowest feature can be implemented by simply using SOAP/HTTP and WSDL (not all of them are ):

• URL addressing and the existing HTTP and DNS infrastructure provide a "bus" with routing service and location transparency )".
• Soap/HTTP supports request-response communication specifications.
• HTTP transmission protocol is widely used.
• Soap and WSDL are open and implementation-independent service communication and Connection Models.

However, the basic applications of SOAP/HTTP and WSDL are only point-to-point integration and cannot implement some key functions required by the ESB:

• Currently, there is no management function for controlling service addressing and naming. The service name is independently controlled by each adapter. The service routing control is dispersed between the addresses called by the service client, the HTTP infrastructure, and the service name allocated to the adapter.
• Although this method depends on implementation details, it often does not make the replacement of service implementation simple; the service requestor code (may also be generated by development tools) generally, the protocol of a specific address is directly bound to a specific service provider. To replace the original service implementation with another service implementation, You need to modify the application code and redeploy the code.

Of course, in many or even most cases, other functions are often required, and such requirements become increasingly common. In particular, the following types of requirements may lead to the use of more complex and advanced technologies:

• Service quality and service level functions.
• Advanced SOA concepts, such as service orchestration, directory, and conversion.
• On-demand operation environment requirements, such as management and autonomy functions and smart infrastructure functions.
• Asynchronous operations across multiple networks with different ownership, multiple protocols, and multiple domains.