SOA の実践: BPEL および SCA でのケース・スタディー

SOA での社会福祉管理プロセスの実装

サービス指向アーキテクチャー (SOA) と SOA プログラミング・モデルは、真のアジリティー、そして IT とビジネスとの緊密な連携を実現する可能性を秘めています。しかし、本当の意味でのサービス指向ソフトウェアを開発するためには、実際にはどのようにすればよいのでしょうか?この記事では、少人数のアーキテクトと開発者からなるチームが、WebSphere Business Modeler でモデル化したビジネス・プロセスをベースに、一から SOA アプリケーションを構築していく過程を詳しく追っていきます。記事ではまず、設計・開発プロセスについてサービス指向の設計とデータ・モデリングに関する考慮事項と併せて説明します。続いてプロジェクトで実装した 1 つのビジネス・プロセスを詳しく調べ、WebSphere Integration Developer を使用して BPEL プロセスと SCA サービス・コンポーネントを開発する手法を説明します。

Barry Ruzek, Senior I/T Architect, IBM

Barry RuzekIT アーキテクチャーおよび開発に 30 年間携わってきた Barry Ruzek は、SOA 原則からシステムの設計・開発を専門とする IBM Senior IT Architect です。オペレーティング・システムおよびエンタープライズも含め、大規模なソフトウェア・システムを中心に幅広い技術経験を持っています。オブジェクト指向の設計と Java 関連の技術に精通している彼は、エンタープライズ・アーキテクトとして、クラウド・コンピューティングとサービス指向アーキテクチャーを組み込んだ柔軟でコスト効果の高いエンタープライズ IT システムを構築するための新しい手法を研究しています。



Dr. Bob Pratt, Executive I/T Architect, IBM

Bob PrattDr. Bob Pratt は、エンタープライズ・アプリケーションの革新およびサービス指向アーキテクチャーを専門とする IBM Senior Certified Executive I/T Architect です。コンピューター・サイエンスで理学士号と修士号を取得し、IT 管理で博士号を取得しました。29 年間 IBM に勤務している彼は、Technology Group と Global Business Services でさまざまな役職を経験しています。最近では、米国社会保障庁での IBM アカウントのチーフ・アーキテクトを務め、障害者手当裁定システムを再設計する大規模な取り組みをはじめ、数々のプロジェクトを担当しました。



2010年 9月 28日

概要

社会福祉に関するプロセスは一般に複雑なビジネス・プロセスですが、それが複合的なビジネス・プロセス (社会保障プログラムと保険金請求など) になると、さらに複雑なものになってきます。このようなビジネスでは、プロセス全体を通して多数の例外パスがあるだけでなく、プロセスを通じたいわゆるハッピー・パス (正常系のパス) でさえも長く複雑です。社会福祉に関するビジネス・プロセスには、オートメーションおよびサービス指向の設計、開発をする機会があふれています。このプロジェクトに取り組んだチームは、「ビジネス・プロセスの実装において SOA が従来のプログラミング手法に勝る付加価値をもたらすことを実証する」という目的に、WebSphere Business Modeler で作成したビジネス・プロセス・モデルを適合させました。

このプロジェクトに取り組むまで、開発チームは SOA アーキテクチャー・スタイルを扱ったことも、SOA プログラミング・モデルを扱ったこともありませんでした。そこでアーキテクト・チームは、使用するツール (WID、WPS、WESB) についての教育を行うことにし、時間を割いて開発者に SOA のスタイルとプログラミング・モデルを教えました。その結果、開発チームは SOA の概念を熟知し、独力で設計、開発できるだけのスキルを身に付けました。

こうした取り組みのおかげで、チームは SCA (Service Component Architecture) で一連の再利用可能なサービスを作成し、BPEL (Business Process Execution Language) で 3 つのビジネス・プロセスを作成することができました。また、基礎となるデータ構造とリッチな Web インターフェースを作成することで、ユーザー・エクスペリエンスを提示し、技術的な概念を明らかにすることができました。記事では、このアプリケーション設計の主要な要素と、最終的なプロセスおよびサービスの開発について説明し、最後にアプリケーションのデプロイメントとテストについて説明します。


概念

この開発プロジェクトで最初に取り組んだのは、サービス指向のさまざまな主要概念を展開して実証することです。これらの概念は、ビジネス・プロセスに応じた IT ソリューションを実現するために、典型的なビジネス・プロセスで必要とされるもの、すなわち SOA の目標に直接関係します。

以下に、基本概念を説明します。

  • サービス指向: 長期間にわたって繰り返し価値をもたらし、その価値が初期開発コストを超えることが見込まれる IT 資産として、サービスを位置付けます。
  • 自動プロセス・フロー: 人によるアクションとサービス・コンポーネントによるアクションを調整し、すべての障害ケースが一貫した処理ステップを踏むようにします。この自動プロセスによってイベントに反応し、次の処理ステップに進むタイミングを決定します。
  • サービス・ベースのアクティビティー: 自動プロセス・フローには、サービス・コンポーネントによって実行されるステップが含まれます。フローによって、プロセスの特定の時点で使用可能な情報を渡してサービス処理を呼び出します。サービス処理はアクションを実行することもあれば、そのプロセスが以降の自動フローに伝搬するための情報を返すこともあります。
  • 人間が管理するアクティビティー: 自動プロセス・フローには、人間が配慮してアクションを行わなければならないステップも含まれます。保留中のアクションは、システム・ユーザー・インターフェースで管理された作業負荷ダッシュボードによって、担当者に通知されます。少なくとも、その担当者はシステム・ユーザー・インターフェースを使ってアクションの結果を表示し、プロセス・フローの実行が継続できるようにします。
  • 時間主導のアクティビティー: 自動プロセス・フローのアクティビティーのなかには、ある特定の時点で実行されなければならないアクティビティーがあります。プロセス・フローを開始する時刻、あるいはフローを中断する期間は、指定することが可能です。時間主導のアクティビティーは、一度だけ実行することも、スケジュールに従って繰り返し実行することもできます。
  • 情報通知アラート: 自動プロセス・フローでは、システムのユーザーにとって重要な意味を持つ状態を検出することができます。そのような状態を検出した時点で、フローによって情報通知アラートを生成し、1 人または複数のシステム・ユーザーに送信します。これらのアラートはユーザー・ダッシュボードに表示されます。
  • 外部化されたビジネス・ルール: プロセス・フローの方向は、決定点でビジネス・ルールを適用することにより決まります。これらのルールは、システムが運用中であっても専用の管理インターフェースで更新することができます。

アプリケーションの設計

このセクションでは、アプリケーションの設計中に必要となる多くの考慮事項について詳しく説明します。

ユース・ケースの設計パターン

設計・開発プロセスで重要な最初のステップは、システムの使用方法を定義することです。これは、あらゆるアーキテクチャーやプログラミング・スタイルにも当てはまることですが、SOA の設計および開発が関係する場合には特に重要なステップとなります。概念実証 (PoC) での設計プロセスで最初に取り組んだのは、PoC の目指す目標を具体化した一連のユース・ケースの定義です。もっと具体的に言うと、PoC によって実証する SOA 概念をサポートするユース・ケースが選ばれました。

アプリケーションのコンポーネント、サービス、プロセスの開発を容易にするとともに、ユース・ケースを文書化する目的でテンプレートを作成し、それを使用して各ユース・ケースを記述しました。Word 文書として作成されたこれらのユース・ケースは、以下の主要なパーツ (「Overview (概要)」、「Authors (作成者)」、「Subject Matter Experts (サブジェクト・マター・エキスパート)」、「Actors (アクター)」、「Main Flow (メイン・フロー)」) で構成されています。

図 1. ユース・ケース
ユース・ケース

ユース・ケース文書には、いくつかの重要な特徴があります。まず、ユース・ケース文書は誰が、または何 (アクター) がシステムの特定の使用方法に関与するのか、そしてこれらのアクターがその特定の使用シナリオで何をするのかを記述します。システムの使用方法は、ユース・ケースのメイン・フローでの使用方法が記述されるだけでなく、特定の条件に適合した場合や特定のエラーが発生した場合にメイン・フローに代わって発生する代替フロー (上記の図には示されていません) での使用方法も記述されます。このように、システムのある 1 つの使用方法を完全に記述するユース・ケースが集まって、システムのあらゆる使用方法が表現されることになります。これらのユース・ケースがあれば、システムの設計者と開発者は技術レベルでシステムのデータ、振る舞い、特性を完全に表現することができます。

ユース・ケース文書の完全なテンプレートについては、この記事の「ダウンロード」セクションを参照してください。

以下の表に、この PoC を対象に定義されたユース・ケースについて説明します。

ユース・ケース名説明
審査官用ダッシュボードの表示障害審査官用ダッシュボードは、審査官に逐次情報を提供するためのディスプレイで、ここには審査官の全作業負荷の状態、実行する必要があるアクション、担当している障害ケースに関するイベントが表示されます。審査官はこのダッシュボードを出発点として、担当の障害ケースにアクセスし、割り当てられたアクションを実行して完了し、イベントに関する詳細情報を確認します。このユース・ケースでは、審査官がダッシュボードを表示する方法と、ダッシュボードに表示される情報について記述します。
障害ケース情報の表示障害ケース情報ディスプレイは、審査官に特定の障害ケースに関する詳細情報を表示します。決定プロセス全体を通して、審査官はこのディスプレイから、障害ケースに関連するアクティビティーを検討、分析、更新、管理するために必要な機能のすべてにアクセスすることができます。
審査主任への障害ケースの割り当てこのシステムでは、いずれの障害ケースも 1 人の障害審査官に割り当てられます。審査官は、割り当てられた障害ケースを進展させ、決定プロセス全体でその障害ケースを管理することに責任を持ちます。このユース・ケースは、審査官がある特定の障害ケースの審査主任になる流れを記述します。
システムへの障害ケースの送信このユース・ケースは、障害ケースがシステムに入力される流れを記述します。主なアクターは、外部システムです。外部システムは、システムが決定プロセスを完了できるように、障害ケースに関する十分な情報を収集してシステムに送信します。
電子証拠文書の要請障害審査官は、障害ケース内に見られるソースから、障害ケース申し立てを支援する電子証拠文書を取得するプロセスを開始します。システムは選択された文書提供者に通知を送ります。提供者が一定の日数内に応答しない場合、システムは障害審査官にフォローアップ・アクションを行うよう催促します。
電子証拠文書の提出障害ケース電子証拠文書 (UC005) が要請されると、証拠提供者は中間ステージング・システムを介して文書を提供します。ステージング・システムは障害ケース・システムに文書が送信されたことを通知します。すると、その文書が障害ケースの証拠コレクションに追加されます。審査主任にはアラートが送信されます。
審査官の作業負荷の振り替えシステムは、階層構造の組織に属する作業者たちによって作業が行われることを認識します。これらの組織にオプションで作業場を関連付けると、組織の地理的位置を定義することができます。このユース・ケースは、審査官の作業割り当てを同じ組織内の別の審査官の割り当てへと変更する方法を記述します。
組織の作業負荷の振り替えこのユース・ケースは、システム内の作業の責任を、ある組織から別の組織に振り替える方法を記述します。この機能が必要となるのは、例えば天災や人災によって、組織が作業を行うことができない場合などです。作業負荷を組織から移すと、その組織の作業者の作業割り当てが解除されて、別の組織の作業者にその作業が割り当てられます。
支援文書の要請障害ケース分析の実行中に、審査官は障害ケースに対する支援を要請します。システムは一連のビジネス・ルールに基づいて、支援を提供するユーザーを選択します。
支援文書の提供支援要請文書を受信すると、支援提供者は注釈情報送信ページによって注釈情報を提供します。システムは、支援を要請した審査主任に通知すると同時に、注釈情報を障害ケースの注釈コレクションに追加します。

サービス・コンポーネントの設計パターン

明確に定義された内部アーキテクチャーに準じたサービス実装は、そのサービスのライフサイクル全体を通して容易に設計、構築、管理、拡張することができます。PoC チームはその開始段階で大幅に時間を割いて、アプリケーションとサービスの作成中に使用するパターンを検討しました。このチームは少人数で構成されていたので、プロジェクトで作成するすべてのソフトウェアに適用する規約について合意に至ることができました。これは、このプロジェクトの 1 つの強みです。私たちはすべてのサービスに同じような構造と規約を適用しましたが、SOA が機能するには、このような統一性が絶対不可欠というわけではありません。それぞれの開発組織が、独自に開発した規約に開発作業を適合させることもあります。サービス・インターフェースが明確に定義され、効果的に実装されている限り、企業はソフトウェアを作成するのに多種多様な手法を用いることができます。

プロジェクトの設計フェーズでは、チームは毎日集まって、必要なサービスを決定するためにビジネス・プロセスおよびユース・ケースを 1 つひとつ検討しました。以下の図に、この作業によって決定したサービスとサービス間の関係を、UML 図で使用される一般的な方法で示します。特定されたサービスとそれぞれの基本的な機能は、その下の表に記載されています。この表が、詳細なサービス仕様の出発点としての役割を果たします。記事の後のほうで、開発者がこれらのサービスを作成できるように詳細にサービスを記述するためにプロジェクト内で使用したサービス仕様テンプレートの例を記載します。小規模なチームであったことから、サービスを指定したメンバーとサービスを作成したメンバーは同じです。けれども規模とは関係なく、あらゆるチームで使用すべきプラクティスとして、チームはサービス仕様の文書化にベスト・プラクティスを採り入れるよう十分気を配りました。

図 2. サービス・モデル
BPEL 証拠文書プロセス

サービス・コンポーネント・アーキテクチャーについての詳細

サービス・コンポーネント・アーキテクチャー (SCA) についての詳細は、「Service Component Architecture」を参照してください。

サービス

サービス
サービス名説明
アラート・サービスアラートとは、ビジネス・イベントの通知のことです。アラートは、イベントに関する情報と併せてコンテキスト情報を提供します。アラートの受信時に特定のアクションを開始するには、このコンテキスト情報を使用することができます。
ビジネス・イベント監査サービス監査証跡の概念を実装するこのサービスでは、重要なビジネス・イベントを登録、記録、取得します。イベントのタイプは名前で識別されます。名前のフォーマットはサービスでは未指定のままですが、固有ドメイン名のルールに従うことが推奨されます。
文書サービス 文書管理リポジトリーの電子文書を保管、取得するための処理を行います。この汎用サービスは、障害ケースに具体的に関連する文書を保管するために、障害ケース文書化サービスによって使用されます。
組織サービス 企業の組織間の関係と、組織単位での作業員の構成を反映したモデルを管理します。各作業者が属する組織は 1 つだけです。各組織が属する親組織も 1 つに限られます。オプションで組織に作業場所を関連付けると、その組織の地理的位置が定義されます。
テキスト通信サービス テキスト通信サービスは、メッセージ・テンプレートのライブラリーを管理し、これらのテンプレートからメッセージを生成して送信し、カスタマイズした情報を指定の挿入ポイントで追加します。このサービスは E メールと SMS によるテキスト通信を処理します。
作業割り当てサービス 作業割り当ての概念を実装します。この概念では、割り当てのタイプを動的に定義し、その割り当てタイプに関連するコンテキスト情報と併せてインスタンス化することができます。割り当ては、システムのユーザーをはじめ、任意の名前付きエンティティーに結合することができます。このサービスは、割り当ての振り替えおよび割り当て履歴の管理をサポートします。
ベンダー・サービス ベンダーとは、障害ケース文書化のソースとして使用できるあらゆる外部ビジネスに適用される総称です。このサービスが管理する障害ケース文書化ベンダーのレジストリーには、ベンダーのビジネス名、連絡先情報、および対話方法が保管されます。
障害ケース情報サービス システム内の障害ケースに関する基本情報を管理します。このサービスは、障害ケースの請求、請求者、連絡先などの情報を扱います。これらの障害ケース関連の情報を取得するには、いずれも一意のキーが使用されます。
障害ケース処理サービス ビジネス・ルールに従って、障害ケースとビジネス・ドメインの他の部分との関係を管理するための処理を行う複合サービスです。このサービスが行う処理には、障害ケース、組織、および作業者の特質に基づいて障害ケースの割り当て対象とする作業者を選択するための処理や、障害ケースの転送、組織の障害ケース作業負荷の要約などがあります。
証拠文書サービス 障害ケースとその障害ケースを支援する文書との関係を管理します。
障害ケース支援サービス 障害ケース関連のタスクを割り当てられる可能性のある多数の作業者の間で、アクションを調整することを専門とするサービスです。

SOA 内の各サービスには仕様が必要です。このプロジェクトでは、チームはサービス仕様文書によってサービスの機能を記述しました。以下は、サービス仕様文書からの抜粋です。

図 3. サービス仕様 (1)
サービス仕様その 1
図 4. サービス仕様 (2)
サービス仕様その 2

以下に、サービス仕様の重要な要素について説明します。

  • サービス処理: サービスがその WSDL でサービス処理として公開する機能を完全に記述します。処理ごとに、入力パラメーター、戻り値、そしてサービスが処理してコンシューマーに渡す可能性のあるエラーが指定されます。
  • データ型: サービスはデータの処理を公開します。サービス仕様でのデータ型の記述が、着信データと戻りデータに想定される型と構成を定義します。この定義は、サービスのコンシューマーが適切にサービス処理を呼び出し、サービスによって処理されて返されるデータを正しく認識する上で不可欠です。

サービス仕様文書の完全なテンプレートについては、この記事の「ダウンロード」セクションを参照してください。

データの設計

大抵の場合は、サービスの境界を考慮しないでデータをモデル化すると、ある特定のアプリケーションには最適であっても、疎結合の再利用可能なサービスをサポートするだけの柔軟性に欠けたモデルになってしまいます。PoC チームはそれよりも有効な手法を見つけました。それは、アプリケーションの要件を使用して、柔軟な名前空間、追加のオブジェクト属性、そしてその他のカスタマイズ機能もサポートするようにサービス・モデルを作成するという手法です。このようなサービス・モデルを作成したことで、アプリケーションをサポートするために必要な個々のサービスに応じて、より賢い、しかも単純なデータ・モデルを作成することが可能になりました。

図 5. データ・サービス
データ・サービス

サービス・オブジェクトの動的登録

広範なアプリケーションで役立つサービスにするためには、開発作業や構成作業を行わなくても新しい使用方法に対応できるようなサービスにしなければなりません。このプロジェクトで指定したサービスは、この原則を堅持しました。チームが検討したのは、障害ケース・システムだけでなく、他のアプリケーションでも考えられるさまざまな使用方法をサポートできるように、サービス管理オブジェクトのタイプにバリエーションを持たせる方法です。拡張可能なサービスを作成する 1 つの方法としては、XML や同様の手段により、オブジェクト・タイプの属性を使ってサービスを静的に構成することが考えられます。しかしチームは、有効なサービス指向アーキテクチャーとは両立しないとして、この手法を却下しました。この手法だと、開発者が新しいアプリケーションを開発するときに、そのアプリケーションをサポートするためのオブジェクト型を新しくサービスに定義しなければならないからです。そこで代わりに採用したのが、プロジェクトで開発するすべてのサービスで、新規オブジェクト型をサービス・インターフェースの処理によって動的にサービスに登録できるようにするという手法です。この手法を使えば、新しいアプリケーションは、サービスでサポートされるカスタマイズされたオブジェクト型を使用してプロビジョニングすることができます。このプロビジョニングは、サービス用に作成された管理ユーザー・インターフェースによって実装することも、クライアント・アプリケーション・コードに直接実装することもできます。PoC プロジェクトでは管理ユーザー・インターフェースとクライアント・アプリケーション・コード両方の手法を使用しました。

ソフトウェア・アーキテクチャー

以下に、このプロジェクトで組み立てたソフトウェアの構成図を示します。ソフトウェア・コンポーネントは、関心を分離し、近年よく使われる MVC パターンおよび SOA アーキテクチャー・スタイルに準じたモジュール式の設計になるように配列され、相互接続されています。

図 6. ソフトウェア・アーキテクチャー
ソフトウェア・アーキテクチャー

アプリケーションの作成

チームはアプリケーションの設計を基に、モジュール式のアプリケーション設計から論理的に導かれた構成タスクを複数の作業に分けました。SOA では以下の図に示すように、開発タスクが関連付けられたサービス・コンポーネントの境界に合わせて、作業を分割することができます。この記事ではデータベースの実装や UI の実装について説明することはせずに、サービス・コンポーネントと BPEL の実装に焦点を絞ります。これらの実装では、プレゼンテーション層とこの層に関連するコントローラー・ロジック、さらには明確に定義されたデータ・アクセス層を実装するために、多大な作業が必要になります。このプロジェクトでは、ユーザー・インターフェース層には Struts フレームワークと Ajax を使用し、データ・アクセス層には Hibernate を使用しました。これらの技術についての詳細は、記事の著者に問い合わせるか、この記事の「参考文献」セクションを参照してください。

この後のセクションでは、WebSphere Integration Developer ソフトウェアで SCA と BPEL を使用して SOA アプリケーションを 開発する際に重要となる要素について説明します。

シーケンス図

プロセスでの処理の順序と、どのコンポーネントが処理の要求に対処するかを図示するシーケンス図は、ビジネス・プロセスを編成する上で、非常に有用な設計ツールとなります。

図 7. 証拠文書要請プロセスのシーケンス図
BPEL シーケンス図

サービス・インターフェース (WSDL)

アプリケーションを構成するサービスは、それぞれの WSDL (Web Services Definition Language) ファイルによって定義されます。このプロジェクトでは、WebSphere Integration Developer の WSDL エディターに WSDL (および XML ファイル) を表示して変更します。各サービスの WSDL には、そのサービスが提供する処理、想定されるパラメーター、結果として返す内容がコンシューマーにはっきりとわかるような形で、サービスの処理と入力/出力の型が記述されます。以下の図に一例として、このアプリケーションの 1 つのサービスを記述する WSDL を示します。

図 8. 証拠文書プロセスの WSDL
WSDL インターフェース

BPEL プロセス

プロジェクトによって行われる作業を説明する好例は、証拠文書要請ビジネス・プロセスです。プロジェクトでは、電子証拠文書を取得する役割を担う BPEL コンポーネントを作成しました。

システムに送信される障害ケースには、必要になる可能性のある文書のリストとそれぞれの提供者 (現在文書を保有しているベンダー) のリストが含まれます。これらの文書提供者は、審査官の障害ケース情報ディスプレイに表示されます。審査官は、障害ケースの基本情報を補うために特定の文書が必要だと判断すると、証拠文書要請プロセスを開始します。

このプロセスで受け取る証拠アイテムには、障害ケース ID、必要な証拠のタイプ、そしてその証拠文書を保有するベンダーが示されます。プロセスはベンダーに対し、ベンダーが目的の文書を見つけられるようにするための情報と、セキュアな文書リポジトリー (ここで、文書を障害ケース情報の一部にすることができます) に文書のコピーをアップロードするためのコード化された URL を送信します。この通知は、ファックスや郵便など、さまざまな形を取ることが考えられますが、このプロジェクトでは E メールによる通信が最も簡単に実装できる通信チャネルとなります。

最初の通知を送信した後、プロセスではリクエストの進行状況をモニタリングします。あらかじめ設定された日数が経過しても要求した文書がリポジトリーに現れない場合、プロセスはフォローアップ・アラートを審査官に送信します。このアラートに含まれるのは、リクエストに関してカスタマイズされたコンテキスト情報です。ディスプレイ・アプリケーションはこのコンテキスト情報を使用してリクエストの現状についての情報を表示します。この時点で、審査官は次に取るべきアクションを決定することができます。プロセスが受け入れるイベント・メッセージは、リクエストの取り消し、続行 (待機状態を維持)、そして通信の続行 (文書提供者に別の通知を送信して待機) の 3 つです。

ベンダーが文書をリポジトリーに送信すると、プロセスは障害ケースを更新して文書が使用可能であることを示すとともに、証拠文書が提出されたというアラートを審査官に送信します。これで、このプロセスは完了です。プロセス完了と同時に、審査官が提出された証拠文書を表示できるようになります。

図 9. BPEL での証拠文書要請プロセス
BPEL Evidence Process

上記に示した BPEL プロセスは、大規模で堅牢な BPEL プロセス定義のほんの一部です。BPEL プロセス全体を見るには、「ダウンロード」セクションで BPEL プロセス・イメージのダウンロード・リンクにアクセスしてください。

アセンブリー図

プロジェクトでは、上記の証拠文書要請プロセスを BPEL コンポーネントとして専用の SCA モジュールに実装しました。そのために最初に行ったステップは、このプロセスの WSDL インターフェースを定義し、プロセスがサポートする処理またはイベントを記述することです。プロセスは、startRequest 処理によって開始されます。cancelRequest、continueRequest、および continueRequestWithCommunication 処理は、審査官がプロセスの実行を制御できるようにするためのイベント・メッセージを定義します。要求した文書が提出されたことを知らせるのは submitEvidenceDocument 処理です。クライアントは captureCurrentState 処理を使用して要求の進行状況を表示することができます。

図 10. 証拠文書要請プロセスの WID アセンブリー図
SCA アセンブリー図

上記のアセンブリー図から、証拠文書要請プロセスは、このプロジェクト用に作成された多数のサービスに依存していることがわかります。これらのサービスは、図の右側にインポートとして表示されています。


アプリケーションのデプロイメント

以下の図は、デプロイされた PoC のアーキテクチャーです。これは概念実証を説明するためのデモなので、デプロイメント・アーキテクチャーのスケーラビリティーや耐障害性についてはそれほど重要視していません。私たちは SOA での仮想化を具体的に説明するため、そして説明する上での便宜上の理由から、異種混合のハードウェアおよびオペレーティング・システムで構成された環境にサービスをデプロイすることにしました。本番レベルのアーキテクチャーはこれとは大幅に違ってくるはずであり、このデプロイメント・アーキテクチャーは、プロジェクトの限られた範囲をカバーするように決められている点に留意してください。

図 11. デプロイメント・アーキテクチャー
デプロイメント・アーキテクチャー

このデプロイメント・アーキテクチャーには、概念実証の概念を明らかにする上で重要な特徴があります。これらの特徴は、以下のとおりです。

  1. イントラネットおよびインターネットの存在: 証拠提供者はファイアウォールの外側に位置し、インターネット上のユーザーが Gmail を使ってその存在を示します。その意図は、プロセスに異種のコンポーネントを含められることを明らかにするためです。
  2. サービスの仮想化: SOA の重要な特徴は、複数のエンドポイントのサービスを参照して呼び出すことが可能であることです。エンドポイントの構成によって、必要に応じてサービスを仮想化することができます。このデモでは、チームはエンドポイントを意のままに、中央に位置する E メール・サービスからリモート・サービス・エンドポイントに切り替えています。
  3. データの統合: さまざまな種類のソースからのデータが統合され、データ・サービスを介してアプリケーション層に公開されます。データ・サービスは、データに対するすべての CRUD 処理を扱います。
  4. 水平スケーリングおよび耐障害性: ソフトウェア・スタックは、双方向の WAS クラスターからなるクラスター環境にデプロイされます。これは、n 方向のクラスターに拡張することが可能です

アセンブリー

WebSphere Application Server で実行するようにアプリケーションを WebSphere Process Server にパッケージ化するには、いくつかの方法があります。その 1 つは、すべてのサービスと関連コードを 1 つにまとめた大きなデプロイメント・ユニットを作成することです。この方法にはモジュール性に欠けるという欠点がありますが、その一方、簡単にデプロイできるという利点があります。

このプロジェクトで採用した方法は、サービス・コンポーネントごとにデプロイメント・ユニット (EAR ファイル) を作成し、Web インターフェースには 1 つの EAR ファイルを作成するという方法です。こうすれば、サービスが必要になったときに、アプリケーション全体をデプロイすることなく、個々のサービスをデプロイ (または再デプロイ) することができます。この方法が役立つことは、開発時に証明されています。開発では、1 つのサービス・コンポーンネントだけに変更を加え、そのコンポーネントを再デプロイしなければならないことがよくあったためです。各サービスをそれぞれ固有のデプロイメント・パッケージにすることで、処理時間が短縮され、開発とテストを効率的に行えるようになりました。

以下の図に、すべてのサービス・コンポーネントがインストールされて、それぞれ独立したエンタープライズ・アプリケーションとして稼働する WebSphere Application Server を示します。

図 12. デプロイメント・ユニット
デプロイメント・ユニット

まとめ

BPEL と SCA を使用してビジネス・プロセスを SOA に実装するのは、これらの概念に馴染みのない方にとっては難しい取り組みです。このプロジェクトに取り組んだチームは、ビジネス・プロセスを選択し、そのプロセスを BPEL で実装し、SCA アーキテクチャーでサービスを呼び出す方法を実際の体験から学びました。さらにこの経験を通して、チームはベスト・プラクティスを開発し、避けなければならない落とし穴についても学びました。

この記事では、WebSphere ファミリーのツールを利用して、BPEL と SCA を適用してプロジェクトを設計、開発する方法を簡単に説明しました。記事を読んで理解していただけたと思いますが、SOA のアーキテクチャー・スタイルとプログラミング・モデルは、ソフトウェアのビジネス・プロセスを実現する上で大きなメリットをもたらします。また、SOA ツールによる開発およびランタイムのサポートや BPEL によって、堅牢な環境が提供されます。この環境のなかでは、長時間実行されるビジネス・プロセスが実装され、これらのプロセス内での状態が長期間にわたって管理されます。そして、このプロジェクトの経験によって明らかになったのは、SCA によってサービス実装の詳細を抽象化することで、開発チームの生産性が向上するとともに、SOA アーキテクチャー・スタイルが持つ極めて重要な利点、つまりサービスの再利用と構成が可能になるということです。


詳細について

このプロジェクトの詳細を知りたい方、あるいはサンプル・コードを入手したい方は、著者に連絡してください。


ダウンロード

内容ファイル名サイズ
Samples from the articleSOAInActionBPELSCA.zip300KB

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=607144
ArticleTitle=SOA の実践: BPEL および SCA でのケース・スタディー
publish-date=09282010