ESB Overview 1: Defining an ESB

The theme is: It takes five years to activate the full potential of SOA. However, there is a simple assertion in the interview that using the Enterprise service Bus (Enterprise service bus,esb) is the third step in 4 steps to achieve the full potential of the ESB. The steps in the Don Rippert model are as follows:

Use XML to use the application interface in a more standard way.

Capture some business processes and transform them into Web services.

Introduce and fully use the Enterprise service bus.

Generates the business Process Execution language (Business process Execution language,bpel), which can be completed by the Business Process modeling tool. BPEL can change the behavior of an application without modifying the software.

In an interview, Mr. Rippert said that while many organizations had an ESB, it was not fully exploited. He further indicated that most of the companies were still in phase 1. In contrast to the position of the ESB, it is published in a recent discussion of the Yahoo Group, a service-oriented architecture. Anne said:

...... Without the "Basic components" I recommend to start SOA, the ESB will not be listed in my list. In fact, I don't encourage people to start with the ESB. An ESB does not encourage good SOA behavior. An ESB is essentially an integration system, not an SOA system. SOA is used to dismantle the application shafts (application silos), while the integrated systems are to repair these shafts.

Reference, she went on to mention the basic components include:

One or more service platforms (e.g.,. Net,java EE application servers, etc.)

SOA Management Solutions

Registration Form

If the service is to be exposed outside the firewall, then an XML gateway is required

Citing the early posts of the group, she said:

“...... The ESB is particularly suitable for bridging traditional applications, so it is a useful component in the service infrastructure. Many ESB also support reliable messaging, asynchronous messaging, and publish/subscribe exchange patterns. These capabilities are very useful, but they may not be of much use at the initial stage of an SOA project. (Each organization has many projects that do not use these capabilities.) Later in the SOA project, you may also need a orchestration engine, and most of the ESB will provide one. Even so, an ESB is definitely not the starting point for an organization to start an SOA. All these abilities you don't need at first. Therefore, the ESB should be purchased at a later stage. ”

This seems to be in line with Mr. Rippert's view that although many organizations have an ESB, it is not fully exploited. Ms. Manes's comments also help define the scope of the ESB, which identifies a set of appropriate capabilities by hinting at the attributes that many ESB supports.

Based on this, the ESB has the following characteristics:

It is a service-oriented architecture implementation.

It is usually independent of the operating system and programming language; it should work between Java and. NET applications.

It uses XML (extensible Identity language) as the standard communication language.

It supports Web service standards.

It supports message delivery (synchronous, asynchronous, point-to-point, publish-subscribe).

It contains standards-based adapters, such as J2C/JCA, for integrating legacy systems.

It includes support for service preparation (orchestration) and choreography (choreography).

It contains intelligent, content-based routing services (itenerary routing).

It contains a standard security model for the authentication, authorization, and auditing of the ESB.

It contains transformation Services (usually using XSLT), transforms formats between sending applications and receiving applications, and simplifies conversion of data formats and values.

It contains validation based on schema (schema) for sending and receiving messages.

It can uniformly apply business rules, enrich messages from other sources, split and combine multiple messages, and handle exceptions.

It can conditionally route, or message conversions based on an unmanaged policy, that is, no centralized rule engine is required.

It monitors the message response thresholds for different SLAs (service level contracts) and other features defined in the SLA.

It (often) simplifies the "service category" and responds appropriately to higher or lower priority users.

It supports queues, which are used to save messages when the application is temporarily unavailable.

It consists of a selective deployment application adapter in a (geographic) distributed environment.

Wikipedia's definition allows for "precisely defined variants of the ESB".

Both Ms. Manes and Mr. Rippert seem to agree that the ESB is useful and represents a collection of features that are used later in the project to deploy SOA. Wikipedia's definition can serve as a starting point for discussion on how to define this useful technique.

In the ensuing discussion, focus on the definition of the ESB rather than the views of the industry experts cited in this article.