ESB-Enterprise Service Bus has no myth

In many seminars, Enterprise Architects have discussed many issues, such as issues related to Service-Oriented Architecture (SOA) and how to enable the Enterprise Service Bus (ESB) as the backbone of building an Enterprise SOA framework. Many people question the significance of ESB, which also shows that the current IT group has some misunderstandings about ESB.

In many seminars, Enterprise Architects have discussed many issues, such as issues related to Service-Oriented Architecture (SOA) and how to enable the Enterprise Service Bus (ESB) as the backbone of building an Enterprise SOA framework. Many people question the significance of ESB, which also shows that the current IT group has some misunderstandings about ESB. The following is a summary of the 10 most concerned ESB issues.

Misunderstanding 1: ESB only changed the EAI name
While building SOA, many IT architecture groups are still plagued by a problem: "What is the difference between ESB and EAI ?" ESB is an infrastructure for Building Enterprise SOA. It is more widely used than traditional EAI agents. According to the report of the forister Institute, ESB can improve connectivity, increase flexibility to promote development, and enhance control over important resources, so as to help enterprises realize the value of SOA.
An ESB can be used not only to process integration projects that previously relied on EAI tools, but also to establish B2B relationships between enterprises.
ESB can provide the functions that EAI can provide, but its basic architecture is different: This architecture facilitates enterprises to switch from traditional integration methods to coordination service interaction. EAI is usually implemented in the form of independent applications using a star architecture.
The functions provided by the ESB are the same as those provided by the EAI proxy-the connectivity, application adapter, message routing based on rules, and data conversion engine-but these functions are SOA-oriented, they are distributed across the service bus and stored in independently deployed service containers. This allows us to selectively deploy the required integrated proxy functions without generating redundancy. This distributed feature of the ESB container model enables the integration components added to SOA in the form of event-driven services to have independent scalability.
To enable the integration agent to support SOA in a true sense and become an ESB in a true sense, we need to distribute its basic functions to components, each component can then be deployed to the bus independently and coordinated.
Let's look at a XSLT-based conversion engine. The engine can convert an XML file to another XML format based on the XSLT schema table. I can tell you responsibly that nothing consumes computing resources more than analyzing and processing XML. If there is XSLT conversion between two frequently interconnected applications, this conversion may become a bottleneck of performance and expansion. If you are using a standalone star set as a proxy, you must install the integrated proxy on a machine with powerful processing capabilities to solve this bottleneck and expand deployment, or install it on multiple machines. This is only to solve the conversion problem. At the same time, other integrated proxy functions, such as routing rule processing, are still competing with Conversion Processing to snatch computing resources.
Unlike the star architecture integrated with proxy, the basic core of ESB provides a distributed service architecture. This architecture is integrated-oriented. It can selectively deploy various functions in the integration proxy, such as message routing, data conversion, and application adapter on demand, these independent integration services constitute part of SOA.
You can deploy XSLT transformations in the form of services to the ESB service container, and then distribute multiple instances of the container to many machines according to the load balancing. If this ESB container is implemented across platforms, you can also flexibly choose the platform that the conversion service spans, such as Linux host, Solaris host, and Windows host. If you do not like this simple architecture, you can also consider the following: suppliers who propose non-difficult ESB definitions and products also provide us with convenience: you can deploy any number of lightweight ESB service containers at no extra cost.
This integration service provided by ESB can be integrated with other services into the SOA-based processing process to expand the business scope. The distributed service in ESB can be combined with the Route Selection Based on itinerary-based (see Error #7) to achieve self-oriented and message-oriented service interaction, in this way, each part of the ESB can work independently without dependency on a centralized routing engine.

misunderstanding 2: Microsoft is using "Indigo" to create an ESB
Microsoft's indigo incorporates messaging queuing, Component Object Model COM + ,. and Web services. They are working on a message bus with Web service extensions. This is very different from the Enterprise Service Bus. The message bus exposes the details of the low-level message technology. It needs to write Code to define the relationship between applications and services. The significance of ESB lies in configuration rather than encoding. Therefore, you do not need to manually write the relationships between applications that are interconnected internally. ESB is conducive to improving the loose coupling between applications exposed on the bus in the form of event-driven. The good news is that the Applications created on indigo are at least message-based, so it is easier to integrate with ESB.
that is to say, some of the items in the BizTalk Server may be compared to the ESB after being combined with Indigo. However, it is very important that BizTalk is a star integration proxy, so it is also affected by all the adverse aspects mentioned in ESB and EAI. You cannot detach the XML Conversion engine from the BizTalk Server and run it on multiple machines as a server Load balancer service without increasing the cost (see the previous discussions on EAI and ESB).

misunderstanding 3: WS-rliability, WS-reliable messaging, and other WS-* standards will eventually lift the requirements for the ESB
when designing the ESB, we should consider making it based on these evolving and gradually adjust the standards for commercial application value. The development of WS-* standards enables application terminals to better interact with each other through ESB.
due to parallel work, as part of the evolving web service standard, WS-* standards naturally have many uncertainties. Even if these standards are ultimately well developed and widely used, they still need a platform that can support them. An ESB can provide enterprises with a unified model for building, orchestrating, and managing SOA at a level unrelated to the underlying collaboration standards.
The Implementation of The WS-reliability standard requires reliable message persistence and support for storage and forwarding processors. The Enterprise message layer is a basic component of ESB. It ensures the quality of data transmission service through message protocols such as message persistence, storage transfer, message verification, and interfaces with the external XA-compliant transaction processor. The deployment of ESB may also make the message routing in the complex network layout transparent, and realize the continuous availability of message facilities through the fault-tolerant message server architecture. In the current high-pressure enterprise environment, it takes many years to implement all these designs.
that is to say, one or more WS-rel * protocols should also be used as supplementary protocols to prepare for the future when deploying an ESB with a proprietary message layer. However, this is not a solution that can solve all the problems. We still need to provide support for the combination of multiple messages and protocols.

Misunderstanding 4: model or product?
The term enterprise service bus (ESB) does not actually fall into the product category. It is just an abstract concept that can realize the coupling relationship between application servers and integrated middleware.
ESB is a backbone bus used to build a highly distributed Enterprise SOA. Enterprises need to build a service-oriented architecture, while ESB is the basic bus of this architecture. Because the emergence of ESB has a lot of impact on the integration market, some integration vendors will release the MOG shell that ESB is just an abstract model that can be used to combine the current middleware and application service facilities. In fact, the ESB is indeed a kind of hardware design, and it can be purchased from various vendors a few years ago. So far, many ESBs have been deployed in manufacturing, finance, telecommunications, retail, and other industries.
The definition of ESB should include the following basic elements:
· A distributed service architecture, including a lightweight container model for storing integrated components as remote services
· An enterprise message backbone bus that provides reliable message transmission for various applications and services
· XML Data Conversion
· Service orchestration and smart Routing Based on Message Content
· A flexible security architecture
· Remote service management facilities can be configured, deployed, monitored, and managed
Because of the distributed service architecture of ESB, we can access services through virtual terminals anywhere in the world. This distributed service architecture is built on an interconnected system consisting of lightweight service containers that can be configured, deployed, managed, and monitored through remote services. These service containers are combined by a standardized backbone bus that achieves scalability, continuous availability, low-latency processing, security consistency, and Quality of Service (QoS.

Misunderstanding 5: competition between ESB and J2EE Application Service Products
The ESB and J2EE app server are highly complementary. Connect to the ESB through standard interfaces such as JMS, mdb, JCA, and Web services. The J2EE app server can be well integrated with other application servers even in non-J2EE environments.
Most ESB users are also users of application server technologies. These users use the application server and ESB as the optimal component of their integrated environment-use the application server to store business logic and provide website services in the form of portals, at the same time, ESB is used to integrate the application server with various backend applications and data sources in the enterprise.

Misunderstanding 6: you only need to use web service call to connect the portal website to the backend system.
Although theoretically web service calls can connect portals to the backend target system, this method cannot be extended to multiple backend systems. By using ESB, the Portal Server can connect to the bus through a unique interface, the bus is the medium for various connection attributes, protocols, security, and data formats on all backend systems that the Portal Server may call.
The use of ESB as the Portal Server and the middle layer of various backend applications that may interact with the Portal Server is equivalent to providing an SOA with more flexibility and better scalability for the ESB users, therefore, when the project is more successful and changes based on business needs, they can freely process a variety of integration jobs.

Misunderstanding 7: When BPEL is widely used, the ESB will exit the stage.
ESB supports multiple event-driven service calling orchestration methods. BPEL is only one of them. The ESB also provides route-based routes to specify a series of routing commands for messages. When messages pass through the bus because they are called by the Service, these routing commands defined in the business process are always bound to messages. Then, the remote ESB service container determines where the message is sent.
There is no centralized routing rule engine in this process, so route-based routing is also a major manifestation of the distributed feature of ESB. A centralized message routing rule engine such as the one used by the star EAI proxy may become a bottleneck of the system, and if this part fails, the whole system will be paralyzed. It is enough to use message routes, messages, and process definitions. This allows different parts of the ESB to work independently.
Message routes can effectively process stateless random processes that can end with limited steps without a long processing time. Gantt said this process was defined as "microflows )". Based on the usage of the content-based routing service, simple branches may be generated in the route.
If you need more complex process definitions, you can add a Process Orchestration engine to the ESB as a supplementary service. This Process Orchestration can support State processes that may exist for a long time. It also supports parallel execution paths with sub-branches, and supports message stream execution path Fusion Based on the connection conditions or conversion conditions. Such a process can support BPEL and other process definition syntaxes, such as ebXML BPSS. It can also combine Mature Process Orchestration with non-State Route-based routing to build an SOA that can solve complex integration problems.

Misunderstanding 8: The ESB technology, like other technologies, is experiencing a typical technological development curve: it was created out of thin air and rapidly developed, and then immediately entered the "zombie" stage.
The concept of ESB is the result of the joint efforts of leaders in multiple industries, such as manufacturing, e-commerce, telecommunications, financial services, and retail. This was due to the need to build a new approach based on the already successful distributed computing model and EAI technology. The final results of these IT pioneers are consistent: "Our distributed messaging infrastructure is successful, therefore, we hope to build a standard-based event-driven SOA for integration based on this. We hope it can include web services, XML data conversion, content-based routing, and service calling models for Distributed processes. "Therefore, the concepts embodied in ESB are mature and have a sound foundation. Because of this, the ESB technology is playing its due role. There are already hundreds of ESB services in various industries, such as supply chain, logistics automation, global direct processing in financial services, real-time telecommunications services, and remote store management in the retail industry.

Misunderstanding 9: ESB is just a streamer, but it does not provide mature tools, such as graphic editors for designing business flows.
There is a new IDE (or the ISE defined by Gartner) that allows you to design, configure, test, and debug the integrated services you develop when building an SOA for an application ESB. The graphic interface is used. The integrated designer can describe the process definition in UML notation. You can also use ISE to create a graphical conversion mode between different data and create and debug An XSLT schema table.

misunderstanding 10: you can use EJB containers to implement an ESB container
A key component of the ESB structure is a highly distributed and lightweight service container. This service container can store integrated components in the form of event-driven services. For example, a content-based routing service that adds an XPATH expression to an XML message to determine the route. It can also store customized services or dedicated adapters for accessing packaged applications.
This is different from the Application Server container and integration proxy of their distant relatives. The ESB service container allows you to selectively deploy the integration service anywhere at any time, not much or less. On the other hand, even if you only need to add some integration functions, you need to install the complete Application Server Stack in all places. This leads to the so-called "application servers everywhere" problem. At the same time, a large number of licenses, installation, and subsequent fees will be generated.
the essence of ESB is "replacing the encoding configuration ". If it is based on application server integration, you usually need to write code to describe the dependency between services. The EJB model uses the integration mode of Client/Server, and interfaces between services are tightly coupled. All these must be written into the code and compiled into the class file. In this way, modify and redeploy these files each time you need to modify them.
In ESB, services are configured based on information related to the input and output channels. These channels send and receive Content-based request and response modes and one-way Event Notifications, and then process them through other call frameworks, rather than the service itself.
you can configure and deploy the ESB service. You only need to read information such as the XSL mode table, XPath expression, script, and parameters from the configuration repository. Once the deployment is complete, its performance is highly flexible.

conclusion
in general, the understanding of ESB includes the following aspects:
· ESB is the backbone bus for establishing an Enterprise SOA integration environment.
· the development of WS-* standards will improve the interaction of ESB. Using ESB today will allow you to prepare for the future and make appropriate adjustments when the WS-* standard has real commercial value.
· ESB is not just an abstract mode. It belongs to the product category and has a clear definition, and many suppliers can choose from.
· Strong complementarity between ESB and application server.
· ESB provides flexible connectors and scalable facilities to facilitate the integration of portal servers into backend systems.
· ESB provides many options for coordinating interactions between services.
· the ESB technology is based on reality and has been applied in many industries.
· ESB provides high-level visualization tools for service integration in the ISE environment.
· ESB provides a lightweight, configurable, and highly distributed service container environment.