WSFLの仕組みを理解する（2）
■ステップ3 フローモデルの定義
次に内部フローを定義する。まず、ここでは、登場人物（旅行者、旅行業者、航空会社）をサービス・プロバイダという位置付けで定義している。それぞれ、travelerType、agentFlow、airlineFlowという名前になっている。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
次に、airlineFlowのフロー・モデルを見てみよう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
このフロー・モデルは、airlineFlowが持つ「bookTicket（チケットの予約）」（1）というフローだ。このフローは、「receivedTicketOrder」というデータタイプから始まることを示しており（2）、最初のアクティビティは、receiveTicketOrderから始まり（4）、spawnで定義されている（3）。
その後アクティビティが4つ（reserveSeats、chargeCreditCard、confirmFlight、issueETicket）定義され、それぞれの間を「データの流れ」と「処理の流れ」でつなぐための定義が「controlLink」、「dataLink」として定義されている。このほか、同様にAgentのフロー・モデルも定義される。
■ステップ4 グローバル・モデルの定義
グローバル・モデルは、ここまでに定義されてきたサービス・プロバイダ「agentFlow」と「airlineFlow」同士をつなぎ合わせて、さらに大きなサービス・プロバイダ「agentNAirlineFlow」にしてしまおうという定義である。
このサービス・プロバイダは「tripNTicketHandler（旅行とチケット取り扱い業者）」という新しいポート・タイプを持っており、receiveTripOrder、sendItinerary、sendETicketsという操作が定義されている。そして、それぞれの操作は中に含まれる2つのサービス・プロバイダから「export」指定によりマッピングされる、という具合である。
中に含まれる2つのサービス・プロバイダが持つ、エクスポートされないポートに関しては、後半でplugLink要素でお互いが接続されているのが分かるだろうか。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
まず、別々のサービス・プロバイダが持っている「receiveTripOrder」、「sendItinerary」、「sendETicket」を貼り合わせて、新しいポートタイプ「tripNTicketHandler」を定義する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
次に、このポートを持っている新たなサービス・プロバイダ「agentNAirlineFlow」を定義する。これが、AgentとAirlineを合体させた複合Webサービスを表現する。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
新しく作成されたサービス・プロバイダ「tripNTicketHandler」は、それ自体新たなグローバル・モデルを作るときのインプットにすることができ、さらに大きなサービス・プロバイダを定義することも可能だ。
サービス・プロバイダとして定義された複合Webサービスは、検索対象としてUDDIなどに登録することができると考えられる。
以上のような定義で、複数のWebサービスを「コンポーネント」として組み立て、その定義をXMLドキュメントで表すことができるようになる。これがWSFLが行おうとしていることである。
定義されたWSFLはどのように使われるか、ということに関してはまだ具体的ではないが、Webサービスを統合するワークフロー・エンジンの定義に使われたり、浅い意味ではあるが、簡単なセマンティクスの定義といえないこともない。複雑なWebサービスを作り上げていく、将来のテクノロジといえるだろう。
Copyright © ITmedia, Inc. All Rights Reserved.