はじめに

SOA (Service-Oriented Architectures) および Web サービスの基本概念は、私たちの日常の言語の一部分となりつつあり、現代のエンタープライズ・アプリケーションの構築に適切なアーキテクチャー・スタイルとして認識されています。このような状況においては、良いサービスとは何かという基本的な論点が、SOA の実装を確実に成功させるためにますます重要になってきています。

OOAD (Object-Oriented Analysis and Design)、EA (エンタープライズ・アーキテクチャー) フレームワーク、そして BPM (ビジネス・プロセス・モデリング) などの既存のモデリング手法は、アーキテクチャー内の適切な抽象化の識別と定義に役立つ高品質の方法を提供してくれます。ただし経験上、それぞれを独立して適用すると、これらの事例では十分でないことが分かっています。

この記事では、OOAD、EA、および BPM から使用できる適切な要素を検討します。また、すべての手法の要素を多数の独特な新しい要素と組み合わせるハイブリッド手法の必要性も説明します。私たちが SOAD (Service-Oriented Analysis and Design) と呼ぶ、SOA デプロイメントを簡単に行うことができる総合的 OOAD 方法はまだ正式に定義されていません。この記事は、単に SOAD の世界に最初の一歩をちょっとだけ踏み出すしてみます。

上に戻る

サービス指向のコンセプト

SOA アーキテクチャー・スタイルは、ビジネスの新しい機会または脅威が発見されることを予想して、オンデマンドで拡張または変更が可能なエンタープライズ・ビジネス・ソリューションを提供することを目的としています。SOA ソリューションは再使用可能なサービスで構成され、特定の公開された標準準拠インターフェースを備えています。SOA は、プラットフォームや言語を問わずに既存のレガシー・アプリケーションを統合するメカニズムとなります。

概念上では、SOA 内の抽象化には次の 3 つの主要なレベルがあります。

• 操作: 単一の論理作業単位 (LUW) を表すトランザクションです。通常、操作を実行することによって １ つ以上の永続データ・レコードの読み取り、書き込み、または変更が行われます。SOA 操作はオブジェクト指向 (OO) メソッドに相当します。操作には特定の構造化インターフェースがあり、構造化された応答を戻します。メソッドに関してのみ言えば、特定の操作の実行には追加操作の呼び出しが必要になる場合があります。
• サービス: 操作の論理グループ化を表します。例えば、CustomerProfiling をサービスとして考えると、電話番号によるカスタマーの検索、名前と郵便番号別のカスタマーのリスト、新規カスタマーのデータ保管は関連する操作を表しています。
• ビジネス・プロセス: 特定のビジネス目標に向けて長期にわたって実行される一連のアクションまたは活動です。ビジネス・プロセスには通常、複数のサービス呼び出しが含まれます。ビジネス・プロセスの例には、新規従業員の雇用、製品またはサービスの販売、注文の履行などがあります。

  SOA の用語では、おけるビジネス・プロセスは、一連のビジネス・ルールに従って決められた順序で実行される一連の操作で構成されています。操作の順序付け、選択、および実行は、サービスまたはプロセスのコレオグラフィーと呼ばれます。一般的には、コレオグラフィーで計画されたサービスが呼び出されてビジネス・イベントに対応します。

モデリングの観点から見ると、ここで難問となるのは、どのようにして優れた設計の操作、サービス、およびプロセスの抽象化を体系的に特徴づけ、構成できるかということです。これに関連する課題は、産業と学究的な世界で最も頻繁に取り上げられています。そのようなサービス・モデリングの点が主要な話題とならず、数々の議論も巻き起こらないような SOA プロジェクトやワークショップは、最近見たことはありません。それでは、詳細を検討してみましょう。

上に戻る

BPM、EA、および OOAD では十分ではない理由

初期の SOA 実装プロジェクトの経験から、OOAD、EA、そして BPM などの既存の開発プロセスと表記は、SOA パラダイムをサポートするために必要な要件を一部しかカバーしていないことがわかっています。SOA 手法は、情報隠蔽、モジュール化、コンサーンの分離などの確立された一般ソフトウェア・アーキテクチャーの原則を強化するとともに、サービス・コレオグラフィー、サービス・リポジトリー、サービス・バス・ミドルウェア・パターンなどのテーマも追加します。モデル化の際には、これらのテーマにもしっかり注意を向けなければなりません。

図 1 に、既存の EA、BPM、OOAD の各モデリング手法の主要なアプリケーション分野の位置付けを示します。この図は、これから SOAD を討議する上で適切な出発点となります。図中の横軸はプロジェクト・ライフサイクルのフェーズで、縦軸は、通常モデリング作業が行われる抽象化またはドメインの各レベルの違いを示しています。

SOA の技術基盤はよく知られているため、その考え方を把握するのはそれほど難しくはありません。例えば、どんな SOA への取り組みでも、一般ソフトウェア・アーキテクチャーの原則と OO 手法を適用することから開始できます。ただし前にも言ったように、初期の適用者たちから最も頻繁に質問されたのは、正しいサービスを見分ける方法です。OOAD、EA、BPM をそれぞれ個別に適用しても、満足した答えを引き出すことはできません。その理由について、これから説明していきます。

Booch と Jacobson による権威ある著書 (10 年前に発行) のなかで紹介された OOAD方法は、SOA を定義する際に絶好の足掛かりとなります。OOAD 自体は、クラスや個別オブジェクトのインスタンスなどのマイクロ・レベルの抽象化を対象としていますが、長年の間、OOAD 手法と UML (Unified Modeling Language) 表記をアーキテクチャー・レベルに適用するのが一般的な方法となっています。スタンドアロンのユースケース・モデルを問題のドメインごとに、そして結果的にはアプリケーション開発プロジェクトごとに作成するにつれ、ほとんどの場合、エンタープライズの全体像はぼやけてしまいます。さらに、さまざまな理由から、ユースケース・モデルは必ずしも、BPM の対応する部分と同期するわけではないからです。

TEAF (Treasury Enterprise Architecture Framework) 、 FODA (Feature-Oriented Domain Analysis) 、 Zachman などの EA 手法は、ソリューション・アーキテクチャーの最上部に都市計画の観点を盛り込みますが、エンタープライズ全体で再使用と存続性を向上させる高品質の抽象化を見つける方法には対処しません。

BPMI などの BPM 手法は機能作業単位でエンドツーエンドの見解を提供しますが、アーキテクチャーや実装ドメインにまで至ることはめったにありません。その例として、BPEL (Business Process Execution Language for Web Services) などの言語が登場するまでは、BMP 表記には操作的セマンティクスが欠けていました。さらに、プロセスのモデリングと開発イニシアシブが互いに独立している事例を数多く目にしてきました。

結論として、既存の手法はどれ 1 つとして、既存のアプリケーションで SOA を有効にする方法には対処していないため、ほとんどの場合はトップダウン・プロセスが採用されています。既存のシステムには通常、大量の重要データとビジネス・ロジックがあるため、単純に置き換えることはできません。従って、このようなシステムでは、ラッピングおよびリファクタリング・ストラテジーを調査するには、ボトムアップ分析を行う必要があります。既存のアプリケーションを考慮すると、meet-in-the-middle プロセスという結果になります。

ハイブリッド SOAD モデリング手法が必要となるのは、以上の理由からです。この手法は、OOAD、BPM、および EA からの要素を最善の方法で組み合わせ、さらに特定の革新的要素で補完します。 図 2 に、この新しい手法のための SOAD のアセット (要素および手法) を示します。

EA

エンタープライズ・アプリケーションおよび IT インフラストラクチャーの SOA への展開は、複数のビジネス単位と組織単位に影響する大事業となることがあります。このため、個別ソリューション間でアーキテクチャーの一貫性を保つためには、EA フレームワーク、そして TOGAF (The Open Group Architecture Framework) および Zachman などの参照アーキテクチャーを適用する必要があります。

過去の経験によると、大部分の既存の EA フレームワークには 1 つ以上の分野で制約事項があります。例えば、第一の関心事が下位ビルディング・ブロック (技術デバイス) をマクロ・レベルで相互接続させる方法だとしたら、ビジネス・レベルのプロセスやサービスの概観を得ることはできません。一方 SOA コンテキストでは、このような考え方を論理ビルディング・ブロック (ビジネス・サービス) を中心とした考え方に変え、サービス間のインターフェースとサービス・レベル・アグリーメント (SLA) の定義に集中する必要があります。

さらに、多くのエンタープライズ・レベルの参照アーキテクチャーとフレームワークはむしろ一般的なもので、設計ドメインにまでは及びません。そのような高位レベルのアーキテクチャーでは、ソリューション・アーキテクトや開発者に具体的で戦術的なアドバイスを与えることはできないため、結果として、エンタープライズ・アーキテクチャーとソリューション・アーキテクチャーの間に根本的なギャップが生まれることは珍しくありません。

SOAD は、SOA アーキテクトが全体論的ビジネス・レベルでサービスの全体像を定義できるように支援する必要があります。これは、今日の EA フレームワークでは、将来の SOA 固有の拡張なしでは達成できないことです。 ODOE (On Demand Operating Environment) は、その方向に向けた主要な IBM イニシアチブです。

BPM

BPM はフラグメント化された手法で、多種多様なスタイル、表記、アセットが含まれます。例えば、UML はアプリケーション・ドメインから BPM レベルまで共通して使用されます。頻繁に使用されるもう 1つの手法は、 Barker と Longman が定義しているように、概念的なプロセス・フローを表すイベント駆動型プロセス・チェーンを定義することです。この 2 番目の手法では、UML 以外の表記を使用します。

さらに、コンサルティング会社や ERP (Enterprise Resource Planning) パッケージ・ベンダーにとっては競争上、優位になる可能性のある、BPM 手法などの専有アプローチも多数あります。ARIS Implementation Platform ® は、そのようなオファリングの一例です。その他の手法には、LOVEM ™ (Line of Visibility Enterprise Modeling)、IBM の CBM (Component Business Modeling) イニシアチブなどがあります。

最近は、実行可能フロー・モデルを表す標準方法を定義する傾向があり、その一例として BPEL (Business Process Execution Language for Web Services) があります。BPEL はプロセス・モデルの範囲を分析から実装まで広げます。そのような拡張可能モデルによって、以下をはじめとする新しい疑問が生まれています。

• BPEL と WSDL にはそれぞれ、どの側面を記述すればいいのか。プロセス・モデルと従来のプログラミング・モデルはどこで分けられるのか。
• 機能性以外の要件とサービス品質特性などの側面をモデルに組み込むにはどうしたらいいのか。
• J2EE などの従来のコーディングに対して、BPEL エンジンのプログラミング言語拡張で実行されるロジックの量はどれくらいか。
• 実行可能プロセス・モデルの品質の評価方法、そして適用するベスト・プラクティスは何か。
• BPEL フローの設計は、ビジネス・エキスパート (アナリスト) と開発者 (ソフトウェア・アーキテクト) のどちらのジョブ役割が実行するのか。

既存のすべての BPM 手法は SOAD の開始点として利用できますが、これらの手法にはプロセス・モデルから候補サービスとその操作を導くための別の手法を追加しなければなりません。さらに、SOAD でのプロセス・モデリングは設計レベルのユースケース・モデリングと同期させて、BPEL 関連の質問に対する答えを出す必要があります。

OO 対サービス指向 (SO) のパラダイム

OO 分析は非常に強力で実績のある手法なので、SOAD では OO 分析手法をできる限り利用する必要があります。OO 分析を SOA プロジェクトにうまく適用するには、一度に複数のシステムを検討しなければなりません。ユースケース・モデルは引き続き重要な役割を果たします。ただし、SOAD はユースケース駆動型ではなく、第一にプロセスでなければなりません。そのため、SOAD には BMP とユースケース・モデリング作業との間の強力なリンクが必要となります。

設計レベルでの OO の目標は、柔軟かつ拡張可能なアプリケーションを素早く効率的に設計、開発、実行することです。オブジェクトは、モデリング対象の実世界のエンティティーのように動作するソフトウェア構成です。例えば、カスタマー・オブジェクトには名前、連絡情報があり、場合によっては 1 つ以上のアカウント・オブジェクトが関連付けられます。OO の視点から見ると、すべてがオブジェクトになります。

OO の基本原則は、以下のとおりです。

• カプセル化: ソフトウェア・オブジェクトは、物理プロパティー (データ) と、実世界の対象物を模倣する機能 (動作) の両方が含まれる個別のパッケージです。例えば、アカウント・オブジェクトには残高が保持され、その残高に対する預金/引き落としのメカニズムが含まれます。
• 情報隠蔽: よく構成されたオブジェクトは単純なインターフェースを持ち、その内部メカニズムを外部に見せることはしません。自動車がどのように機能するかを詳しく知らなくても、自動車を運転することはできます。これが、実世界での情報隠蔽の一例です。
• クラスおよびインスタンス: クラスは、特定タイプのソフトウェア・オブジェクトが持つプロパティーと動作の種類を定義するテンプレートで、インスタンスはこれらのプロパティーの値を持つ個別のオブジェクトです。クラスの新しいインスタンスを作成することをインスタンス化と言います。生物学的に例えると、人間は 1 つのクラスです。すべての人間は、身長、体重、髪と目の色などのプロパティーを持っています。個々の人間は、HumanBeing というクラスのインスタンスであり、このインスタンスには身長、体重などの特定の値があります。クラスは永続する一方、インスタンスの寿命は限られています。
• 関連と継承: OO の重要なコンセプトは、クラスとオブジェクト間の関連を表現可能であるということです。継承は、1 対多の関連を表現するために使用する強力な形式です。生物学的種が、界、門、類、目、属、種に構造化されるのと同じように、ソフトウェア・オブジェクトにも自然な階層が見られることがよくあります。例えば、Entities という財務アプリケーションを作成する場合、CheckingAccount、SavingsAccount、LoanAccount などのクラスを構成することになるはずです。もう少し詳しく見てみると ( 図 3 を参照)、これらのクラスには、残高を持っている、預金/引き落としができるなど、多くの共有プロパティーがあります。
  図 3. UML のクラス継承の例
  
  これらのプロパティーを定義および管理するコードを複製するのではなく、現金残高を持つ共通の Account 親クラスを作成して、預金と引き落としのトランザクションを処理することができます。その他すべてのクラスは、この Account オブジェクトの特殊な形式です。例えば、LoanAccount にはゼロから最大値として合意された値のマイナス残高が含まれます。SavingsAccount にはプラス残高が含まれ、利子の加算などの動作を行います。
• メッセージング: 有益な作業を行うには、ソフトウェア・オブジェクト同士が通信可能でなければなりません。この通信は、互いにメッセージを送信することによって行います。例えば、当座預金から普通預金に 1000 ドルを移すには、引数が $100 の引き落としメッセージを CheckingAccount インスタンスに送信し、対応する預金メッセージを SavingsAccount インスタンスに送信します。インスタンスがメッセージを受け取ると、対応する関数を実行します。この関数はメソッドと呼ばれ、メッセージと同じ名前を持ちます。
• ポリモーフィズム: この用語は、2 つ以上のクラスが同じメッセージを受け入れ、それぞれのクラスが異なる方法で実装するという状況を意味します。例えば、 FreeCheckingAccount インスタンスと CheckingAccount インスタンスはどちらも debit($100) メッセージに応答しますが、FreeCheckingAccount インスタンスは口座残高から 100 ドルちょうどを引き落とすのに対し、CheckingAccount インスタンスは取引手数料 100 ドルを加算した額を引き落とします。

OO は、アプリケーションの分析、設計、および開発のライフ・サイクル全体をサポートします。

• OOAD は、最適なオブジェクトのセットと、このセットを実装する最も自然なクラス階層を検索します。
• OO 開発は、アプリケーションの増分開発に焦点を絞り、一度に 1 つのビジネス・シナリオまたはユースケースを実装します。IBM WebSphere ® Studio Application Developer などのツールによって、開発者は OO アプリケーションを素早く構築してテストすることができます。
• Java ™ Virtual Machine などによって提供される OO ランタイム環境は、異なるサーバーに常駐するオブジェクトが相互通信するためのメカニズムを提供する J2EE などのフレームワークとともにコードを実行して、ガーベッジ・コレクション (オブジェクトが廃棄されると、そのオブジェクトが使用していたリソースを除去する) などのアプリケーション・サービスを提供します。

SO から見た現在の OO 設計方法の主な問題は、その粒度がクラス・レベルに重点を置いているという点です。クラス・レベルは、ビジネス・サービス・モデリングの抽象化レベルとしては低すぎます。継承などの強力な関連は、関連する対象の間にむしろ密結合 (結果的には従属関係) を作り出します。一方、SO パラダイムは疎結合によって柔軟性と敏しょう性を向上させようとします。サービス・ライフ・サイクルのハウスキーピング問題 (リモート・ガーベッジ・コレクションなど) に対処する必要をなくすため、SOA には今のところ、プラットフォーム間の継承サポートやサービス・インスタンスの第 1 級の概念はありません。

このような考慮事項が、OO を SO アーキテクチャー・スタイルにそのまま一致させることを難しくしている要因です。それでも、定義されたサービス内で基本クラスとコンポーネント構造を設計するには OO が貴重な手法となることには変わりありません。さらに、抽象化のレベルが高くなれば、クラス、責務、およびコラボレーション (CRC) カードなどの多くの OOAD 技法をサービス・モデリングに利用することができます。この点については、後で説明します。

図 4 に、OO 設計、コンポーネント指向設計、および SO 設計による可視性レベルと焦点レベルの対応を示します。この図では、SOA と SOAD のコンテキスト内でのそれぞれの設計の関係も示しています。

表記については、いくつかのステレオタイプとプロファイルを追加して拡張された UML (Unified Modeling Language) が必然的に SOAD の主要な要素となります。

Rational Unified Process ® (この RUP は、繰り返されるソフトウェア開発の分析と設計をサポートする主要な OOAD プロセスの 1 つとして認められています) を使用するプロセス・エリアで第一の価値があるのは、UML モデルの利用です。ただし、RUP はその基礎が OOAD の原則に基づいているため、SOA 設計に簡単に結びつけることはできません。RUP の観点からは、システムのアーキテクチャーは、定義されたインターフェースで相互作用する主要コンポーネントの構造としてとらえられます。さらに、これらのコンポーネントの構成要素は、クラス・レベルまで細分化するにつれ、ますます小さなコンポーネントになります。逆に、SOA でのシステム・アーキテクチャーは通常、ステートレスで完全にカプセル化された自己記述型のサービスで構成され、これらのサービスは BMP に密接にマップされた汎用ビジネス・サービスに応じます。 図 5 を参照してください。

これらのサービスは、多数の連携サービスや組織化されたサービスで構成される場合があります。これによって、RUP が導入する OO の観点が排除されることはありませんが、別の抽象化層がサービス階層の最上部に実装されます。このスーパー層は、RUP 成果物 (ソフトウェア・サービス) として設計されたコンポーネントを正式な層間インターフェース構造内にカプセル化するためのものです。

上に戻る

SOAD の要素

このセクションでは、SOAD の要件を詳細に検討し、そのテーマと要素を定義します。目的は、このトピックについての議論を、さらなる設計作業に発展させることです。SOAD 手法を正式化するためには、明らかに今後の作業が必要です。

SOAD の要件

SOAD の要件として、以下が特定されています。

• プロセスと表記は、その他すべてのプロジェクトや設計方法と同じく、正式に (あるいは少なくても準正式に) 定義される必要があります。SOAD はゼロから始める必要はありません。OOAD、BPM、EA 要素を選択して組み合わせ、必要に応じて追加要素を定義することができます。
• サービスを概念化するための構造化された方法がなければなりません。
  • OOAD がアプリケーション・レベルでクラスとオブジェクトを提供する一方、BPM にはイベント駆動型プロセス・モデルがあります。SOAD には、これらを結合するという課題があります。
  • メソッドはユースケース指向ではなくなり、ビジネス・イベントとプロセスによって駆動されます。ユースケース・モデリングは、下位レベルでの 2 番目のステップとなります。
  • メソッドには、構文、セマンティクス、およびポリシーが含まれます。これは、臨機応変な構成、セマンティック・ブローカリング、ランタイム・ディスカバリーに必要です。
• SOAD は、明確に定義された品質要因およびベスト・プラクティス (粒度に関する疑問への回答など) を提供しなければなりません。また、BPEL によって持ち上がった役割についての疑問が解決されなければなりません。例えば、作業のどの部分を開発者、アーキテクト、アナリストの誰が行うかなどという疑問です。
• SOAD 活動も、良いサービスでないものは何かという疑問に答える必要があります。例えば、再使用可能でない、あるいは再使用できそうにないものは、第一級の SOA 要素 (つまり、サービス) にはなりません。もう 1 つの例は、XML の処理オーバーヘッドを許容できない、厳しい非機能的要件を持つリアルタイムの組み込みシステムです。
• SOAD はエンドツーエンドのモデリングを容易にし、包括的なツール・サポートを備える必要があります。SOA がビジネスに柔軟性と敏しょう性を与えることが期待されている場合、ビジネスからアーキテクチャーおよびアプリケーション設計ドメインに至るまで、同じことがサポートするメソッドにも期待されます、

品質要因

いくつかの一般的な原則または品質要因はすでに特定可能で、SOAD 内で設計のベースラインとして機能します。

• 優れた設計のサービスは、ビジネスに柔軟性と敏しょう性を与えます。これによって、疎結合、カプセル化、そして情報隠蔽による再構成と再使用がさらに容易になります。
• 優れた設計のサービスは有意義で、エンタープライズ・アプリケーションに限らず適用できます。つまり、サービス間の従属関係は最小限に抑えられ、明確に規定されています。
• サービスの抽象化は、一体性があり完全かつ一貫したものです。例えば、サービスとその操作シグニチャーを設計する際の作成、読み取り、更新、削除、および検索 (CRUDS) メタファーが考えられます。
• よく規定される前提の 1 つは、サービスはステートレス (会話型ではないなど) であるということです。この記述は、特定の問題ドメインとコンテキストでは、サービスをできる限りステートレスにするという記述に弱められる場合があります。
• サービス命名は、詳細な技術的専門知識がなくても、ドメイン・エキスパートには理解できます。
• SOA では、すべてのサービスは (パターンとテンプレートによって明確にされた) 同じ設計理念と対話パターンに従います。基礎となるアーキテクチャー・スタイルは、簡単に識別できます (アーキテクチャーの検討中など)。
• サービスおよびサービス・コンシューマーの開発に必要なのは、基本的なプログラミング言語のスキルとドメインに関する知識だけです。ミドルウェアの専門知識は、理想的な世界のツール・ベンダーやランタイム・ベンダーで働いている少数の専門家にのみ必要で、エンタープライズ・アプリケーションを SOA として作成している会社には必要ありません。

サービスの識別と定義

CBM などのトップダウンのビジネス・レベル・モデリング手法は、SOA モデリング作業の第一歩として使用できます。ただし、すでに述べたように、SOA 実装は何もないところから開始することはめったにありません。SOA ソリューションの作成には必ずと言っていいほど、既存のレガシー・システムをサービス、操作、ビジネス・プロセス、そしてビジネス・ルールに分解して統合するという作業が伴います ( 図 6 を参照)。

• 既存のアプリケーションとベンダー・パッケージは、関連操作のグループを表す個別サービスのセットに分解されます (ボトムアップ手法)。
• ビジネス・プロセスとルールは、アプリケーションから個別の BMP に抽象化され、ビジネス・コレオグラフィー・モデルによって管理されます。

すべての OOAD 手法は、サービスの識別と定義に関連付けて適用することができますが、より高い視野を持つ必要があります。さらに、SOA が目標とするものは従来の開発プロジェクトを超えているため、独創的な考え方を加える余地があります。

直接ビジネス分析と間接ビジネス分析
投資家インタビューと CBM による BPM および直接的要件の分析は、候補サービスを識別する方法として疑う余地なく最適です。

過去の経験から、補足的かつ間接的な手法によって、この本道を修正しなければならないことが分かっています。候補サービスを探し出す際には、例えば計画されている支払いモデルと請求モデルは何かなど、プロダクト・マネージャーとその他のビジネス・リーダーにインタビューする必要があります。作成中のシステムを使用する予定の企業の組織図も検討しなければなりません。SOA 以外のプロジェクトでの既存のユースケース・モデルも同じく検討する必要があります。作成中のシステムのマーケティング・プレゼンテーションで使用する用語もまた、サービス操作の候補に関する優れた情報源になります (対象はマーケティングの副詞ではなく、特に動詞)。

ドメインの分解
Endrei が定義するドメインの分解、サブシステムの分析、目標モデルの作成、そして関連する手法は、 Levi および Arsanjani の初期の研究において構築された SOA プロセスの構成方法またはサービス概念化フレームワークに対して出された初めての有望な提案です。 SEI の FODA 研究も、この議論に貢献しています。

サービスの粒度
正しい抽象化レベルの選択は、サービス・モデリングの重要な課題です。粒度を荒くしてモデリングするようにというアドバスをよく耳にすることでしょう。これは少々、単純化しすぎです。このアドバイスは、関連性、一貫性、そして完全性を損なったり妥協したりすることなしに、できるだけ粒度を荒くするという言い方に変えなければなりません。ビジネスのニーズがあるという前提のもと、SOA ではサービス抽象化をきめ細かくする余裕があります。SAO は Web サービスと SOAP を同等にしないため、さまざまなプロトコル・バインディングを使用して、異なる抽象化レベルに存在するサービスにアクセスできます。もう 1 つのオプションは、関連サービスを荒削りなサービス定義にバンドルすることで、これは、ファサード・パターンのバリエーションとなります。

命名規則
エンタープライズ全体の命名スキーマ (XML 名前空間、Java パッケージ名、インターネット・ドメイン) を定義する必要があります。単純な例は、サービスには常に名詞を割り当て、その操作には常に動詞を割り当てるように推奨することです。このベスト・プラクティスは、OOAD 空間に由来します。

最初の純粋な SOAD 要素

OOAD、BPM、EA 手法の組み合わせに加え、まだ具体化されていない以下の重要な SOAD の概念と側面があります。

• サービスのカテゴリー化と集約
• ポリシーおよびアスペクト
• Meet-in-the-middle プロセス
• セマンティック・ブローカリング
• サービス獲得と知識ブローカリング

サービスのカテゴリー化と集約
サービスにはさまざまな使用方法と目的があります。例えば、ソフトウェア・サービスはビジネス・サービスとは区別できます ( 図 5 を参照)。さらに、アトミック・サービスを高位レベルの本格的サービスに編成 (作成) することもできます。

サービス作成は、実行可能モデル (BPEL モデルなど) によって単純化されます。これは、従来のモデリング・ツールやメソッドでは対処していません。

ポリシーおよびアスペクト
サービスには構文、セマンティックス、および QoS 特性があり、これらはすべてモデル化されなければなりません。正式なインターフェース契約によって、WSDL (Web Services Description Language) が行う以上のことをカバーする必要があります。その結果、 WS-Policy フレームワーク が重要な関連仕様となります。

定着したアーキテクチャー 追跡可能性の原則に加えて望ましい品質は、ビジネス追跡可能性です。つまり、すべてのランタイム成果物を、専門的なドメイン・エキスパートでなくても理解できる言語に直接結合することが可能でなければなりません。これは特に、ビジネス層およびサービス層で直接公開される抽象化層に重要です。SOX (Sarbanes-Oxley) 法は、このようなビジネス追跡可能性を必要とするビジネス・ドライバーの場合の例です。

プロセス: Meet-in-the-middle
常にレガシー・アプリケーション (既存のアプリケーションの同義語) を考慮する必要があるため、実世界では未開発のプロジェクトというものは存在しません。そのため、純粋なトップダウン・プロセスやボトムアップ・プロセスではなく、meet-in-the-middle 手法が必要となります。

設計が現在または今後のビジネスのニーズではなく、既存の IT 環境に基づいている場合、ボトムアップ手法ではビジネスとサービス間の抽象化が不十分になりがちです。一方、トップダウンによる処理では、要件の特性が不十分で機能しない場合があり、別のアーキテクチャーの品質要因が犠牲にされる (ドメイン・モデルでの正規化が欠けていることによるパフォーマンス問題など) とともに、サービスとコンポーネント層でインピーダンスの不一致が発生する可能性があります。

セマンティック・ブローカリング
いずれの SOA コンテキストでも、呼び出し構文の正式なインターフェース契約が重要です。セマンティクス問題 (パラメーターの意味など) も解決されなければなりません (ドメイン・モデリング)。これは、ビジネス間 (B2B) の動的呼び出しシナリオでの鍵となります。合併および買収、ビジネスの転換、グローバリゼーションなどの世界で、SOA の考え方が新しいビジネス・ニーズに柔軟かつ敏しょうに対応するには、動的呼び出しシナリオが不可欠です。

サービス獲得と知識ブローカリング
知識管理とライフ・サイクルの問題は、サービスを準備し、概念化してから再使用できるようにする確実な方法は何かという点です。

SOA を左右する主要な基準の 1 つであることを踏まえた上でサービスを識別し、再使用 (および獲得) できるように定義する必要があります。あるコンポーネント (つまりサービス) に再使用の可能性がないとしたら、そのコンポーネントはおそらくサービスとしてデプロイされません。エンタープライズ・アーキテクチャーに関連する他のサービスには接続できますが、それ自体がサービスになることはありません。

最初から再使用が計画されているとしても、プロセスでサービス獲得プロセスが定式化されなければならないことには変わりありません。複数のカスタマーによるサービスの使用は、明白な SOA 設計の目標です。ビルド時のサービス・レジストリーを例にあげると、エンタープライズ全体の UDDI ディレクトリーをその答えの一部にできます。

上に戻る

例: 自動車作業発注

自動車作業発注のドメインは、自動車整備会社がカスタマー業務を管理するプロセスを説明します。このドメイン問題を用いて、SOAD の課題を説明しましょう。

作業の発注とは、50,000 マイル毎の定期点検、ブレーキ・パッドやタイヤの交換、またはオイル交換など、定期点検あるいは緊急の修理作業を実行する際の自動車整備会社とカスタマーとの間の合意を表します。

ビジネス・シナリオ ( 図 7 を参照) は以下のとおりです。

• カスタマーが電話で予約した時点で、発注書が作成されます。
• 定期点検作業または修理作業ごとに、予測される部品の使用量、補給品、人件費の明細をはじめとする個別の作業発注項目が作成されます。
• 予約をスケジュールに入れる前に在庫が点検され、すべての必要な部品が揃っていることが確認されます。
• 設備が揃った修理工場と適切な資格のある整備士が、それぞれの発注項目ごとに予約されます。
• 合計見積額が計算され、カスタマーが予約に同意するか、あるいはシナリオが終了して発注がキャンセルされます。
• 予約時間の直前に、必要な部品、補給品、工具、機材が選択された工場に集められます。
• カスタマーが到着すると、計画された作業が行われます。自動車の点検時に他にも必要な作業が明らかになった場合は、その作業も行われます。
• 使用された部品と補給品の実際の価格と人件費が記録されます。
• すべての整備が完了した時点で、合計金額が計算されます。
• 請求書が作成され、カスタマーに提示されます。

これをスタンドアロンのアプリケーションとして一から作成するとなると、 図 8 に示すようなクラスのセットを作成することになります。

作業発注を OO アプリケーションとして作成した場合は、ソフトウェア・オブジェクトには必要なすべてのビジネス・ルールが含まれることになるため、オブジェクトは、それが従う必要のあるビジネス・プロセスを把握します。

ただし、この手法には以下のような実際的な欠点があります。

• ステップの多くは、請求書作成システム、スケジュール作成システム、在庫管理システムなど、既存のレガシー・システムおよびデータベースとの対話が必要ですが、これらのシステムはおそらく、OO パラダイムに従って設計されていません (そのような場合は、アダプターまたはメディエーター・パターンを適用すると役立ちます)。
• システムをできる限り柔軟にするには、規則のいくつかを外部化して、コードを変更せずにプロセスまたはワークフローを変更できるようにします。例えば、以下のような規則です。
  • 標準の 24,000 マイル点検には、4 リットルのオイルが含まれる。オイルの追加料金は、4 リットルを超えたオイルが使用された場合、またはカスタマーがプレミアム・グレードのオイル (合成潤滑油など) を要求した場合にのみ発生する。
  • レガシー・アプリケーションで使用可能な共通の自動車整備作業には、一連の業界規準の人件費見積りがある。整備士がその見積りの X% を超え、その違いに対する正当な理由を報告した場合を除き、カスタマーには標準人件費を請求する。
  • 見積額が Y% を超えた場合、確認のためにカスタマーに連絡する。

SOAD は上記の課題に、優れたソリューションを提供します。SOAD では、サービスをカプセル化 (動作とデータ) するのではなく、関連する動作に基づいてグループ化するため、サービスのセットはビジネス・オブジェクト・モデルとは微妙に異なります。

例えば、Work Order と Work Order Item をまとめて Work Order Services にグループ化し、Scheduling、Catalog、および Inventory サービスを作成します。また、サービス・インスタンスはないため、サービス間の関係に相当するものはありません。発注のサービス・モデルは、 図 9 のようになります。

OO パラダイムとは異なり、このモデルは機能的なシステムを表していません。このモデルにはフローの観念も、ビジネス・イベントやビジネス・ルールの記述もありません。SOA パラダイムでは、サービスの外部で維持されるビジネス・プロセス・コレオグラフィーが、サービス呼び出しのシーケンスと実行タイミングを決定するからです。

概念上では、最初のカスタマーからの連絡から、作業および請求書の支払いが完了するまでのビジネス全体は、数日から数週間の存続時間を持つ単一のマクロ・レベルの作業単位として表されます。つまり、ビジネス上の観点からすると、この作業単位が収益を生み出します。

ただし実際に発生するのは、比較的長い非活動期間の合間の一連の集中的な作業です (例えば、作業の定義、予定のスケジューリング、部品と補給品の選択、そして整備作業)。ITシステムでは、数分以上継続する実際のプロセスはありません。そのため、このビジネス・プロセスの状態は、イベントとイベントの間にデータとしてデータベースに存続します。

このようなタイプのプロセスは、状態遷移モデル (UML などで使用可能) で明確に表すことができます。 図 10 に、有限状態マシンの手法を用いてビジネス・フローをモデル化する例を示します。この図では、ビジネス・プロセスの進行に従って作業発注の状態がどのように変化するかの概要を示しています。

ビジネス・プロセス・コレオグラフィーは、状態間の 3 つの遷移に重点を置いています。個別の操作は、関連する状態変更を永続的に記録します。

図 11 は、 図 10 のステップ 1 から 5 までのビジネス・シナリオを抜粋したコレオグラフィーの例です。ここでは、カスタマーが自動車に必要な作業を定義し、作業の実行日を計画しています。

上に戻る

まとめ

この記事では、ビジネスと IT の溝を埋め、SOA プロジェクトの分析設計フェーズをサポートする革新的な meet-in-the-middle 手法の必要性について説明しました。ここで提案した新しい総合的 SOAD 手法は、今日実績のある OOAD、EA、および BPM を基礎の上に構築された、全体論的モデリング手法となります。

SOAD の表記とプロセスはまだ詳細に定義されていませんが、サービスの概念化 (または識別)、サービスの分類と集約、ポリシーとアスペクト、meet-in-the-middle プロセス、セマンティック・ブローカリング、そしてサービス獲得 (再使用のための) はすでに識別可能です。

SOAD では、既存のソフトウェア設計工学による方法を拡張して、エンタープライズ・アプリケーション開発プロジェクトに対する有用性と適用性をさらに改善する必要があります。関連するベスト・プラクティスとパターンは時間とともに進化します。

UML は、プロセス側で選択される表記として依然優勢を保つと認められていますが、SOAD の幅広い適用範囲を満たすには、拡張が必要になるはずです。

SOAD の方法を完成させるための次のステップは、必要なエンドツーエンド・プロセスと表記を定義し、関与と責任における必要な役割を検討し、そして、提案された手法の有効性をプロジェクトで確認することです。

参考文献

• IEEE Xplore サイトにアクセスして、Ali Arsanjani の「 A Domain-Language Approach to Designing Dynamic Enterprise Component based Architectures to Support Business Services 」を購入してください。
  
  
• Amazon.com で Barker and Longman 共著「 CASE Method - Function and Process Modeling 」を購入してください。
  
  
• Addison Wesley サイトで Grady Booch 著「 Object-Oriented Analysis and Design with Applications 」を入手してください。
  
  
• BPMI.org で BPMI (Business Process Management Initiative) を調べてください。
  
  
• 「 Web サービスの将来を拡げるサービス指向アーキテクチャー 第 1 回 」(developerWorks、2004年4月) を読んでください。
  
  
• 「 Patterns: Service-oriented Architecture and Web Services Redbook」(SG24-6303-00、2004年4月、Endrei M. 他)
  
  
• Carnegie Mellon University Software Engineering Institute (SEI) サイトでは、 Feature-Oriented Domain Analysis の詳細を説明しています。
  
  
• Grady Booch のインタビュー 詳細内容を読むには、InfoWorld.com にアクセスしてください。
  
  
• 「 Object-Oriented Software Design : A Use Case Driven Approach 」を入手してください。
  
  
• Ali Arsanjani 著「 A goal-driven approach to enterprise component identification and specification 」を読んでください。
  
  
• 「 Web Services and Business Process Management 」(IBM Systems Journal、Vol. 41、No 2、 2002年、F. Leymann、D. Roller、M.T. Schmidt 著)
  
  
• RUP (Rational Unified Process) について学んでください。
  
  
• Open Group サイトには、 TOGAF (The Open Group Architecture Framework) バージョン 8 の詳細が記載されています。
  
  
• Web サービスのポリシー・フレームワークに関する情報: WS-Policy framework
  
  
• エンタープライズ・アプリケーション用 Zachman Framework については、Zifa.com を参照してください。
  
  
• この技術やその他の技術に関する本 を参照してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• サービス指向のコンセプト
• BPM、EA、および OOAD では十分ではない理由
• SOAD の要素
• 例: 自動車作業発注
• まとめ
• 参考文献
• 著者について
• コメント