Web Servicesインサイダー 第6回: 責任の引き受け

WSFLにおける役割のインプリメント

Web Servicesは、テクノロジーとビジネスの両分野にわたって、きわめて動的で多用途の分散アプリケーションを作成することを可能にし、サービス提供者およびサービス消費者がビジネスの方法を改善できるようにします。Web Service Flow Language (WSFL) は、サービス提供者とサービス消費者が協力して標準的なビジネス・プロセスをインプリメントするために使用できるフレームワークを構築することにより、この可能性を広げます。(それは「誰が何をする」というよりも、「何がなされた」ということの方が重要という立場をとります。)このフレームワークは、適切なWeb serviceインターフェースを正しくインプリメントした人が、ビジネス・プロセスにおけるさまざまな役割を担うことができるようにします。Web Serviceインサイダー・シリーズの今回の記事では、前回に引き続いてWSFLを取り上げ、サービス提供者になる方法を中心にお話しします。

James Snell (jasnell@us.ibm.com), Software Engineer, Emerging Technologies, IBM

James Snellは、IBMのEmerging Technologies Toolkitチームの一員です。過去2年間は、新興のWebサービス技術や標準などに焦点を当てており、またAtom 1.0仕様にも貢献しました。新興技術に焦点を当てたウェブログ、http://www.ibm.com/developerworks/blogs/page/jasnellを維持管理しています。



2001年 7月

Web Servicesインサイダー・シリーズの前回の記事 (参考文献を参照) では、ビジネス・プロセスのモデル化、およびそれらのビジネス・プロセスをインプリメントするためのさまざまな責任を果たす、サービス提供者タイプの概念を紹介しました。今回は、WSFLサービス提供者になるということについて、さらに詳しく検討します。幸いなことに、そのために必要な作業は、Web Services対応プラットフォームを使用して単一または複数のWSDLのWeb serviceインターフェースをインプリメントすることだけです (そのプラットフォームがWSFLであるか、あるいはWSDL対応であるかどうかは問いません)。つまり、WSFL service提供者の役割を引き受けるためには、WSFLについての知識を必要としないのです。Web Servicesインターフェース定義を受け入れて、それを実際のWeb Servicesインプリメンテーションに変換する方法さえ知っていればよいのです。その方法については、これから説明します。

プロセスの概要

WSFLフロー・モデルにおけるすべてのアクティビティーは、Web service提供者によって提供されるWeb serviceの形でインプリメントされ、そのプロセスの中で定義されている役割のうちの1つを果たします。当然のことですが、それぞれのサービス提供者は、実際にそのアクティビティーを実行するWeb serviceまたはWeb serviceのセットをインプリメントするための要件を、正しく満たすものと期待されています。WSFLフロー・モデルにおけるそれぞれのアクティビティーは、WSFLグローバル・モデルに含まれる情報を使用して、実際のWeb serviceインプリメンテーションにリンクされています (図1 を参照)。それぞれのWeb serviceインプリメンテーションは、そのインプリメンテーションについてのWSDLベースの記述を指し示し、その記述は、そのWeb serviceとの間で送受信できる実際のメッセージおよび操作をすべて記述する、WSDLベースのインターフェース記述にリンクされています。

図1: 旅行予約ビジネス・プロセスのフロー・モデル
旅行予約ビジネス・プロセスのフロー・モデル

上記のグラフィカルな表記によるビジネス・プロセスのフロー・モデル対応するグローバル・モデルをリスト1 に示します。

リスト1:  旅行予約ビジネス・プロセスのグローバル・モデル
<globalModel name="bookTripNTickets" serviceproviderType="agentType">
  <!-- Defines the identity, location and implementation of the service 
        provider fulfilling the role of the travel agent -->
  <serviceProvider name="travelAgent" serviceProviderType="tio:agentType">
    <export>
      <source portType="tio:tripHandler" operation="sendItinerary"/>
      <target portType="tio:tripNTicketHandler" operation="sendItinerary"/>
    </export>
    <export>
      <source portType="tio:tripHandler" operation="receiveTripOrder"/>
      <target portType="tio:tripNTicketHandler" operation="receiveTripOrder"/>
    </export>
    <locator type="..." />
  </serviceProvider>
 
  <!-- Defines the identity, location and implementation of the service provider 
        fulfilling the role of the airline -->
  <serviceProvider name="airline" serviceProviderType="tio:airlineType">
    <export>
      <source portType="tio:ticketDelivery" operation="sendETicket"/>
      <target portType="tio:tripNTicketHandler" operation="sendETickets"/>
    </export>
  </serviceProvider>
 
  <!-- A plugLink links the output of an operation of one service provider to 
       the input of an operation for another service provider -->
  <plugLink>
    <source serviceProvider="airline" portType="tio:ticketHandler" 
operation="sendConfirmation"/>
    <target serviceProvider="travelAgent" portType="tio:tripHandler" 
operation="waitForConfirmation"/>
  </plugLink>
  <plugLink>
    <source serviceProvider="travelAgent" portType="tio:tripHandler" 
operation="requestTicketOrder"/>
    <target serviceProvider="airline" portType="tio:ticketHandler" 
operation="receiveTicketOrder"/>
  </plugLink>
</globalModel>

WSFLで定義されたプロセスでサービス提供者の役割を果たすためには、まず最初に、Web serviceにインプリメントする必要のある基本的なデータ型、メッセージ、およびポート・タイプを定義するWSDL文書にアクセスできるようになっている必要があります。そのうえで、必要なポート・タイプ内で定義されているそれぞれの操作をインプリメントするアプリケーション・コードを設計および作成し、そのコードをWeb Servicesプラットフォーム (IBM WebSphere Application Server 4.0やApache SOAPなど) に配置する必要があります。


プロセスの一部となる

ありがたいことに、読者がビジネス・プロセスの一部になりたいときには、Web serviceの作成方法さえ本当に分かっていれば十分です。これが分かっていれば、必要なことは、Web serviceインプリメンテーションをフロー・モデルで定義された役割のうちの1つにリンクする、WSFLグローバル・モデルにプラグインすることだけです。このリンクは、静的に (グローバル・モデルが読者のWeb serviceを特定の役割のサービス提供者として明示的に識別することによって) 行うことも、動的に (グローバル・モデルがサービス提供者を選択するための検索規則のセットを指定し、読者のWeb serviceが選択されるようにすることによって) 行うこともできます。

Web serviceの作成方法を詳しく述べた参考文献はたくさんあります。私は、自分でWeb Services ToolKitのチュートリアル (参考文献を参照) を書いている手前、公平な評価は下しにくいので、ここではそれらについて詳しくは立ち入らないことにします。その代わりに、Web serviceインプリメンテーションをグローバル・モデルにプラグインする方法を説明するために、若干の例を以下に示します。

まず初めに、開発者である読者が、インプリメントしたWeb serviceのWSDL記述を提供します。この記述では、クライアント・アプリケーションが読者のWeb serviceを呼び出すのに必要となる、すべての情報を提供します。WSFLワークフローの場合、「クライアント」は、各種のアクティビティーをインプリメントする他のWeb serviceです。自分のWeb serviceが他のサービスを呼び出す方法は、自分のフロー・モデルがデータおよび制御リンクをどのように定義しているのかによって異なります。作成されたWSDLは、ネットワーク・アクセス可能なロケーション、できれば自分のWebサーバーに配置する必要があります。そして、オプションとして、WSDLで定義されたWeb serviceをUDDIレジストリーに公開することができます。

さしあたっては、以下のステップが行われるものと想定してください。http://acme.com/services/agent.wsdlAgent.wsdl という名前のWSDL文書があります。そのWSDL文書のターゲット・ネームスペースはurn:Agent_Service_Implementation であり、Web serviceの名前はAgentService です。このサービスの目的は、上記のビジネス・プロセスにおける旅行代理店の役割を果たすことです。

WSFL仕様で定義されているように、Web serviceの配置方法は4つあります。すなわち、静的な配置、ローカルでの配置、UDDI経由による配置、またはビジネス・プロセスの実行中における動的な配置です。

静的な配置を行う場合は、WSDLサービス定義への直接リンクをWSFLグローバル・モデルに追加するだけで済みます。これにより、どのような決定も行うことなく、WSFLワークフロー・エンジンに対して自分のWeb serviceの配置場所が正確に示されます (リスト2 を参照)。

リスト2:  サービスの静的配置
<serviceProvider name="travelAgent" type="tio:agentType">
    <!-- the service attribute is a QName that links to
        the service definition within a WSDL document -->
    <locator type="static" service="abc:agent"/>
</serviceProvider>

「ローカル」サービスはWeb serviceですが、必ずしもWeb serviceインターフェースを介して提供されるとは限りません。むしろ、要求を処理するワークフロー・エンジンにとってローカルなアプリケーションまたはJavaクラスの形を取ります。これらのアプリケーションは、WSDL文書を使用して記述することもできますが、その記述方法は若干異なります。WSFL仕様では、ローカル・サービスに関してさらに詳しく記述することができます (リスト3を参照)。

リスト3:   サービスの「ローカル」配置
<locator type="local">
    <!-- whatever information is needed to locate the local service.  This is 
        up to the WSFL implementation -->
</locator>

Web serviceを検索する3番目の方法は、UDDI照会を使用するやり方です。基本的に、グローバル・モデルはUDDIのfind_service 操作を定義します。これは、UDDIレジストリーを検索し、目的に合ったWeb serviceの候補のリストを検索するためです。グローバル・モデルは、選択ポリシー を使用することにより、検索結果で戻されたWeb serviceの中から、ビジネス・プロセスの役割を果たすために使用するものを選択します。有効な選択ポリシーとしては、リスト内の最初のサービスを選択する、リストからランダムにサービスを選択する、またはなんらかのユーザー定義のアルゴリズムを使用するなどのポリシーがあります。グローバル・モデルは、いつUDDI照会を実行するのかを指示することができます。選択肢としては、開発時に照会を実行する方法 (この場合、WSFLモデルが実稼働環境に配置されると、UDDI照会は静的ロケーターによって置き換えられます)、または実行時に照会を実行する方法 (この場合、そのフロー・モデルが初めて起動されるときにUDDI照会が実行されます) があります (リスト4 を参照)。

リスト4:  UDDIベースのサービス検索
<locator type="uddi" bindTime="startup" selectionPolicy="first">
    <uddi-api:find_service businessKey="uuid_key"
        generic="1.0" xmlns:uddi-api="urn:uddi-org:api">
        ...
    </uddi-api:find_service>
</locator>

UDDIを使用するとWSFLの柔軟性と能力が大幅に向上し、複数のサービス提供者にビジネス・プロセスでの役割を果たす権利を競わせることができます。しかし、WSFLの柔軟性を最も大幅に向上させるものは、モビリティー・ロケーター・メカニズムです。モビリティー・ロケーターを使用すると、WSFLワークフロー・エンジンは、プロセスの起動時に適用される一連の規則だけに基づいて、サービス提供者を選択できるようになります。たとえば、10,000ドルを超える金額の注文が行われる場合、ワークフロー・エンジンは、10,000ドル未満の注文の場合とは異なるWeb serviceインプリメンテーションを選択することができます。

モビリティー・ロケーターは、実際に起動するWeb serviceインプリメンテーションを選択するために従わなければならない条件を探すために、メッセージのどの部分を使用してWeb serviceを起動するのかを指定します (リスト5 を参照)。

リスト5:  サービスのモビリティー検索
<locator type="mobility" activity="getFlight"
      message="flightInfo" messagePart="airline" dataField="providerInfo">
     <!-- rules for applying the mobility locator, these
        are determined by the WSFL implementation -->
</locator>

要約

ビジネス・プロセスで定義された任意のアクティビティーを任意のWeb service提供者がインプリメントできるというWSFLの能力は、おそらくWSFLの最も強力で便利な機能のうちの1つです。動的に検索を行い、ユーザー定義の一連の規則に基づいてサービス提供者にバインドする能力は、Webによるビジネスの運営に、これまで存在しなかった新しい次元 (緩やかに結合されたアプリケーション・コンポーネントの動的な連携と統合) を付け加えます。このコラムの次回の記事では、WSFLのもう1つのすばらしい機能である、既存のビジネス・プロセスから新しいビジネス・プロセスを帰納的に構築する能力を紹介します。

参考文献

  • このコラムのこれまでの3つの記事 (第3回第4回、および第5回) を読んでください。
  • Web Services Toolkitを使用してWeb Servicesをインプリメントする方法を学んでください。
  • WSFL仕様を読んでください。
  • Google で検索されたビジネス・プロセス・モデル化の参考文献を調べてください。
  • SOAPWSDL、およびUDDI について学習してください。
  • IBMの MQSeriesおよびそのワークフロー・コンポーネント(日本語サイト)について学習してください。

コメント

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=242282
ArticleTitle=Web Servicesインサイダー 第6回: 責任の引き受け
publish-date=072001