By Simon Johnston, Architect, IBM Corporation.
本稿では、ソフトウェア・サービス向けの UML プロファイル、つまり、サービスのモデリング、SOA およびサービス指向のソリューションを可能にする、UML 2.0 のプロファイルについて説明します。 このプロファイルの目的は、開発ライフ・サイクルを通して数多くのアクティビティーをカバーするサービスを記述するための共通の言語を提供し、 また、さまざまな利害関係者にビューを提供することです。 そのため、例えば、プロファイルを使用することによって、アーキテクトは論理パーティションを使用してライフ・サイクルの初期にサービスを計画し、 企業規模のサービスのポートフォリオ全体を記述することができるようになります。 このビューは、サービス・クライアントと実装者の間で交わされる契約として機能する、構造と振る舞いの両方の サービス仕様を作成する設計者によってさらに詳細に記述されます。 メッセージ・ビューは、設計者が共通のサービス・データ定義のための情報モデルを再利用できるようにします。
このプロファイルは、複雑な顧客シナリオのモデルを作成する際に、また、 サービス指向のソリューションの開発関係者を教育する際に、Rational Software Architect に実装され、正常に使用されました。
以下の図はサービスのモデリングにおける重要な概念を示すモデルです。 概念の数は比較的少なく、サービス指向のソリューションに取り組んだことがあれば馴染みのあるものです。 ただし、プロファイルはこのモデルの実現ではあるものの、プロファイル内には明示的なステレオタイプである概念は多くないことに注意してください。 例えば、操作やプロトコルのためのステレオタイプはありません。 これらは UML 2.0 の既存の概念であり、プロファイルでは、曖昧さや追加の制約なしに再利用されるためです。
以下の表では、UML プロファイルのステレオタイプのためのメタクラスとして使用される UML 2.0 メタモデルの要素をリストしています。
UML 2.0 メタクラス | ステレオタイプ |
---|---|
クラス | メッセージ、サービス・パーティション、サービス・プロバイダー |
分類子 | サービス・コンシューマー |
コラボレーション | サービス・コラボレーション |
コネクター | サービス・チャネル |
インターフェース | サービス仕様 |
ポート | サービス、サービス・ゲートウェイ |
プロパティー | メッセージ添付ファイル |
以下の (クリック可能な) 図は UML 2.0 のプロファイル図です。 それぞれのステレオタイプでプロファイルの実際の詳細を示し、 拡張概念 (塗りつぶされた矢印の先) を使用してそのメタクラスを表します。 また、モデルの制約のいくつか、特にプロファイル要素間の共通の制約が示されています。
以下のセクションでは、現在定義されている UML 2.0 プロファイルの各要素について概要を説明します。 各セクションで個々のステレオタイプについて概要を説明します。 それぞれの詳細では、プロファイルを使用するときに適用するメタクラス、プロパティー、および制約が指定されています。
クラス
メッセージは WSDL 仕様で定義された概念を表します (すなわち、サービスとコンシューマーに対して意味を持つ実際のデータのコンテナー)。
メッセージは操作を持たず、プロパティーと他のクラスへの関連付けを持つことがあります (何らかのドメイン・モデルのクラスを前提とする) 。
メッセージのステレオタイプはプロパティーを持ち、
想定するエンコード方式を表します (すなわち、SOAP-literal
、SOAP-rpc
、ASN.1
など)。
この要素の使用は、2 つの理由から、ツールのオプションとなります。 1 つめは、モデリング担当者が、メッセージを指定するよりも、要素を直接ドメイン・モデルからパラメーターとして操作に使用することを単に望む場合があります。 2 つめは、モデリング担当者が、操作に対して入出力メッセージのセットを指定する規則を使用することを望む場合があります。 この場合、モデリング・ツールは、WSDL でサービス記述を生成するとき、パラメーターに一致する入出力メッセージを構成しなければなりません。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | encoding | 文字列 | メッセージのためのスキーマ生成に使用するプラットフォームのエンコード・メカニズムを表します。
例として SOAP-RPC、Doc-Literal、ASN.1 などがあります。
|
プロパティー
このステレオタイプは、(メッセージ自体に直接含まれるものとは対照的に) メッセージのあるコンポーネントがメッセージ添付ファイル であることを示すために使用されます。 一般に、これがハイレベルの設計アクティビティーに使用されることはあまりないようですが、多くの場合、 プロセスに添付されたデータを組み込まれたメッセージ・データと区別することは重要です。 例えば、カタログ・サービスは一般的な製品の詳細を構造化メッセージの一部分として戻しますが、 イメージはメッセージへの添付ファイルとして返す可能性があります。 また、これにより、イメージのエンコードは (メイン・メッセージのテキスト・エンコードとは対照的に) バイナリーであることを示すことができます。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | encoding | 文字列 | メッセージのためのスキーマ生成に使用するプラットフォームのエンコード・メカニズムを表します。
例として SOAP-RPC、Doc-Literal、ASN.1 などがあります。
|
ポート
サービスのモデル要素は、
(Web サービス用語における) サービスの相互作用のエンドポイントを提供しますが、これらの相互作用の定義はサービス仕様の一部です。
このモデルでは、サービスは提供されたインターフェースを識別するだけではなく、
(コールバック・インターフェースなどの) 必要なインターフェースも識別します。
サービスは追加のプロパティーを持っていて、SOAP-HTTP
、SOAP-JMS
など、使用されるバインディングを表します。
なし
コネクター
チャネルは 2 つのサービス間のコミュニケーション・パス を表します。 相互作用はチャネル上で発生しますが、チャネルが特定の相互作用を表すことはないので、注意してください。 Web サービスの世界では、各サービスは (クライアントがアクセスできるように) そのサービスに関連するバインディングを示します。 モデリング・プロファイルでは、サービス間の通信、または、サービスとコンシューマー間の通信のどちらかにおけるバインディングを示します。 このように、バインディング要求は柔軟に理解できます。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | binding | 文字列 | WSDL でサービス・バインディングを生成する際に使用するプラットフォーム・バインディング・メカニズムを表します。例として SOAP-RPC 、SOAP-Doc 、HTTP-Get などがあります。
|
コラボレーション
サービス・コラボレーションは、他のサービス・コラボレーションとしてサービスの実装を指定する方法です。 Web サービスの観点からすると、これはサービス実装の指定における BPEL4WS の使用に相当します。 したがって、これはサービス・コラボレーションがサービスの振る舞いとして使用されることを意味し、 また、BPEL などの言語への生成を目的とする場合、別の実装固有の制約が発生する可能性があります。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | Binding | 文字列 | プロセスの振り付けとしてコラボレーションを生成する際に使用するプラットフォーム・バインディング・メカニズムを表します。 例として "BPEL"、"WSFL" などがあります。 |
分類子
どの 分類子 (クラス、コンポーネントなど) もサービス・コンシューマーとして機能する可能性があり、 それには別のサービスも含まれます。 このステレオタイプは、確かにオプションではあるものの、サービスのクライアントとしてモデルの要素 (サービスそのものではない) を識別する際に役に立つことがあります。 また一方では、これはオーバーヘッドとなり、使用されない場合もあります。
なし
なし
ポート
サービス・ゲートウェイはサービスに似ていますが、 サービス・プロバイダーでなく、パーティションでのみ使用可能です。 ゲートウェイはプロキシー・サービスとして機能し、 プロトコルを仲介するために、または、パーティションで使用可能なインターフェースを示すために使用できます。 例えば、多くのサービスがパーティション内に実装されているが、パーティションの外側で使用可能なのはそのうちの一部だけなので、 ゲートウェイがこれらのサービス用に用意されることを示す場合があります。 これにより、他のサービスやパーティションは、ゲートウェイを介して公開されているサービス以外とは通信できなくなります。
なし
クラス
パーティションはシステムのある論理的または物理的な境界 を表します。 パーティションのモデル化はオプションですが便利です。 例えば、従来の n 層アプリケーションの Web、ビジネス、およびデータ層を表すためにパーティションを使用することもできます。 また、パーティションは、より物理的な境界 (1 次データ・センター、2 次サイト、 カスタマーのサイト、パートナーなど) を示すために使用されることがあり、 その場合、パーティションを越えるには、セキュリティー、許容プロトコル、帯域幅などについて特定の制約がある可能性があります。
パーティションは、ネストされたパーツ (それがサービスまたは他のパーティションであるかどうかに関わらず) を表すプロパティーのみを持つ場合があります。 これは制約である ことに注意してください。パーティション内で他の要素が同時に表されることはありません。
また、パーティションには、「厳密」という概念があります。 パーティションが、他のパーティションとの間の通信はすべて、型指定されたゲートウェイを経由しなければならないと示している場合、それは厳密なパーティション と呼ばれます。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | Classifier | 文字列 | 分類名、このパーティションのネーム・スペースのスコープを表します。 |
クラス
サービス・プロバイダーは、1 つ以上のサービスを提供するソフトウェア要素です。 モデリングの観点では、通常最も考えられるのは UML コンポーネントですが、 そのような制限には特に理由はないので、より柔軟性を高めるためにメタクラスはクラスとして示されています。 サービス・プロバイダーには、 そのロケーションに関する情報を収集するプロパティーがありますが、この意味は実装環境に依存します。 サービス・プロバイダーとして機能するクラスは、どのような属性または操作も直接公開せず、 公開ポートだけが提供されることがあります (サービスとしてステレオタイプ化)。これらのポートはサービス仕様によって型指定されます。
ロケーション・プロパティーは、実装/プラットフォームに固有のものですが、サービスのエンドポイント名を生成する際役に立ちます。
例えば、WSDL でロケーションが http://svc.myco.com/
であり、
サービスが CustInfo
と呼ばれる場合、サービスのエンドポイント名は http://svc.myco.com/CustInfo
として生成されます。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | allowedBindings | 文字列 | チャネルがサービスへの接続に使用する、許容プラットフォーム・バインディング・メカニズムを表します。
例として SOAP-RPC 、SOAP-Doc 、HTTP-Get などがあります。
|
プロパティー | location | 文字列 | プロバイダーのロケーション、これはエンドポイント名を生成するために生成プログラムによって使用されます。 |
インターフェース
インターフェースの使用は、サービスが操作のセットを提供することを示します。 サービスは複数のインターフェースを実装することがあるので注意してください。 規約により、プロトコル状態マシンまたは UML 2.0 コラボレーションを仕様に付加し、サービス仕様に対する操作の呼び出し順番を示すことが可能です。 そのような振る舞いの仕様によって、実装側のサービスを、その構造と振る舞いの静的仕様だけでなく動的仕様に対しても検証することができます。 サービス仕様が public の操作しか提供しない場合があるので注意してください。
種類 | 名前 | 型 | 説明 |
---|---|---|---|
プロパティー | published | ブール | このプロパティーは、サービスがサービス・リポジトリーに公開されることが前提とされているかどうかを示します。 これは UML の public/private プロパティーとは異なった概念です。 |