JP2010009520A - フロー処理装置及びメッセージ変換方法 - Google Patents

Abstract

【課題】 異なるサービス定義文書のサービス間で、第２の型のサービスを第１の型のサービスとして利用可能にする。
【解決手段】 フロー処理装置において、第２の型のサービスのサービス定義文書を予め決められた規則に従って第１の型のサービスのサービス定義文書へと変換する。そして、変換されたサービス定義文書に基づいて、第２の型のサービスを第１の型のサービスとして利用するためにメッセージ変換処理を行う。
【選択図】 図６

Description

本発明は、フロー処理装置及びメッセージ変換方法に関するものである。

ユーザがＷｅｂから利用可能なアプリケーションにＷｅｂサービスがある。このＷｅｂサービスを利用する際の接続手順を、以下の説明ではプロトコルと称す。

従来、Ｗｅｂサービスは、プロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を利用して提供されるのが一般的である。しかし近年、プロトコルとしてＳＯＡＰを利用しない形態のＷｅｂサービスも提供されている。

これらのＳＯＡＰを利用しないＷｅｂサービスのうち、広く普及しているものとして、ＲＥＳＴ（REpresentational State Transfer）を利用したものがある。ＲＥＳＴとは、本来アーキテクチャスタイルの呼称であるが、次第にＨＴＴＰ上でＸＭＬ文書を送受信することで、遠隔呼び出しを行うシステムのことを指し示す意味としても利用されるようになった。

以降の説明では、この２種類のＷｅｂサービスを区別するため、従来からのＳＯＡＰを利用するＷｅｂサービスを「ＳＯＡＰ型サービス」と呼ぶこととする。また、ＳＯＡＰを利用せずにＲＥＳＴスタイルでサービスを提供しているＷｅｂサービスを「ＲＥＳＴ型サービス」と呼ぶこととする。

また、Ｗｅｂサービスはアプリケーションの連携や統合を実現するための技術としても利用されている。業務や作業における一連の流れであるワークフローを逐次実行していくことをフロー処理という。Ｗｅｂサービスを利用することで、フロー処理を自動化することが可能となる。

フロー処理を自動化する技術として、フロー処理記述言語のＢＰＥＬ４ＷＳ（Business Process Execution Language for Web Services）がある。このＢＰＥＬ４ＷＳの仕様は、ＯＡＳＩＳのOASIS Web Services Business Process Execution Language TCで管理されている。ＯＡＳＩＳはorganization for the Advancement of Structured Information Standardsの略である。

尚、ＢＰＥＬ４ＷＳでは、Ｗｅｂサービスを識別するインタフェースとして、ＷＳＤＬ（Web Services Description Language）を用いている。ＷＳＤＬは、Ｗｅｂサービスのインタフェースを記述するために用いる言語であり、仕様はｗｗｗコンソーシアム（Ｗ３Ｃ）によって公開されている。内容はhttp://www.w3.org/TR/wsdlにて参照可能である。

しかし、ＢＰＥＬ４ＷＳにて連携可能なＷｅｂサービスは、ＳＯＡＰ型サービスのみであり、ＲＥＳＴ型サービスはその対象ではない。これにより、単体のＷｅｂサービスとして、同様に利用されるＳＯＡＰ型サービスとＲＥＳＴ型サービスであっても、ＳＯＡＰ型サービスとＲＥＳＴ型サービスの両方を利用して１つのワークフローを実現できない、という問題があった。

上述したように、プロトコルの違いでシステムが利用できないという問題に対しては、利用不可のプロトコルを利用可能な別のプロトコルに変換することでシステムを利用可能にする、プロトコルの変換技術が利用されている。例えば、特許文献１参照。

特許文献１では、人間がブラウザから手動で各種パラメータを入力することで利用するＷｅｂアプリケーションとＳＯＡＰ型サービスとの間で変換を行う。変換処理としては、まず変換したいＷｅｂアプリケーションに対する要求のＵＲＬを分析することで変換規則を生成する。その後、そのＷｅｂアプリケーションに対応した専用のプロトコル変換部を生成する。このプロトコル変換部はＳＯＡＰ型サービスのクライアントからはＳＯＡＰ型サービスのサーバとして動作しているように見えている。そして、ＳＯＡＰ型サービスのクライアントアプリケーションは、専用のプロトコル変換部にＳＯＡＰ型サービスを利用するのと同様にアクセスすることにより、Ｗｅｂアプリケーションの結果を受信することが可能になる。
特開2005-149131号公報

しかし、特許文献１に示すような従来の方法では、対応するＷｅｂアプリケーションが増加するにつれ、そのＷｅｂアプリケーションに対応したプロトコル変換部も増加する。そのため、プロトコル変換部を提供する機器が組み込み機器など、メモリ使用量に制限がある場合、多くのＷｅｂアプリケーションを収容することができない。これは、対応したいＷｅｂアプリケーションが増加するにつれて、そのメモリ使用量が増加してしまうためである。

また、ＳＯＡＰ型サービスのサーバとして動作しているプロトコル変換部が、ＳＯＡＰ型サービスのインタフェース定義であるＷＳＤＬ文書を公開していない。そのため、ＳＯＡＰ型サービスを連携させる際に、機械的にサービスを識別することができなくなるため、変換処理を行ったにも関わらずフロー処理で利用することができない。同時に、従来のＳＯＡＰ型サービスクライアントの生成方法が利用できないという問題もある。

具体的には、ＷＳＤＬ文書を参照することで、ＳＯＡＰ型サービスクライアントのひな形となるスタブが生成できない。これにより、ＳＯＡＰ型サービスクライアントを開発する際に多くの時間を消費してしまう。

本発明は、異なるサービス定義文書のサービス間で、第２の型のサービスを第１の型のサービスとして利用可能にすることを目的とする

本発明は、フロー処理装置であって、
第２の型のサービスのサービス定義文書を予め決められた規則に従って第１の型のサービスのサービス定義文書へと変換する手段と、
前記変換されたサービス定義文書に基づいて前記第２の型のサービスを前記第１の型のサービスとして利用するためにメッセージ変換処理を行う手段と、
を有することを特徴とする。

また、本発明は、フロー処理装置におけるメッセージ変換方法であって、
第２の型のサービスのサービス定義文書を予め決められた規則に従って第１の型のサービスのサービス定義文書へと変換する工程と、
前記変換されたサービス定義文書に基づいて前記第２の型のサービスを前記第１の型のサービスとして利用するためにメッセージ変換処理を行う工程と、
を有することを特徴とする。

本発明によれば、異なるサービス定義文書のサービス間で、第２の型のサービスを第１の型のサービスとして利用することが可能となる。

以下、図面を参照しながら発明を実施するための最良の形態について詳細に説明する。

［第１の実施形態］
まず、サーバ装置やクライアント装置として機能するコンピュータ装置の構成を、図１に示すブロック図を参照して説明する。尚、サーバ装置やクライアント装置は、それぞれ単一のコンピュータ装置で実現しても良く、また必要に応じて複数のコンピュータ装置に各機能を分散して実現するようにしても良い。その場合、互いに通信可能なようにＬＡＮ（ローカルエリアネットワーク）などで接続されていれば良い。

図１は、本実施形態におけるコンピュータ装置の構成の一例を示すブロック図である。図１において、１０１はコンピュータ装置１００全体を制御するＣＰＵである。１０２は変更を必要としないプログラムやパラメータを格納するＲＯＭである。１０３は外部装置などから供給されるプログラムやデータを一時記憶するＲＡＭである。

１０４はコンピュータ装置１００に固定して設置されたハードディスクやメモリカード、或いはコンピュータ装置１００から着脱可能な外部記憶装置である。ここで、外部記憶装置は、フレキシブルディスク（ＦＤ）やコンパクトディスク（ＣＤ）などの光ディスク、磁気や光カード、ＩＣカード、メモリカードなどを含む。１０５はユーザからの操作を受け、データを入力するポインティングデバイスやキーボードなどの入力デバイス１０９との入力デバイスインタフェースである。

１０６はコンピュータ装置１００の保持するデータや供給されたデータを表示するためのモニタ１１０とのディスプレイインタフェースである。１０７はインターネット１１１などのネットワーク回線に接続するためのネットワークインタフェースである。１０８は１０１〜１０７の各ユニットを通信可能に接続するシステムバスである。

尚、本実施形態の機能を実現するソフトウェアのプログラムコードを記録した記録媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（ＣＰＵ若しくはＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行する。これによっても、本発明の目的が達成されることは言うまでもない。

この場合、コンピュータ読み取り可能な記録媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。

このプログラムコードを供給するための記録媒体として、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。

また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、次の場合も含まれることは言うまでもない。即ち、プログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合である。

更に、記録媒体から読出されたプログラムコードがコンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込む。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部又は全部を行い、その処理により前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

次に、ＳＯＡＰを利用するＷｅｂサービス（以下、ＳＯＡＰ型サービス）について説明する。まず、ＳＯＡＰ型サービスには、サービスがどのようなものかを定義するサービス定義文書が存在する。このサービス定義文書は、記述言語としてＷＳＤＬ（Web Services Description Language）を利用している。ＷＳＤＬの仕様はｗｗｗコンソーシアム（Ｗ３Ｃ）によって公開されている。内容はｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｓｄｌにて参照可能である。ここで、ＷＳＤＬを利用して記述されたＳＯＡＰ型サービス定義文書を、図２を参照して説明する。

図２は、ＷＳＤＬを利用して記述されたＳＯＡＰ型サービス定義文書の一例を示す図である。まず、サービス定義文書は、大きく分けて５つの部分で構成されている。サービス定義文書全体は、＜definitions＞タグで開始され、＜definitions＞タグの属性値targetNamespaceにて、サービス定義文書自体を一意に識別することが可能となっている。

５つの部分のうち、１つ目はデータ型定義記述部である。このデータ型定義記述部は、＜types＞タグで開始され、＜types＞タグの子要素としてXMLSchemaで記述されたデータ型を記述する。このXMLSchemaの仕様は、ｗｗｗコンソーシアム（Ｗ３Ｃ）によって公開されている。また内容は、http://www.w3.org/TR/xmlschema-0/、http://www.w3.org/TR/xmlschema-1/、http://www.w3.org/TR/xmlschema-2/で参照可能である。

２つ目は、メッセージ定義記述部である。メッセージ定義記述部は、＜message＞タグで開始され、１つ目のデータ型定義記述部によって定義されているデータ型を、どのようなメッセージで利用するのかを定義する。メッセージ定義記述部では、＜message＞タグを並列することで複数のメッセージを定義することが可能である。

３つ目は、サービス機能定義記述部である。サービス機能定義記述部は、＜portType＞タグによって開始され、２つ目で定義したメッセージを組み合わせてサービス機能を定義する。各サービス機能は＜operation＞タグで開始される。この＜operation＞タグ内では、サービス機能を利用するために送受信されるメッセージを定義する。また、＜operation＞タグを並列することで、複数のサービス機能を定義することが可能である。

４つ目は、通信プロトコル関連付け定義記述部である。通信プロトコル関連付け定義記述部は、＜binding＞タグで開始され、実際に通信に使うプロトコルと、３つ目で定義したサービス機能との関連付けを定義する。図２に示す例では、プロトコルとしてＳＯＡＰを利用している。

５つ目は、サービス公開アドレス定義記述部である。サービス公開アドレス定義記述部は、＜service＞タグで開始され、１つ目から４つ目までで定義したサービスと、実際にアクセス可能なアドレスとの関連付けを定義する。実際に、サービスを利用するユーザに向けて公開するアドレスは＜port＞タグにて定義する。

ＳＯＡＰ型サービスのサービス定義文書は、ＳＯＡＰ型サービスのサーバ及びクライアントを作成する際に広く用いられている。そして、ＳＯＡＰ型サービスのサーバ作成では、サービス定義文書を事前に作成し、そのサービス定義文書を読み込むことでＳＯＡＰ型サービスのサーバアプリケーションのひな形であるスケルトンプログラムを作成している。その際の作成手順を、図３を参照して説明する。

図３は、本実施形態におけるＳＯＡＰ型サービスサーバの一般的な作成手順を示す図である。ＳＯＡＰ型サービス開発者３００は、ＳＯＡＰ型サービスサーバスケルトンプログラム生成部３０１にＳＯＡＰ型サービス定義文書３０２を送信する。ＳＯＡＰ型サービス定義文書３０２を受信したＳＯＡＰ型サービスサーバスケルトンプログラム生成部３０１は、ＳＯＡＰ型サービス定義文書３０２を解析し、スケルトンプログラム３０３を生成してＳＯＡＰ型サービス開発者３００に送信する。

スケルトンプログラム３０３を受信したＳＯＡＰ型サービス開発者３００は、スケルトンプログラム３０３に、実際に行う処理部分を実装し、ＳＯＡＰ型サービスサーバプログラム３０４を生成する。

また、ＳＯＡＰ型サービスのクライアント作成でも、サーバ作成時と同様に、サービス定義文書を読み込んで、クライアントアプリケーションのひな形となるスタブを生成する方法が広く用いられている。この際の作成手順を、図４を参照して説明する。

図４は、本実施形態におけるＳＯＡＰ型サービスクライアントの作成手順を示す図である。クライアント側４００には、スタブ生成部４０１がある。また、サーバ側４１０にはＳＯＡＰ型サービスサーバ４１１とＳＯＡＰ型サービスのサービス定義文書４１２が公開されている。

ここで、スタブ生成部４０１は、公開されているサービス定義文書４１２を参照４２０する。そして、サービス定義文書４１２からスタブプログラム４０２を生成する。次に、生成されたスタブプログラム４０２に対して、クライアントアプリケーション開発者が、クライアントとして必要となる処理を加えて、ＳＯＡＰ型サービスクライアント４０３を完成させる。

完成したＳＯＡＰ型サービスクライアント４０３は、ＳＯＡＰ型サービスサーバ４１１に対してＳＯＡＰメッセージの要求メッセージ送信４３０を行う。このメッセージを受信したＳＯＡＰ型サービスサーバ４１１は、要求された処理を実行し、処理結果をＳＯＡＰメッセージとして応答する。そして、ＳＯＡＰ型サービスクライアント４０３がＳＯＡＰメッセージの応答メッセージ受信４３１を行い、ＳＯＡＰ型サービスを利用する。

次に、ＳＯＡＰを利用せずにＲＥＳＴスタイルでサービスを提供するＷｅｂサービス（以下、ＲＥＳＴ型サービス）について説明する。

ＲＥＳＴ型サービスでは、上述したＷＳＤＬで記述されたサービス定義文書と同様に、ＷＡＤＬ（Web Application Description Language）を利用してサービス定義文書を記述している。ＷＡＤＬはＷＳＤＬと同様に、ＸＭＬを基にした言語になっている。この仕様については、https://wadl.dev.java.net/にて公開されている。ＷＡＤＬを利用して記述されたＲＥＳＴ型サービスのサービス定義文書を、図５を参照して説明する。

図５は、ＷＡＤＬを利用して記述されたＲＥＳＴ型サービスのサービス定義文書の一例を示す図である。まず、ＲＥＳＴ型サービス定義文書は大きく分けて、２つの部分で構成されている。サービス定義文書全体は、＜application＞タグで開始される。

２つの部分のうち、１つ目はデータ型記述部である。データ型記述部は、＜grammars＞タグで開始され、ＲＥＳＴ型サービスが扱うＸＭＬデータの型定義を記述する。データ型定義は、上述したＳＯＡＰ型サービスと同様にXMLSchemaを用いて行う。図５に示すように、＜include＞タグを用いて、別ファイルにて構成されているXMLSchemaファイルを読み込んだり、＜grammars＞タグ以下に直接記述したりすることが可能である。

２つ目は、関連サービス定義記述部である。ＲＥＳＴ型サービスはＳＯＡＰ型サービスとサービスの概念が異なる。つまり、ＳＯＡＰ型サービスでサービス機能と呼ばれていた単位が、ＲＥＳＴ型サービスではResourceという名前でサービスとして扱われる。また、ＳＯＡＰ型サービスでサービスと呼ばれていた単位がＲＥＳＴ型サービスではResourcesとして複数のResourceによって構成される。関連サービス定義記述部は、＜resources＞タグで開始され、関連ある複数のサービスを定義している。＜resources＞タグのbase属性で、関連ある複数のサービスを全体として識別するＵＲＩを記述する。このＵＲＩは関連ある複数のサービスが公開されているＵＲＬの基本部分として定義される。個々のサービスは、＜resources＞タグの子要素＜resource＞タグ以下で定義される。

＜resource＞タグは、path属性で個々のサービスを識別するＵＲＩを記述する。ここで記述されたpath属性の値を＜resources＞タグのbase属性の値と組み合わせることにより、個々のサービスにアクセスする際のアクセス先アドレスを構成することが可能である。また、＜resource＞タグは、子要素として＜method＞タグを持ち、サービスにアクセスする際のメソッドを定義している。また＜method＞タグと並列して＜request＞タグと＜response＞タグがあり、＜request＞タグではサービスに対する要求メッセージを定義し、＜response＞タグではサービスの応答メッセージを定義している。

また、＜resource＞タグは、＜resources＞タグの子要素として、並列して複数存在することが可能であるため、＜resources＞タグ以下で複数のサービスを定義することが可能である。

次に、ＳＯＡＰ型（第１の型の）サービスクライアントからＲＥＳＴ型（第２の型の）サービスを利用する場合について説明する。この場合、ＳＯＡＰ型サービスクライアントがＲＥＳＴ型サービスを利用しようとすると、プロトコルが異なるためにサービスを利用することができない。

そこで、ＳＯＡＰ型サービスクライアントがＲＥＳＴ型サービスを利用するために変換を行う必要がある。その変換に必要な構成を、図６を参照して説明する。

図６は、異なるＷｅｂサービスを利用するために必要な変換処理を示す図である。図６に示すように、必要な変換処理は２つある。１つ目は、ＲＥＳＴ型サービスで定義されているサービス定義をＳＯＡＰ型サービスのサービス定義に変換するサービス定義変換処理６１０である。次に、２つ目は、実際にサービスを利用する際に送受信されるメッセージについて変換する、送受信メッセージ変換処理６２０である。また、２つの変換処理は、ＳＯＡＰ型サービスサーバ６００として利用可能である。

上述のサービス定義変換処理６１０では、サービス定義変換処理部６１１が、ＲＥＳＴ型サービス６４０が公開しているＲＥＳＴ型サービス定義文書６４１を取得する。次に、取得したＲＥＳＴ型サービス定義文書６１３からＳＯＡＰ型サービスを定義するのに必要な情報を抽出し、ＳＯＡＰ型サービス定義文書６１２を生成するという変換処理を行う。ここで、サービス定義変換処理部６１１は、予め決められた変換規則６１４に従って変換処理を行う。この変換規則６１４の詳細については、図９を用いて後述する。

そして、変換することで生成されたＳＯＡＰ型サービス定義文書６１２を公開することで、ＲＥＳＴ型サービス６４０をＳＯＡＰ型サービスクライアント６３０が認識できるようにしている。

また、送受信メッセージ変換処理６２０は、メッセージ変換処理部６２１と、ＳＯＡＰメッセージ送受信部６２２と、ＲＥＳＴメッセージ送受信部６２３と、から構成される。行われる処理としては、ＳＯＡＰ型サービスクライアント６３０が、ＳＯＡＰ型サービスサーバ６００が公開しているＳＯＡＰ型サービス定義文書６１２を取得する。ＳＯＡＰ型サービスクライアント６３０は、取得したＳＯＡＰ型サービス定義文書６３１に記述された定義に基づき、ＳＯＡＰ型サービスリクエストメッセージ６５０を生成する。そして、生成したＳＯＡＰ型サービスリクエストメッセージ６５０をＳＯＡＰメッセージ送受信部６２２へ送信する。

ＳＯＡＰ型サービスリクエストメッセージ６５０を受信したＳＯＡＰメッセージ送受信部６２２は、ＳＯＡＰ型サービスリクエストメッセージ６５０を解析し、その解析結果をメッセージ変換処理部６２１に送信する。そして、解析結果を受け取ったメッセージ変換処理部６２１は、サービス定義変換処理部６１１で定義された変換規則６１４を用いて、ＲＥＳＴ型サービスリクエストメッセージ６５１を生成し、ＲＥＳＴメッセージ送受信部６２３に送信する。

このように、変換規則６１４を用いることにより、ＲＥＳＴ型サービス定義文書６４１を参照することなく、ＲＥＳＴ型サービス６４０が要求するメッセージを生成することが可能となる。

一方、ＲＥＳＴ型サービスリクエストメッセージ６５１を受信したＲＥＳＴメッセージ送受信部６２３は、ＲＥＳＴ型サービス６４０にＲＥＳＴ型サービスリクエストメッセージ６５１を送信する。そして、結果として、ＲＥＳＴ型サービス応答メッセージ６５２を受信する。

次に、ＲＥＳＴ型サービス応答メッセージ６５２を受信したＲＥＳＴメッセージ送受信部６２３は、ＲＥＳＴ型サービス応答メッセージ６５２を解析し、解析結果をメッセージ変換処理部６２１に送信する。そして、解析結果を受け取ったメッセージ変換処理部６２１は、ＳＯＡＰ型サービスクライアント６３０が解釈可能なＳＯＡＰメッセージに変換し、ＳＯＡＰ型サービス応答メッセージ６５３としてＳＯＡＰメッセージ送受信部６２２に送信する。この変換処理は、リクエストメッセージの変換処理と同様に、サービス定義変換処理部６１１で定義した変換規則６１４を用いて行う。

次に、ＳＯＡＰ型サービス応答メッセージ６５３を受信したＳＯＡＰメッセージ送受信部６２２は、ＳＯＡＰ型サービスクライアント６３０に対して、ＳＯＡＰ型サービス応答メッセージ６５３を送信する。この一連の処理により、ＳＯＡＰ型サービスクライアント６３０からＲＥＳＴ型サービス６４０を利用可能になる。

次に、サービス定義変換は行わずにＳＯＡＰ型サービスのサービス定義を機械的に作成する送受信メッセージ変換処理を、図７を参照して説明する。この処理は、実行時のメッセージ変換のみで対応する場合やＲＥＳＴ型サービスのサービス定義から要求メッセージや応答メッセージに必要なデータ型の記述を抽出し、ＳＯＡＰ型サービスのサービス定義を機械的に作成する処理である。

図７は、サービス定義変換は行わずに送受信メッセージ変換処理を行うシステムの構成を示す図である。ＳＯＡＰ型サービスクライアント７００から、ＲＥＳＴ型サービス７２０を利用しようとした場合、プロトコルの違いからサービスを利用することができない。そこで、上述のようにメッセージ変換処理部７１２によってＳＯＡＰメッセージとＲＥＳＴメッセージを変換することで、ＲＥＳＴ型サービス７２０を利用することを行う。ここで、ＳＯＡＰメッセージ送受信部７１１と、メッセージ変換処理部７１２と、ＲＥＳＴメッセージ送受信部７１３とは、ＳＯＡＰ型サービスサーバ７１０として作成する必要がある。

従来の方法では、開発効率を向上させるために、上述のようにサービス定義文書を用いてＳＯＡＰ型サービスサーバ７１０を作成する方法をとっていた。この方法を用いると、対応したいＲＥＳＴ型サービスのサービス定義文書から変換されたＳＯＡＰ型サービス定義文書を用いることになる。そのため、対応したいＲＥＳＴ型サービスの数と同じ数だけメッセージ変換処理部７１２及びＲＥＳＴメッセージ送受信部７１３を生成しておく必要がある。

そのため、複数のＲＥＳＴ型サービスに対応するために多くのメモリが使用されることになってしまい、メモリ使用量が限られている機器での利用が困難になってしまう。またＳＯＡＰメッセージ送受信部７１１内で、本来ＲＥＳＴ型サービスを呼び出すための変換処理を行えれば良いのに対して、呼び出すＳＯＡＰ型サービスの決定やＸＭＬ要素の値を型に合わせて割り当てるという冗長な作業が発生してしまう。

ＳＯＡＰメッセージ送受信部７１１で行われている処理のうち、ＳＯＡＰ型サービスクライアント７００からメッセージを受信した際の処理を、図８を参照して説明する。

図８は、要求ＳＯＡＰメッセージを受信したＳＯＡＰメッセージ送受信部の処理を示すフローチャートである。まず、ＳＯＡＰメッセージ送受信部７１１がＳＯＡＰ型サービスクライアント７００からＳＯＡＰメッセージ７０１を受信する（Ｓ８０１）。次に、受信したＳＯＡＰメッセージ７０１を解析する（Ｓ８０２）。そして、その解析結果を受けて該当するサービスを決定する（Ｓ８０３）。

その後、Ｓ８０３にて決定したサービスの中でどのサービス機能を利用するのかを決定する（Ｓ８０４）。そして、Ｓ８０４で決定したサービス機能が引数として要求する型に対して該当するＸＭＬ要素の値を割り当てる（Ｓ８０５）。この処理を行うことで、複数存在するメッセージ変換処理部７１２を呼び分けることができる。

次に、ＲＥＳＴ型サービスのサービス定義文書からＳＯＡＰ型サービスのサービス定義文書へ変換規則を用いて変換するサービス定義変換処理について説明する。このサービス定義変換処理において、ＲＥＳＴ型サービスのサービス定義文書からＳＯＡＰ型サービスのサービス定義文書に変換する際に、変換規則を設ける。この変換規則を設けることで、送受信メッセージ変換処理の課題を解消する。ここで、サービス定義変換処理を、図９を参照して説明する。

図９は、サービス定義変換処理における変換規則を説明するための図である。ＲＥＳＴ型サービス定義文書９００内の関連サービス記述部の＜resources＞タグのbase属性の値である関連サービス識別子９０１をＳＯＡＰ型サービス定義文書の属性の値として利用する。ここでは、その識別子９０１を、＜definitions＞タグのtargetNamespace属性の値と＜types＞定義内のＸＭＬSchemaの＜schema＞タグのtargetNamespace属性の値として利用する。

つまり、ＲＥＳＴ型サービス定義文書で定義された、ＲＥＳＴ型サービスが公開されているＵＲＬの基本部分を、ＳＯＡＰ型サービス定義文書に記述することが可能になる。

また、個々のＲＥＳＴ型サービスを識別するＵＲＩ９０２と、そのＲＥＳＴ型サービスにアクセスするためのメソッド９０３を“_”で連結し、ＳＯＡＰ型サービス定義文書内の＜operation＞要素のname属性の値として利用する。

図９に示すＲＥＳＴ型サービス定義文書の場合では、＜resource＞タグのpath属性値が“sample”であり、＜method＞タグのname属性値が“GET”である。従って、ＳＯＡＰ型サービス定義文書内に“GET_sample”というoperation名を持つ＜operation＞タグが生成される。

また、メッセージ定義名及びデータ型定義名においてもoperation名を用いる。ここで、メッセージ定義名とは＜message＞要素のname属性を意味する。operation名で定義されたoperationに対する要求メッセージ名は、９１０のようにoperation名+“_Request”を用いる。また、operation名で定義されたoperationの応答メッセージ名は、９１１のようにoperation名+“_Response”を用いる。

データ型定義名とは、＜types＞タグ内のＸＭＬSchemaで定義する＜element＞要素のname属性値を意味する。このoperation名で定義されたoperationに対する要求メッセージのデータ型名は、９１２のようにoperation名をそのまま用いる。要求メッセージに対する応答メッセージのデータ型名は、９１３のようにoperation名+“_Response”を用いる。

図９に示す変換規則に基づいて変換されたＳＯＡＰ型サービス定義文書は、ＳＯＡＰ型サービスサーバによって公開される。本実施形態では、対応するサービスが増えた場合でもメッセージ変換処理部は１つである。そのため、ＳＯＡＰ型サービス定義文書内で定義するＳＯＡＰ型サービスのアドレスは、ＲＥＳＴ型サービスの違いに関係なく常に同じである。

実際に、サービス定義文書の変換を行う際には、ＷＳＤＬ及びＷＡＤＬがＸＭＬ言語に基づくことに着目し、ＸＳＬＴを利用して処理を自動化することが可能である。ＸＳＬＴはXML Stylesheet Language Transformationsの略である。

図１０は、本実施形態で送信される要求ＳＯＡＰメッセージを示す図である。ＳＯＡＰ型サービスクライアント１０１０が実際にサービスを利用する際に、上述した変換規則を用いて作成されたＳＯＡＰ型サービス定義文書１０００を参照して、ＳＯＡＰメッセージ１０２０を生成する。

ＳＯＡＰメッセージ１０２０には、上述の変換規則による効果で、ＳＯＡＰメッセージ自体にアクセスすべきＲＥＳＴ型サービスのアドレスとアクセスする際に必要となるパラメータ情報が含まれている。

＜Body＞要素の最初の子要素名１０２１は、ＲＥＳＴ型サービスにアクセスする際のメソッド“GET”とＲＥＳＴ型サービスの基本アドレスに対するパス（path）の“sample”が“_”で結合された状態なので文字列処理により分割する。また、ＳＯＡＰメッセージの＜Body＞要素の最初の子要素が属する名前空間１０２２は、アクセスすべきＲＥＳＴ型サービスの基本アドレスになっている。更に、＜GET_sample＞要素の子要素として、アクセスする際に必要となるパラメータが記述されている。要素名１０２３がパラメータ名になっており、値１０２４がパラメータの値になっている。

このような仕組みを持つＳＯＡＰメッセージ１０２０をメッセージ変換処理部１０３０が変換処理し、ＲＥＳＴメッセージ１０４０を生成する。変換処理中には、参照したのはＳＯＡＰメッセージのみであり、オブジェクト割り当てなどは行わず、文字列処理のみでＲＥＳＴメッセージを作成することが可能となっている。

図１１は、本実施形態における送受信メッセージ変換処理を行うシステムの構成を示す図である。また、図１２は、本実施形態における送受信メッセージ変換処理のシーケンスを示す図である。

本実施形態では、ＳＯＡＰ型サービスクライアント１１００から、ＳＯＡＰ型サービスサーバ１１１０にアクセスすることでＷｅｂサービスの変換を行い、ＲＥＳＴ型サービスＡ１１４０を利用する。

まず、ＳＯＡＰ型サービスクライアント１１００が、ＳＯＡＰメッセージ送受信部１１１１にＳＯＡＰメッセージを送信する（１２０１）。ここで送信するＳＯＡＰメッセージは、上述した変換規則に基づいて変換されたＳＯＡＰ型サービス定義を参照して生成したものである。

ＳＯＡＰメッセージ送受信部１１１１は、受信した要求ＳＯＡＰメッセージをメッセージ変換処理部１１１２に送信する（１２０２）。その際、従来技術で行っていた解析処理、サービス及びサービス機能の決定、ＸＭＬ要素の値の割り当て処理は行わない。

一方、メッセージ変換処理部１１１２は、受信した要求ＳＯＡＰメッセージを変換規則によって定義された情報に従って取得する（１２０３）。そして、取得した情報からＲＥＳＴ型サービスへの要求メッセージを生成する（１２０４）。次に、ここで生成した要求ＲＥＳＴメッセージをＲＥＳＴメッセージ送受信部１１１３に送信する（１２０５）。

要求ＲＥＳＴメッセージを受信したＲＥＳＴメッセージ送受信部１１１３は、ＲＥＳＴ型サービスＡ１１４０へＲＥＳＴ型サービスに送信する（１２０６）。要求ＲＥＳＴメッセージを受信したＲＥＳＴ型サービスＡ１１４０は、要求された処理を行い、その結果として応答ＲＥＳＴメッセージをＲＥＳＴメッセージ送受信部１１１３へ送信する（１２０７）。

応答ＲＥＳＴメッセージを受信したＲＥＳＴメッセージ送受信部１１１３は、メッセージ変換処理部１１１２に応答ＲＥＳＴメッセージを送信する（１２０８）。応答ＲＥＳＴメッセージを受信したメッセージ変換処理部１１１２は、応答ＲＥＳＴメッセージから応答ＳＯＡＰメッセージを生成する（１２０９）。応答ＳＯＡＰメッセージは、ＲＥＳＴ型サービスからの応答メッセージをＳＯＡＰメッセージの＜body＞要素以下に格納することで応答ＳＯＡＰメッセージを生成する。そして、メッセージ変換処理部１１１２は、生成した応答ＳＯＡＰメッセージをＳＯＡＰメッセージ送受信部１１１１に送信する（１２１０）。

応答ＳＯＡＰメッセージを受信したＳＯＡＰメッセージ送受信部１１１１は、受信した応答ＳＯＡＰメッセージをＳＯＡＰ型サービスクライアント１１００に送信する（１２１１）。

本実施形態では、従来のように対応するＲＥＳＴ型サービスの数だけメッセージ変換部を作成する必要がなく、メッセージ変換処理部は常に一つで良い。これは、変換規則によるものであり、実際に送信された要求ＳＯＡＰメッセージ内にＲＥＳＴ型サービスにアクセスするためのアドレスやパラメータ情報が含まれているためである。

［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態を詳細に説明する。第２の実施形態として、ファイル共有にて扱う場合を例に挙げて説明する。

図１３は、第２の実施形態におけるメッセージ変換処理を説明するための図である。

この例では、ＳＯＡＰ型サービスクライアント１３０１は使用可能なリソースに余裕があり、ＳＯＡＰ型サービスを利用することが可能なＰＣ１３００上で動作している。このＳＯＡＰ型サービスクライアント１３０１は、ＳＯＡＰ型サービスで提供されたファイル共有サービスを利用することを想定して作成されている。ここで、ファイル共有サービスＡ１３２１やファイル共有サービスＢ１３２２が、ＳＯＡＰ型サービスとして提供されたファイル共有サービスである。しかし、ＳＯＡＰ型サービスしか利用することができないため、ＲＥＳＴ型サービスとして提供されているファイル共有サービスＣ１３２３は直接利用することができない。

一方、組み込みデバイス１３３０は、使用できるリソースに限りがあるため、ＳＯＡＰ型サービスを利用することができない。そこで、組み込みデバイス１３３０では、Ｗｅｂサービスを利用する際に、ＲＥＳＴ型サービスを利用している。そのため、ファイル共有サービスＡ１３２１やファイル共有サービスＢ１３２２は利用できない。その代わりに、ＲＥＳＴ型サービスで提供されたファイル共有サービスＣ１３２３やファイル共有サービスＤ１３２４は、ＲＥＳＴ型サービスクライアント１３３１が利用できる。

このように、クライアントアプリケーションが動作する環境によって利用できるＷｅｂサービスが異なると、デバイスの種類によってファイルを共有できないという問題が発生する。具体的には、ＲＥＳＴ型サービスクライアント１３３１が利用できるファイル共有サービスＣ１３２３は、ＳＯＡＰ型サービスクライアント１３０１からは利用できない。そのため、ＰＣ１３００と組み込みデバイス１３３０との間で、ファイル共有ができないというものである。

この問題を解消するために、リソースが潤沢なデバイスでもＲＥＳＴ型サービスクライアントを作成し、作成されたＲＥＳＴ型サービスを利用するという方法がある。しかし、ファイル共有サービスにアクセスするためのクライアントが２種類必要になるため、追加の開発が必要になる。また、異なるプロトコルで通信するクライアントをシステムが管理する必要が生じるため、システムが複雑になるという新たな問題が発生する。

そこで、ＳＯＡＰ型サービスクライアント１３０１は、ＳＯＡＰ型サービス１３１０としてサービスを公開しているＷｅｂサービスの変換サービスを利用することにより、追加の開発をすることなく、ＲＥＳＴ型サービスが利用可能になる。具体的には、ＳＯＡＰ型サービスクライアント１３０１は、ＳＯＡＰメッセージ送受信部１３１１に要求ＳＯＡＰメッセージを送信し、メッセージ変換処理部１３１２が要求ＳＯＡＰメッセージから要求ＲＥＳＴメッセージへ変換を行う。

そして、ＲＥＳＴメッセージ送受信部１３１３からファイル共有サービスＣ１３２３にアクセスする。これにより、ＳＯＡＰ型サービスクライアントはＲＥＳＴ型クライアントを開発せずに、ＲＥＳＴ型サービスを意識することなくＳＯＡＰ型サービスと同様に利用することが可能となる。

また、上述したメッセージ変換処理部１３１２は、複数のＲＥＳＴ型サービスに対して１つのモジュールで対応できるように構成されている。そのため、ファイル共有サービスＣ１３２３からファイル共有サービスＤ１３２４に変換になった場合でも、ファイル共有サービスＤ１３２４が公開しているＲＥＳＴ型サービス定義文書をＳＯＡＰ型サービス定義文書に変換し、公開するだけで利用可能となる。その際に、追加の開発作業は伴わない。

［第３の実施形態］
次に、図面を参照しながら本発明に係る第３の実施形態を詳細に説明する。第３の実施形態として、フロー処理にて利用する場合を例に挙げて説明する。

図１４は、第３の実施形態におけるメッセージ変換処理を説明するための図である。

図１４に示すフロー処理サービス利用者１４１０は、複数のＳＯＡＰ型サービスを連携したワークフローを利用する利用者である。フロー処理実行装置１４２０は、ＳＯＡＰ型サービスを適宜呼び出すことで１つのワークフローを成立させる装置である。ここでは、旅行プランを作成するワークフローを例に挙げて説明する。

通常、旅行プラン作成のワークフローは、まず飛行機予約サービス１４３１を利用することで飛行機のチケットを予約し、ホテル予約サービス１４３２で宿泊するホテルを予約するというものである。ここで、旅行先で利用できるクーポンについても検索し、取得したいという利用者の要求があると、ワークフローとしては、フロー処理記述文書１４２１に示すようなフロー処理を実行する必要が発生する。具体的には、飛行機予約サービスを利用して飛行機を予約し、ホテル予約サービスを利用してホテルを予約し、クーポン取得サービスにてクーポンの取得を行った後、その結果を送信する。

しかし、クーポン取得サービスがＲＥＳＴ型サービスで提供されている場合、ＳＯＡＰ型サービスしか利用できないフロー処理実行装置１４２０では、フロー処理を行うことができない。以下、第３の実施形態におけるメッセージ変換処理を説明する。

第３の実施形態は、従来、利用することができなかったクーポン取得サービス１４３３を利用可能とするものである。

まず、クーポン取得サービス１４３３をフロー処理実行装置１４２０から認識することができるように、サービス定義変換処理部１４５０を用いて、クーポン取得サービス定義文書１４５１から、ＳＯＡＰ型サービス定義文書１４５２を生成する。サービス定義変換処理部１４５０では、図９を用いて説明した変換規則に従って変換を行う。そして、変換処理を行った後、ＳＯＡＰ型サービス定義文書１４５２を公開する。

これにより、フロー処理実行装置１４２０は、公開されたＳＯＡＰ型サービス定義文書１４５２を参照することで他のＳＯＡＰ型サービスと同様に、ＲＥＳＴ型サービスであるクーポン取得サービス定義文書１４５１を認識することが可能になる。また、フロー処理実行装置１４２０はクーポン取得サービス１４３３を利用可能になる。

そして、フロー処理実行装置１４２０は、公開されたＳＯＡＰ型サービス定義文書１４５２を参照し、サービス呼び出しのための要求ＳＯＡＰメッセージを生成する。その後、生成した要求ＳＯＡＰメッセージを、ＳＯＡＰメッセージ送受信部１４４１に対して送信する。この要求ＳＯＡＰメッセージを受信したＳＯＡＰメッセージ送受信部１４４１は、メッセージ変換処理部１４４２に要求ＳＯＡＰメッセージを送信する。

要求ＳＯＡＰメッセージを受信したメッセージ変換処理部１４４２は、上述の変換規則に従い、ＲＥＳＴ型サービスにアクセスする際のアドレス及び要求ＲＥＳＴメッセージに必要なパラメータを抽出する。抽出したパラメータを利用して要求ＲＥＳＴメッセージを生成する。

次に、抽出したアドレスと生成した要求ＲＥＳＴメッセージをＲＥＳＴメッセージ送受信部１４４３に送信する。ＲＥＳＴメッセージ送受信部１４４３は、メッセージ変換処理部１４４２より送信されたアドレスと要求ＲＥＳＴメッセージを利用してクーポン取得サービス１４３３にアクセスし、処理結果である応答ＲＥＳＴメッセージを受信する。

応答ＲＥＳＴメッセージを受信したＲＥＳＴメッセージ送受信部１４４３は、応答ＲＥＳＴメッセージをメッセージ変換処理部１４４２に送信する。メッセージ変換処理部１４４２は、応答ＲＥＳＴメッセージを受信した後、応答ＲＥＳＴメッセージから応答ＳＯＡＰメッセージを生成し、ＳＯＡＰメッセージ送受信部１４４１に送信する。そして、応答ＳＯＡＰメッセージを受信したＳＯＡＰメッセージ送受信部１４４１は、フロー処理実行装置１４２０に対して応答ＳＯＡＰメッセージを送信する。

これにより、フロー処理実行装置１４２０は、従来扱うことができなかったＲＥＳＴ型サービスから、処理結果を受信することが可能となる。また、ＳＯＡＰ型サービスのみで構成されたフロー処理の中に、ＲＥＳＴ型サービスを組み込むことが可能となる。

また、メッセージ変換処理部１４４２に上述の変換規則を導入したことで、変換対象となるＲＥＳＴ型サービスが限定されずに、複数のＲＥＳＴ型サービスを扱うことが可能となる。

例えば、ＲＥＳＴ型サービスで提供された地図案内サービスを追加する場合、最初に、地図案内サービスが定義されたＲＥＳＴ型サービス定義文書を、サービス定義変換処理部１４５０に送信する。次に、そのサービス定義文書を受け取ったサービス定義変換処理部１４５０は上述の変換規則に基づいて変換処理を行い、ＳＯＡＰ型サービス定義文書を公開する。最後に、ＳＯＡＰ型サービス１４４０のサービス定義の一つとして変換処理結果であるＳＯＡＰ型サービス定義文書を公開する。

これにより、ＳＯＡＰ型サービス１４４０では処理部分は１つであるが、サービス定義が２つ公開されることになり、擬似的に２つのサービスが動作しているように振る舞うことが可能となる。

また、複数のサービスに対応した場合でも、実行時にメッセージ変換処理部の実体は１つであるため、メモリ使用量が制限された機器上での動作も可能となっている。

第１乃至第３の実施形態によれば、プロトコルとしてＳＯＡＰを利用しないＲＥＳＴ型サービスをＳＯＡＰ型サービスのクライアントから利用可能になる。また、実行時の効果として、対応するＲＥＳＴ型サービスの個数が増加しても、メモリ使用量が増加することが無い。

これは、Ｗｅｂサービスの変換を行う変換処理部分が１つで変化しないため、変換処理部分のメモリ使用量が対応するサービス数に影響されないためである。そのため、メモリ使用量に制限のある組み込み機器上でも動作させることが可能となる。

また、Ｗｅｂサービスの変換を行う変換処理部は、ＳＯＡＰ型サービス定義文書を公開するため、フロー処理の中でＲＥＳＴ型サービスをＳＯＡＰ型サービスと同様に扱うことが可能となる。

更に、ＳＯＡＰ型サービス定義文書を公開することで、ＳＯＡＰ型サービスを利用する際に作成するＳＯＡＰ型サービスクライアントの開発も、従来と同様に行うことが可能となる。

本実施形態におけるコンピュータ装置の構成の一例を示すブロック図である。 ＷＳＤＬを利用して記述されたＳＯＡＰ型サービス定義文書の一例を示す図である。 本実施形態におけるＳＯＡＰ型サービスサーバの一般的な作成手順を示す図である。 本実施形態におけるＳＯＡＰ型サービスクライアントの作成手順を示す図である。 ＷＡＤＬを利用して記述されたＲＥＳＴ型サービスのサービス定義文書の一例を示す図である。 異なるＷｅｂサービスを利用するために必要な変換処理を示す図である。 サービス定義変換は行わずに送受信メッセージ変換処理を行うシステムの構成を示す図である。 要求ＳＯＡＰメッセージを受信したＳＯＡＰメッセージ送受信部の処理を示すフローチャートである。 サービス定義変換処理における変換規則を説明するための図である。 本実施形態で送信される要求ＳＯＡＰメッセージを示す図である。 本実施形態における送受信メッセージ変換処理を行うシステムの構成を示す図である。 本実施形態における送受信メッセージ変換処理のシーケンスを示す図である。 第２の実施形態におけるメッセージ変換処理を説明するための図である。 第３の実施形態におけるメッセージ変換処理を説明するための図である。

符号の説明

１００ コンピュータ装置
１０１ ＣＰＵ
１０２ ＲＯＭ
１０３ ＲＡＭ
１０４ 外部記憶装置
１０５ 入力デバイスインタフェース
１０６ ディスプレイインタフェース
１０７ ネットワークインタフェース
１０８ システムバス
１０９ 入力デバイス
１１０ モニタ
１１１ インターネット

Claims (12)

1. フロー処理装置であって、
   第２の型のサービスのサービス定義文書を予め決められた規則に従って第１の型のサービスのサービス定義文書へと変換する手段と、
   前記変換されたサービス定義文書に基づいて前記第２の型のサービスを前記第１の型のサービスとして利用するためにメッセージ変換処理を行う手段と、
   を有することを特徴とするフロー処理装置。
2. 前記予め決められた規則は、前記第２の型のサービスのサービス定義文書で定義された複数の第２の型のサービスを定義する識別子を、前記第１の型のサービスのサービス定義文書を一意に識別するための識別子として利用する規則であることを特徴とする請求項１に記載のフロー処理装置。
3. 前記予め決められた規則は、前記第２の型のサービスのサービス定義文書で定義された複数の第２の型のサービスを定義する識別子を、前記第１の型のサービスのサービス定義文書のメッセージが属する名前空間を一意に識別するための識別子として利用する規則であることを特徴とする請求項１に記載のフロー処理装置。
4. 前記予め決められた規則は、前記第２の型のサービスのサービス定義文書で定義された複数の第２の型のサービスを定義する識別子の組み合わせを、前記第１の型のサービスへの呼び出しに対する機能を識別するための識別子として利用する規則であることを特徴とする請求項１に記載のフロー処理装置。
5. 前記予め決められた規則は、前記第２の型のサービスの識別子を、前記第１の型のサービスを利用する際に送受信されるメッセージを識別する識別子として利用する規則であることを特徴とする請求項１に記載のフロー処理装置。
6. 前記メッセージ変換処理は、前記第１の型のサービスを利用するクライアントから送信されたメッセージが属する名前空間の識別子を前記第２の型のサービスの基本アドレスに変換することを特徴とする請求項１に記載のフロー処理装置。
7. 前記メッセージ変換処理は、前記第１の型のサービスを利用するクライアントから送信されたメッセージを構成する要素名から、前記第２の型のサービスの基本アドレスに対するパスに変換することを特徴とする請求項１に記載のフロー処理装置。
8. 前記メッセージ変換処理は、前記第１の型のサービスを利用するクライアントから送信されたメッセージに基づいて前記第２の型のサービスに対する要求メッセージを生成することを特徴とする請求項１に記載のフロー処理装置。
9. 前記メッセージ変換処理は、前記第２の型のサービスが送信したメッセージを前記第１の型のサービスのメッセージに格納し、前記第１の型のサービスに対する応答メッセージを生成することを特徴とする請求項１に記載のフロー処理装置。
10. フロー処理装置におけるメッセージ変換方法であって、
    第２の型のサービスのサービス定義文書を予め決められた規則に従って第１の型のサービスのサービス定義文書へと変換する工程と、
    前記変換されたサービス定義文書に基づいて前記第２の型のサービスを前記第１の型のサービスとして利用するためにメッセージ変換処理を行う工程と、
    を有することを特徴とするメッセージ変換方法。
11. コンピュータを請求項１乃至９の何れか１項に記載のフロー処理装置として機能させるためのプログラム。
12. 請求項１１に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images