目
錄

第1章    概述    1

1.1    讀者對象    1

1.2    定義    1

第2章    面向服務的體系架構簡介    2

2.1    SOA的業務驅動力    2

2.2    什麼是面向服務的體系架構    4

2.3    面向服務的體系結構所帶來的好處    5

2.4    應用系統的的整合與ESB    6

2.4.1    企業應用整合與ESB    7

2.4.2    ESB的要素    9

2.4.3    ESB的功能    10

2.4.4    ESB的實現模式    12

2.5    應用系統整合的國內外現狀    14

2.5.1    項目案例    16

2.5.1.1    某國內著名通信公司方案概述    16

客戶需求：    16

建設方案：    16

產品選擇：    17

2.5.2    某較大型商業銀行ESB項目簡介    17

第3章    關鍵技術分析    19

3.1    與現有系統的集成    19

3.1.1    與基於J2EE系統的集成    19

3.1.2    與基於MQ系統的集成    20

3.1.3    與基於CICS系統的集成    21

3.1.4    與基於郵件系統的集成    22

3.1.5    與基於C/S架夠系統的集成    22

3.2    平台擴展性與高可用性的實現    23

3.3    平台安全性的考量    24

附錄A：產品技術文檔和白皮書    26

A.1 WebSphere MQ 產品簡介    26

什麼是WebSphere MQ?    26

WebSphere MQ重要特點：    28

其它特點…    30

為什麼要用WebSphere MQ產品？    31

A.2 WebSphere Message Broker 產品簡介(Gu)    33

WebSphere Messages Broker 亮點和概括    34

WebSphere Messages Broker 產品商業應用範圍和功能    34

實時與您無處不及的企業共享信息    34

可靠、一致地管理業務事件    35

利用定製的信息流優化響應    35

集成無界限    36

圖形化的開發環境加快部署速度    37

快速啟動    37

利用市場領先的業務集成解決方案滿足要求    37

MESSAGE BROKER 是一個戰略性的開放框架    38

應用程序格式轉換和智能路由功能    38

強大的數據處理功能    39

對各種應用系統的接口功能    39

WebSphere Messages Broker 產品特點    39

IBM WebSphere Message Broker解決方案的優勢    41

產品構架優勢    41

網狀結構到星型結構的改變，大大簡化MQ的配置和管理    41

不同格式的數據轉換    42

WMB全面支持XML    42

各種“Processor Node”組成的Message Flow    42

與Database緊密集成    43

功能強大的發佈預訂系統    43

 

第1章    概述

1.1    讀者對象

預期閱讀人員包括負責科技管理的各級領導、負責科技管理的業務人員、ESB項目管理人員、ESB平台實施人員、ESB平台運維人員和其他需要閱讀本報告的項目經理、IT架構師等。

1.2    定義

SOA—Service Oriented Architecture                    面向服務的架構

ESB—Enerprise Service Bus                         企業服務總線

WMB—WebSphere Message Broker                    IBM 高級ESB產品

第2章    面向服務的體系架構簡介

目前，大多數企業都有各種各樣的系統、應用程序以及不同時期和技術的體系結構。同時，網絡的發展，使得跨機構和組織的應用系統越來越普遍。另一方面，政策和業務方面的壓力要求IT系統能夠方便靈活地適應不斷的變化。如何集成來自多個廠商跨不同平台的產品和應用系統，以滿足業務上靈活多變的要求，一直是企業IT部門的主要挑戰。面向服務的體系結構(Service Oriented Architecture, SOA)為解決這一問題提供了良好的途徑。

 

2.1    SOA的業務驅動力

雖然 IT 經理一直面臨著削減成本和最大限度地利用現有技術的難題，但是與此同時，他們還必須不斷地努力，以期更好地服務客戶，更快地響應企業戰略重點，從而贏得更大的競爭力。

在所有這些壓力之下，有兩個基本的主題：異構和改變。現在，大多數企業都有各種各樣的系統、應用程序以及不同時期和技術的體系結構。集成來自多個廠商跨不同平台的產品簡直就像一場噩夢。但是我們也不能單單使用一家廠商的產品，因為改變應用程序套件和支持基礎設施是如此之難。

在當今 IT 經理面臨的問題之中，改變是第二個主題。全球化和電子商務加快了改變的步伐。全球化帶來了激烈的競爭，產品周期縮短了，每個公司都想贏得超過競爭對手的優勢。在競爭產品和可以從 Internet 上獲得的大量產品信息的推動下，客戶要求更快速地進行改變。因而，在改進產品和服務方面展開的競爭進一步加劇了。

為了滿足客戶提出的越來越多的新要求，技術方面的改進也在不斷地加快。企業必須快速地適應這種改變，否則就難以生存，更別提在這個動蕩不安競爭激烈的環境中取得成功了，而 IT 基礎設施必須支持企業提高適應能力。

因此，企業組織正在從上世紀八十年代或更早的時期的相互隔離的垂直業務部門，到上世紀八十年代和九十年代關注業務流程的水平結構，向新的生態系統業務範例發展。重點是擴展供應鏈，支持客戶和合作夥伴訪問業務服務。下圖展示了企業的這種發展。

我如何使我的 IT 環境更靈活且更快地響應不斷改變的業務需求呢？
我們如何使這些異構系統和應用程序儘可能無縫地進行通信呢？我們如何達到企業目標而不使企業走向破產的深淵呢？

IT 響應者/支持者是隨着企業的這種發展而並行發展的，如下圖所示。現在，許多 IT 經理和專業人員都同樣相信，我們真的快找到了一種滿意的答案——面向服務的體系結構。

為了減少異構性、互操作性和不斷改變的要求的問題，這樣的體系結構應該提供平台來構建具有下列特徵的應用程序服務：

    鬆散耦合

    位置透明

    協議獨立

基於這樣的面向服務的體系結構，服務使用者甚至不必關心與之通信的特定服務，因為底層基礎設施或服務“總線“將代表使用者做出適當的選擇。基礎設施對請求者隱藏了儘可能多的技術。特別地，來自不同實現技術（如 J2EE 或 .NET）的技術規範不應該影響 SOA 用戶。如果已經存在一個服務實現，我

以下文章點擊率最高