ビジネス・オペレーションは、あるシーケンスとして実行される複数のステップまたはタスクで構成されます。現実の一般的なビジネス・ワークフローにおけるタスク・シーケンスは、本質的には動的です。つまり、シーケンスは通常固定的ではなく、実行中にしか決められない要素によって変化します。この 2 回の連載では WS-BPEL と IoC を使用して構成可能な動的ビジネス・ワークフローを構築する方法を紹介します。第 1 回目のこの記事では WS-BPEL と IoC を使用して行うビジネス・ワークフローの実装の全体的なアーキテクチャーを概説し、第 2 回で、WS-BPEL を利用して生産管理のワークフローを実装する方法を説明します。

この記事で最初に説明するのは、ビジネス・ワークフローの動的性質です。その上で、柔軟なワークフロー・ソリューションを構築するための 2 層構造のモデルを紹介し、XML ベースの IoC を使用してこの 2 層のうちの 1 層を実装する方法を説明します。そして最後に、ワークフロー・ソリューションを構築する際に BPEL が果たす役割について解説したいと思います。

ビジネス・ワークフローの性質

ここでは製品を製造する例を用いて、ビジネス・ワークフローの動的性質を説明します。現実の世界では、ほとんどの製造会社で多種多様な製品を生産していますが、大量に生産する製品もあれば、生産量の少ない製品もあります。このような生産量の違いに対応するには、比較的単純な 2 つのワークフローを併せて実装して現実に合った動的ワークフローを形作らなければなりません。

生産管理のための単純なワークフロー

最初に紹介する単純な生産ワークフローは、多種多様な製品を生産している製造会社にのみ適しています。

1. 生産部門が生産注文書を受け取ります。
   
   
2. 生産部門はこの生産注文書から生産する必要がある製品のリストを抽出し、必要とされる製品それぞれについてのプロセス詳細を取得します。プロセス詳細には、以下の情報が含まれます。
   • その製品を生産するために実行しなければならない生産タスク
   • 用意しなければならない製造リソース (人的リソースやマシンなど)
   • 製造に適用される標準、基準、図面、手順、および品質基準
     
     
3. 生産部門は、必要な製品を生産するために実行するタスクのそれぞれについての作業指示書を発行します。この作業指示書には、関連するプロセス詳細を添付します。

さまざまな種類の製品を生産する会社は、一般的に、生産リソースを最大限有効に使用するために同じ生産リソース (組み立てラインやマシンなど) を使って作業指示を実行します。作業指示書ごとに関連プロセス情報が伴っていることが重要なのは、そのためです。プロセス情報により、作業指示を実行するマシンのオペレーターやソフトウェア・モジュールが、実行すべき内容を正確に把握できるようにするというわけです。

ここからは、この 3 ステップのタスク・シーケンスを多種類生産ワークフロー、あるいは単純に多種類ワークフローと呼びます。

大量生産のワークフロー

次に紹介する単純なワークフローは、多種多様な製品ではなく、数種類の製品を大量に生産する製造会社に適用されます。限られた種類の製品を大量生産する会社では、製品ごとに専用の生産リソースを使用するほうが経済的なので、一般的には、製造リソースを共有する必要はありません。

通常、このような会社が採用する広範な生産計画手順は、会社が生産する製品それぞれの製造スケジュールとなります。会社がこの製造スケジュールを採用すると、作業指示書が専用リソースに対して発行されます。

会社が生産リソースを特定の製品の生産専用として使用する場合には、作業指示書にプロセス情報を添付する必要はありません。そのため、この生産ワークフローは多種類ワークフローとはかなり異なってきます。例えば、以下の 5 ステップのタスク・シーケンスを考えてみてください。

1. 会社の生産部門が生産注文書を受け取ります。
   
   
2. 生産部門が、生産注文書から生産する必要がある製品のリストを抽出します。
   
   
3. 生産部門は、生産対象製品の製造スケジュールを確認し、生産注文書の要件を既存の製造スケジュールと突き合わせます。
   
   
4. 生産部門が、既存の製造スケジュールで新しい生産必要高に十分に対応できると判断した場合には、生産注文書に指定された必要量をこのスケジュールで確保します。
   
   
5. 既存の製造スケジュールで新しい生産必要高に対応しきれない場合には、生産部門はこの新しい生産注文書の生産必要高を満たす新しい作業指示書を発行します。この作業指示書は生産する製品を指定するだけのもので、プロセス詳細を指定する必要はありません。

この 5 ステップのタスク・シーケンスについては、以降、大量生産ワークフローと呼びます。

多種類ワークフローと大量生産ワークフローのマージ

典型的な現実の製造アプリケーションでは、会社が生産する製品の種類はさまざまにあり、そのうちのいくつかは大量に生産されます。これはつまり、これらの会社では上記で説明した 2 つの単純なワークフローを併せて実装しているということです。例えば、この 2 つのワークフローをマージした以下の 8 ステップのワークフローは、大量生産と多種類生産の両方を処理します。

1. 会社の生産部門が生産注文書を受け取ります。
   
   
2. 生産部門が、生産注文書から生産する必要がある製品のリストを抽出します。
   
   
3. 生産部門が生産注文書の各製品をチェックし、多種多様な製品のうち、どの製品を共有リソースを使用して生産する必要があるか、そして大量生産する製品のうち、どの製品を専用リソースで生産する必要があるかを判断します。
   
   
4. 生産部門が、多種類のカテゴリーに含まれる製品ごとにプロセス詳細を取得します。
   
   
5. 生産部門が、多種類のカテゴリーに含まれる製品を生産するために実行しなければならないタスクそれぞれについての作業指示書を発行します。作業指示書には、該当するプロセス詳細を添付します。
   
   
6. 生産部門が、大量生産のカテゴリーに含まれる製品それぞれの現行の製造スケジュールを確認します。
   
   
7. 現行の製造スケジュールで新しい生産必要高を十分に満たせる場合、生産部門は現行の製造スケジュールで大量生産製品に必要な量を確保します。
   
   
8. 既存の製造スケジュールで新しい生産必要高を満たせない場合には、生産部門はこの新しい生産注文書の生産必要高を満たす新しい作業指示書を発行します。

マージされた上記の 8 ステップからなるワークフローでは、正確なタスクのシーケンスは実行時にしか決められません。このことから、ビジネス・ワークフローの動的性質は明らかとなります。例えばステップ 3 では、生産部門が生産注文書にさまざまな種類の製品が含まれていないと判断すると、ステップ 4 とステップ 5 を省略してステップ 6 に進むことになります。同様に、生産注文書に大量生産製品が含まれていなければ、ステップ 6 からステップ 8 までは実行されません。

上に戻る

ビジネス・ワークフローの 2 層構造モデル

ビジネス・ワークフローの動的性質は、図 1 に示す階層化された 2 層構造のモデルに分析することができます。

上記の図を見るとわかるように、上位の層はプロセス実行ロジックを実装します。この層が果たす役割は以下のとおりです。

• ワークフローを構成するタスクを 1 つずつ制御して実行する。
• 各タスクの結果を判断する。
• 次に実行するタスクを決定する。

ここからは、この層をプロセス実行層 (Process execution layer)、あるいは単に実行層と呼びます。

下位の層は複数のクラスで構成され、それぞれのクラスが各タスクのビジネス・ロジックを実装します。この層は、個別タスク層 (Individual task layer)、あるいは単にタスク層と呼ぶことにします。

この 2 層構造にモデル化する方法に従った場合の主な利点は、2 層構造ならではの柔軟性です。この方法では、極めて細分化したタスクを定義して、変化するワークフローの要件に合わせてタスクを構成したり、再構成したりすることができます。

細分度は重要です。例えば、多種類ワークフローのステップ 2 と大量生産ワークフローのステップ 2 を比較してください。多種類ワークフローのステップ 2 では 2 つのタスク (生産注文書から製品のリストを抽出するというタスクと、製品ごとのプロセス詳細を取得するというタスク) を実行します。一方、大量生産ワークフローのステップ 2 では、1 つのタスク (生産注文書から製品のリストを抽出するというタスク) しか実行しません。大量生産ワークフローのステップ 2 を細分化すれば、マージされたワークフローに直接当てはめることができます。この例から、細分度の高いタスクのほうが、変動するワークフローの要件に適合しやすいことがわかります。

ここからは、マージされた 8 つのステップからなるワークフローの個別タスク層を構成する細分化されたタスクを特定します。その後、実行層がタスク層をどのように利用してマージされたワークフロー全体を実装するかを説明します。

細分化されたタスクの特定

マージされた 8 ステップのワークフローから抽出した以下の 8 つの細分化タスクのそれぞれで説明しているように、細分化されたタスクは入力を取り、特定のタスクを実行します。以下のタスクのそれぞれは、Java<trade/> クラスのメソッドにより、図 1 のタスク層の構成部分として実装することができます。

1. 生産注文書を入力として取り、生産する必要がある製品のリストを返すタスク。この後の「タスク層の IoC 構成」セクションで、このタスクのビジネス・ロジックを実装する items2BProduced という Java Bean を構成します。
   
   
2. 生産製品の名前または ID を入力として取り、生産製品のタイプ (多種類製品または大量生産製品のどちらか) を返すタスク。このタスクのビジネス・ロジックは、typeOfItem という Java Bean が実装します。
   
   
3. 多種類製品の名前または ID を入力として取り、そのプロセス詳細を返すタスク。このタスクのビジネス・ロジックは、processDetails という Java Bean が実装します。
   
   
4. 多種類製品の名前または ID を入力として取り、この製品を生産するための作業指示書を発行するタスク。作業指示書には、該当するプロセス詳細を添付します。このタスクのビジネス・ロジックは、largeVarietyWO という Java Bean が実装します。
   
   
5. 大量生産製品の名前または ID を入力として取り、対応する現行の製造スケジュールを返すタスク。このタスクのビジネス・ロジックは、manufacturingSchedule という Java Bean が実装します。
   
   
6. 大量生産製品の現行の製造スケジュールと新規生産必要高を入力として取り、現行の製造スケジュールでは生産できない新規生産必要高の量を返すタスク。このタスクのビジネス・ロジックは、additionalProductionRequirement という Java Bean が実装します。
   
   
7. 大量生産製品の名前または ID と、その新規生産必要高を併せて入力として取り、大量生産製品の現行の製造スケジュールで生産必要高を確保するタスク。このタスクのビジネス・ロジックは、productionReservation という Java Bean が実装します。
   
   
8. 大量生産製品の名前または ID を入力として取り、この製品を現行の製造スケジュールで生産するための作業指示書を発行するタスク。このタスクのビジネス・ロジックは、bulkProductionWO という Java Bean が実装します。

単独のプロセスを実装する Java Bean のそれぞれが入力を取り、他の Bean とは独立してプロセスを実行します。

プロセス実行層の操作

図 1 のプロセス実行層は、個別のタスクを実装する Java クラスを図 2 に示す順で使用します。

図 2 のシーケンスを以下に説明します。

1. プロセス実行層が、クライアント・アプリケーションから生産注文書を受け取ります。
   
   
2. プロセス実行層は items2BProduced Java Bean を使用して、生産注文書から生産する必要がある製品のリストを抽出します。
   
   
3. 生産注文書の製品ごとに、プロセス実行層が typeOfItem Java Bean を使用して、その製品が多種類カテゴリーに属するのか、あるいは大量生産カテゴリーに属するのかをチェックします。
   
   
4. 多種類カテゴリーに属する製品ごとに、プロセス実行層が processDetails Java Bean を使用して、多種類項目のプロセス詳細を取得します。
   
   
5. プロセス実行層が largeVarietyWO Java Bean を使用して、多種類製品の製造作業指示書を発行します。
   
   
6. プロセス実行層が manufacturingSchedule Java Bean を使用して、大量生産製品ごとの現行の製造スケジュールをチェックします。
   
   
7. プロセス実行層が additionalProductionRequirement Bean を使用して、生産注文書の大量生産製品ごとの必要生産高を満たすために追加で生産する必要がある量 (現行の製造スケジュールでは対応しきれない分の量) をチェックします。
   
   
8. 追加生産が必要ない場合 (つまり、現行の製造スケジュールで、生産注文書で指定されている大量生産製品の量に対応できる場合)、プロセス実行層は productionReservation Bean を使用して、大量生産製品ごとに必要な生産量を現行の製造スケジュールで確保します。
   
   
9. 追加生産が必要な場合には、プロセス実行層が bulkProductionWO Bean を使用して、大量生産製品ごとの追加作業指示書を発行します。

これで、個別タスク層とプロセス実行層のビジネス・ロジックについては十分理解できたはずです。次に、個別タスク層とプロセス実行層それぞれの実装方法について説明します。

上に戻る

IoC を使用してタスク層を実装する方法

IoC とは、前のセクションで説明した個別タスク層の Java Bean のような柔軟な疎結合モジュールを作成するための概念です。

XMLをベースとした IoC 実装では、XML を使用して以下のものを指定することができます。

• アプリケーションで使用する Java Bean
• Bean ごとの Java クラスの名前
• Bean が依存する他の Bean

IoC 実装では XML 構成を使用して、インスタンス化する必要のある Java クラスとインスタンス化の順序を把握してから、該当する Java クラスをインスタンス化します。つまり、XML ベースの IoC を使って Bean を構成すれば、Bean のインスタンス化について心配する必要がなくなるということです。

IoC を使用して個々のタスクの Java クラスを構成することにより、Java クラスに含まれるタスクごとのビジネス・ロジックの実装に専念できます。タスク層のクラスがどのようにビジネス・ワークフロー・アプリケーションに統合されるかについて考える必要はありません。Bean をただ単に IoC 実装として構成すれば、後は IoC フレームワークが Bean をインスタンス化してプロセス実行層で使用できるようにしてくれます。

この手法には大きな利点があります。変化するビジネス・シナリオでは、時として、ワークフローに新しいタスクを追加しなければならなくなります。そうなった場合、新しいタスクに新しい Java クラスを実装する必要が出てきますが、IoC Bean の XML ベースの構成であれば、既存のワークフロー・アプリケーションに新規クラスを簡単に統合することができます。

これは、XML の IoC では、ワークフローに含まれるタスクのビジネス・ロジックをそれぞれ個別に実装し、テストできるということでもあります。ビジネス・ロジックのテストが済んだ後、XML 構成ファイルを更新することによって Bean をワークフロー・アプリケーションに統合できます。

この記事では、よく使われている Spring Framework を IoC フレームワークとして使用します。Spring Framework は、Java および XML をベースとしたオープンソースの IoC 実装です (IoC 全般についての記事や、Spring の IoC 実装について説明している記事へのリンクについては、「参考文献」を参照してください)。

タスク層の IoC 構成

リスト 1 は、Spring XML 構成ファイルです。このファイルの内容を見ると、前のセクションで抽出したタスク層の 8 つの Java Bean を構成する方法がわかります。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    http://www.springframework.org/schema/aop
    http://www.springframework.org/schema/aop/spring-aop-2.0.xsd
    http://www.springframework.org/schema/tx
    http://www.springframework.org/schema/tx/spring-tx-2.0.xsd">

    <!--Business objects for production management-->

    <bean id="items2BProduced"
        class="sample.wf.Items2BProduced" scope="application" />

    <bean id="typeOfItem"
        class="sample.wf.TypeOfItem" scope="application" />

    <bean id="processDetails"
        class="sample.wf.ProcessDetails" scope="application" />

    <bean id="largeVarietyWO"
        class="sample.wf.LargeVarietyWO" scope="application" />

    <bean id="manufacturingSchedule"
        class="sample.wf.ManufacturingSchedule" scope="application" />

    <bean id="additionalProductionRequirement"
        class="sample.wf.AdditionalProductionRequirement" scope="application" />

    <bean id="productionReservation"
        class="sample.wf.ProductionReservation" scope="application" />

    <bean id="workOrderForBulkProductionItem"
        class="sample.wf.WorkOrderForBulkProductionItem" scope="application" />

</beans>

上記のリストでは、<beans> タグが、それぞれに Java Bean を表す複数の <bean> タグをラップしています。各 <bean> タグの id 属性が指定しているのは、Bean の名前です。この名前からわかるように、リスト 1 にはタスク層の 8 つすべての Java Bean があるはずです。

例えば、最初の <bean> タグを見てください。このタグの id 属性の値は、items2BProduced となっています。これは、個別タスク層の最初のタスクを実装する Bean です。

items2BProduced <bean> タグの class 属性には、org.manufacturing.Items2BProduced という値が設定されています。これは、items2BProduced Bean の Java クラスの完全修飾名です。同様に、それぞれの <bean> タグの class 属性が、該当する Bean の Java クラスを指定しています。

今度は各 <bean> タグの scope 属性を見てください。scope 属性が指定するのは、Bean が application スコープ内にあるのか、request スコープ内にあるのか、それともそのいずれでもない他のスコープ内にあるのかどうかです。Bean が application スコープ内にある場合、Spring フレームワークはその Bean をアプリケーションの起動中にインスタンス化します。Bean が request スコープ内にある場合には、その Bean はリクエストを受信するたびにインスタンス化されます。

すべての Bean には application スコープが指定されているため、Spring はアプリケーションの起動中にこれらの Bean をインスタンス化することになります。Spring が Bean をそれぞれのスコープ内でどのようにインスタンス化するかについては、第 2 回の記事で詳しく説明します。

ここでは簡単のために、1 つの XML 構成ファイルに 8 つすべての Bean の構成を記載しましたが、実際には、各 Bean をその特定の Bean が提供するサービスに対応する個別の構成ファイルに構成することができます。

プロセス実行ロジックの実装

ビジネス・ワークフローの個別のタスクを実装するために使用するクラスの構成方法がわかったところで、今度は図 1 のプロセス実行層を実装する方法について説明します。

Spring の IoC フレームワークが有効に機能するのは、サーブレットのコンテキスト内においてです。つまり、あらゆるサーブレットがリスト 1 で構成されている IoC Bean を使用することができます。プロセス実行層は個別の Java クラスとして実装することも可能で、その場合、サーブレットはこのクラスを使用して、個別タスクのシーケンスをワークフローの要件に応じて制御することができます。

ただし、プロセス実行層を Java クラスに実装 (ハードコーディング) すると、タスク層を実装するために IoC を使用する目的が台無しになってしまいます。XML を使用して IoC Bean を構成する上での大きな利点は、IoC では既存のワークフロー・アプリケーションに新しいクラスを簡単に統合できることだったはずです。プロセス実行層を Java クラスにハードコーティングした場合、タスク層を構成するために IoC を使用するかしないかに関わらず、ワークフローは構成不可能になってしまいます。

この問題は、プロセス実行層でも同じく XML を使用することで解決します。そこで、これから WS-BPEL (Business Process Execution Language) を使って構成可能なプロセス実行層を構築することにします。WS-BPEL は、OASIS (Organization for the Advancement of Structured Information Standards) が (その名前からわかるように) ビジネス・プロセスの実行を定義するために規定している XML をベースとした標準です (「参考文献」を参照)。

次のセクションでは、WS-BPEL をプロセス実行層として使用し、IoC を個別タスク層で使用するワークフロー・アプリケーションのアーキテクチャーについて説明します。

上に戻る

WS-BPEL を使用して構築する構成可能なワークフロー

図 3 は、ワークフロー・アプリケーションに WS-BPEL と IoC の両方を使用したアーキテクチャーです。

図を拡大して見るには、ここをクリックしてください。

図 3 には、以下のさまざまなコンポーネントがあります。

• 要求側クライアント (Client application): 要求側クライアントのアプリケーションは、生産注文書をワークフロー・アプリケーションに送信し、生産必要高に従って生産注文が実行されることを要求します。このようなクライアント・アプリケーションは、製造会社のさまざま場所に存在する可能性があります。例えば、会社の営業部門は、顧客から注文を受けたときに要求側クライアントの役割を果たし、顧客が購入した製品を生産するための生産注文書を発行します。
  
  ワークフロー・アプリケーションでは、生産注文書を受け付けるための Web サービス・インターフェースを公開します。この記事で使用する Web サービス・インターフェースは、WSDL (Web Service Definition Language) および SOAP をベースとしたものです (WSDL および SOAP に関する記事へのリンクは、「参考文献」を参照)。
  
  
• BPEL エンジン (BPEL ENGINE): BPEL エンジンはプロセス実行層の実行ロジックを実装します。ここでは Apache ODE という Java ベースのオープンソース BPEL エンジンを使用することにします (「参考文献」を参照)。マージした生産管理ワークフローを Apache ODE でホストする方法については、第 2 回で説明します。
  
  
• BPEL ファイル (BPEL FILE) およびパートナー・リンク (PartnerLink): BPEL ファイルとは、プロセス実行層のビジネス・ロジックを構成する XML ファイルのことです (次のセクションから、BPEL ファイルに XML 構成を作成する方法について説明します)。BPEL ファイルにはタスク層を実装するパートナー・サービスへのリンクが含まれます。BPEL では、これらのリンクをパートナー・リンクと呼んでいます。パートナー・リンクについての詳細は、この後の「サービス・パートナーへのリンク」で説明します。
  
  
• WSDL ファイル (WSDL File): 図 3 を見ると、「細分化されたタスクの特定」で挙げた Bean ごとに WSDL ファイルがあります。WSDL ファイルは、タスク層を実装する Bean に XML ベースのインターフェースを定義するだけに過ぎません。
  
  
• IoC フレームワーク (IOC framework) および IoC Beans (IOC beans): Spring は、タスク層を実装する Bean のそれぞれをホストする IoC フレームワークとして機能します。

これで、マージした生産ワークフローを BPEL ファイルで構成する方法を学ぶ準備がすべて整いました。

上に戻る

プロセス実行ロジックを実装する BPEL ファイル

BPEL 構成ファイルでは、ワークフロー・アプリケーションのプロセス実行ロジックを定義することができます。例えばリスト 2 の BPEL ファイルを見てください。このファイルは、「プロセス実行層の操作」で説明したプロセス実行ロジックを実装しています。

<?xml version="1.0" encoding="UTF-8"?>
<process name="MergedProductionWorkflow"
    targetNamespace=http://fictitiousManufacturingEnterprise.com/pms
    queryLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
    expressionLanguage="urn:oasis:names:tc:wsbpel:2.0:sublang:xpath2.0"
    xmlns=http://docs.oasis-open.org/wsbpel/2.0/process/executable
    xmlns:xsd=http://www.w3.org/2001/XMLSchema
    xmlns:pms="http://fictitiousManufacturingEnterprise.com/pms">

  <import />

  <import />

  <!--other import tags--/>

  <partnerLinks />

  <variables />

  <sequence />

</process>

上記のコードから、BPEL ファイルで生産ワークフロー全体を表すルート・タグは <process> であることがわかります。<process> タグにはいくつもの属性、名前空間宣言、子タグがあり、これらがまとまって MergedProductionWorkflow のプロセス実行ロジックを定義します。リスト 2 では <process> タグの子を空のタグにしてありますが、この後、それぞれのタグの完全な内容を記載します。

<process> タグには、以下の 4 つの属性があります。

• name 属性。この属性の値が、これから構成するワークフロー (MergedProductionWorkflow) の名前を決定します。この名前は、第 2 回でワークフローのデプロイメント記述子を作成するときに参照することになります。
  
  
• targetNamespace 属性。この BPEL ファイルで使用するすべての名前が含まれる名前空間を指定する属性です。BPEL ファイルで使用する名前の種類には、例えば以下のものがあります。
  • ワークフローの名前 (MergedProductionWorkflow)
  • BPEL ファイルで使用するパートナー・リンクの名前
  • ワークフロー・データを保持するために使用する変数の名前
  
  
  
• queryLanguage 属性。BPEL ファイルで使用する問い合わせ言語を指定します。問い合わせ言語は、パートナー・サービスから送られてくるワークフロー・データ (生産注文書に含まれる生産対象製品など) を抽出して使用するために必要です。第 2 回では、BPEL ファイルで XPath (よく使われる問い合わせ言語) を使用する方法を説明します。
  
  
• expressionLanguage 属性。BPEL ファイルで使用する式言語を指定します。式言語は、ワークフロー・データで論理演算と算術演算 (生産注文書の製品の個数がゼロより大きいかどうかなど) を表現するために必要です。

BPEL ファイルの <process> タグには、複数の名前空間宣言も含まれます。

• 最初の名前空間宣言は BPEL 名前空間を表します。この名前空間は、OASIS が定義する BPEL 語彙を使用するために必要です。
  
  
• xmlns:xsd 名前空間宣言は、BPEL ファイルでスキーマ機能を使用するために必要となる XML スキーマの名前空間を指定します。この生産管理で必要となる最も重要なスキーマ機能は、カスタマイズしたデータ構造を定義する機能です。
  
  
• xmlns:pms 名前空間宣言は、生産管理システムの名前空間を表します。カスタム要素および属性を定義できるようにするには、独自の名前空間を XML アプリケーションに定義しなければなりません。また、BPEL ファイルで WSDL 定義とポート・タイプを使用するためのカスタム名前空間も必要です (BPEL で WSDL 定義を使用する方法について説明している記事へのリンクは、「参考文献」を参照してください)。

次は、<process> タグの子タグそれぞれについて 1 つずつ説明します。

外部名前空間のインポート

WS-BPEL が提供する import 要素を使用して、外部名前空間と WSDL ファイルを BPEL ファイルにインポートすることができます。これらのインポートを行ってから、WSDL または XML スキーマ文書に定義された要素を使用してください。

リスト 3 に、リスト 2 の <import> タグを展開して記載します。このリストから、マージされた生産ワークフローの BPEL 構成では 10 の <import> タグを使用していることがわかります。

<?xml version="1.0" encoding="utf-8" ?>
<process name="MergedProductionWorkflow" xmlns:...>

  <import location="ProductionManagementSystem.xsd"
      namespace="http://fictitiousManufacturingEnterprise.com/pms/"
      importType=" http://www.w3.org/2001/XMLSchema" />

  <import location="ProductionManagementSystem.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms/"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="Items2BProduced.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="TypeOfItem.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="ProcessDetails.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="LargeVarietyWO.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="ManufacturingSchedule.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="AdditionalProductionRequirement.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="ProductionReservation.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <import location="BulkProductionWO.wsdl"
      namespace="http://fictitiousManufacturingEnterprise.com/pms"
      importType="http://schemas.xmlsoap.org/wsdl/" />

  <partnerLinks />

  <variables />

  <sequence />
</process>

リスト 3 の <import> タグごとに、以下の 3 つの属性があります。

• location 属性。インポートする文書の URL を指定します。相対 URL (Items2BProduced.wsdl など)、または絶対 URL (http://fictitiousManufacturingEnterprise.com/Items2BProduced.wsdl など) のどちらでも指定することができます。
  
  
• namespace 属性。インポートする WSDL または XML スキーマの名前空間を指定します。リスト 3 で、すべての <import> タグの namespace 属性が同じ値 (http://fictitiousManufacturingEnterprise.com/pms) になっている理由は、生産管理システムの XML スキーマと WSDL ファイルは同じ名前空間に属しているからです。
  
  
• importType 属性。インポートする文書のタイプを参照します。WS-BPEL では 2 つのタイプの文書をインポートできます。XML スキーマをインポートする場合は、importType 属性の値を http://www.w3.org/2001/XMLSchema に設定します。WSDL 文書をインポートする場合は、importType 属性の値を http://schemas.xmlsoap.org/wsdl/ に設定します。

リスト 3 の最初の <import> タグは、生産管理スキーマ (XML スキーマ・ファイル) をインポートします。2 番目の <import> タグがインポートする ProductionManagementSystem.wsdl という名前の WSDL ファイルは、マージされた生産ワークフロー全体を表します。残りの 8 つの <import> タグは、「細分化されたタスクの特定」で説明した 8 つのタスクを表します。

マージされた生産ワークフローに実装する必要がある生産管理スキーマと WSDL については、第 2 回で説明します。

サービス・パートナーへのリンク

「WS-BPEL を使用して構築する構成可能なワークフロー」セクションで、BPEL アプリケーションにはタスク層を実装するパートナー・サービスが必要だと説明したことを思い出してください。パートナー・サービスは、その機能を WSDL インターフェースを使って公開します。そのため各パートナー・サービスの BPEL ファイルおよび WSDL ファイルには、パートナー・リンク (BPEL-WSDL リンク) を定義する必要があります。

まずは WSDL ファイルに BPEL-WSDL リンクを定義する方法を説明します。リスト 4 に記載する WSDL ファイルを見てください。このファイルは、Items2BProduced パートナー・サービスの機能を公開しています。

<?xml version="1.0" encoding="utf-8" ?>
<wsdl:definitions ...... >

    <wsdl:message name="ProductionOrderMessage" />

    <wsdl:message name="ProductionItemsMessage" />

    <wsdl:portType name="Items2BProducedPortType">
       <wsdl:operation name="getItems2BProduced">
          ......
       </wsdl:operation>
    </wsdl:portType>

    <wsdl:binding name="Items2BProducedBinding">
        ......
    </wsdl:binding>

    <wsdl:service name="Items2BProducedService">
          ......
    </wsdl:service>

    <plnk:partnerLinkType name="Items2BProducedLinkType">
        <plnk:role name="Items2BProduced_Role"
            portType="list:Items2BProducedPortType"/>
    </plnk:partnerLinkType>

</wsdl:definitions>

この WSDL ファイルは、「細分化したタスクの特定」で紹介した items2BProduced Bean に対応付けられます。リスト 4 では getItems2BProduced という操作を定義するために、<wsdl:types>、<wsdl:message>、<wsdl:portType>、<wsdl:operation> などの WSDL タグを使っています。これらの WSDL タグの詳細は省略してあることに注意してください (「参考文献」に、WSDL タグについて詳細に説明している記事へのリンクを記載しています)。

今度はリスト 4 の <plnk:partnerLinkType> タグに注目してください。このタグは、OASIS が定義するパートナー・リンクの名前空間に属します。<plnk:partnerLinkType> タグの name 属性が定義するのは、パートナー・リンクの名前です (リスト 4 の Items2BProducedLinkType など)。BPEL ファイルでもこのパートナー・サービスを使うために同じ名前が使用されます。

<plnk:partnerLinkType> タグにある <role> という子タグは、パートナー・サービスのビジネス・ロールを指定します。リスト 4 では、パートナー・サービスの名前に _Role というサフィックスを追加して、ビジネス・ロールの名前としています。

<role> タグの portType 属性が指定するのは、このパートナー・サービスの機能を公開する WSDL ポートです。

リスト 5 に示すように、BPEL ファイルにも同じパートナー・リンクを定義する必要があります。

<process xmlns="..">

   <import />

   <!--Other import tags--/>

   <partnerLinks>
       <partnerLink name="mergedProductionWorkflowPartnerLink"
          partnerLinkType="pms:MergedProductionWorkflowLinkType"
          myRole="MergedProductionWorkflow_Role"/>

       <partnerLink name="items2BProducedPartnerLink"
          partnerLinkType="pms:Items2BProducedLinkType"
          partnerRole="Items2BProduced_Role" initializePartnerRole="yes"/>

       <partnerLink name="typeOfItemPartnerLink"
          partnerLinkType="pms:TypeOfItemLinkType"
          partnerRole="TypeOfItem_Role" initializePartnerRole="yes"/>

       <partnerLink name="processDetails"
          partnerLinkType="pms:ProcessDetailsLinkType"
          myRole="ProcessDetails_Role" initializePartnerRole="yes"/>

       <partnerLink name="largeVarietyWOPartnerLink"
          partnerLinkType="pms:LargeVarietyWOLinkType"
          partnerRole="LargeVarietyWO_Role" initializePartnerRole="yes"/>

       <partnerLink name="manufacturingSchedulePartnerLink"
          partnerLinkType="pms:ManufacturingScheduleLinkType"
          partnerRole="ManufacturingSchedule_Role" initializePartnerRole="yes"/>

       <partnerLink name="additionalProductionRequirementPartnerLink"
          partnerLinkType="pms:AdditionalProductionRequirementLinkType"
          partnerRole="AdditionalProductionRequirement_Role" initializePartnerRole="yes"/>

       <partnerLink name="productionReservationPartnerLink"
          partnerLinkType="pms:ProductionReservationLinkType"
          partnerRole="ProductionReservation_Role" initializePartnerRole="yes"/>

       <partnerLink name="bulkProductionWOPartnerLink"
          partnerLinkType="pms:BulkProductionWOLinkType"
          partnerRole="BulkProductionWO_Role" initializePartnerRole="yes"/>

    </partnerLinks>

    <variables />

    <sequence />

</process>

上記のコードはリスト 2 の <partnerLinks> タグを展開した形で、<partnerLinks> には 9 つの <partnerLink> 子タグが含まれています。リスト 5 の最初の <partnerLink> タグは、ProductionManagementSystem.wsdl ファイル (マージされた生産ワークフロー全体を表すファイル) とのパートナー・リンクを表します。残りの <partnerLink> タグは、パートナー・サービスのそれぞれとのパートナー・リンクを表します。

上に戻る

第 1 回のまとめ

この連載の第 1 回では、BPEL と IoC を使用したビジネス・ワークフローの実装アーキテクチャー全体を説明しました。さらに、動的ビジネス・ワークフローを分析する 2 層構造のモデルを紹介するとともに、構成可能なワークフロー・アプリケーションの主要なコンポーネントすべてについても解説しました。

第 2 回では、リスト 5 の <variables> タグと <sequence> タグの詳細を取り上げ、WS-BPEL を使用して生産管理ワークフローを実装する方法を実演します。

参考文献

学ぶために

• Spring Framework: Spring のサイトにアクセスしてください。
  
  
• WS-BPEL: OASIS サイトから、WS-BPEL 仕様および関連リソースを入手できます。
  
  
• Apache ODE: ODE (Orchestration Director Engine) は、WS-BPEL 標準に従って作成されたビジネス・プロセスを実行します。
  
  
• 「Understanding Web Services specifications, Part 2: Web Services Description Language (WSDL)」(Nicholas Chase 著、developerWorks、2006年7月) および「Understanding Web Services specifications, Part 7: WS-Business Process Execution Language」(Hernan Silberman、Manas Mandal 共著、developerWorks、2007年5月): WSDL および WS-BPEL については、Web サービス仕様に関する連載に含まれるこの 2 つのチュートリアルで詳しく説明しています。
  
  
• 「The Spring series, Part 1: Introduction to the Spring framework」(Naveen Balani 著、developerWorks、2005年6月): Spring の IoC コンテナーについて紹介する記事を読んでください。
  
  
• 「Design Better Software with the Inversion of Control Pattern」(Mani Malarvannan 著、DevX.com、2005年3月): この記事では IoC デザイン・パターンについて解説しています。
  
  
• 「WSDLによるWebサービスの配置: 第1回」(Bilal Siddiqui 著、developerWorks、2001年11月): WSDL を使用して Web サービス・インターフェースを作成する方法を学んでください。
  
  
• technology bookstore で、この記事で取り上げた技術やその他の技術に関する本を探してください。
  
  
• developerWorks Java technology ゾーン: Java プログラミングのあらゆる側面を網羅した記事が豊富に用意されています。
  
  
• developerWorks SOA and web services ゾーン: Web サービス・アプリケーションの開発方法についての情報記事と初級者、中級者、上級者向けのチュートリアルが豊富に揃っています。
  
  

製品や技術を入手するために

• Spring Framework: Spring をダウンロードしてください。
  
  
• Apache ODE: ODE をダウンロードしてください。
  
  

議論するために

• developerWorks blogs から developerWorks コミュニティーに加わってください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ビジネス・ワークフローの性質
• ビジネス・ワークフローの 2 層構造モデル
• IoC を使用してタスク層を実装する方法
• WS-BPEL を使用して構築する構成可能なワークフロー
• プロセス実行ロジックを実装する BPEL ファイル
• 第 1 回のまとめ
• 参考文献
• 著者について
• コメント