| 掲載日：2006年8月9日 （水） |
 |
日本アイ・ビー・エム株式会社
本間 由紀子 |
|
前回のステップでは、ビジネス・プロセスをあるべき（To-be）プロセスへと改善し、さらにITで実装するためのエクスポートを行いました。今回は、そのビジネス・プロセスをITで実装するステップを行ってみます。そのビジネス・プロセスは人が行うものでしょうか？それともどこか既存のサービスを利用するものでしょうか？あるいは現状ではサービスが存在しないため、新しく開発する必要があるものでしょうか？前回まではWebSphere Business Modelerを使いましたが、今回からは実装のための統合開発環境として、WebSphere Integration Developer（以下、WID）という製品を使用します。
第2回の最後でWIDにインポートしたビジネス・プロセスを見てみる方法が説明されています。ここでは、縦に流れるビジネス・フローが書かれています。これは、ツール上ではGUIで表現されていますが、実はBPELというビジネス・プロセスを表現するためのXMLベースの言語で書かれています。
前回もご紹介したとおり、BPELはそのままではサーバで稼働するシステムにはなりません。これはビジネス・プロセスの流れと、その中で呼び出すサービスに対してのインターフェースを定義しているのみなので、実際には何を呼び出しているのか、実装は何も定義されていません。呼び出すサービスを実装して、コンポジット・アプリケーションとして組み立てることによって、初めて実行可能なアプリケーション・モジュールとなるのです。
コンポジット・アプリケーションを、実装の形を気にせずに実際のサービスを結びつけることのできる画面がアセンブリー・エディターというもので、図1のように表示されます。実際にビジネス・プロセスを起動するための入口のインターフェースは「エクスポート」と呼ばれ、ビジネス・プロセスに結びついています。また、BPELのビジネス・プロセスからは、「一次審査」と「二次審査」に関しては、すでにModeler上で、「人間のタスク」（WIDの世界では「ヒューマン・タスク」と呼ばれています）と定義してあるため、ヒューマン・タスクとして実装されています。また、ここで「！」印がついているものは、実装が定義されていないものを表します。これら実装が定義されていないものについて、色々な形の実装と結び付けていくことにします。
図1 アセンブリー・エディターで表示される画面
この例では「一次審査」と「二次審査」以外に関しては、サービスの実装形態はまだ決定していません。当初のビジネス・プロセスではこれらのプロセスはすべて人手で処理することになっていましたが、実際はもともとITシステムを使っている部分があれば、それの再利用も可能です。また、今まで人手で処理していた部分を自動化するとなれば、追加でサービスの開発が必要となってきます。サービスの粒度も問題になってきます。モデリングしたビジネス・プロセスの呼び出すサービスは、実はもう1段階ブレイクダウンしたプロセスになることもあります。
このように、コンポジット・アプリケーション全体を見渡すために、「インテグレーション開発者」の存在が必要です。インテグレーション開発者は、サービス開発者とうまく連携を取りながら、サービスをどう実装していくか、インターフェースをどうしていくかを考えなくてはいけません。
それでは、コンポジット・アプリケーションにおけるサービスの「実装」をどうするかを考えながら、いくつかの場合に分けて実際の実装方法にについて解説していくことにしましょう。
コンポジット・アプリケーションを実際に動かすためのランタイムとなるのは、WebSphere Process Server（以下、WPS）には図2のようなコンポーネントがあります。WPSについての詳しい説明は「WebSphere Process Server V6解体新書」を見ていただくとして、アセンブリー・エディター上のコンポーネントは、WPSの「サービス・コンポーネント」のレイヤー（いちばん上のレイヤー）で提供されているコンポーネントで実装することが可能となっています。具体的にはビジネス・プロセス、ヒューマン・タスク、ビジネス・ステート・マシン、ビジネス・ルールです（ビジネス・プロセスから呼び出す先のサービスがビジネス・プロセスというと疑問に思われる方もいらっしゃるかもしれませんが、このような形も可能です）。
図2 WPSのコンポーネント・レイヤー
これらWPSのサービス・コンポーネントで実装を行う場合には、アセンブリー・エディターからコンポーネントを右クリックし、「実装の生成」を選び、実装の種類を選ぶと、選んだサービス・コンポーネントのエディターが現れます。実際のサービス・コンポーネントの実装はそのエディター上で行い、保存します。
ここでは、「不備確認」は自動的なルール・ロジックに従って判断したいので「ルール・グループ」を選び、「確認書送付」は人間の手によって、チェックしながら行いたいので「ヒューマン・タスク（人的タスク）」を選択します。ただし、ビジネス・ルールでは、「実装の生成」で生成されるのは、「ルール・グループ」というビジネス・ルールの集合体です。そこから日付や時間によって呼び出される個々のルールを別途実装していかなくてはいけません。これは、特定の時期だけ割引率を変える、など、時期によるビジネス・ルールの変更に柔軟に対応させるためです。
アセンブリー・エディターからサービス・コンポーネントの実装を生成するのではなく、最初にサービス・コンポーネントを作成し、アセンブリー・エディターから「実装の選択」でそのコンポーネントを選択することで実装と結びつける方法もあります。
内部のサービス・コンポーネントではなく、外部のサービスで実装する場合の代表的なものが、Webサービスを呼び出す場合でしょう。ここでは、「カード発行」と「お断り通知」の2つのサービスを、外部のWebサービスを呼び出すようにします。
Webサービスの場合は、WSDLファイルをコンポジット・アプリケーションのプロジェクト内にインポートするところから始まります。WIDのビジネス・インテグレーション・ペインを見てみると、「Webサービス・ポート」にWebサービスが追加されていることがわかります。これをアセンブリー・エディターにドラッグ＆ドロップし、Webサービス・バインディングのインポートを作成することによって、コンポジット・アプリケーションからWebサービスが呼び出せることとなります。
しかし、すべてのWebサービスが呼び出し元のインターフェースをそのまま使えるわけではありません。そのような時のために、「トランスフォーメーション・サービス」という様々なマッピングの機能が存在しています。まずは「インターフェース・マップ」を使い、インターフェース同士のマッピングを行います。インターフェースの中のデータの内容をマッピングするには、「データ・マップ」を使います。これらの方法で、違った形のインターフェースやデータの内容を結びつけ、データのやり取りをすることが可能となります。
既存のサービスがない場合、ローカルのJavaBeansによって実装を行うことも可能です。この場合、WIDを使ったコンポジット・アプリケーションから呼び出すためのコーディングのお約束が必要なのですが、ツールから生成することにより、それらの約束事をあまり気にすることなく開発が可能です。ここでは、「申込受付」「不備受付」の2つについて、ローカルのJavaBeansによって実装することにします。
JavaBeansによる実装は、WPSのサービス・コンポーネントによる実装と似た手順で行います。アセンブリー・エディターからコンポーネントを右クリックし、「実装の生成」を選び、「Java」を選ぶと、Javaのエディターが現れます。Javaの実装はそのエディター上で行い、保存します。
ただし、実際の開発場面では、サービスの実装は、WIDでのコンポジット・アプリケーションの組み立てとは別の開発者が行うことが多いでしょう。その場合は、コンポジット・アプリケーションから呼び出すためのコーディング形式を使って、サービス開発者がコーディングを行い、インテグレーション開発者がモジュールを取り込んで「実装の選択」メニューから選択して実装を行うのが一般的となるでしょう。
以上のような形で、ModelerからインポートしたBPELやインターフェース、データ型を使って、ITの世界に実装を行っていきました。詳しくは、添付のFlashムービーにて、どのような手順で行うかを見てください。次回は、さらに一歩進んだサービス実装との結びつきと、テストの実行について解説していきます。
|
