WSFLを紹介する4回の連載記事からなるこのシリーズを開始したとき、わたしの目標は、WSFLの意味、その機能、使用法、および有用性について基本的な考え方を提供するという簡単なものでした。しかし、WSFLを完全に説明するためには、WSFLの中核機能の1つである"ビジネス・プロセスの再帰的構成" を避けて通るわけには行きません。

再帰的構成の紹介

再帰的構成の考え方は単純です。すなわち、新しいビジネス・プロセスの定義は、既存のビジネス・プロセスを結合することによって行うことができるということです(図1 を参照)。この記事ではWeb Servicesについて説明しますので、ここでの再帰的構成の本質的な意味は、WSFLを使用することにより、あるビジネス・プロセスをWebServicesインターフェース(WSDL文書) でラップし、それを対話相手の他の任意のWebServiceと同じように扱うことができるということです。

読者は「だからどうした?」と思うかもしれません。その質問に、わたしは実生活のシナリオを用いてお答えします。たとえば、あなたがReaderCo社に勤めていて、1冊の本を買いたいと思っています。あなたの会社は、WSFLでモデル化した調達ビジネス・プロセスをすでに導入しています。さて、わたしが勤めるSnellCo社は書籍販売会社です。わたしは、書籍注文を処理するためのビジネス・プロセスを導入しています。あなたのWSFLフロー・モデルには、注文処理ができる会社に注文を発行するアクティビティーが組み込まれています。わたしのWSFLフロー・モデルは、注文を受け取った後でしか処理を開始できません。したがって、わたしがビジネス・プロセスをWSDLインターフェースでラップして、それを"書籍注文Web Service" としてWebに公開すれば、あなたのWSFLフロー・モデルは、わたしのサービスを見つけ出し、注文を発行できるようになります。

このシナリオでは、わたしのWSFLフロー・モデルがどんな形態かについて、あなたは気にする必要がなく、単にそれに注文を入れて処理させればよいわけです。また、わたしとしても、あなたのWSFLフロー・モデルがどのような形態になっているかについてまったく気にする必要はなく、単にあなたから注文を受け取るだけで処理できます。WSFLは再帰的構成をサポートしていますので、あなたとわたしは、この2つのビジネス・プロセスをリンクすることができ、発行する注文のフォーマットについて合意しておくだけで済みます。これにより、分散ワークフロー・アーキテクチャーを維持しながら、業務の単純化が図れます。

上に戻る

ビジネス・プロセスの非公開部分

WSFLでは、すべてのビジネス・プロセスが非公開部分と公開部分の両方を持っています。内部からは見えるが、外部には見えない処理があります。あるビジネス・プロセスの非公開部分は、そのビジネス・プロセスの非公開インターフェース と呼ばれ、同様に、公開部分は公開インターフェース と呼ばれます。ビジネス・プロセスが実際に何を実行するかを定義したフロー・モデルとグローバル・モデルが入っているのは、非公開インターフェースです。WSFLを利用すれば、そのプロセスの個々の部分(たとえば、注文を受け取ったり、受領書を発行したりした時点など) を受け取り、それらをビジネス・プロセス公開インターフェースの一部としてエクスポート することができます。図2 は、WSFL内の個々のアクティビティーをエクスポートすることにより、他のアプリケーションとの対話を可能にするビジネス・プロセスのWSDLインターフェースを構築する方法を示しています。

WSFLアクティビティーをエクスポートする操作は、Javaクラスの操作にpublic のマークを付ける処理に似ています。つまり、あるメソッドがpublic とマーク付けされると、このメソッドは、そのJavaクラスを利用する他のアプリケーションから見ることができ、かつアクセスできるようになります。アクティビティーをエクスポートする場合は、これとまったく同じであり、そのアクティビティーは見えるようになり、WSDLを使って記述したWebServiceインターフェース記述の一部になります。それを分かりやすく説明するために、簡単な例を示します。

まず、図3 のような非常に簡単なワークフロー・プロセスを考えます。

ここには、在庫品の検査、最適な販売価格の決定、および在庫品の販売 という3つのアクティビティーしかありません (非販売の操作 は、本質的にそのワークフローを終了させ、それ以上のアクティビティーは行われません)。このプロセスのフロー・モデルは、リスト1 のようになります。

                
<flowModel name="sample" serviceProviderType="sampleType">
 <flowSource name="samplesource">
    <output name="processInstanceData" message="tio:doStocks"/>
  </flowSource>
  <serviceProvider name="buyer" type="buyerType"/>
  <serviceProvider name="seller" type="sellerType"/>
  <export lifecycleAction="spawn">
    <target portType="tio:sample" operation="doStocksRequest">
      <map sourceMessage="doStocks"
targetMessage="processInstanceData" targetPart="request"/>
    </target>
  </export>
  <activity name="checkStocks">
    <input name="checkStocks" message="tio:checkStocks"/>
    <output name="checkStocksOutput" message="tio:stockQuote"/>
    <performedBy serviceProvider="buyer"/>
    <implement>
<!--implementation details -->
    </implement>
  </activity>
  <activity name="determineSellPrice">
    <input name="dataIn" message="tio:stockQuote" />
    <output name="dataOut" message="tio:sellOrder"/>
    <performedBy serviceProvider="buyer"/>
    <implement>
<!--implementation details -->
    </implement>
  </activity>
  <activity name="sellStocks" >
    <input name="sellOrder" message="tio:sellOrder"/>
    <output name="sellOrderOut" message="tio:sellConfirmation"/>
    <performedBy serviceProvider="buyer"/>
    <implement>
<!--implementation details -->
    </implement>
  </activity>
  <controlLink name="c1" source="checkStocks"
target="determineSellPrice"/>
  <controlLink name="c2" source="determineSellPrice"
target="sellStocks"/>
  <dataLink  name="c1" source="checkStocks" 
target="determineSellPrice"/> 
  <dataLink  name="gT-rS-data"
source= "determineSellPrice" target="sellStocks"/>
</flowModel>

在庫品の検査 と在庫品の販売 という2つの操作の場合、ビジネス・プロセスは、そのビジネス・プロセスの外部にあるWebServicesと対話する必要がありますので、これらのアクティビティーをプロセスの公開インターフェースとしてエクスポートする必要があります。これを行うには、リスト2 に示されているようなフロー・モデルのエクスポート・メカニズムを使用します。

                
  <activity name="checkStocks">
    <input name="checkStocks" message="tio:checkStocks"/>
    <output name="checkStocksOutput" message="tio:stockQuote"/>
    <performedBy serviceProvider="buyer"/>
    <implement>
      <export portType="tio:stockBuyer" operation="checkStocks">
      <map sourceMessage="checkStocks" sourcePart="check"
targetMessage="checkStocksOutput" targetPart="stockQuote"/>
      </export>
    </implement>
  </activity>

これで、WSFLインプリメンテーション・エンジンは、グローバル・モデルを受け取り、WSDL生成プロセスを使ってそれを実行し、公開WebServiceインターフェース (WSDLportType) 定義を作成できるようになります (リスト3 を参照)。

                
<definitions>
     <message name="checkStocks">
        <part name="check" element="tio:checkStocks" /> 
     </message>
        
     <message name="sellStocks">
        <part name="order" element="tio:sellStocks" /> 
     </message>
        
    <portType name="stockBuyer"> 
       
         <operation name="checkStocks">
           <input message="tns:checkStocks" />
           <output message="tns:checkStocksOut" />
         </operation>
       
         <operation name="sellStocks">
           <input message="tns:sellStocks" />
           <output message="tns:sellConfirmation" />
         </operation> 
    </portType>
</definitions>

さてここで、これまで実行してきたことを説明するために、後戻りをします。在庫品の検査 操作について考えます。このアクティビティーを実行するためには、WSFLエンジンが、ネットワーク上のどこかに配置された在庫見積サービスにWebサービス要求を出す必要があります。ただし、このエンジンは、その呼び出しを実行するための方法と実行すべき内容を正確に知っていなければなりません。WSDLでは、在庫品の検査 操作は要求 / 応答操作です。WSFLグローバル・モデルのプラグリンク・メカニズムを使用して、この操作を実行するために必要な情報をエンジンに提供し、このエンジンを実行対象のビジネス・プロセスと結合します。

では、これを再帰的構成と結合するにはどうすればよいでしょうか?WSFLワークフロー内のすべてのアクティビティーは、WebServiceによって公開されている操作によって実行されます。これらの操作は、WSDLポート・タイプ定義を使って公開されます。WSFLグローバル・モデルとプラグリンクを使用すれば、ビジネス・プロセスのさまざまな部分についてWSDLポート・タイプ定義を構築することができます。2つの部分を互いにリンクできるため、あるプロセスのアクティビティーが別のプロセスの公開インターフェースを介してインプリメントされます。図4 は、あるプロセスのアクティビティーが別のプロセスの公開インターフェースと結合されている、再帰的に構成されたプロセスを示しています。

上に戻る

サービスの統合

再帰的構成は、さまざまなプロバイダーが提供するサービスを統合して単一のソリューションにまとめ上げるための1つの方法を提供します。たとえば、サービス・プロバイダーは注文WebServiceを提供できますが、これは、実際には、多くの異なるサービス・プロバイダーから提供されたWebServices (たとえばクレジット・カード認証、ロジスティックなどのサービス)を統合したものです。エンド・ユーザーの観点からは、注文サービスは見えますが、背後で行われているすべての操作が見えるわけではありません。

上に戻る

動的構成

ワークフロー内の特定のアクティビティーを実行するために、どのWeb Serviceインプリメンテーションとサービス・プロバイダーを使用すればよいかを動的に選択するWSFLの機能と、再帰的構成の考え方とを結合することにより、柔軟性のレベルがさらに高まります。このプロセスは、前回の記事で説明したプロセスとまったく同じです(参考文献を参照)。

複数のサービス・プロバイダーは、まったく同じ公開インターフェースを使って、完全に異なる2つのワークフローをインプリメントすることができます。これらのサービス・プロバイダーは、同一セットのWebService操作をエクスポートしますので、それらは互いに交換可能です。WSFLフロー・モデルはWebServicesの公開インターフェース (そのインターフェースの特定のインプリメンテーションではなく)にリンクするので、どちらのサービス・プロバイダーもそのアクティビティーを実行することができます。WSFLエンジンは、WSFLフロー・モデルの設計者によって提供された規則に基づいて作成されているため、特定の状態でどのサービス・プロバイダーを使用すればよいかを動的に決定することができます。

上に戻る

まとめ

WSFLは、正しく利用すれば、企業内における包括的なWeb Servicesストラテジーの重要なコンポーネントになります。これらの考え方の多くは相当に複雑であり、また、優れたビジネス・プロセスの設計作業が、どう見ても一筋縄でいかないことは、ほとんど疑う余地のないところです。しかし、適切な量の練習、正しい種類のツール、および少しの忍耐で、複雑さを耐えてあまりある利益を得ることができます。

わたしがこのシリーズの記事で目指した目標は、WSFLを紹介するということだけでした。そのため、詳細な説明を控え目にしたところも多くありましたし、また完全に無視した部分もありました。わたしの狙いは、皆さんをエキスパートにすることではなく、WSFLの基本的な考え方を実際に試してもらうことでした。皆さんがまだ読んでいない場合は、WSFLの仕様を読むことをお勧めします。その仕様を学び、この考え方を実行し、ワークフローを統合するための練習を行ってください。また、いつものように、コメントや質問がある場合は、わたし宛てにメールを送信してください。

参考文献

• このシリーズの前回までの記事、第4回、第5回、および第6回 を読んでください。
  
  
• alphaWorksからWeb Services Process Management Toolkit をダウンロードしてください。
  
  
• WSFL仕様 をよんでください。
  
  
• SOAP、WSDL、およびUDDI について調べてください。
  
  
• WebSphere MQ とそのワークフローのコンポーネントを調べてください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• 再帰的構成の紹介
• ビジネス・プロセスの非公開部分
• サービスの統合
• 動的構成
• まとめ
• 参考文献
• 著者について
• コメント