ソフトウェア・サービスのためのUMLプロファイルの概要

IBM Rational Sofware Architectに実装されている、このプロファイルの目的は、サービスを記述するための共通言語を提供することです。つまり、この言語は開発ライフサイクルにおける幾つかのアクティビティーを網羅しており、またこの言語が提供するビューを、様々な利害関係者が利用することができます。例えば、アーキテクトがこのプロファイルを利用すると、（ライフサイクルの初期段階に）全体的なサービス設計を行うことができます。つまり、論理パーティションを使って、企業全体に渡ってのサービス・ポートフォリオを記述できるのです。一方（サービス仕様を設計する）設計者は、アーキテクトによるこうしたビューを、サービス・クライアントと実装者間の契約として動作するサービス仕様（構造的な仕様および振る舞い仕様の両方）として、さらに詳細に記述します。また『メッセージ』ビューによって、設計者は共通サービス定義用の情報モデルを再利用することができます

概念的なモデル

下記の図1は、サービスのモデル化に関する重要な概念を示しています。ご覧の通り、概念の数は比較的少なく、サービス指向ソリューションに経験のある人には見慣れたもののはずです。この図が示すUML 2.0プロファイルは、IBM Rational Sofware Architectで実装されており、複雑な顧客シナリオのモデル開発に活用されています。また、サービス指向ソリューションの開発に関する懸念事項についての教育用にも使われています。ただし、確かにUML 2.0プロファイルはこのモデルを実現したものですが、幾つかの概念は、UML 2.0プロファイルでは明示的なステレオタイプとなっていないことに注意してください。例えば、『オペレーション』や『プロトコル』用のステレオタイプはありませんが、これらの概念は既にUML 2.0の中にあるためです。UML 2.0プロファイルでは、曖昧さ無しに、また追加の制約を使用するする必要もなく、これらを再利用できるのです。

UML 2.0で指定されているサブセット

表1は、UML 2.0のメタデータ・モデルの要素を示しています。（これらの要素はUMLプロファイルのステレオタイプに対するメタクラスとして使われています。）

上に戻る

プロファイル自体

図2（クリックできます）は、UML 2.0のプロファイル図です。この図は、このプロファイルの実際の詳細を示しており、各ステレオタイプには拡張標記（先頭を塗りつぶした矢印）を使ったメタクラスが付いています。また、モデルの中にある制約の幾つか（特にプロファイル要素間の補助制約）も見ることができます。

この先のセクションでは、現在定義されているUML 2.0プロファイル要素の概略について説明します。各セクションでは、各ステレオタイプと、メタクラスを規定する詳細、プロパティー、また、このプロファイルを使用する際に適用される制約についての概略を説明します。

ステレオタイプ: メッセージ

拡張対象

クラス

意味体系

メッセージは、WSDL（Web Services Description Language）仕様の中で定義されている概念を表現します。つまり、『メッセージは、サービスとコンシューマーにとって意味を持つ実際のデータに対するコンテナーである。』メッセージにはオペレーションは無いかも知れませんが、プロパティーや、他のクラス（恐らく何らかのドメイン・モデル）への関連付けは持っている場合があります。メッセージ・ステレオタイプは、想定するエンコード形式（例えば、SOAP-literal, SOAP-rpc, ASN.1など）を記述するプロパティーを持っています。

プロパティー

表2は、メッセージ・ステレオタイプのプロパティーのリストです。

制約

• 誰かが所有するオペレーションを持ってはならない
• 誰かが所有する振る舞いを持ってはならない

ステレオタイプ: メッセージ添付

拡張対象

プロパティー

意味体系

このステレオタイプは、『メッセージのうち、一部のコンポーネントは（メッセージ自体の直接的な部分ではなく）メッセージへの添付である』ということを表すために使われます。一般的に言って、上位レベルの設計作業では、このステレオタイプはあまり使わないはずですが、多くのプロセスにとって、添付されたデータと埋め込まれたメッセージ・データの区別は重要です。例えばカタログ・サービスは、製品についての一般的な詳細は構造化されたメッセージの一部として返しますが、画像はメッセージへの添付として返します。またこれによって、画像のエンコーディングは、（メッセージ本体のテキスト・エンコーディングとは異なり）バイナリーであると表すこともできます。

プロパティー

表3は、メッセージ添付ステレオタイプのプロパティーを表しています

制約

• <<Message>>というステレオタイプのクラスが所有するプロパティーに対してのみ使用できる

ステレオタイプ: サービス

拡張対象

ポート

意味体系

サービス・モデルの要素は、（webサービスの用語での）サービス対話動作でのエンドポイントとなりますが、こうした対話動作の定義はサービス仕様ステレオタイプの一部です。通常のモデルでは、サービスは提供されるインターフェースを指定するだけではなく、必要なインターフェース（コールバック・インターフェースなど）も指定します。サービスにはその他にも、使用されるバインディング（SOAP-HTTPやSOAP-JMSなど）を表すプロパティーがあります。

プロパティー

無し

制約

• <<Service Provider>>というステレオタイプのクラスに対してのみ使用できる
• <<Service Specification>>というステレオタイプのインターフェースによって型付けされる

ステレオタイプ: サービス・チャネル

拡張対象

コネクター

意味体系

チャネルは、『2つのサービス間のコミュニケーション・パス』を表します。対話動作はチャネル上で行われますが、チャネルは特定な対話動作を記述するわけではないことに注意することが重要です。Webサービスの世界では、各サービスは、（クライアントがアクセスできるように）そのサービスに関連するバインディングを記述しています。モデリング・プロファイルでは、バインディングを、サービス間のコミュニケーションに対して、あるいはサービスとコンシューマー間でのコミュニケーションに対して記述します。こうすることによって、バインディング要求を柔軟に理解することができます。

プロパティー

表4は、サービス・チャネル・ステレオタイプのプロパティーを表しています。

制約

• 『最低限の場合』でも、コネクターの一方の端は<<Serviceというステレオタイプのポートに接続される必要がある
• 『最大の場合でも』コネクターの一方の端は、<<Service Gateway>>というステレオタイプのポート、あるいは<<Service Provider>>というステレオタイプのクラス、あるいは<<Service Consumer>>というステレオタイプの分類子（classifier）に接続することができる

ステレオタイプ: サービス・コラボレーション

拡張対象

コラボレーション

意味体系

サービス・コラボレーションは、『サービスの実装を、他のサービスのコラボレーションとして規定するための方法』です。Webサービスの観点から見ると、これはサービス実装を規定する際のBPEL4WS（Business Process Execution Language for Web Services）の使い方に対応します。つまりこれは、サービス・コラボレーションを、サービスの『振る舞い』として使用することを意味しています。もしBPELのような言語の生成に使用する場合には、他にも実装特有の制約があるかも知れません。

プロパティー

無し

制約

• <<Service Provider>>というステレオタイプのクラスのみがコラボレーションに参加することができる

ステレオタイプ: サービス・コンシューマー

拡張対象

分類子（classifier）

意味体系

『いかなる分類子（クラス、コンポーネントなど）も、サービスのコンシューマーとして動作することができます。』そしてこの中には、他のサービスも含まれます。ほとんどの場合、このステレオタイプはオプションですが、あるモデルの要素（それ自体はサービスではないような要素）を、サービスの『クライアント』として指定するのに便利な場合があります。それ以外の場合には、単なるオーバーヘッドとして、使う必要のないものかも知れません。

プロパティー

無し

制約

無し

ステレオタイプ: サービス・ゲートウェイ

拡張対象

ポート

意味体系

サービス・ゲートウェイはサービスのように見えますが、『パーティションに対してのみ使用できる』ものであり、サービス・プロバイダーに対しては使用できません。ゲートウェイはプロキシー・サービスとして動作し、プロトコルの仲介や、パーティションに利用可能なインターフェースの記述に使用することができます。例えば、「パーティションの中では幾つかのサービスが実装されていますが、パーティション外で使用できるのは一部のみのため、こうしたサービスのためにゲートウェイが提供されます」というような記述をすることができます。これによって、他のサービスやパーティションが、ゲートウェイから公開されていないサービスとコミュニケーションすることを防ぐことができます。

プロパティー

無し

制約

• <<Service Partition>>というステレオタイプのクラスに対してのみ使用できる
• <<Service Specification>>というステレオタイプのインターフェースによって型付けされる

ステレオタイプ: サービス・パーティション

拡張対象

クラス

意味体系

パーティションは、『システムの、論理的あるいは物理的な境界』を表します。これはオプションですが、パーティションをモデル化する上で便利です。例えばwebやビジネス、伝統的なn階層アプリケーションのデータ層などを、パーティションを使って表現することができます。また、より物理的な境界（例えば、私のプライマリー・データ・センター、セカンダリー・サイト、顧客サイト、パートナーなど、）を、パーティションを使って記述することもできます。この場合、セキュリティーや許可されているプロトコル、帯域幅などの理由から、パーティションを横断することには特別な制約があるかも知れません。

パーティションは、（サービスであれ、他のパーティションであれ）ネストした部分を表すプロパティーしか持っていない場合があります。『これは制約である』ことに注意してください。つまり、現在このパーティションの中で表現されている要素は、他にないのかも知れません。

またパーティションには、「厳密である」という概念があります。あるパーティションが、他のパーティションとの間の全コミュニケーションは型付けされたゲートウェイを通して行う必要がある、と記述している場合には、『厳密なパーティション（strict partition）』と言われます。

プロパティー

無し

制約

• 誰かが所有するプロパティーを持ってはならない
• 誰かが所有するオペレーションを持ってはならない
• 誰かが所有する振る舞いを持ってはならない
• 誰かが所有する部分は、<<Service Provider>>というステレオタイプのクラスでなければならない

ステレオタイプ: サービス・プロバイダー

拡張対象

クラス

意味体系

サービス・プロバイダーは、『1つ以上のサービスを提供するソフトウェア要素』です。モデリング条件では、通常はここにUMLコンポーネントがあるはずです。しかし、そうした制限は任意なようです。そのため、より柔軟性を高めるために、メタクラスはクラスとして表現されます。サービス・プロバイダーには、その位置の情報をキャプチャーするためのプロパティーがあります（ただし、その意味については実装依存です）。サービス・プロバイダーとして動作するクラスは、直接には属性やオペレーションを公開しないかも知れません。つまりパブリック・ポートのみが（サービスとしてステレオタイプ化された）提供され、これらはサービス仕様によって型付けされます。

位置プロパティーは、実装あるいはプラットフォーム依存ですが、サービス・エンドポイントの名前を生成する上で便利です。例えば（WSDLでは）、位置はhttp://svc.myco.com/ であり、またサービスは『CustInfo』という名前だとしましょう。この場合、サービスに対するエンドポイント名は、http://svc.myco.com/CustInfoとして生成することができます。

プロパティー

表5は、サービス・プロバイダー・ステレオタイプのプロパティーを表しています。

制約

• 誰かが所有するプロパティーを持ってはならない
• 誰かが所有するオペレーションを持ってはならない
• 誰かが所有する振る舞いを持ってはならない
• 誰かが所有するポートは、<<Service >>というステレオタイプでなければならない

ステレオタイプ: サービス仕様

拡張対象

インターフェース

意味体系

インターフェースを使うということは、『サービスが提供する一連のオペレーションを記述する』ことです。サービスは1つ以上のインターフェースを実装する場合もあることに注意してください。慣例的に、ある仕様にプロトコル状態マシンやUML 2.0コラボレーションを添付することによって、サービス仕様に対するオペレーション呼び出しの順序を記述することができます。そうした振る舞い仕様を利用すると、任意の実装サービスの構造や振る舞いに関して、静的な仕様だけではなく動的な仕様の面から検証することができます。サービス仕様には公開オペレーションしかないこと、また各オペレーションが利用できるメッセージは最大でも1つ、生成できるメッセージは最大でも1つでなければならないことに注意してください。

プロパティー

表6は、サービス仕様ステレオタイプのプロパティーを表しています。

制約

• 誰かが所有するプロパティーを持ってはならない
• すべてのオペレーションはpublicとしてマーキングされなければならない
• <<Service>>あるいは<<Service Gateway>>というステレオタイプのポート用の型としてのみ利用できる

上に戻る

参考文献

• この記事はUML Profile for Software Services, RSA Plug-Inを基にしています。
  
  
• RUP for SOA Plug-In V1.0について調べてください。
  
  
• Rational Software Architectの評価版をTrials and betasページから入手してください。
  
  
• IBM Software Developer Platform homepageには、IBMのソフトウェア開発プラットフォーム全体に関する詳細な情報が用意されています。Rational Software Architectも、このプラットフォームの一部です。
  
  
• Rational製品に関する技術資料に関しては、Rational Developer Domainをご覧ください。技術資料やハウツー記事、教育資料、ダウンロード、製品情報など、豊富な資料が用意されています。特にRational Software Architectに関する情報については、RSA technical resources pageをご覧ください。
  
  
• IBM Rational marketing pagesには、さらに製品関連の情報が用意されています。
  
  
• developerWorks blogsを通してthe developerWorksコミュニティーに参加してください。
  
  
• UML 2.0に関する詳しい情報は、UML Resource Centerを見てください。
  
  
• Rational Software Architectに関する質問には、Rational Software Architect, Software Modeler, Application Developer and Web Developer forumをご利用ください。
  
  
• この記事で取り上げた話題や、その他の話題に関する様々な技術書をご覧ください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ソフトウェア・サービスのためのUMLプロファイルの概要
• プロファイル自体
• 参考文献
• 著者について
• コメント