企业集成模式：构建分布式系统

需积分: 50 141 浏览量更新于2024-07-26 收藏 12.65MB PDF 举报

"Enterprise Integration Patterns" 这本书探讨了企业集成中的消息传递技术，它不专注于特定的技术或产品，而是面向使用各种消息产品和技术的开发者和集成者，如IBM的WebSphere MQ、Microsoft的BizTalk、TIBCO、WebMethods等中间件，Java Message Service (JMS)，Microsoft的Message Queuing (MSMQ)以及新兴的Web服务标准等。在书中，作者阐述了以下主要知识点： 1. **消息中间件（Message-Oriented Middleware, MOM）**：MOM是企业集成中的一种关键技术，它提供了一种平台无关的方式，允许不同系统间进行异步通信。IBM的WebSphere MQ和Microsoft的BizTalk等都是MOM的实例。 2. **Java Message Service (JMS)**：JMS是Java环境中用于消息传递的标准接口，它被集成到J2EE应用服务器中，也可以作为独立产品使用。JMS允许应用程序创建、发送、接收和读取消息。 3. **Microsoft’s Message Queuing (MSMQ)**：MSMQ提供了一种可靠的消息传递机制，可以通过多种API访问，包括.NET框架中的System.Messaging库。 4. **Web服务标准**：书中的内容涵盖了支持异步Web服务的新兴标准，如WS-ReliableMessaging，以及相关的API，如Sun的Java API for XML Messaging (JAXM)和Microsoft的Web Services Extensions (WSE)。书的组织结构包括： - **前言和序言**：解释了书的写作目的和读者群体。 - **介绍**：定义了消息传递的概念，以及消息系统的作用和使用消息的原因。 - **挑战**：讨论了异步消息传递面临的困难，并提出了异步思维的重要性。 - **模式形式**和**图示符号**：解释了书中使用的模式表示方法和图表表示规则。 - **例子和插曲**：通过实例深入解析概念。 - **各章节**：深入探讨了集成问题、集成风格、应用集成的标准和选项，如文件传输、共享数据库、远程过程调用和消息传递等。本书旨在帮助读者理解如何使用模式解决集成问题，强调了松耦合的重要性，并介绍了各种集成风格，以帮助读者选择合适的集成策略。书中的案例研究，如Widget-Gadget Corp，展示了如何构建一个松散耦合的集成解决方案。这本书是针对那些需要理解和实施企业级系统集成的IT专业人士的宝贵资源，无论他们是在使用传统的消息中间件还是新兴的Web服务技术。通过学习这些模式和最佳实践，读者可以更有效地设计和实现跨系统的通信方案。

• Remote Communication. Messaging enables separate applications to communicate and

transfer data. Two objects that reside in the same process can simply share the same data

in memory. Sending data to another computer is a lot more complicated and requires

data to be copied from one computer to another. This means that objects have to

"serializable", i.e. they can be converted into a simple byte stream that can be sent across

the network. If remote communication is not needed, messaging is not needed; a simpler

solution such as concurrent collections or shared memory is sufficient.

• Platform/Language Integration.When connecting multiple computer systems via remote

communication, these systems likely use different languages, technologies and platforms,

perhaps because they were developed over time by independent teams. Integrating such

divergent applications can require a demilitarized zone of middleware to negotiate

between the applications, often using the lowest common denominator—such as flat data

files with obscure formats. In these circumstances, a messaging system can be a universal

translator between the applications that works with each one’s language and platform on

its own terms, yet allows them to all communicate through a common messaging

paradigm. This universal connectivity is the heart of the Message Bus

pattern.

• Asynchronous Communication. Messaging enables a send and forget approach to

communication. The sender does not have to wait for the receiver to receive and process

the message; it does not even have to wait for the messaging system to deliver the

message. The sender only needs to wait for the message to be sent, e.g. for the message to

successfully be stored in the channel by the messaging system. Once the message is

stored, the sender is then free to perform other work while the message is transmitted in

the background. The receiver may want to send an acknowledgement or result back to

the sender, which requires another message, whose delivery will need to be detected by a

callback mechanism on the sender.

• Variable Timing. With synchronous communication, the caller must wait for the receiver to

finish processing the call before the caller can receive the result and continue. In this way,

the caller can only make calls as fast as the receiver can perform them. On the other hand,

asynchronous communication allows the sender to batch requests to the receiver at its

own pace, and for the receiver to consume the requests at its own different pace. This

allows both applications to run at maximum throughput and not waste time waiting on

each other (at least until the receiver runs out of messages to process).

• Throttling. A problem with remote procedure calls is that too many of them on a single

receiver at the same time can overload the receiver. This can cause performance

degradation and even cause the receiver to crash. Asynchronous communication enables

the receiver to control the rate at which it consumes requests, so as not to become

overloaded by too many simultaneous requests. The adverse effect on callers caused by

this throttling is minimized because the communication is asynchronous, so the callers

are not blocked waiting on the receiver.

• Reliable Communication. Messaging provides reliable delivery that a remote procedure call

(RPC) cannot. The reason messaging is more reliable than RPC is that messaging uses a

store and forward approach to transmitting messages. The data is packaged as messages,

which are atomic, independent units. When the sender sends a message, the messaging

system stores the message. It then delivers the message by forwarding it to the receiver’s

computer, where it is stored again. Storing the message on the sender’s computer and the

receiver’s computer is assumed to be reliable. (To make it even more reliable, the

messages can be stored to disk instead of memory; see Guaranteed Delivery

.) What is

unreliable is forwarding (moving) the message from the sender’s computer to the

receiver’s computer, because the receiver or the network may not be running properly.

The messaging system overcomes this by resending the message until it succeeds. This

automatic retry enables the messaging system to overcome problems with the network

such that the sender and receiver don’t have to worry about these details.

• Disconnected Operation. Some applications are specifically designed to run disconnected

from the network, yet to synchronize with servers when a network connection is

available. Such applications are deployed on platforms like laptop computers, PDA’s, and

automobile dashboards. Messaging is ideal for enabling these applications to

synchronize—data to be synchronized can be queued as it is created, waiting until the

application reconnects to the network.

• Mediation. The messaging system acts as a mediator—as in the Mediator pattern

[GoF

]—between all of the programs that can send and receive messages. An application

can use it as a directory of other applications or services available to integrate with. If an

application becomes disconnected from the others, it need only reconnect to the

messaging system, not to all of the other messaging applications. The messaging system

can be used to provide a high number of distributed connections to a shared resource,

such as a database. The messaging system can employ redundant resources to provide

high-availability, balance load, reroute around failed network connections, and tune

performance and quality of service.

• Thread Management. Asynchronous communication means that one application does not

have to block while waiting for another application to perform a task, unless it wants to.

Rather than blocking to wait for a reply, the caller can use a callback that will alert the

caller when the reply arrives. (See the Request-Reply

pattern.) A large number of blocked

threads, or threads blocked for a long time, can be problematic. Too many blocked

threads may leave the application with too few available threads to perform real work. If

an application with some dynamic number of blocked threads crashes, when the

application restarts and recovers its former state, re-establishing those threads will be

difficult. With callbacks, the only threads that block are a small, known number of

listeners waiting for replies. This leaves most threads available for other work and defines

a known number of listener threads that can easily be re-established after a crash.

So there are a number of different reasons an application or enterprise may benefit from

messaging. Some of these are technical details that application developers relate most readily to,

whereas others are strategic decisions that resonate best with enterprise architects. Which of these

reasons is most important depends on the current requirements of your particular applications.

They’re all good reasons to use messaging, so take advantage of whichever reasons provide the

most benefit to you.

Challenges of Asynchronous Messaging

Asynchronous messaging is not the panacea of integration. It resolves many of the challenges of

integrating disparate systems in an elegant way but it also introduces new challenges. Some of

these challenges are inherent in the asynchronous model while other challenges vary with the

specific implementation of a messaging system.

• Complex programming model. Asynchronous messaging requires developers to work with

an event-driven programming model. Application logic can no longer be coded in a

single method that invokes other methods, but the logic is not split up into a number of

event handlers that respond to incoming messages. Such a system is more complex and

harder to develop and debug. For example, the equivalent of a simple method call can

require a request message and a request channel, a reply message and a reply channel, a

correlation identifier and an invalid message queue (as described in Request-Reply

• Sequence issues. Message channels guarantee message delivery, but they do not guarantee

when the message will be delivered. This can cause messages that are sent in sequence to

get out of sequence. In situations where messages depend on each other special care has

to be taken to re-establish the message sequence.

• Synchronous scenarios. Not all applications can operate in a send and forget mode. If a user

is looking for airline tickets, he or she is going to want to see the ticket price right away,

not after some undetermined time. Therefore, many messaging systems need to bridge

the gap between synchronous and asynchronous solutions. (See the Request-Reply

pattern.)

• Performance. Messaging systems do add some overhead to communication. It takes effort

to make data into a message and send it, and to receive a message and process it. If you

have to transport a huge chunk of data, dividing it into a gazillion small pieces may not

be a smart idea. For example, if an integration solution needs to synchronize information

between two exiting systems, the first step is usually to replicate all relevant information

from one system to the other. For such a bulk data replication step, ETL (extract,

transform, and load) tools are much more efficient than messaging. Messaging is best

suited to keeping the systems in sync after the initial data replication.

• Limited platform support. Many proprietary messaging systems are not available on all

platforms. Often times it is easier to FTP a file to another platform than accessing it via a

messaging system.

• Vendor lock-in. Many messaging system implementations rely on proprietary protocols.

Even common messaging specifications such as JMS do not control the physical

implementation of the solution. As a result, different messaging systems usually do not

connect to one another. This can leave you with a whole new integration challenge:

integrating multiple integration solutions! (See the Messaging Bridge

pattern.)

So asynchronous messaging does not solve all problems, and can even create some new ones.

Keep these consequences in mind when deciding which problems to solve using messaging.

Thinking Asynchronously

Messaging is an asynchronous technology, which enables delivery to be retried until it succeeds.

In contrast, most applications use synchronous function calls; for example: a procedure calling a

sub-procedure, one method calling another method, or one procedure invoking another remotely

through a remote procedure call (RPC) (such as CORBA and DCOM). Synchronous calls imply

that the calling process is halted while the sub-process is executing a function. Even in an RPC

scenario, where the called sub-procedure executes in a different process, the caller blocks until

the sub-procedure returns control (and the results) to the caller. When using asynchronous

messaging, the caller uses a send and forget approach that allows it to continue to execute after it

sends the message. As a result, the calling procedure continues to run while the sub-procedure is

being invoked.

Synchronous and Asynchronous Call Semantics

Asynchronous communication has a number of implications. First, we no longer have a single

thread of execution. Multiple threads enable sub-procedures to run concurrently, which can

greatly improve performance and help ensure that some sub-processes are making progress even

while other sub-processes may be waiting for external results. However, concurrent threads can

also make debugging much more difficult. Second, results (if any) arrive via a callback. This

enables the caller to perform other tasks and be notified when the result is available, which can

improve performance. However, the caller has to be able to process the result even while it is in

the middle of other tasks, and it has to be able to use the result to remember the context in which

the call was made. Third, asynchronous sub-processes can execute in any order. Again, this

enables one sub-procedure to make progress even while another cannot. But it also means that

the subprocesses must be able to run independently in any order, and the caller must be able to

determine which result came from which sub-process and combine the results together. So

asynchronous communication has several advantages but requires rethinking how a procedure

uses its sub-procedures.

Distributed Applications vs. Integration

This book is about enterprise integration—how to integrate independent applications so that they

can work together. An enterprise application often incorporates an n-tier architecture (a more

sophisticated version of a client/server architecture) enabling it to be distributed across several

computers. Even though this results in processes on different machines communicating with each

other, this is application distribution, not application integration.

Why is an n-tier architecture considered application distribution and not application integration?

First, the communicating parts are tightly coupled—they dependent directly on each other, so

that one tier cannot function without the others. Second, communication between tiers tends to

be synchronous. Third, an application (n-tier or atomic) tends to have human users that will only

accept rapid system response.

In contrast, integrated applications are independent applications that can each run by itself, but

coordinate with each other in a loosely coupled way. This enables each application to focus on

one comprehensive set of functionality and yet delegate to other applications for related

functionality. Integrated applications communicating asynchronously don’t have to wait for a

response; they can proceed without a response or perform other tasks concurrently until the

response is available. Integrated applications tend to have a broad time constraint, such that they

can work on other tasks until a result becomes available, and therefore are more patient than

most human users waiting real-time for a result.

Commercial Messaging Systems

The apparent benefits of integrating systems using an asynchronous messaging solution have

opened up a significant market for software vendors creating messaging middleware and

associated tools. We can roughly group the messaging vendors’ products into the following four

categories:

1. Operating Systems. Messaging has become such a common need that vendors have started

to integrate the necessary software infrastructure into the operating system or database

platform. For example, the Microsoft Windows 2000 and Windows XP operating systems

include the Microsoft Message Queuing (MSMQ) service software. This service is

accessible through a number of API’s, including COM components and the

System.Messaging namespace, part of the Microsoft .NET platform. Similarly, Oracle

offers Oracle AQ as part of its database platform.

2. Application Servers. Sun Microsystems first incorporated the Java Messaging Service (JMS)

into version 1.2 of the J2EE specification. Since then, virtually all J2EE application servers

(such as IBM WebSphere, BEA WebLogic, etc.) provide an implementation for this

specification. Also, Sun delivers a JMS reference implementation with the J2EE JDK.

3. EAI Suites. Products from these vendors offer proprietary—but functionally rich—suites

that encompass messaging, business process automation, workflow, portals, and other

functions. Key players in this marketplace are IBM WebSphere MQ, Microsoft BizTalk,

TIBCO, WebMethods, SeeBeyond, Vitria, CrossWorlds, and others. Many of these

products include JMS as one of the many client API’s they support, while other

vendors—such as SonicSoftware and Fiorano—focus primarily on implementing

JMS-compliant messaging infrastructures.

剩余573页未读，继续阅读

kunshou625

粉丝: 0
资源: 1

企业集成模式：构建分布式系统

入门指南：Java轻量级ESB框架MuleESB详解

Spring Integration：企业应用集成解决方案深度解析

掌握Java Spring Integration与企业集成模式EIP

Enterprise Integration Patterns.chm

Apache Camel_ Enterprise Integration Patterns.pdf

Addison.Wesley.Enterprise.Integration.Patterns

Salesforce doc: Integration Patterns and Practices

Enterprise.Integration.Patterns.Designing.Building.And.Deploying.Messaging.Solutions

Just Spring Integration

belajar-spring-integration:使用Spring Integration的示例

最新资源