Enterprise Services Bus ---5&6

1. Itinerary-Based Routing: Highly Distributed SOA

The key importance of the ESB approach to SOA is that the service definition is separated from the mechanism for locating and invoking services.

A message itinerary contains metadata that describes how to route the message, including a list of forwarding addresses described as abstract endpoints or as rules to evaluate along the way.

 

有序的黑板模式（仓库风格)

2. Content-Based Routing (CBR)

3.Service Reusability

One primary value of an SOA is the reusability of services. In an ESB, services are meant to be reusable. An ESB service is an instance of a service type. Reusability can be accomplished by instantiating a particular type of service and applying variable data and conditions through parameterization and configuration. Examples of variable conditions that can affect the behavior of a service are the use of different XSLT stylesheets, different rules for CBR, and different endpoint locations.

4.Specialized Services of the ESB

Routing Patterns Using Itineraries and Services

Multi-itinerary splitter pattern:

Multi-itinerary CBR pattern:

5.Sophisticated Process Flow Using an Orchestration Service (BPEL4WS)

Conclusion:

In this chapter we have examined three different ways of managing the steps in a business process: itinerary-based routing, sophisticated process orchestration using an orchestration service that is layered on top of the ESB, and the XML processing pipeline in an XML persistence service, also a layered service on top of the ESB.

 

1.The ESB MOM Core

At the core of the ESB communications layer is a MOM infrastructure that is capable of supporting a variety of industry-standard access mechanisms and protocols.

an ESB needs to be capable of connecting and transporting messages across multiple transports and protocols such as JMS, proprietary MOM, HTTP/S, SOAP, WS-Rel*, FTP, and SMTP (email).

Store-and-forward Model!

An ESB relies on a MOM, which can be JMS-based, to carry XML-formatted messages over message channels. Some people view JMS simply as a common API for connecting into a MOM. It is certainly that, but in addition to being an API, JMS also provides a set of rules for defining the semantic behavior of message delivery. Such behavior includes asynchrony, exactly-once delivery, and transactional recovery due to failure of the messaging provider or of the sending and receiving applications. In addition, JMS provides a clear set of definitions for structuring message content and headers.

2. A Generic Message Invocation Framework

Here are brief descriptions of these protocol stacks:

SOAP-over-HTTP/S

The standard means of carrying a SOAP message over an HTTP or HTTP/S transport.

WS-Rel*

Using WS-Reliability or WS-ReliableMessaging as a transport. (Although not shown here, WS-Security, WS-SecureConversation, etc., can be used to secure SOAP over HTTP messages.)

MOM/JMS

Using a MOM channel, JMS-based or otherwise, to transport messages.

SOAP-over-JMS-over-HTTP/S

Using JMS to carry SOAP messages, combined with tunneling of a JMS connection through a firewall using the HTTP or HTTP/S protocol. This can be done between a JMS client and a message server, or between two JMS servers. This usually involves mutual authentication using x509 digital certificates.

JMS-over-SSL

The act of tunneling a JMS connection through a firewall using the SSL protocol. This can be done between a JMS client and a message server, or between two JMS servers. This usually involves mutual authentication using x509 digital certificates.

SOAP is not a prerequisite for an ESB, although it is fairly common for ESB channels to carry SOAP messages. In some cases, the ESB may even strip off the SOAP envelope and just use the remaining XML payload information as the message that gets passed between services.

Quality of Service (QoS) levels can vary depending on which protocol is chosen to carry a message. This is another reason why there is a unified MOM at the core of the ESB. In fact, the enumeration of benefits to having a MOM at the core of the ESB is almost the antithesis of the disadvantages of the accidental architecture:

• Consistent QoS levels

• Consistent management

• Metrics and monitoring

• Consistent troubleshooting techniques

• Consistent scalability methodology

• Consistent performance tuning techniques

• Consistent security and ACL model

• Publish-and-subscribe broadcast of information

• Message persistence and reliability of message delivery

2.1 Protocol Bridging

Bridging is one way to attach a legacy protocol such as FTP or SMTP (email) into an ESB. As illustrated in Figure 8-5, an FTP or SMTP bridge is implemented as a specialized messaging client, which converts data from one protocol to and from the MOM channel.

 

2.2 MOM Bridging

An ESB also provides a bridge across MOM implementations. Many corporations, especially larger ones that have been through a few acquisitions, have multiple installations of MOM from different vendors across their organization.

 

异步服务提供了原地失败的可能性。同时是否可以将错误本身在ESB上重新投递？服务虚拟化交付，自动重定向。