The detour I took on the ESB.

Over the years, people have been talking about SOA, and people with service-oriented development experience are certainly not unfamiliar with the Enterprise service bus ESB. But the understanding of the ESB is not the same, it may be strange, I found a lot of information, and did not find a universally accepted definition. Because of the different understanding of the ESB, the use of the ESB is different. I think it's a good idea to understand the role of the ESB in SOA so that the ESB is really doing its job.

Recently in the implementation of an ESB project, relying on a few people to study, we have no previous experience in this area, is stones it, go a lot of detours, for your reference.

1, once and for all reality.

At first, our vision was: can we design a once and for all ESB intermediate platform, in the future no matter what kind of service can be easily connected to the ESB, when the service is enough, we can provide a universal platform.

The idea is exciting, and the project we're doing is actually leaning towards that goal, but now it seems naïve. First, when different clients access the same service in different ways, this time, the arbitration logic in the service is very specific, and we have to consider not only the differences of the protocols, but also the differences in the message formats. On the other hand, the specific business is often complex and does not have a completely generic service for each system, as it is impossible to have two identical people. If the ESB is to be concerned with business-level matters, I feel that it is a one-sided understanding of the ESB, that complex business should be implemented in a specific business system, and that the ESB solves the technical aspects of the work.

If we define a standard set of data interfaces, using a unified protocol, all the consumers and producers of ESB services follow that standard.

This must be done to simplify the development of the ESB, but if the protocol standards and data standards of all the perimeter applications are required to be unified, then what do we want the ESB to do.

The ability to lose the most powerful connectivity features of the ESB itself, formally due to the difference between the applications that need to be connected, has evolved the components of the ESB

2, in a system all business operations are using the ESB, using the message mechanism, that is, the lower layer of the system to provide services.

This is the way to maximize the flexibility and scalability of the system, which means that we can orchestrate and add services to meet the needs of the system changes.

Now it seems that the idea is too naïve, first, originally very simple business, we need to edit a lot of code, configure a lot of XML to complete, and eventually lead to the system is very bloated. Second, through the ESB, the data has to be processed and passed through the network ... Get processed back, if the real-time is not high, the amount of data is small, can withstand, on the contrary, will be a disaster. Thirdly, implementing an ESB within a system is the original intention of the ESB. Is this the responsibility of the ESB? Obviously, an ESB is not a component that exists in a system.

3. Implementing business processes with an ESB

We see the ESB Support Service Mix (servicecomposition) pattern, which we think can be used to implement business processes. As a result, ESB products evolve into BPM products.

In fact, there is a fundamental difference between the two. One: The ESB is a technology-biased component, such as the "User Information modification" service and the "log" service to assemble, the result is "User Information modification" service, just inserted in the middle of the mediation flow a new additional function, namely "Log" service. The meaning of service orchestration in BPM is focused on the concept of business turnover. For example, "Project approval process", the implementation of the process may require from a number of related systems in the participation of services, they may be "project Application", followed by "first-level functional experience approval", followed by "department manager approval", "financial approval" and so on. These services flow together to form a complete business process. Second: The service mix on the ESB is stateless, and the ESB runtime establishes an instance for each request to execute its quorum logic, with no timing relationship between the request and the request, which is irrelevant and independent. In contrast, service orchestration on BPM is not the same, and unfinished business process instances will always survive in the BPM runtime, with a lifetime of one day, one week, or even 1 months or more, and there may be some correlation between requests and requests, such as the approval process for a project (the same project ID). First-level functional managers, department managers, and finance requests for processes are made for the same runtime instance.

You should recognize the difference between a technical service mix and service orchestration.

4. Make data transmission bus with ESB

We only use the ESB to move data directly from one system to another. This means that only the connectivity features provided by the ESB are used, and no other functions such as message parsing, conversion, routing, etc. are used.

ESB as an enterprise-class service Unicom, management platform, the need to penetrate the ESB service should be the most likely to reuse in the enterprise, the most valuable services, applications to such services should be very frequent, so the need for ESB support at the same time the business can be very onerous. Therefore, the ESB product is designed to implement a stateless, high-throughput service bus that provides transparent, standard, open access to critical business services within the enterprise. It is not a good deal to transfer large amounts of data just as a data transmission channel.

The above is only one-sided thinking, but also refer to some of the views of Daniel, I hope that when the implementation of the ESB, we can really understand what the ESB is capable of, where to put the most appropriate.

Reference documents

Http://soft.zdnet.com.cn/software_zone/esb-soa-middleware.shtml

Http://www.cnblogs.com/skyme/archive/2012/08/06/2623414.html

Http://www.infoq.com/cn/articles/esb-enterprises-case

Http://www.infoq.com/cn/articles/mgy-esb-implementation-suggestion

Wait a minute