用于軟件服務的 UML 2.0 Profile

這篇文章描述了用于軟件服務的 Profile，一個UML 2.0 profile，它涉及對服務的建模、面向服務架構（SOA）以及面向服務的解決方案。這個 profile 已經在IBM Rational Sofware Architect 上實現了，被成功的應用于客戶建模復雜的場景以及用于幫助人們訓練在開發面向服務的解決方案過程中關心的問題。

用于軟件服務的 UML 2.0 Profile 概述
在IBM Rational Sofware Architect 上實現 profile 的目的是為描述服務提供一個共同語言，該 profile 包括了在開發生命周期內的很多活動并且為不同的涉眾提供了視圖。例如，該 profile 提供為架構師指定服務的能力――在生命周期的早期――使用邏輯劃分來描述整個企業范圍的服務組合。這個視圖再由設計師來細化，設計師開發服務規約說明――結構上的和行為上的――這個服務規約說明擔當服務的客戶和實現者之間契約的作用。消息視圖為設計師對于公共的服務數據定義提供重用信息模型的能力。

概念模型
下面的圖一顯示了在建模服務時重要的概念。正如你可以看到的，概念的數目相對較小，而且對于任何從事面向服務的解決方案的人應當相當地熟悉。該圖表示的UML 2.0 profile 已經在IBM Rational Sofware Architect 上實現了，被成功的應用于客戶復雜場景的建模以及用于幫助人們訓練在開發面向服務的解決方案過程中關心的問題。然而，盡管這個profile是該模型的一個實現，在這個profile中注意很多概念不是明顯的原型。例如，操作（operation ）或者協議（protocol）就是沒有原型，就像UML 2.0中已經有一些概念一樣，該 profile 可以進行沒有歧義的或者進一步約束的重用。

圖一. 對服務建模

被識別的 UML 2.0 子集
表一列出了UML 2.0元模型中在UML profile中用作原型元類的元素。

表一. UML 2.0元模型中的元素

UML 2.0元類	原型
類	消息，服務劃分，服務提供者
分類器	服務消費者
協作	服務協作
連接器	服務信道
接口	服務規約說明
端口	服務，服務網關
屬性	消息附件

profile本身
圖二（可以點擊）是一個UML 2.0 profile 圖。它表明了profile 的實際細節，使用擴展標記（實心的箭頭）顯示了每一個原型以及它的元類。你可以在該模型中，看到一些約束。尤其是那些在profile元素之間的相互約束。

圖二. 一個 UML 2.0 profile圖

接下來的部分概述了UML 2.0 profile 現在定義的元素。每個部分略述了一個單個的原型，它的細節詳細說明了它的元類、屬性以及在使用該profile時應該應用的任何約束。

原型消息
繼承自

類（Class）

語義

一個消息代表在 Web 服務描述語言（WSDL）規范中定義的一個概念；即，它是實際數據對服務和消費者有意義一個容器。消息不能有操作，但是它可能有屬性和與其他類的關聯（很可能是某個領域模型）。一個消息原型具有一個屬性來表示它的假定的編碼格式（例如SOAP-literal, SOAP-rpc, ASN.1等等）。

屬性

表二列出了一個消息原型的屬性。

表二. 一個消息原型的屬性

種類	名稱	類型	描述
屬性	編碼	字符串	代表了用于產生消息模式的平臺編碼機制。例如SOAP-literal, SOAP-rpc, ASN.1等等

符號

約束

• 不應有任何自己的操作
• 不應有任何自己的行為

 

原型消息附件
繼承自

屬性（Property）

語義

這個原型用于表示消息的某些組件是一個該消息的附件（相對于消息的直接部分本身）?？傮w而言，你不太可能在高級的設計活動中經常使用這個原型，但是對于許多過程，區分附件數據和內嵌的消息數據還是很重要的。例如，一個目錄服務可能返回概括的細節作為一個結構化的消息的一部分，但是返回圖像作為該消息的附件。這也允許你表示這個圖片的編碼是二進制的（與主要消息的文本編碼方式相對）。

屬性

表三列出了消息附件原型的屬性

表三. 消息附件原型的屬性

種類	名稱	類型	描述
屬性	編碼	字符串	代表了用于產生消息模式的平臺編碼機制。例如SOAP-RPC, Doc-Literal, ASN.11等等。

符號

約束

• 只能用于屬于原型為<<Message>>的類的屬性。

 

原型服務
繼承自

端口（Port）

語義

該服務模型的元素提供服務交互作用（在Web服務技術中）的一個終點，然而這些交互作用的定義是服務規約說明原型的一部分。在你的模型中，服務不僅識別提供的接口，而且識別需要的接口（例如回調接口）。一個服務擁有附加的屬性表示需要使用的綁定，例如SOAP-HTTP, SOAP-JMS等等。

屬性

無

符號

約束

• 應該只在原型為<<Service Provider>>的類中使用
• 應該被作為原型為<<Service Specification>>的接口

 

原型服務信道
繼承自

連接器（Connector）

語義

一個信道表示兩個服務之間的通訊路徑。注意交互作用可能出現在一個信道，但是信道并不表示任何特殊的交互作用。在Web服務世界里，每個服務表示與之相聯系的綁定（這樣一個客戶可以訪問它）。在建模一個profile的時候，你要么在服務之間的通信，要么在服務與客戶之間的通信來表示綁定。以這樣的方式，在理解綁定需求的時候你可以很靈活。

屬性

表四列出了一個服務信道原型的屬性。

表四。一個服務信道原型的屬性

種類	名稱	類型	描述
屬性	綁定	字符串	表示了用于在 Web 服務描述語言（WSDL）規范中產生服務綁定的平臺綁定機制。例如 SOAP-RPC, SOAP-Doc, HTTP-Get等等。

符號

約束

• 連接器的至少一端應當連接到原型為<<Service >>的端口
• 連接器的至多一端能夠連接到原型為<<Service Gateway>>的端口，一個原型為<<Service Provider>>的類或者<<Service Consumer>>的分類器

 

原型服務協作
繼承自

協作（Collaboration）

語義

服務協作是一種指定一個服務的實現作為一個其他服務的協作的方式。從Web服務的角度來看，這對應于在指定服務實現過程中使用BPEL4WS（Web服務的業務過程執行語言）。所以，這意味著你使用一種服務協作作為服務的行為――如果有意要產生一種類似BPEL的語言――它可能由其他的實現相關的特殊的約束。

屬性

無

符號

約束

• 協作參與者應當只應該是原型為<<Service Provider >>的類

 

原型服務消費者
繼承自

分類器（Classifier）

語義

任何分類器（類，組件等等）可能充當服務的消費者，也包括其他的服務。當這個原型是明確的最優的時，它可能幫你識別模型的元素――這不是服務本身－－作為服務的客戶。另一方面，它可能僅僅是更高層次的，而你并不需要使用它。

屬性

無

符號

約束

無

原型服務網關
繼承自

端口（Port）

語義

原型服務網關看起來像一個服務，但是它卻只是對劃分可用的，而對服務提供者是不可用的。一個網關充當一個代理服務，你可以使用它來協調協議或者表示一個劃分上的可以利用的接口。例如，你可能表示――盡管許多服務實在一個劃分內實施的――只有某些服務對于劃分之外的使用是可用的，因此網關來提供這些服務。這不允許不暴露于網關的從通信到服務的其他服務或者劃分。

屬性

無

符號

約束

• 應當只用于原型為<<Service Partition>>的類
• 應該被作為原型為<<Service Specification>>的接口

 

原型服務劃分
繼承自

類（Class）

語義

一個劃分代表系統的某個邏輯或者物理的邊界。建模劃分是可選的但是有用的。例如，你可以使用劃分來表示傳統的n層應用中的網絡，業務以及數據層。你也可以使用劃分來表示更多的物理邊界（例如我的主要數據中心、第二站點、客戶站點、合作伙伴等等），在這些情況下，劃分的跨越可能具有特別的約束，安全方面、允許的協議、帶寬等等。

一個劃分可能只具有表示嵌套部分的屬性，成為服務或者其他的劃分。注意這是一個約束――沒有其他的元素現在劃分內可以被表示。

一個劃分的符號也比較嚴格。如果一個劃分表示它和其他所有劃分的全部通信必須直接通過指定的網關，那么它被稱為是一個嚴格的劃分。

屬性

無

符號

約束

• 不應當有任何自己的屬性
• 不應當有任何自己的操作
• 不應當有任何自己的行為
• 任何自己的部分應當是原型為<<Service Provider>>的一個類

 

原型服務提供者
繼承自

類（Class）

語義

服務提供者是一個提供一個或者多個服務的軟件元素。在建模的術語里，你可能最經常期望見到的一個UML組件。然而，這樣的一個約束似乎是武斷的，所以為了更大的靈活性，元類被指明作為一個類。一個服務提供者擁有一個屬性能夠捕捉他的位置信息，盡管它的意思是隨具體的實現而定的。該類充當服務提供者可能不直接暴露任何屬性和操作：只有公開的端口可能被提供（原型為Service），而且這些事被寫入服務規約說明書中的。

位置屬性――在實施的時候――或者平臺特定的――在生產服務的端點名稱時是有效的。例如（有了WSDL），位置可能是http://svc.myco.com/ ， 服務可能被稱為CustInfo，在這種情況下服務的端點名字可以生成如下：http://svc.myco.com/CustInfo。

屬性

表五列出了服務提供者原型的屬性

表五。服務提供者原型的屬性

種類	名稱	類型	描述
屬性	允許的綁定	字符串	表示了允許的平臺綁定機制，一個信道可能使用在連接服務中；例子可能是SOAP-RPC, SOAP-Doc, HTTP-Get等等.
屬性	位置	字符串	提供者的位置，它可以被生成器用作創端點點的名字。

符號

約束

• 不應當有任何自己的屬性
• 不應當有任何自己的操作
• 應當有任何自己的行為
• 任何自己的部分應當是原型為 <<Service>>的一個類

 

原型服務規約說明
繼承自

接口（Interface）

語義

對接口的使用表示服務提供的一個操作集合。注意一個服務可能實現多個接口。習慣上，可以將一個協議狀態機或者UML2.0 協作附加到這樣的規約說明上來表示服務規約說明上的操作調用的順序。有了這樣一個行為的規約說明，任何實現服務相對于不僅是靜態的而且是動態的結構和行為的規約說明，都可以是有效的。注意服務的規約說明只能提供公開的操作，而且每個操作應當只能消耗至多一條消息、產生至多一條消息。

屬性

表六列出了服務規約說明原型的屬性

表六。服務規約說明原型的屬性

種類	名稱	類型	描述
屬性	公開的	布爾型	這個屬性表示了服務是否被認為發布到一個服務的存儲庫中；這和UML中提供的共有/私有的屬性是一個不同的概念。

符號

約束

• 不應當有任何自己的屬性
• 所有的操作都應當被標記為公有的
• 只能被用作原型為 <<Service>> 或者 <<Service Gateway>>端口的類型

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