支持服務 ___________________________
Various Artist_______http://www.pcgames.com.cn/fight/warcraft/zblx/0604/783821.html

除運行時基礎設施和 SOA 核心之外，WebSphere Process Server 還提供了多種服務組件。支持服務是所有集成解決方案中都需要的組件，其中包括數據轉換和同步服務。

• 接口映射：現有組件的接口可以在語義上匹配，但是在語法上不匹配（例如，updateCustomer 和 updateCustomerInDB2）。對于已存在的組件和需要訪問的服務更為如此。接口映射通過轉換這些調用使您能夠調用這些組件。此外，可以使用業務對象轉換服務調用的實際業務對象參數。
• 業務對象映射：可以使用業務對象映射將某種類型的業務對象轉換成另一種類型的業務對象。可以通過多種方式使用這些映射，例如，在接口映射中將某種類型的參數數據轉換成另一種類型。
• 關系：您可能需要在業務集成場景或者不同的后端系統（如 ERP 系統和 CRM 系統）中訪問相同的數據（如客戶記錄）。保持業務對象同步的一個常見的問題就是不同的后端系統使用不同的關鍵字表示同一對象。可以使用 WebSphere Process Server 中的關系服務建立這些完全不同的后端系統中的對象之間的關系實例。通常在將一種業務對象格式轉換成另一種格式時，從業務對象映射中訪問這些關系。
• 選擇器：可以使用選擇器組件動態選擇和調用共享同一接口的不同服務。例如，客戶支持流程在假日期間使用的人工任務實現可以與正常工作日中的不同。WebSphere Process Server 提供了一個基于 Web 的接口，以啟用對選擇標準和目標服務的動態更新，這意味著，如果啟用對集成解決方案的動態更改，該選擇器組件還可以調用隨后部署的模塊。
• Java：可以使用 Java 組件調用 Java 代碼。

服務組件

WebSphere Process Server 提供了四個服務組件：

• 業務流程：WebSphere Process Server 中的業務流程組件實現了與 Web 服務業務流程執行語言（Web Services Business Process Execution Language，WS-BPEL）兼容的流程引擎。可以開發和部署業務流程，它支持長時間運行和短時間運行的業務流程以及可伸縮的基礎設施中的補償模型。您可以在 WebSphere Integration Developer 中創建 WS-BPEL 模型，也可以從在 WebSphere Business Modeler 中創建的業務模型導入。
• 人工任務：人工任務是 WebSphere Process Server 中的獨立組件，可以用來向員工分配任務或調用任何其他服務。此外，人工任務管理器還支持臨時創建任務和跟蹤任務。可以使用現有的 LDAP 目錄（以及操作系統資源庫和 WebSphere 用戶注冊表）訪問員工信息。WebSphere Process Server 還支持人工任務的多級升級，其中包括電子郵件通知和優先級老化。WebSphere Process Server 包括可擴展的 Web 客戶機，可以用于處理任務或者流程。該 Web 客戶機基于一組可重用的 Java Server Faces (JSF) 組件，這些組件可以用于創建自定義客戶機或者將人工任務功能嵌入其他的 Web 應用程序。
• 業務狀態機：業務狀態機提供了建模業務流程的另一種方式。通過這種方式，可以根據狀態和事件表示公司的業務流程，有時使用這種方式進行建模比采用面向圖形的業務流程模型簡單。訂購流程就是這樣一個例子，您可以在訂單處理過程中的任何時刻修改或者取消訂單，直到實際完成訂單為止。
• 業務規則：業務規則是一種通過外化業務功能實現和執行業務策略的方式。這為響應更快的業務環境啟用了業務流程的動態更改。基于 Eclipse 的桌面工具支持業務規則的創建。在業務需求指示時，業務分析師可以使用 WebSphere Process Server 提供的基于 Web 的運行時工具更新業務規則，而不會影響其他服務。

可以通過 WebSphere Application Server 管理控制臺和配置功能的擴展配置和管理 WebSphere Process Server 的所有功能。這就為管理整個應用程序堆棧提供了一席之地。

可以使用 WebSphere Process Server 做些什么？

事務、安全性、集群和工作負載管理：WebSphere Process Server 解決方案使用 WebSphere Application Server 功能，因而向您提供了一個可伸縮的、可靠的業務集成環境，可以用于事務、安全性、集群和工作負載管理。

完整的 ACID 事務支持：WebSphere Process Server 為業務流程提供了完整的 ACID 事務支持，既包括短時間運行的流程（端對端的一個事務）也包括長時間運行的流程（多個流程）。可以在工具中修改事務邊界來將業務流程中的多個步驟集中到一個事務。此外，它還支持 WS-BPEL 規范中定義的業務流程的靈活補償。

恢復管理器與恢復控制臺：WebSphere Process Server 包括恢復管理器和恢復控制臺。如果在執行業務集成應用程序期間出現故障，則服務器將檢測該故障，并允許您（管理員）在恢復控制臺管理出錯的應用程序。

封裝業務功能：WebSphere Process Server 中的唯一體系結構允許將業務功能封裝到各個模塊，然后單獨進行更新。例如，您可以使用包含用于實際審批的人工任務的審批模塊，隨后使用包含業務規則的另一個審批模塊替換它。這一更改對于該模塊的使用者是完全透明的。此外，封裝的概念確保了數據和接口定義在使用它們的位置封裝。例如，可以隱藏如何在模塊內的后端系統中表示使用者的細節，而模塊本身將具有一般業務對象的通用接口作為數據公開。這一規范的數據表示還啟用了任何給定集成應用程序中的高度重用。

WebSphere Process Server 如何處理現有系統和新的應用程序？

WebSphere Process Server 提供了許多選項，可以用于將公司的現有系統與新的集成應用程序相集成。

WebSphere Application Server 消息資源：WebSphere Process Server 使用 WebSphere Application Server 中的消息資源綁定到現有的 WebSphere MQ 網絡。可以配置 WebSphere Application Server V6 附帶的本機 Java JMS 提供程序，以連接到現有的 WebSphere MQ Queue Manager，這樣您就可以創建 WebSphere MQ 網絡的擴展。

本機 Web 服務互操作性：WebSphere Process Server 包含對 Web 服務的完整支持，其中包括通過 HTTP 對 SOAP 的支持或者通過 JMS 對 SOAP 的支持。WebSphere Process Server 還包括對導入和導出 WebSphere Process Server 組件、JMS 和 Enterprise Java Session Bean 的支持。

WebSphere Adapters：WebSphere Adapters 包括特定于應用程序的適配器（如用于 Siebel、SAP 或者 PeopleSoft 的適配器），以及技術適配器（如用于關系數據庫或者平面文件的適配器）。

WPS V6運行環境建立在WebSphere應用服務器之上，其最基礎的部分是SOA核心機制。它基于Web服務（Web Service）規范，實現并規定了WPS V6中服務組件的交互方式和統一的業務模型，是整個WPS V6運行環境的基礎。

• 服務組件架構（Service Component Architecture，SCA）提供了統一的服務調用模型。
• 業務對象(Business Object，BO)提供了統一的業務數據模型。
• 通用事件基礎設施（Common Event Infrastructure，CEI），以統一的事件格式(Common Base Event，CBE)記錄運行環境中的事件，為WebSphere監測器（WebSphere Monitor）提供數據存儲。

在SOA核心機制之上的是WPS V6的支撐服務，包括：

• SCA接口轉接器（Interface Mediator）提供了SCA接口轉接的功能，它可以把同一SCA模塊內不同SCA組件接合起來，即使它們的接口并不匹配。接口轉接器與業務對象映射服務（Map Service）以及關系服務（Relationship Service）一起，完成接口轉接的功能。
• Selector提供輸入輸出的路由選擇功能，動態決定調用目標，降低客戶和調用目標間的耦合度。

在支撐服務之上的是WPS V6運行環境進行業務處理的主體服務組件，包括

• 業務流程引擎（Business Process Engine，BPE）。
• 人工任務管理器（Human Task Manager，HTM）。
• 業務狀態機（Business State Machine，BSM）。
• 業務規則（Business Rules，BR）。

WPS V6運行環境建立在WebSphere應用服務器之上，其最基礎的部分是SOA核心機制。它基于Web服務（Web Service）規范，實現并規定了WPS V6中服務組件的交互方式和統一的業務模型，是整個WPS V6運行環境的基礎。

• 服務組件架構（Service Component Architecture，SCA）提供了統一的服務調用模型。
• 業務對象(Business Object，BO)提供了統一的業務數據模型。
• 通用事件基礎設施（Common Event Infrastructure，CEI），以統一的事件格式(Common Base Event，CBE)記錄運行環境中的事件，為WebSphere監測器（WebSphere Monitor）提供數據存儲。

在SOA核心機制之上的是WPS V6的支撐服務，包括：

• SCA接口轉接器（Interface Mediator）提供了SCA接口轉接的功能，它可以把同一SCA模塊內不同SCA組件接合起來，即使它們的接口并不匹配。接口轉接器與業務對象映射服務（Map Service）以及關系服務（Relationship Service）一起，完成接口轉接的功能。
• Selector提供輸入輸出的路由選擇功能，動態決定調用目標，降低客戶和調用目標間的耦合度。

在支撐服務之上的是WPS V6運行環境進行業務處理的主體服務組件，包括

• 業務流程引擎（Business Process Engine，BPE）。
• 人工任務管理器（Human Task Manager，HTM）。
• 業務狀態機（Business State Machine，BSM）。
• 業務規則（Business Rules，BR）。

3.1 服務組件架構

SCA（Service Component Architecture） 是一種通用的面向業務服務的組件模型。它使現有的各種服務，包括EJB，Web服務, Java代碼以及業務流程執行語言（Business Process Execution Language，BPEL）等，有了統一的抽象表示，從而實現了業務邏輯和實現邏輯的分離。

Table 1. SOA layers of adoption

Adoption level	Name	Description
1	Implementing individual Web services	Creating services from tasks contained in new or existing applications
2	Service-oriented integration of business functions	Integrating services across multiple applications inside and outside the enterprise for a business objective
3	Enterprise-wide IT transformation	An architected implementation enabling integration across business functions throughout an enterprise
4	On Demand Business Transformation	Broad transformation of existing business models or the deployment of new business models

Table 2. The six approaches to SOA

Approach	Description (typical project owner characterization)	Qualifications
Business process driven	My business processes need to tap into resources, and each activity requires the invocation of IT functionality; I want that functionality to be available in a flexible, replaceable way.	Top-down
Tool-based MDA	I want to define a model (business model) and then let my tools generate the detail for me.	Top-down
Wrap legacy	I have existing systems I have been investing heaviliy on, but they are not resilient. I want new functionality added quickly, but these systems are partitioned. They are silos where functions are locked into them.	Bottom-up
Componentize legacy	Decompose the monolithic legacy systems into modules using compiler-based tools.	Bottom-up
Data-driven	Provide access to information using services without having to expose schemas or implementation decisions on the provider side.	Data-focused
Message-driven	"Just want to have these systems integrate, communicate, over standard, non-proprietary protocols."	Service-Oriented Integration of Applications and Systems

Table 3. Patterns and their corresponding benefits

Context	Pattern	Applicability
Silo; concentrated functionality	Hard-coded (not a pattern, but a point in time state)	Point in time; low risk; low-changing, high-performance systems
Distributed; multi-point of access	Point-to-point exposure	Expose existing functionality rapidly; unlock value fast; access embedded functionality
Wrap a legacy function and make it callable through Web services	Service adaptor	Consumer needs access to functionality that is not service-enabled ( access to a legacy system through a service invocation, for example -- a Web service)
Access a service using its proxy if you do not have direct access to the service provider?s service description and are unable to directly invoke the service	Service proxy	Provides consumers with an SOA interface
Provide flexibility in the choice of the service provider	Remote service strategy	Provides flexibility in changing service providers based on quality of service or functionality considerations. This opens up possibilities in expediting mergers and acquisitions and flexible alteration of the provider when you consolidate application portfolios.
Eliminate redundant functionality; refactor and consolidate or, in some cases, replace existing systems	Single point of access	Provides one access point to a number of potential variants in functionality. A service strategy often requires a single point of access.
One project or LOB at a time, yet relies on others for some functions not yet exposed as services	Virtual provider	Non-existent providers; ramp up service critical mass
Single point of access	Service integrator	Routing, transformation
General enterprise integration approach	Enterprise service bus	Mediation; routing; transformation, policies, rules, events; inside the organization or between partners in ecosystem/value-net
The Nirvana of SOA; dynamic reconfiguration through context-aware services relying on business domain specific capabilities	Integrated service ecosystem	Provides dynamic configuration capabilities to a set of semantically interrelated industry specific business partners that leverage and recombine the ecosystem capabilities to provide greater value to themselves and the ecosystem as a whole

Often an initial challenge is the concrete determination of the value proposition for using SOA within a project, line of business, or organization. This has to do with flexibility and the ability to alter the actual service provider who implements a service once their quality of service dwindles or they fail to provide the required functionality. This flexibility, which is the primary value of SOA, is overcome by understanding the steps in achieving flexibility through a remote service strategy. There are two more challenges that we describe and overcome with the use of patterns presented here.

SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. The solutions below are descriptions of how these issues have been recurrently solved and may serve as a pattern to help you on your next project. Like any other pattern, these must also be adapted to fit the context and the forces that shape your individual problem space: the tradeoffs and considerations of your project, whether organizational or technical, make a difference, and you can determine if you need to skip a step from one pattern to another or to partially implement the pattern

The purely object-oriented strategy pattern primarily relies on inheritance-based polymorphism to create a family of interchangeable algorithms that are swapped out based on context. Rather than have an object hierarchy, in an SOA context, we need to be able to change the service provider with minimal or no impact on the consumer?s perception of the service, thus varying the actual implementer of the service description. The implementer may, in most cases, be a provider of a remote unit of functionality, somewhere in the internal network or Internet. Therefore, for
example, a service provider for a VerifyAddress service in an OrderEntry application may need to be changed because our quality of service needs have changed due to higher transaction volumes or security constraints. Or, the provider has decided to charge twice the amount for the same basic service, which we have relied on, in the past. Now, we would like to have the flexibility of changing service providers with IT and Business impunity, which means minimal changes to IT systems and no impact on the business or customer experience in their online shopping experience.


以上是今天看得兩篇英文文章中一些摘要，文章很長，說實話沒看太明白。只能在文章中找一些比較重要的東西貼在這，希望能有用。
原文鏈接：http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi/
?????????????????????http://www-128.ibm.com/developerworks/webservices/library/ws-soa-soi2/

6. 開發過程

盡管以服務為中心的企業集成在開發階段和普通的應用開發并沒有本質的區別，但是它在角色，職責、工具和方法還是有不少自己的特色。下圖匯總了本文示例中開發角色，職責，開發方法和工具，僅供大家參考。

?

SOA 的一個架構模板

SOA 的一個抽象觀點將它描述為與業務過程結合在一起的合成服務的部分分層架構。 圖 3 呈現了這種類型的架構。

服務和組建之間的關系是，企業級的組件（大粒度的企業或者業務線組件）實現該服務并且負責提供它們的功能和維持它們的服務質量。通過組合這些公開的服務到合成的應用程序，就可以支持業務過程流。綜合的架構通過使用 Enterprise Service Bus（ESB）支持這些服務、組件和流程的路由、中介和轉化。為了服務質量和非功能性的需求，必須監視和管理已經部署的服務。

圖 3：SOA 層

對于每一層，你都必須做設計和架構決定。因此，為了幫助用文件說明你的 SOA，你可能應該創建文檔，由每個層相應的部分所組成。

這里是為你的 SOA 架構文檔設計的模板：

1. 范圍 <此架構適用于企業的哪個領域>
2. 操作系統層
   1. 打包的應用程序
   2. 自定義應用程序
   3. 架構決策
3. 企業組件層
   1. 企業組件支持的功能范圍
   2. <這個企業組件支持業務領域、目標和過程>
   3. 關于控制的決策
      1. <作為這個客戶端組織內部企業組件來選擇某物的標準>
   4. 架構決策
4. 服務層
   1. 服務分類表
   2. 架構決策
5. 業務過程和合成層
   1. 業務過程可以表現為舞蹈編排（choreographies）
   2. 架構決策
      1. <哪一個過程需要編排在舞蹈編排里面以及哪一個鑲嵌在應用程序里面？>
6. 訪問或者表現層
   1. <證明這層中 Web 服務和 SOA 的含意；即便要。例如，在用戶接口級別上調用 Web 服務的 portlet 的使用，以及在此層機能上的含意。>
7. 集成層
   1. <包含 ESB 因素>
   1. <我們如何確保使用服務的客戶端系統級的一致性（SLA）和服務質量（QoS）？>
   2. 安全問題和決策
   3. 性能問題和決策
   4. 技術和標準的局限性以及決策
   5. 服務的監控和管理
      1. 描述和決策

現在，讓我們更加仔細的描述一下每一層以及每一層之間的合成。

層 1：操作系統層。本層包含現有的自定義構建的應用程序，也叫做 遺留系統，包含現有的 CRM 和 ERP 打包應用程序，以及 較舊的基于對象的系統實現，還有業務智能應用程序。SOA 的復合層架構可以利用現有的系統并且用基于服務的集成技術來集成它們。

層 2：企業組件層。本層由那些負責實現功能和保持公開服務 QoS 的企業組件組成。這些特殊的組件是企業和業務單元級支持的企業資產的受管理和控制的集合。 同企業范圍資產一樣，他們通過架構最佳實踐應用程序來負責確保 SLAs 的一致。大多數情況下，本層使用基于容器的技術，比如實現組件、負載均衡、高可用性和工作量管理的應用服務器。

層 3：服務層。業務選擇來支持和公開的服務處在這一層。它們可以被 發現或者直接靜態綁定，接下來被調用，或者可能的話，編排到合成服務中。這個服務公開層同樣提供了獲取企業范圍組件，業務單元特定組件，以及有些情況下，特定項目組建的機制，并且以服務描述的形式具體化了他們的接口子集。因此，企業組件使用它們接口提供的功能在運行時提供服務實現。在這一層的接口公開為一個服務描述，在這層中他們被公開以提供使用。他們可以獨立存在或者作為合成服務。

層 4：業務過程合成或編排層。第三層中公開的服務的合成和編排在這一層中被定義。通過配合、編排，服務被綁定成一個流程，并且從而作為單獨的應用程序而共同作用。這些應用程序支持特殊的用例和業務過程。這里，可視的流程合成工具，比如 IBM? WebSphere? Business Integration Modeler 或者 Websphere Application Developer Integration Edition，都可以用來設計應用程序流程。

層 5：訪問或表現層。盡管這一層經常超出了圍繞 SOA 討論的范圍，但是它卻變得越來越有意義。在這里我描述它因為標準越來越集中，比如用于 Remote Portlets Version 2.0 的 Web 服務和其他技術，這些技術追求在應用程序接口或者表現層來利用 Web 服務。你可以把它作為將來的層用來滿足將來的解決方案的需求。注意到以下這兩點是非常重要的：SOA 將用戶接口從組件中分離出來；最終你需要提供從訪問路線到服務或者合成服務的端到端解決方案。

層 6：集成（ESB）。這一層使服務可以集成，通過引入一系列可靠的性能的集合，比如智能路由，協議中介和其他轉化機制，經常被描述為 ESB（參閱 參考資料）。Web Services Description Language（WSDL）制定了綁定，其包含提供服務的地址。另一方面，ESB 為集成提供了位置獨立機制。

層 7：QoS。這一層提供了監視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個通過 sense-and-respond 機制和監測 SOA 應用程序健康的工具來進行的后臺處理過程，包括 WS-Management 和其他相關協議的所有的重要的標準實現以及為 SOA 實現服務質量的標準。

?

     摘要: 1. 隨機數? // Create a random number generator,?? // seeds with current time by default:Random?rand?=?new?Random();????int?i,?j,?k;???//?Choose?value?from?1?to?100:????j?=?rand.nextInt(100)?+?1;2. Aliasi...  閱讀全文

在本文中，我將談論如何將 Web 服務及非 Web 服務的多重 SOA 合并成三維的整合中心來連接各種后端企業主機系統，包括：

• 企業資源規劃（Enterprise Resource Planning，ERP）
• 客戶關系管理（Customer Relationship Management，CRM）
• 供應鏈管理（Supply Chain Management，SCM）
• 其它企業應用程序集成（Enterprise Application Integration，EAI）的應用程序
• 虛擬的數據庫管理系統

我也將討論中心如何接受輸入數據——事件和數據——來源于各種資源。我使用 X、Y 和 Z 軸在三維空間中展示圖片。

什么是 SOA 整合中心？

SOA 整合中心是 Web 服務與非 Web 服務的合并的 SOA 與后端企業系統的集成。它使得 Web 服務及非 Web 服務能夠與運行在不同平臺上的服務器、主機和微機上的企業系統交互。

然而，SOA 整合中心不同于面向服務的整合（service-oriented integration，SOI）。SOI 將 Web 服務與運行在不同平臺上的主機系統相整合。它使得 Web 服務能夠通過網關與主機交互。您需要 ASP.Net 或其它技術獲取網關來執行普通的 Web 服務。

SOA 是基于一套業務流程的 Web 服務的交互的體系結構。您可以在第一個 SOA 中獲取 Web 服務來在第二個 SOA 中復用代表 Web 服務的服務。Web 服務可能由一些小的 Web 服務組成，它們將服務傳遞給客戶。

您使用描述語言（例如，SOAP）或其它描述交互的方法（例如，REST）來定義交互。每個交互都是獨立且松耦合的，以便每個交互都能獨立于任何其它交互。這與依賴網關來與 Web 服務集成的緊耦合的主機系統形成對照。

SOA 層

我們看一下二維空間中的 SOA 層。之后，我將向您展示為何三維的整合中心是更好的選擇。

SOA 的 IBM 版本的前五層（請見參考資料）是（從下至上）：

• 操作系統
• 基于組件的（系統）
• 服務
• 業務流程
• 表示層

第六層是集成體系結構（也作為企業集成總線（Enterprise Integration Bus）），它垂直覆蓋了前五層。下一層是服務質量、安全、管理及監控層。

顯而易見，操作層由 EAI 打包的應用程序、遺留、老式的面向對象及商業智能應用程序組成。它們都可以通過使用 SOI（在項目級或企業級）來同第二層的基于組件的系統相集成。然后，將組件結合或集成到復合應用程序中來提供第三層的服務。

第四層向您展示了那些服務是如何根據一套業務流程從一個流向另一個的。更高一層通過遠程門戶網站 Web 服務（Web Services for Remote Portlet，WSRP）標準或其它面向人的表示層的方法來將 Web 服務應用于應用程序接口中。

二維靜態的 SOA 可能是有問題的。幸好，整合中心的發展意味著 SOA 將變成三維動態的。

可復用的體系結構

我們假設該 Web 服務需要在 .Net 平臺上或隨后的 WebSphere 平臺上運行前從主機系統獲取信息。您需要將 Web 服務與執行普通 Web 服務的主機網關相整合。

所有 Web 服務彼此以 XML 傳遞信息——多個 SOA 中的業務流程應當如何整合及其在提供的服務中如何實現。雖然在多個 SOA 中 Web 服務是可復用的，但是我進一步將 SOA 處理成可復用的體系結構。

我有多個實例，它們關于將可復用的 SOA 合并成與主機系統相連的整合中心，我提出如下四步來創建中心：

1. 將作為可復用的體系結構的 SOA 數組劃分成兩個模塊。第一模塊主要包括整合 Web 服務的機制，而第二個模塊重在服務交互。
2. 為了獲得最佳的速度及可靠性，將每個 SOA 優化成更緊湊的形式。檢查可能影響性能的磁盤碎片空間。
3. 將 SOA 按照重要性及復用頻率區分優先次序。檢查用戶對于更改 SOA 優先權的需求。
4. 將 SOA 合并成連接到一個或更多主機系統的整合中心，這些主機系統運行在不同的平臺上。檢查先前沒有被提出的互用性問題。

模塊化的 SOA 庫

您可以開發模塊化的和優化的 SOA 庫，這些 SOA 被分成了不同類別的層次。每個類別可以通過層次最低級別的 Web 服務被進一步劃分成 SOA 的子組。

您可以將庫用作到 Web 服務應用程序的動態鏈接。當應用程序需要訪問模塊化的 SOA 時，它將自己鏈接到庫中。當它不再需要檢索到的 SOA 時，將從庫中釋放自己，當提高速度及性能時節省磁盤空間。

下列是庫中模塊化的 SOA 的一些實例：

• 衛生保健 SOA
• 零售管理 SOA
• 物流 SOA
• 無線射頻識別（Radio Frequency Identification，RFID）SOA

庫用例

假設您使用在庫中使用最后三個 SOA（零售管理、物流和 RFID）來開發整合中心并將它們連接到主機網關中。今后，用戶的需求改變了——取消零售管理 SOA 并以衛生保健 SOA 代替它。

同時，用新版本更新物流 SOA 使其迎合用戶的需求。在 RFID SOA 中包含新的子組之后，將所有子組區分優先次序并將它們優化。

二維非共享的 SOA

我們看一下 Blue Repository 中的三個模塊化的 SOA（零售管理、物流和 RFID）的二維中心（請見圖 1）。所有都連接到主機網關中。例如，如果您使用 ASP.Net，那么您可以通過網關來執行普通的 Web 服務。

圖 1. 非共享的 SOA 的二維中心

如您所見，SOA 不是共享的。您可以將這三者結合成復合應用程序以減少到主機網關的連接器的數目。

二維共享的 SOA

如圖 2 所示，RFID SOA 與物流 SOA 在一邊相交疊。交疊區域用黃色帶黑色斜線來顯示。它包含 SOA 用于生成一個或兩個服務的資源。

圖 2. 共享的 SOA 的二維中心

代表三維空間中的中心

您怎樣在二維計算機屏幕上設想三維的中心？處理該問題的一種方法是在二維平面中畫出整合中心的 X、Y 和 Z 軸。另一種方法是使用軟件簡單地將 2D 圖片轉換成 3D 的版本。

在三維的中心，您可以在不改變 SOA 的情況下將現有的主機替換成新樣式或另一供應商的樣式。另外，您可以重新配置或更改 SOA 的優先權以適合新的或已更新的主機系統對于更改用戶及組織的需求的響應。

第一個三維中心

考慮如圖 3 所示的三維空間中的整合中心。如您所見，RFID SOA 中部分位于物流 SOA 之后。RFID SOA 的隱藏部分用到物流 SOA 的藍色線畫出。

圖 3. 第一個共享的 SOA 的三維中心

如您所見，連接器從 RFID SOA 通過（而不是環繞）物流 SOA 到主機網關。這意味著從 RFID SOA 而來的連接器與物流 SOA 共享了一些資源。

第二個三維中心

設想 RFID SOA 的重疊部分在物流 SOA 的前面，但是不是從任一側，如圖 4 所示。這給了 RFID SOA 更多的選擇來共享物流 SOA 中的大量資源。

圖 4. 第二個共享的 SOA 的三維中心

如您所見，連接器從 RFID SOA 通過物流 SOA。

有多少共享的 SOA？

在三維中心中您可以共享的 SOA 的數目依賴于項目復雜性、合并問題及業務流程中的利弊。向您避免 SOA 的過量開銷一樣，您需要確保在開發的整個生命周期中不會在三維空間中發生中心超負荷的問題。您應當在周期的每個時刻都測試超負荷。

結束語

在三維中心中合并 SOA 需要預先規劃來設置開發和共享的 SOA 的數目限制。您應當同業務分析師開發組交流有關各種合并問題的信息。您將發現解決合并問題會使您開發三維中心的工作變得非常容易。您可以開發在中心可復用和共享的 SOA。分析師將發現解決該問題會使他們的設計和分析三維空間的中心的工作變得非常容易。他們可以確定在不會導致中心超負荷的前提下哪個主機系統可以連接到中心。

體系結構中的集成需求

討論至此，集成已限定為通過基于組件的服務進行的應用程序的集成，但是集成這個主題比這要寬泛得多。在估計一個體系結構的需求時，必須考慮一些集成的類型或“方式”。您必須考慮如下幾方面：

• 應用程序集成
• 終端用戶界面集成
• 應用程序連接
• 流程集成
• 信息集成
• 構建集成開發模型。

終端用戶界面集成涉及如何集成特定用戶訪問的全部應用程序和服務來提供可用、高效、一致的界面。它是一個正在發展的主題，而新的發展在近期將主要取決于 Portal 服務器使用方面的進展。雖然 Portlet 已經可以通過 Web 服務調用本地服務組件，但是新技術（比如用戶遠程 Portlet 的 Web 服務）將使內容和應用程序提供者能夠創建交互式服務，這些服務在因特網上可以通過 Portal 即插即用，從而為很多新的集成提供了可能。

應用程序連接是一種集成方式，它涉及體系結構必須支持的所有類型的連接。在一個層次上，這意味著數據的同步和異步通信、路由、轉換和高速分布、以及網關和協議轉換器等等。而在另一個層次上，它還與輸入和輸出或源（sources）和匯（sinks）的虛擬化有關，正如您在 EWA 的通道（Channel）和協議轉換程序（Protocol Handlers）中所看到的。這里的問題在于數據移入、移出以及在實現體系結構的框架中移動的方式。

流程集成涉及開發映射到業務流程和為業務流程提供解決方案的計算流程、將應用程序集成到流程以及集成一些流程與其他一些流程。雖然第一項需求可能看起來似乎無關緊要，不過就是體系結構提供一個模擬基本業務問題的環境，但是，如果在這一層中不進行充分的分析，體系結構的任何實現注定都將失敗，不管它采用的技術是多么的巧妙。將應用程序集成到流程可能包括企業中的應用程序，也可能涉及調用遠程系統中的應用程序或服務，而這些遠程系統多半屬于業務合作伙伴。同樣地，流程層集成可能涉及整個流程的集成而不僅僅是來自外部源的單個服務，比如供應鏈管理或金融服務這樣橫跨多個機構的流程。為了滿足這樣的應用程序和流程的集成需求，可以使用像 BPEL4WS 這樣的技術，而應用程序框架也可以使用程序配置 Scheme（比如在 EWA 中看到的）。實際上，可以在底層使用 BPEL4WS 來構造一個高層配置 Scheme，然后通過一個引擎來驅動，這個引擎不僅提供流管理，而且還提供其他功能。然而，在構建這一切之前，您應該首先了解體系結構方面的需求，然后，再構建合適的基礎架構。

信息集成是一個流程，其作用在于為所有需要它的應用程序提供對企業中全部數據的一致訪問，而不管這些應用程序是以什么形式需要它，也不受數據的格式、來源或位置的限制。在實現時，這項需求可能包括 適配器和轉換引擎，不過它通常要比這復雜。而關鍵的概念往往是數據的虛擬化，這可能包括 數據總線（Data Bus）的開發，企業中的所有應用程序都通過標準服務或接口從數據總線中請求數據。因此，不管數據是來自電子數據表、本地文件、SQL 或 DL/I 數據庫，還是來自內存中的數據存儲，都可以將數據提供給應用程序。永久存儲中的數據格式可能還不為應用程序所知。應用程序更不知道管理數據的操作系統，因而訪問 AIX 或 Linux 系統中的本地文件的方式與這些文件放在 Windows、OS/2、ZOS 或其他系統中時訪問它們的方式相同。同樣地，數據的位置也是透明的；由于它是由共同的服務提供的，所以是由訪問服務而不是由應用程序來負責查詢數據（無論是本地的還是遠程的），然后按照請求的格式提供數據。

應用程序開發環境的最后一項需求是，必須考慮可能在企業中實現的集成的所有方式和層次，并且為它們的開發和部署做好準備。要想真正做到健壯，開發環境必須包括（和執行）一種方法來明確地規定如何設計和構建服務和組件，以便促進重用、消除冗余和簡化測試、部署和維護。

上面列出的所有集成方式在任何企業中都有一定程度的體現，盡管在某些情況下它們可能是簡化的，或者沒有明確地進行定義；因而，在著手設計新的體系結構框架時，您必須全面的考慮它們。特定的 IT 環境可能只有很少的數據源類型，因此，消息集成可能會很簡單。同樣地，應用程序連接的作用域可能也很有限。雖然如此，如果希望框架能夠隨著企業的成長和變化成功地繼續得以保持，則框架中的集成功能仍然必須由服務提供，而不是由特定的應用程序來完成。

Where storage lives

It’s useful to visualize some aspects of how things are laid out while the program is running—in particular how memory is arranged. There are six different places to store data: Feedback

1. Registers. This is the fastest storage because it exists in a place different from that of other storage: inside the processor. However, the number of registers is severely limited, so registers are allocated by the compiler according to its needs. You don’t have direct control, nor do you see any evidence in your programs that registers even exist. Feedback
2. The stack. This lives in the general random-access memory (RAM) area, but has direct support from the processor via its stack pointer. The stack pointer is moved down to create new memory and moved up to release that memory. This is an extremely fast and efficient way to allocate storage, second only to registers. The Java compiler must know, while it is creating the program, the exact size and lifetime of all the data that is stored on the stack, because it must generate the code to move the stack pointer up and down. This constraint places limits on the flexibility of your programs, so while some Java storage exists on the stack—in particular, object references—Java objects themselves are not placed on the stack. Feedback
3. The heap. This is a general-purpose pool of memory (also in the RAM area) where all Java objects live. The nice thing about the heap is that, unlike the stack, the compiler doesn’t need to know how much storage it needs to allocate from the heap or how long that storage must stay on the heap. Thus, there’s a great deal of flexibility in using storage on the heap. Whenever you need to create an object, you simply write the code to create it by using new,and the storage is allocated on the heap when that code is executed. Of course there’s a price you pay for this flexibility. It takes more time to allocate heap storage than it does to allocate stack storage (if you even could create objects on the stack in Java, as you can in C++). Feedback
4. Static storage. “Static” is used here in the sense of “in a fixed location” (although it’s also in RAM). Static storage contains data that is available for the entire time a program is running. You can use the static keyword to specify that a particular element of an object is static, but Java objects themselves are never placed in static storage. Feedback
5. Constant storage. Constant values are often placed directly in the program code, which is safe since they can never change. Sometimes constants are cordoned off by themselves so that they can be optionally placed in read-only memory (ROM), in embedded systems. Feedback
6. Non-RAM storage. If data lives completely outside a program, it can exist while the program is not running, outside the control of the program. The two primary examples of this are streamed objects, in which objects are turned into streams of bytes, generally to be sent to another machine, and persistent objects, in which the objects are placed on disk so they will hold their state even when the program is terminated. The trick with these types of storage is turning the objects into something that can exist on the other medium, and yet can be resurrected into a regular RAM-based object when necessary. Java provides support for lightweight persistence, and future versions of Java might provide more complete solutions for persistence. Feedback