JP2007018122A

JP2007018122A - Ｗｅｂサービスカスタマイズシステム

Info

Publication number: JP2007018122A
Application number: JP2005197001A
Authority: JP
Inventors: Hiroyuki Kobayashi; 宏至小林
Original assignee: Hitachi Software Engineering Co Ltd
Current assignee: Hitachi Software Engineering Co Ltd
Priority date: 2005-07-06
Filing date: 2005-07-06
Publication date: 2007-01-25
Anticipated expiration: 2025-07-06
Also published as: JP4702835B2

Abstract

【課題】
業務システムを構成するWebサービスを、その業務に適するようにカスタマイズする技術を提供することを目的とする。
【解決手段】
ワークフローに従って呼び出すWebサービスをカスタマイズするWebサービスカスタマイズシステムで、適用対象となるWebサービスを指定する記述、ワークフロー中の当該Webサービスに係る記述に対して追加・変更する処理の記述、及び、当該Webサービスに対して追加・変更する処理の記述を含む業務ポリシーを作成し、Webサービスを連係して呼び出すことにより所定の業務を実行するビジネスロジックを記述したワークフローを作成する。作成したワークフローに対して、業務ポリシーの記述に応じて、適用対象となるWebサービスに係る記述部分に必要な追加・変更を施すとともに、ワークフローから呼び出されるWebサービスに対して、業務ポリシーの記述に応じて必要な追加・変更を施す。
【選択図】図１

Description

本発明は、複数のWebサービスをワークフローで連携させて一連のサービスを実行するシステムを構築する際に、業務にあわせてWebサービスを変更する技術に関するものである。

近年、業界再編や企業の統廃合、連結経営に伴うグループ企業間の連携、コンプライアンスの確保など、企業の経営を取り巻く環境は大きく変化しており、その変化に迅速に対応できる柔軟な企業情報システムを構築する手法として、SOA(Service Oriented Architecture)が注目されている。SOAの特徴は、サービスの組換えが容易なビルディングブロック方式による高い柔軟性を備えていることである。これを実現する技術として、複数のWebサービスを連携させて業務システムを構築するワークフロー(記述言語 WS-BPEL: Web Services Business Process Execution Language)がある。

このワークフローを用いて業務システムを構築する場合、通常のビジネスロジックの他に横断的な関心事（アクセス制御、ロギング、トランザクション処理など）についてもWS-BPELで記述することになる。ビジネスロジックと横断的な関心事とを分離して記述する方法として、WS-BPELにAOP(アスペクト指向プログラミング)を適用したAO4BPELが存在する（非特許文献１参照）。これは、ビジネスロジックのみ記述されたWS-BPELインスタンスと、横断的な関心事の処理を記述したWS-BPELインスタンスとを別々に記述しておき、ワークフローの実行時にジョイントポイントによって指定されたビジネスロジックのWS-BPEL上の場所に横断的な関心事の処理のWS-BPELインスタンスを組込み、ビジネスロジックと横断的な関心事の処理を含む完全なWS-BPELインスタンスを完成させ実行するものである。この手法は、ビジネスロジックと横断的な関心事とを分離して記述できること、均質な横断的な関心事を規則的に組込むことができること、などの利点がある。
A. Charfi and M. Mezini. Aspect-Oriented Web Service Composition with AO4BPEL In Proceedings of European Conference on Web Services (ECOWS '04), Erfurt, Germany, September 2004.

しかしながら、AO4BPELはWS-BPELインスタンスのみの編集を目的としており、Webサービス自身の編集は考慮されていない。上述したような横断的な関心事の中で、アクセス制御やロギングなどは、業務によってWebサービス側で行う必要があり、しかも１つのWebサービスが複数の業務ワークフローから利用されている場合は、その業務に関連する法令などに従いアクセス制御やロギングの内容を変更する必要がある。したがって、従来方法のようにWS-BPELインスタンスを変更するだけでは不十分であり、Webサービス自身にも、呼び出される業務ワークフローに合わせて必要な処理を組込む必要がある。

本発明の目的は、特定の業務システムのワークフローを構成するWebサービスを、要求される業務に適するようにカスタマイズする技術を提供することにある。

上記目的を達成するために、本発明は、ワークフローに従ってWebサービスを連係して実行するシステムにおいて、ワークフローに従って呼び出すWebサービスをカスタマイズするWebサービスカスタマイズシステムであって、適用対象となるWebサービスを指定する記述、ワークフロー中の当該Webサービスに係る記述に対して追加・変更する処理の記述、及び、当該Webサービスに対して追加・変更する処理の記述を含む業務ポリシーを作成する手段と、Webサービスを連係して呼び出すことにより所定の業務を実行するビジネスロジックを記述したワークフローを作成する手段と、作成したワークフローに対して、前記業務ポリシーの記述に応じて、適用対象となるWebサービスに係る記述部分に必要な追加・変更を施す手段と、前記ワークフローから呼び出されるWebサービスに対して、前記業務ポリシーの記述に応じて必要な追加・変更を施す手段とを備えることを特徴とする。

上記業務ポリシー中で適用対象となるWebサービスを指定する記述は、例えばWebサービスのpartnerLink名で記述すればよいが、Webサービスの特定業務内の役割を明確にできるようにpartnerLinkのnameを決められた規則に従い名付けるようにするとよい。例えば、Webサービスの業務種類や内容に応じてWebサービスのpartnerLink名の頭の文字を決めておき、業務ポリシー中の適用対象となるWebサービスの記述ではそのWebサービスのpartnerLink名の頭の文字を指定するようにしておけば、ワークフローから呼び出しているWebサービスのpartnerLink名を元にしてどのWebサービスにどのポリシーを適用するのかが分かる。なお、業務ポリシーとは、特定業務を行うのに必要な処理が記述された業務プロファイルである。

Webサービスに対して業務ポリシーの記述に応じて必要な追加・変更を施すのは、例えば以下のように行う。予めWebサービスに組み込むべきコンポーネントを作成しておく。業務ポリシーには、適用対象のWebサービスに対して、当該追加するコンポーネントを指定する記述と当該コンポーネントを追加する場所の記述（Webサービスの本来の処理を行う前または後など）を含めておく。そして、業務ポリシーに基づいて、適用対象のWebサービスに対し、前記指定された場所に前記指定されたコンポーネントを追加する。

Webサービスに対して上述したような追加・変更が施されるので、当該Webサービスのインターフェイスが変更されることになる。そこで、変更されたWebサービスに合わせて、その業務に特化したWebサービスのWSDLを生成するものとする。Webサービスの呼び出しは、上記のように生成されたWSDLに従いSOAPメッセージを生成してWebサービスを呼び出すようにする。

本発明のWebサービスカスタマイズシステムによれば、業務に応じてワークフローから呼び指すWebサービスをカスタマイズでき、これによりWebサービス側に横断的な関心事の処理（アクセス制御、ロギング、トランザクション処理など）を行わせることができる。また、１つのWebサービスが複数の業務ワークフローから呼び出される場合であっても、それぞれの業務に必要とされる要件に合わせた形で各業務ワークフローがそのWebサービスを利用することができるようになる。これにより、同じWebサービスを別々の業務ワークフローから利用する場合、それぞれの業務に応じた処理をWebサービスに組み込むことができ、業務別に必要な処理を行うことができる。

以下、本発明を適用したWebサービスカスタマイズシステムの一実施の形態について説明する。

図１は、本発明の実施の形態の一例を示すシステム構成図である。本Webサービスカスタマイズシステムは、エディタ装置１１０、ワークフロー変換装置１２０、ワークフローエンジン１３０、及びWebサービスサーバ１４０を備える。エディタ装置１１０は、ビジネスロジックを記述するWS-BPELインスタンス、組込むコンポーネント、及びワークフローに対する業務ポリシーを記述する装置である。ワークフロー変換装置１２０は、業務ポリシーに従いビジネスロジックが記述されたWS-BPELインスタンスへの必要な処理の追加、及びWebサービスへの必要なコンポーネントの追加を行う。ワークフローエンジン１３０は、ワークフロー変換装置１２０で生成した完全なWS-BPELインスタンスを実行する。Webサービスサーバ１４０は、ワークフローが利用するWebサービスを実行する。

ワークフロー変換装置１２０は、通信を行う通信部１２１、業務ポリシーを保持するポリシーＤＢ１２２、Webサービスに組込むコンポーネントを保持するコンポーネントＤＢ１２３、及び、本ワークフロー変換装置の動作を制御する制御部１２５を備える。制御部１２５は、ビジネスロジックが記述されたWS-BPELインスタンスを解析するWS-BPELインスタンス解析部１２６、業務ポリシーに従いビジネスロジックが記述されたWS-BPELインスタンスに対して必要な処理を追加するWS-BPELインスタンス変換部１２７、及び、業務ポリシーに従い関連するWebサービスに対して変更を行うWebサービス変換部１２８を備える。

ワークフローエンジン１３０は、通信を行う通信部１３１、及び、本ワークフローエンジンの動作を制御する制御部１３５を備える。制御部１３５は、ワークフロー変換装置１２０が生成したWS-BPELインスタンスをコンパイルするコンパイル部１３６、及び、コンパイルされたワークフローを実行するワークフロー実行部１３７を備える。

Webサービスサーバ１４０は、Webサービスを提供するWebサービス部１４３、及び、ワークフロー変換装置１２０のWebサービス変換部１２８の指示に従いWebサービス部１４３に対してWebサービスの変更を行うWebサービス制御部１４２を備える。なお、ワークフローエンジン１３０がワークフローを実行する際に複数のWebサービスを呼び出す場合はそれら複数のWebサービスが存在することになるが、ここでは１台のWebサービスサーバ１４０の１つのWebサービス部１４３のみを図示して他は省略した。

Webサービスをカスタマイズしてワークフローを実行する過程は、(1) ワークフロー環境の構築、(2) ワークフローの実行、の２つの段階から構成される。最初に、(1)ワークフロー環境構築について説明する。

図２は、ワークフロー環境構築処理の概要を示すフローチャートである。ステップ２２１では、エディタ装置１１０がユーザの指示に従い業務ポリシーを作成し、ワークフロー変換装置１２０のポリシーＤＢ１２２に保管する。また、業務ポリシーをWebサービスに適用するのに必要なコンポーネントについても、同様にしてユーザの指示に従って作成し、コンポーネントＤＢ１２３に保管する。

図３は、業務ポリシーとコンポーネントの例である。この業務ポリシー３０１ ”ApplicationPolicy.xml” は、電子申請業務に対するもので、利用ユーザの情報をWebサービスサーバ１４０上に出力する処理を付加するものである。<partnerLinks>は、このポリシーの適用対象となるWebサービスを指定する記述である。<partnerLink target="eD*">は、このポリシーが、partnerLinkが"eD"で始まるWebサービスに適用されることを示している。BPEL_aspectタグ内は、WS-BPELインスタンスに付加する処理の記述である。ここではpartnerLink名が"UserLink"であるWebサービスからユーザ情報を取得する処理が記述されている。pointcutタグのtype属性"before"は、対象となるWebサービスを実行する前にadviceタグ内の処理（すなわち、ユーザ情報を取得する処理）を行うことを指示するものである。

service_aspectタグ内は、適用対象のWebサービスに付加する処理の記述である。ここでは、本来のWebサービスを実行する前に "userlog.class"にある処理を行うことが記述されている。

図３の下段の３０２は、適用対象のWebサービスに付加するコンポーネントであるuserlog.classの内容を示す。ここでは、従来の関数の引数にユーザ情報を追加し、その情報をログとして出力することが記述されている。

図２のステップ２２１で図３に示すようなポリシーとコンポーネントを作成した後、ステップ２２２では、エディタ装置１１０がユーザの指示に従いビジネスロジックを記述したWS-BPELインスタンス（ワークフロー）を作成し、ワークフロー変換装置１２０に送信する。

図４は、WS-BPELインスタンスの作成時に、そのワークフローで利用するWebサービスを追加するときのエディタ装置１１０の画面例である。WSDLの入力BOX内にWSDLがある場所を指定し、WSDLを解析することでエディタ装置１１０がWebサービスのインターフェイスを理解する。このとき「業務種類」４０２及び「内容」４０３をユーザが選択することで、partnerLinkのnameの頭にくる文字４０１が決まるようになっている。すなわち、この例では、本来のWebサービスの名前はDocumentServiceLinkであるが、そのWebサービスを「業務種類」が「電子申請」で「内容」が「電子申請」であるような業務のワークフローから呼び出すときには、先頭にeDを付けたeDDocumentServiceLinkというpartnerLink名でワークフローに追加されるということである。別の業務を行うワークフローから同じDocumentServiceLinkを呼び出すときには、別の先頭文字が付加されるので、別々のワークフローから同じWebサービスを利用するときに区別することができる。そして、ワークフロー中で当該Webサービスにどの様な業務ポリシーを適用するかの判断材料として、そのpartnerLink名の先頭文字で判断できるようにしている。従って、同じWebサービスを別々のワークフローから利用するとき、各業務別に別の業務ポリシーに応じて当該Webサービスに追加・変更が施されるので、同じWebサービスであっても、要求される業務に応じた役割が果たせるように追加・変更されることになる。

図４の画面などを利用してステップ２２２でWS-BPELインスタンスを作成した後、ステップ２２３では、ワークフロー変換装置１２０のWS-BPELインスタンス解析部１２６がエディタ装置１１０から取得したWS-BPELインスタンスを解析して、ポリシーＤＢ１２２からそのWS-BPELインスタンスで呼び出しているWebサービスに適用する業務ポリシーを取得する。このとき、ステップ２２２で設定したpartnerLinkの名付け規則を参考にする。すなわち、WS-BPELインスタンス中で呼び出しているWebサービス名の頭の文字により、そのWebサービスに適用するポリシーを決定する。

ステップ２２４では、ワークフロー変換装置１２０のWS-BPELインスタンス変換部１２７がステップ２２３で取得した業務ポリシーに従い、エディタ装置１１０から取得したWS-BPELインスタンスに必要な処理を追加し、ワークフローエンジン１３０に送信する。

図５は、図３の業務ポリシーが適用されて変更されたWS-BPELインスタンスの例である。図中、点線部分５０１，５０２が変更された部分である。変更前のWS-BPELインスタンスにおいてpartnerLinkタグやinvokeタグを参照することにより、このWS-BPELインスタンスで利用しているWebサービスが分かり、その名前の頭の文字から、そのWebサービスに適用すべきポリシーが分かる。この例だとWebサービス"eDDocumentServiceLink"を呼び出しており、その頭の文字"eD"から図３のポリシーを適用すると判断できる。一方、図３のポリシーでは、BPEL_aspectタグの内容から、当該Webサービスの呼び出しの前に"UserLink"を呼び出す処理を追加すべきことが記述されているので、ステップ２２４では図５の５０１のように追加している。さらに、service_aspectタグの内容から当該Webサービスに組み込むべきコンポーネント"userlog.class"が分かり、コンポーネントＤＢ１２３内の当該コンポーネント"userlog.class"（図３の３０２）を参照することにより、当該Webサービスを呼び出すときには引数の最後にユーザ情報を追加すべきことが分かるので、ステップ２２４では図５の５０２のように追加している。以上のようにして、ユーザ情報を取得するWebサービスが付加され、対象となるWebサービスの引数にユーザ情報が追加される。

次に、ステップ２２５では、ワークフローエンジン１３０のコンパイル部１３６がワークフロー変換装置１２０から取得した完全なWS-BPELインスタンス（図５）をコンパイルする。

図３、４の例では、業務ポリシーを適用するWebサービスを特定する方法として、WS-BPELインスタンスのpartnerLink属性の値を利用している。この方法以外にも、以下の例の下線部に示すように、WS-BPELインスタンスに独自の属性を付加する方法もある。この場合、ステップ２２２で独自タグを付加し、ステップ２２３で適用するWebサービスを特定した後、ステップ２２４で変換時に特定タグを削除し、ステップ２２５でコンパイルする。

また、ステップ２２４，２２５と並行して、ステップ２２６では、ワークフロー変換装置１２０のWebサービス変換部１２８が、ステップ２２３で取得した業務ポリシーに従い、コンポーネントDB１２３から業務ポリシーで指定されたコンポーネントを取得し、Webサービスサーバ１４０のWebサービス制御部１４２に送信する。コンポーネントを受信したWebサービスサーバ１４０のWebサービス制御部１４２は、Webサービス部１４３を制御し、Webサービスに当該コンポーネントを組み込み、公開する。

図６に、コンポーネントが組み込まれたWebサービスの例を示す。点線で囲まれた部分６０１が追加された部分である。従来の関数”read”にIDを付加し、図３のコンポーネント”userlog.class”と引数を対応させた関数”read1”を生成し、新たなログ処理の追加と従来関数”read”の処理を行っている。

また、ワークフロー変換装置１２０のWebサービス変換部１２８は、変更されたWebサービス（図６）のWSDLを生成する。図７に、変更されたWSDLを示す。点線で囲まれた部分７０１が追加及び変更された部分である。図５や図６で説明したように、当該Webサービスを呼び出すときの関数名が変更及び引数にユーザ情報が追加されたので、それに伴って図７のWSDLでも７０１に示すように関数名の変更及び引数へのユーザ情報の追加をしている。

以上で、特定業務に適したワークフロー実行環境が構築された。

次に、(2)ワークフローの実行の段階に関して、図８のシーケンス図を用いて詳細に説明する。ステップ８０１では、リクエスタがワークフローエンジン１３０に対して業務プロセスを呼び出す。ステップ８０２では、ワークフローエンジン１３０のワークフロー実行部１３７が、呼び出された業務プロセスに応じたWS-BPELインスタンス（ワークフロー変換装置１２０が生成した完全なWS-BPELインスタンス）を実行し、そのWS-BPELインスタンスに従いWebサービスサーバ１４０のWebサービスを呼び出す。このとき、ワークフローエンジン１３０のワークフロー実行部１３７は、ワークフロー変換部１２０のWebサービス変換部１２８が生成したWSDLに従ってSOAPメッセージを生成し当該Webサービスを呼び出す。

ステップ８０３では、Webサービスサーバ１４０のWebサービス部１４３が、ワークフロー変換装置１２０のWebサービス変換部１２８によって追加された処理を実行する。例えば、図６の変更されたWebサービスであれば、追加された点線部分６０１が実行され、これによりユーザ情報のロギングを行う。ステップ８０４では、Webサービスサーバ１４０のWebサービス部１４３が、Webサービスとしての本来の処理を実行する。ステップ８０５では、Webサービスサーバ１４０のWebサービス部１４３が、Webサービスの実行結果をワークフローエンジン１３０に返す。ステップ８０６では、ワークフローエンジン１３０のワークフロー実行部１３７が、WS-BPELインスタンスの実行結果をリクエスタに返す。

以上で、業務に適したようにカスタマイズされたワークフロー環境でのワークフローの実行が完了した。

本発明の一実施の形態例を示すシステム構成図である。ワークフロー環境構築処理の概要を示すフローチャートである。業務ポリシー及びWebサービスに追加するコンポーネントの例である。ワークフローにWebサービスを取り込むときのエディタ装置の画面例である。業務ポリシーが適用されて変更されたWS-BPELインスタンスの例である。業務ポリシーが適用されて変更されたWebサービスの例である。業務ポリシーが適用されて変更されたWebサービスのWSDLの例である。ワークフロー実行時のシーケンス図である。

符号の説明

１１０…エディタ装置、１２０…ワークフロー変換装置、１３０…ワークフローエンジン、１４０…Webサービスサーバ。

Claims

ワークフローに従ってWebサービスを連係して実行するシステムにおいて、ワークフローに従って呼び出すWebサービスをカスタマイズするWebサービスカスタマイズシステムであって、
適用対象となるWebサービスを指定する記述、ワークフロー中の当該Webサービスに係る記述に対して追加・変更する処理の記述、及び、当該Webサービスに対して追加・変更する処理の記述を含む業務ポリシーを作成する手段と、
Webサービスを連係して呼び出すことにより所定の業務を実行するビジネスロジックを記述したワークフローを作成する手段と、
作成したワークフローに対して、前記業務ポリシーの記述に応じて、適用対象となるWebサービスに係る記述部分に必要な追加・変更を施す手段と、
前記ワークフローから呼び出されるWebサービスに対して、前記業務ポリシーの記述に応じて必要な追加・変更を施す手段と
を備えることを特徴とするWebサービスカスタマイズシステム。