使用UML為EAI建模

在企業應用集成（EAI）中，通常使用某種形式的消息來提供松散的耦合，使得企業應用易于更改，可以連接異構系統和操作環境，使得在局部系統出錯的時候能更好地恢復，這樣可以使系統獲得更高的強壯性。

EAI技術主要用于集成遺留系統和新的企業應用。而將遺留系統和新的應用集成是一件困難且昂貴的工作，很大程度是因為必須在各孤立系統之間建立連接，所以需要一種機制來更好地描述如何使一個應用程序能被另外一個應用程序所調用。

在EAI建模中使用UML可以更好地描述集成的架構。統一建模語言（UML）是用來對軟件密集系統進行描述、構造、可視化和文檔編制的一種語言。UML的開發者把并行分布式系統的建模作為UML的設計目標，也就是說，UML具有處理這類問題的能力。同樣，UML在EAI領域也可以發揮它的作用。

使用UML來為EAI建模的益處

● 更好地闡明產品的架構，使客戶能理解產品的配置以及如何在客戶的組織中安裝；

● 使得項目的參與者能更好地理解整個產品的架構，避免項目的參與者的思維被限制在產品的某個局部，而沒有從整體上來考慮，防止局部的優化而損害整體的性能；

● 在產品的發布材料中包含UML的建模信息可以支持銷售和技術支持工作；

● 可以幫助開發資源的分配，根據UML架構可以更好地分配開發工作和配置開發資源。

應用程序之間的連接和交互是復雜的。要解決這種復雜性，就需要定義一個所關注和聚焦的層次。使用UML來建模，在用于代表不同層次的細節方面比較成功。對EAI來說，比較適合的層次是應用架構（Application Architecture）??對應用程序之間的接口和交互的處理。UML在這一層次建模比較成功。

三個進階

EAI可以分為三個進階:（1）通過連接來進行應用程序集成;（2）通過信息共享來進行應用集成;（3）通過流程協作來進行應用集成。更高的進階必須在更低慕?椎幕?≈?轄?小?每一進階都具有自己的特點，需要進行的建模工作和建模對象都有所不同。

進階1：連接

在這一階段，應用程序之間進行同步或者異步的通信來提供商業功能。在這一進階，需要進行建模的對象有：

● 服務請求方和服務供應方；

● 同步或者異步的服務請求；

● 請求、響應和通知。

在這一進階，集成的多個應用程序共享一個公共的應用架構。應用程序共用通信的數據模型，并且能夠激活相應的應用程序來獲得服務。

進階2：信息共享

在這一進階，要求能在整個企業系統中更容易添加新的應用和新的功能，而盡可能地減小對已有應用和服務的影響。比較好的一種解決方式就是使用信息共享方式來建模。這種信息共享方式通過應用程序之間業務事件驅動的發布/預定（publication/subscription）通信來實現?？梢约俣ㄟ@些應用并不關心是哪個程序在使用它的信息以及接收方期望什么格式的信息。 在這一進階中，建模的內容有：

● 代表業務事件的消息（對不代表業務事件的信息關注較少）。

● 消息和業務事件的發布??發布消息的能力。

● 隊列和主題??必須能夠將發送方應用程序的輸出容器和接收方應用程序的輸入容器分離。

● 數據轉換??每個應用程序都能以其獨特的格式創建和使用消息。應用程序應該能使用適合其開發語言的數據結構。數據的轉換也包括了數據的校驗。

● 信息的預定（subscription）。

● 保留信息從創建、處理、轉換到使用的歷史記錄。

● 對數據的審查、追蹤和挖掘。

信息共享用于描述參與的應用程序之間的交互。當系統對于實時性要求很高，并且采用消息/事件技術來通信時，這種共享可以被稱為“零延遲信息共享”。

進階3：流程協作(Process Collaboration)

在這一進階，企業應用通過B2B(Business-to-Business)協議和企業外部系統進行集成。為了獲得企業系統的靈活性，要求企業應用獨立于使用的B2B協議，而且企業的內部流程對于企業外部系統是隱藏的。這樣，當企業的內部流程發生變化后，不會影響到外部的合作伙伴。這就要求有一種媒介服務來將B2B協議所隱含的流程和數據語義轉換為企業內部流程和數據語義。這種轉換被稱為語義媒介（Semantic Mediation）。

在這一進階的建模內容有：

● 語義媒介??在應用程序和B2B協議之間的流程和數據結構的轉換。

● 企業之間的信息傳遞??安全、無欺詐、能應付災難性事件。

● B2B級的審查、追蹤和挖掘??業務事件可以被審查、分析以及進行數據挖掘。

● 在信息庫中包含了貿易伙伴和他們之間通信的信息貿易社區協議。

三種建模方式

方式1: 元模型

基于MOF（Meta Object Facility,元對象工具）的元模型使用UML符號的一個子集來進行面向對象的建模。用到的UML元素有：

● 具有屬性和操作（也就是方法）的類；

● 二元關聯；

● 包；

● OCL(對象約束語言)。

EAI的元模型是遵循如下規范來文檔化的：

● 元模型的整體結構顯示為一個或多個包圖；

● 每個包的大小有一定的限制，每個包只需一個類圖；

● 為了描述一個包，類之間的協作(Collaboration)必須指定并且得到描述，為了更好地描述模型，每個類必須分開來進行描述；

● 每個協作的語義遵循一定的規范來描述。

方式2: UML建模集

通過UML 建模集，建模人員可以使用UML符號來為EAI建模。在元模型和UML建模集之間的映射被定義為EAI規范的一部分?？梢允褂靡恍┕ぞ邅磉M行元模型和UML 建模集之間的轉換。映射的細節也作為建模集的一部分。

方式3: 四層結構

OMG組織將EAI規范定義為四層結構。MOF在第三層，EAI元模型在第二層，EAI的UML建模集也在第二層。EAI元模型可以看作是EAI模型的抽象語法的定義。EAI模型在第一層，是抽象語法的一個表示。它是基于事件系統的架構和系統之間的信息流的一個規范。第0層就是基于事件系統的實際行為。

原文轉自：http://www.anti-gravitydesign.com