ESB Overview 2:esb Use Cases

We started our discussion on the basis of Wikipedia (ESB).

It seems that one of the common understandings is that an ESB is a separate category of products that are distinct from the preparation (orchestration) and business process management (Business processes Management). In addition, there is a lot of controversy about whether the ESB is a product or a model.

In the second part of this series, Infoq investigates the purpose of using the ESB-what are the use cases and requirements for the ESB?

The discussion in the Sonic Company's opening paper suggests that sonic software companies may in fact be trying to standardize UML-based pattern sets, essentially defining the ESB's Reference Architecture.

(The Enterprise Architect of BEA System Policy consulting service, Toronto in Canada) provides the following examples of usage:

Consumers use HTTP/S based certification and producers use Ws-security.

Consumers use Http/rss, and producers use WebSphere MQ or JMS.

Consumers use Http/rest and URIs, and producers use SOAP/WSDL.

The consumer has a set of certificates, and the producer has another group (key chain mapping).

One end uses the FTP site as the service interface, while the other end file is split into a JMS message.

Before routing to the destination, the message needs to be enriched so that the callout can be executed to collect additional information.

The producer requires an independent load balancing and/or failover of the protocol.

Messages need to be stored and forwarded to improve reliability on unreliable services.

At the same time, as a complement to these themes, WSO2 (co-founder and VP of Technology) adds:

Thus, the ESB is the communication infrastructure that implements arbitration (mediation). What kind of topology should an ESB have? I think it should be flexible: You can build an ESB as a single, large proxy for the middle tier, and a lot of smart terminals. Of course, the topology can affect manageability, but it will work well as long as there is a central registry/warehouse that configures the ESB. The key point is that the ESB should be driven by policy rather than writing code.

Anne Thomas manes of Burton Group also 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. ”

The above emphasis is on using the ESB as a means of bridging the traditional application. Middle: Investigate a group of respondents, and let them use the criteria "from strong consent to strong opposition" to score a set of representations about ESB technology. The first 4 expressions strongly agreed by the respondents were:

The ESB must provide adapters for enterprise data sources (SAP, Peoplesoft, Oracle, SQL Server).

The ESB must support at least the underlying business process management.

An ESB implementation needs to support open standards (JMS, Web Services).

The ESB must be integrated smoothly with existing enterprise application integration (EAI) and message-oriented products.

This implies that traditional data sources, such as ERP and EAI systems, are important interfaces for the ESB, and that they should expose those application tiers as standards-based messages. The interesting finding is that end users seem to agree that "at least basic" business process management is what the ESB "must support".

On the final comment, Steve Jones (from Capgemini) hinted that the ESB problem was in fact 3 unrelated issues: integration, build, and business.

...... The first challenge is to leverage existing asset discovery capabilities (integration), the second is to build new applications (build), and finally to manage interactions between new applications (business). I'll talk about that later in.

The integration product has many very different requirements, and the driving force comes from people wanting to interact in a more standard-oriented space, and I'm not quite sure why it makes sense to confuse these two areas. Similarly, the construction of new applications (using processes or object-oriented languages) requires different techniques and methods.

The integration bus is measured by its capabilities, while the business service bus is based on simplicity and flexibility in application development solutions. And no matter what the reasonable size of the business will not have a permanent solution.

The second part of the ESB review is expected to help define the usage cases that users require, especially when they need an ESB. The consensus is that business process tools are different from the ESB, and that the ESB contains completely opposite interests from end users, which implies the possibility of merging different kinds of products into one.

To learn more about this discussion, please focus on the usage cases that are appropriate for the ESB.