JP2009223439A - メッセージ生成処理方法及びメッセージ生成処理装置 - Google Patents

Abstract

【課題】 ＷＥＢサービスを呼び出すためのＳＯＡＰメッセージを生成する際に、デバイス機器の資源の使用量を低減させる。
【解決手段】 サービスフロー処理装置がサービスフロー記述文書に基づいてフロー処理を実行中に、外部サービスに対して行ったリクエストに対するレスポンスのメッセージを受信する。サービスフロー記述文書に記述された、メッセージ内の特定の場所を指し示す識別情報を利用して、受信したレスポンスのメッセージからデータを抽出する。抽出したデータと、識別情報とを対応づけて保持し、その識別情報に対応づけて保持したデータから次の外部サービスへリクエストするためのメッセージを生成する。
【選択図】 図２

Description

本発明は、サービスフロー記述文書に基づいて外部サービスへリクエストするためのメッセージを生成する技術に関する。

従来、ＷＥＢサービスを順次実行させるためのＷＥＢサービスフロー記述文書（構造化文書）に従って、ＷＥＢサービスを順次実行させる技術が知られている（例えば、非特許文献１参照）。この構造化文書としては、ＷＳＢＰＥＬ（Web Service Business Process Execution）が広く用いられている。このＷＳＢＰＥＬは、拡張可能なマークアップ言語であるＸＭＬ（eXtensible Markup Language）によって記述されたＷＥＢサービスフロー記述言語である。ＷＳＢＰＥＬの仕様は、ＯＡＳＩＳ（organization for the Advancement of Structured Information Standards）で管理されている（非特許文献２参照）。

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

ＷＥＢサービスフロー記述文書を読み込み、その記述内容に従って、ＷＥＢサービスを順次実行させるフロー処理装置においては、ＷＥＢサービスフロー記述の内容に応じて、ＷＥＢサービスを以下の流れで呼び出す。

まず、呼び出し対象となるＷＥＢサービスのＷＥＢサービスインターフェース記述文書（ＷＳＤＬ）を読み込む。そして、対象のＷＥＢサービスが受け取れるメッセージの型を知るために、ＷＳＤＬに記述された構造定義であるスキーマ言語（ＸＭＬSchema）を参照する。ＸＭＬSchemaは、Ｗ３Ｃで定義されている。参照したスキーマを利用することで、ＸＭＬ形式であるＳＯＡＰ（Simple Object Access Protocol）メッセージの骨格を生成する。このＳＯＡＰは、Ｗ３Ｃで定義されている。

次に、生成したＳＯＡＰメッセージの骨格に対して、送信するデータを、ＸＰａｔｈ（XML Path Language）を利用して挿入し、ＳＯＡＰメッセージを完成させ、そのＳＯＡＰメッセージを送信する。ＸＰａｔｈはＷ３Ｃで定義されている。呼び出した結果、ＷＥＢサービスからの応答をＳＯＡＰメッセージで受信する。

次に、受信したＳＯＡＰメッセージからデータを抽出、或いはメッセージの加工などの処理を行う。そして、その処理結果を上述した方法でＳＯＡＰメッセージとして生成し、次のＷＥＢサービスに対して送信する。以上のような流れで処理を進めて実行させていくのが一般的である。

通常、ＸＭＬなどの構造化文書を扱う場合、Ｗ３Ｃで定義されているＤＯＭ（Document Object Model）が利用される。よって、ＸＭＬ形式であるＳＯＡＰメッセージを生成する過程においても、ＤＯＭインターフェースが利用されるのが一般的である。

また、このようなＷＥＢサービスを順次実行させるフロー処理装置は、本来資源豊富なパーソナルコンピュータやサーバ機器上に搭載するのが一般的である。
「ビジネス・プロセス：ＢＰＥＬ４ＷＳについて 第１回」http://www.ibm.com/developerworks/jp/webservices/library/ws-bpelcol1/ 「Web Service Business Process Execution Language Version 2.0」http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

しかしながら、ＳＯＡＰメッセージを生成する際に、ＤＯＭを利用してスキーマ全体を１度に読み込む場合、ＳＯＡＰメッセージ自体のサイズが大きければ、メモリなどの資源をより多く消費してしまう。この場合、低資源のデバイス機器などで、フロー処理装置を実行させると、ＳＯＡＰメッセージの生成時に、処理可能な資源のサイズを超える可能性がある。そのため、その時点で処理不能となり、ＷＥＢサービスフロー記述文書に記述された次以降の処理を進めることが困難であるという問題があった。

また、上述の処理の流れでは、ＳＯＡＰメッセージの骨格を先に生成し、その後必要な要素に値を挿入するので、実際には値を挿入してない要素をそのままＳＯＡＰメッセージとして書き出すこともある。そのため、不必要な情報が、呼び出し先のＷＥＢサービスに送信されるという問題もあった。

本発明は、ＷＥＢサービスを呼び出すためのＳＯＡＰメッセージを生成する際に、デバイス機器の資源の使用量を低減させることを目的とする。

本発明は、サービスフロー記述文書に基づいてフロー処理を実行するサービスフロー処理装置にて外部サービスへのメッセージを生成するメッセージ生成処理方法であって、フロー処理を実行中に前記外部サービスに対して行ったリクエストに対するレスポンスのメッセージを受信する受信工程と、前記サービスフロー記述文書に記述された、メッセージ内の特定の場所を指し示す識別情報を利用して前記レスポンスのメッセージからデータを抽出する抽出工程と、前記抽出したデータと前記識別情報とを対応づけて保持する保持工程と、前記識別情報に対応づけて保持したデータから次の外部サービスへリクエストするためのメッセージを生成する生成工程と、を有することを特徴とする。

また、本発明は、サービスフロー記述文書に基づいてフロー処理を実行するサービスフロー処理装置にて外部サービスへのメッセージを生成するメッセージ生成処理装置であって、フロー処理を実行中に前記外部サービスに対して行ったリクエストに対するレスポンスのメッセージを受信する受信手段と、前記サービスフロー記述文書に記述された、メッセージ内の特定の場所を指し示す識別情報を利用して前記レスポンスのメッセージからデータを抽出する抽出手段と、前記抽出したデータと前記識別情報とを対応づけて保持する保持手段と、前記識別情報に対応づけて保持したデータから次の外部サービスへリクエストするためのメッセージを生成する生成手段と、を有することを特徴とする。

本発明によれば、外部サービスを呼び出すためのメッセージを生成する際に、サービスフロー記述文書を展開するためのメモリ使用量を低減させることができる。そのため、低資源のデバイス機器でも処理が可能となり、本装置の搭載が可能となる。

また、複数のＸＰａｔｈからＸＭＬ文書をデータ付きで生成し、ＳＯＡＰメッセージを生成するようにすれば、値が含まれない要素などの不必要な情報が、呼び出し先のＷＥＢサービスに送信されるということも無くなる。

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

［第１の実施形態］
第１の実施形態として、識別情報による構造化文書形式のメッセージ生成処理の概要を、図１〜図４を用いて説明する。尚、識別情報は、ＸＰａｔｈ（XML Path Language）として説明する。

図１は、第１の実施形態におけるＷＥＢサービスフロー処理装置の概略を示す図である。図１において、１０１はコピー、スキャン、プリントなどの複数の機能を有する複合機である。第１の実施形態では、複合機１０１はＷＥＢサービスフロー記述文書を読み込み、その記述内容に従ってＷＥＢサービスを順次実行可能なＷＥＢサービスフロー処理装置１０２として機能する。

更に、ＷＥＢサービスフロー処理装置１０２の内部には、ＸＰａｔｈによる構造化文書形式のメッセージ生成及び構造検証部１０３が含まれる。以下、ＸＰａｔｈによる構造化文書形式のメッセージ生成及び構造検証部１０３をメッセージ生成及び構造検証部１０３と呼称する。

１０４はＷＥＢサービスフロー処理装置１０２が呼び出す対象の外部ＷＥＢサービスＡであり、また１０５はＷＥＢサービスフロー処理装置１０２が呼び出す対象の外部ＷＥＢサービスＢである。

１０６は外部ＷＥＢサービスＡ１０４及び外部ＷＥＢサービスＢ１０５を順次呼び出すための手順が記述されているＷＥＢサービスフロー記述文書である。１０７は外部ＷＥＢサービスＡ用ＷＥＢサービスインターフェース記述文書であり、また１０８は外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書である。これらの記述文書の詳細な構成は、更に後述する。

ここで、ＷＥＢサービスフロー処理装置１０２のメッセージ生成及び構造検証部１０３が識別情報による構造化文書形式のメッセージを生成する処理を説明する。

まず、ＷＥＢサービスフロー処理装置１０２は、不図示のスキャナにてＷＥＢサービスフロー記述文書１０６を読み込み、その記述内容に従ってフロー処理を開始する。そして、外部ＷＥＢサービスＡ１０４の呼び出しに関連する記述内容までＷＥＢサービスフロー記述文書１０６の記述内容を順次実行していく。

次に、メッセージ生成及び構造検証部１０３がリクエストＳＯＡＰメッセージＡ１０９を生成する。その際に、ＷＥＢサービスフロー記述文書１０６に記述されたＸＰａｔｈの情報と、検証処理を行う場合には、外部ＷＥＢサービスＡ用ＷＥＢインターフェース記述文書１０７の内容を利用する。尚、メッセージ生成処理及び検証処理の詳細は、更に後述する。

次に、メッセージ生成及び構造検証部１０３は生成したリクエストＳＯＡＰメッセージＡ１０９を外部ＷＥＢサービスＡ１０４に送信する。外部ＷＥＢサービスＡ１０４で処理が行われ、その結果として、レスポンスＳＯＡＰメッセージＡ１１０が返信される。そして、メッセージ生成及び構造検証部１０３がそのレスポンスＳＯＡＰメッセージＡ１１０を受信する。

次に、メッセージ生成及び構造検証部１０３がレスポンスＳＯＡＰメッセージＡ１１０から処理結果の情報を抽出する。ここで抽出した情報と、ＷＥＢサービスフロー記述文書１０６に記述されたＸＰａｔｈの情報と、検証処理を行う場合には、外部ＷＥＢサービスＢ用ＷＥＢインターフェース記述文書１０８の内容を利用してリクエストＳＯＡＰメッセージＢ１１１を生成する。

次に、メッセージ生成及び構造検証部１０３は生成したリクエストＳＯＡＰメッセージＢ１１１を外部ＷＥＢサービスＢ１０５に送信する。外部ＷＥＢサービスＢ１０５で処理が行われ、その結果として、レスポンスＳＯＡＰメッセージＢ１１２が返信される。そして、ＷＥＢサービスフロー処理装置１０２がそのレスポンスＳＯＡＰメッセージＢ１１２を受信する。

このように、メッセージ生成及び構造検証部１０３が外部ＷＥＢサービスを呼び出す際に、必要なリクエストＳＯＡＰメッセージを生成する。その際に、ＷＥＢサービスフロー記述文書１０６の内容と、レスポンスＳＯＡＰメッセージの内容と、検証処理を行う場合には、外部ＷＥＢサービス用インターフェース記述文書の内容を利用する。

ここで、メッセージ生成及び構造検証部１０３の具体的な処理の内容を、図２を用いて説明する。尚、図２では、外部ＷＥＢサービスＢ１０５のＷＥＢサービスを呼び出す際のリクエストＳＯＡＰメッセージＢ１１１を生成する処理を示している。

図２は、メッセージ生成及び構造検証部１０３における内部処理構成の一例を示す図である。図２において、２０１はメッセージ受信処理部であり、レスポンスＳＯＡＰメッセージＡ１１０を外部ＷＥＢサービスＡ１０４から受信する。２０２はデータ抽出処理部であり、ＷＥＢサービスフロー記述文書１０６に記述されたＸＰａｔｈの内容を利用して、レスポンスＳＯＡＰメッセージＡ１１０から必要なデータを抽出する。

このＸｐａｔｈは、ＷＥＢサービスフロー記述文書１０６に記述されているメッセージの構造情報を含み、メッセージ内の特定の場所を指し示す識別情報である。

２０３はＸＰａｔｈ式関連づけ処理部であり、抽出したデータとＷＥＢサービスフロー記述文書１０６から次に呼び出すＷＥＢサービスに関連するＸＰａｔｈ式を抽出し、それらを関連づけた情報として保持する。次に呼び出すＷＥＢサービスに関連するＸＰａｔｈ式は、データ抽出処理部２０２で抽出されたデータの挿入先を示すＷＥＢサービスフロー記述文書１０６に記述されたメッセージの構造情報を含み、メッセージ内の特定の場所を指し示す識別情報である。

２０４はメッセージ生成処理部であり、ＸＰａｔｈ式関連づけ処理部２０３で関連づけた情報からリクエストＳＯＡＰメッセージを組み立て、メッセージを生成する。ここでは、次に呼び出すＷＥＢサービスに関連するＸＰａｔｈ式と、それに対応するデータ抽出処理部２０２で抽出されたデータとを利用して、リクエストＳＯＡＰメッセージＢ１１１を生成する。

上述のメッセージ生成及び構造検証部１０３の処理の流れは以上になるが、次に具体的なＷＥＢサービスフロー記述文書を用いて処理内容を詳細に説明する。

図３は、第１の実施形態におけるＷＥＢサービスフロー記述文書１０６の構成の一例を示す図である。ＷＥＢサービスフロー記述文書１０６はプログラムで言う変数宣言などを記述する宣言部３０１、及びフロー処理のロジックなどを記述するロジック部３０２から構成されている。

尚、ロジック部３０２には、本来であれば、クライアントからリクエストメッセージを受信する記述やクライアントにレスポンスメッセージを返信する記述など、全てのフロー処理の内容が書かれる。しかし、図３に示す例では、本発明を説明するために必要な情報だけを記述している。

まず、宣言部３０１において、３１１はＷＥＢサービスフロー記述文書を特定する情報、及び呼び出し先各ＷＥＢサービスのインターフェース記述文書を特定する情報である。３１２はＷＥＢサービスフロー処理で用いる変数情報である。

そして、ロジック部３０２において、３２１は外部ＷＥＢサービスＡを呼び出し、外部ＷＥＢサービスＡに処理を行わせ、その処理結果のレスポンスメッセージを受信する処理内容である。３２２は受信した処理結果のレスポンスメッセージから、処理結果を抽出し、外部ＷＥＢサービスＢが解釈可能なリクエストメッセージを生成する処理内容である。３２３は外部ＷＥＢサービスＢを呼び出し、外部ＷＥＢサービスＢに処理を行わせ、その処理結果のレスポンスメッセージを受信する処理内容である。

図３において、３０３はＷＥＢサービスフロー記述文書１０６の構成に対応する具体的な記述例である。この例では、ＷＳＢＰＥＬというＷＥＢサービスの処理フローをＸＭＬ文書で記述するための標準仕様になっている言語で記述している。尚、ＷＳＢＰＥＬは、Web Service Business Process Execution Languageの略であり、ＸＭＬは、eXtensible Markup Languageの略である。

ここで、ＷＥＢサービスフロー記述文書１０６の構成と、記述例３０３を比較しながら詳細に説明する。３３１は宣言部３０１における３１１の記述内容に対応する。３３１はＷＥＢサービスフロー記述文書を特定する情報、及び呼び出し先各ＷＥＢサービスのインターフェース記述文書（ＷＳＤＬ文書）を特定する情報が＜process＞タグの属性値としてネームスペースで記述されている。３３２は宣言部３０１における３１２の記述内容に対応する。３３２はフロー処理を行うときに使用するメッセージ変数の型情報がそれぞれ＜variable＞タグで記述されている。

３３３はロジック部３０２における３２１の記述内容に対応する。３３３は外部ＷＥＢサービスＡを呼び出し、処理を行わせ、処理結果のレスポンスメッセージを受信する処理内容が、＜invoke＞タグで記述されている。３３４はロジック部３０２における３２２の記述内容に対応する。３３４は受信したレスポンスメッセージからＸＰａｔｈを利用して処理結果を抽出し、その処理結果とＸＰａｔｈから、外部ＷＥＢサービスＢが解釈可能なリクエストメッセージを生成する処理内容が、＜assign＞タグなどで記述されている。

３３５はロジック部３０２における３２３の記述内容に対応する。３３５は外部ＷＥＢサービスＢを呼び出し、処理を行わせ、処理結果のレスポンスメッセージを受信する処理内容が、＜invoke＞タグで記述されている。

ロジック部３０２の記述内容に対応する＜assign＞、＜invoke＞タグは、ＷＳＢＰＥＬではアクティビティと呼ぶ。＜assign＞タグはメッセージの加工、変換、＜invoke＞タグは外部のＷＥＢサービスの呼び出しといったように、ＷＥＢサービスフロー処理の表現を抽象化したものである。

次に、図４に示すＳＯＡＰメッセージの具体例を用いてメッセージ生成及び構造検証部１０３の内部処理構成の処理の流れを説明する。

４０１はレスポンスＳＯＡＰメッセージＡ１１０の具体例である。４０２は３３４で示した部分を抜粋したものである。即ち、受信したレスポンスのメッセージからＸＰａｔｈを利用して、処理結果を抽出し、その処理結果とＸＰａｔｈから外部ＷＥＢサービスＢが解釈可能なリクエストメッセージを生成する処理内容の抜粋である。

４０１、４０２を利用してデータ抽出処理部２０２の処理を説明する。４０２の＜assing＞タグの次の階層には＜copy＞タグ、その次の階層には＜from＞タグと＜to＞タグが記述されている。＜copy＞タグでは、受信したメッセージから＜from＞タグで記述されたＸＰａｔｈに対応する場所からデータを抽出し、次に送信するメッセージの＜to＞タグで記述されたＸＰａｔｈに対応する場所にデータを挿入すると解釈する。

よって、４０３に示すように、まず、＜from＞タグに示す「/Response/data/address」を利用して、レスポンスＳＯＡＰメッセージＡから、＜address＞タグの「tokyo」というデータを抽出する。また同様に、４０４では、「abc」というデータを抽出し、４０５では「03-1234-5678」というデータを抽出する。

即ち、これらのデータの抽出には、サービスフロー記述文書に記述された（レスポンス）メッセージの構造情報を含み、（レスポンス）メッセージ内の特定の場所を指し示す＜from＞タグを含むＸＰａｔｈが識別情報として使用される。

次に、４０６を用いてＸＰａｔｈ式関連づけ処理部２０３の処理を説明する。４０６は４０３〜４０５で抽出したデータと、４０２の＜to＞タグに記述されたＸＰａｔｈとを対応づけたものである。４０７では、４０３で抽出した「tokyo」というデータと、対応する＜to＞タグに記述された「/Request/address」を対応づけている。また同様に、４０８では、「abc」と「/Request/person/name」、４０９では、「03-1234-5678」と「/Request/person/phone」を、それぞれ対応づけて保持している。

この＜to＞タグに記述されたＸＰａｔｈは、４０３〜４０５で抽出したデータの挿入先を示すサービスフロー記述文書に記述されたメッセージの構造情報を含み、メッセージ内の特定の場所を指し示す識別情報である。

次に、４０６で対応づけた情報を順番に利用してメッセージ生成処理部２０４において、メッセージを組み立てていく処理を説明する。まず、４０７の情報から、４１０に示すように、ＸＰａｔｈ「/Request/address」から、＜Request＞＜address＞＜/address＞＜/Request＞というＸＭＬの構造を組み立てる。そして、＜address＞タグにデータを入れた４１１のメッセージを生成する。次に、４１２に示すように、４１１のメッセージに、４０８の情報を埋め込み、＜address＞タグの次に＜person＞タグ以下を埋め込んだ４１３のメッセージを生成する。次に、４１４に示すように、４１３のメッセージに、４０９の情報を埋め込み、＜name＞タグの次に＜phone＞タグを埋め込んだ４１５のメッセージを生成する。そして、生成した４１５のメッセージを＜Body＞タグに埋め込む形で、最終的に４１６のＳＯＡＰメッセージを生成する。

第１の実施形態によれば、呼び出し先のＷＥＢサービスが解釈可能なＳＯＡＰメッセージの全体骨格をＷＳＤＬ文書から作り、その後、データを挿入していくよりも、ＳＯＡＰメッセージ生成時における資源の消費量を抑えることが可能となる。ここで、資源とは、例えばハードディスク、メモリなどである。

また、データが挿入されていない要素だけの情報といった不必要な情報がメッセージに付加されないので、呼び出し先のＷＥＢサービスに対して不必要な情報までも送信される、ということも無くなる。

［第２の実施形態］
次に、図面を参照しながら本発明に係る第２の実施形態を詳細に説明する。第１の実施形態と同様に、第２の実施形態でも、識別情報をＸＰａｔｈとして扱う。第１の実施形態では、メッセージ生成処理部２０４が、４０６に示す対応づけ情報から順番にメッセージを組み立てただけであった。第２の実施形態では、メッセージの組み立て時にメッセージとして、より正確か否かを検証する処理が追加された場合を、図５及び図６を用いて説明する。

尚、図５に示すメッセージ生成及び構造検証部１０３は、図２に示す構成と一部同じであるため、図２中の符号を用いて説明する。また、図６に示すＸＰａｔｈと抽出データの対応づけ情報や、メッセージ生成処理の過程も、図４に示す情報と一部同じなので、図４中の符号を用いて説明する。

５０１はメッセージ生成及び検証処理部である。メッセージ生成及び検証処理部５０１は、ＷＥＢサービスインターフェース記述文書５０２から、メッセージの構造を示すスキーマの情報を読み込む。そして、ＸＰａｔｈ式関連づけ処理部２０３からの対応づけ情報４０６と比較し、構造が正しいか検証しながらメッセージを組み立てて生成し、検証済みリクエストＳＯＡＰメッセージＢ５０３として送信する。

次に、図５に示す処理の流れを、メッセージの具体例を用いて説明する。図６において、４１１のメッセージを組み立てるまでは、図４で説明した処理と同様である。６０１はＷＥＢサービスインターフェース記述文書５０２の例であり、ＷＳＤＬ文書である。このＷＳＤＬ文書の中にスキーマの情報６０２が記述されている。スキーマの情報としては、構造定義文書（ＸＭＬＳｃｈｅｍａ）が例として記述されている。これらの情報を利用して、スキーマ情報に沿った構造になるように、検証処理を行いながら、メッセージを生成する。

６０２のスキーマを見ると、６０３に＜person＞タグについての情報が＜xsd:element name=”person”＞と記述されている。また同様に、６０４に＜address＞タグについての情報が＜xsd:element minOccurs=”0” maxOccurs=”1” name=”address” type=”xsd:string”＞と記述されている。これらのスキーマ情報は、６０５に示す＜xsd:sequence＞タグに囲まれている。そのため、スキーマの仕様から６０３の＜person＞タグの次に６０４の＜address＞タグが出現しなければならないと解釈できる。

よって、メッセージ生成及び検証処理部５０１では、４１３のメッセージを生成せず、４１１のメッセージに対して４０８の情報を挿入させるときに、その挿入位置を確認し、６０６に示すように、６０７のメッセージを次に生成するようにする。そして、４０９の＜phone＞タグとそのデータの情報を６０８に示すように、スキーマの情報を確認しながら最適な位置に挿入し、６０９のメッセージを生成する。そして、生成した６０９のメッセージを＜Body＞タグに埋め込む形で、最終的に６１０のＳＯＡＰメッセージとして生成する。

第２の実施形態は、第１の実施形態におけるＳＯＡＰメッセージ生成時において、更に検証機能を追加したものとなり、より正確なＳＯＡＰメッセージを外部のＷＥＢサービスに送信することが可能となる。

［第３の実施形態］
次に、図面を参照しながら本発明に係る第３の実施形態を詳細に説明する。第１の実施形態及び第２実施形態では、識別情報をＸＰａｔｈとして扱ったが、第３の実施形態では、識別情報をＸＰａｔｈ以外の情報として扱う。

図７は、第３の実施形態における識別情報の一例を説明するための図である。例えば、外部サービスが解釈できるメッセージの形式が７０１に示す形式であった場合を想定する。７０２は７０１のメッセージ形式に対して、データの取得や挿入を操作できる識別情報とデータを対応づけた情報である。７０３、７０４、７０５で示す部分がそれぞれサービスフロー記述文書に記述されているものとする。まず、７０６に示すように、title=baseから[base]、key=nameとデータであるabcからname=abcというように、対応づけた情報を７０７の形にマッピングする。

また同様に、７０８に示すように、７０９のように対応づけた情報をマッピングする。７１０に示すように、既に[base]は存在するので、その項目を追加する形でaddress=tokyoを７１１に示す形で挿入し、マッピングする。このような流れで、外部サービスへのメッセージを生成する。

生成したメッセージ７１１と、例えばデータがまだ挿入されていない骨格だけを示したメッセージ７０１に対して７１８に示すように、７０２の対応づけた情報からデータを挿入した７１９を比較する。７１９には、７１１にはない、age=やe-mail=などのデータが空の情報までも付加されている。よって、外部サービスに対して不必要な情報を与えないですむ。また、７０１の骨格を示したメッセージ自体が大容量の場合、全体を読み込む時点でメモリを多く消費することが予想される。

よって、上述した流れで、順番にメッセージを組み立てていくことで、メモリの消費量も減らすことが可能となる。

［第４の実施形態］
次に、図面を参照しながら本発明に係る第４の実施形態を詳細に説明する。第１の実施形態では、複合機に本発明を適用した場合を例に挙げて説明したが、本発明はこれだけに限らず、パーソナルコンピュータのような情報処理装置に適用することも可能である。

図８は、ＷＥＢサービスフロー処理装置として機能させる情報処理装置のハードウェア構成の一例を示す図である。図８に示すように、情報処理装置は、入力装置８０１、表示装置８０２、記録媒体ドライブ装置８０３、ＲＯＭ８０５、ＲＡＭ８０６、ＣＰＵ８０７、インターフェース装置８０８、ＨＤ（ハードディスク）８０９を含む。

入力装置８０１は、操作者（オペレータ）が操作するキーボード及びマウスなどで構成され、情報処理装置に各種操作情報などを入力するのに用いられる。表示装置８０２は、操作者が利用するディスプレイなどで構成され、各種情報（又は画面）などを表示するのに用いられる。インターフェース装置８０８は、情報処理装置をネットワークなどに接続するインターフェースである。

前述したメッセージ生成及び構造検証部１０３の処理などのプログラムは、例えばＣＤ−ＲＯＭなどの記録媒体８０４によって情報処理装置に提供されるか、ネットワークなどを通じてダウンロードされる。記録媒体８０４は、記録媒体ドライブ装置８０３にセットされ、プログラムが記録媒体８０４から記録媒体ドライブ装置８０３を介してＨＤ８０９にインストールされる。

ＲＯＭ８０５は、情報処理装置の電源投入時に、最初に読み込まれるプログラムなどを格納する。ＲＡＭ８０６は、情報処理装置のメインメモリである。ＣＰＵ８０７は、ＨＤ８０９よりプログラムを読み出してＲＡＭ８０６に格納し、プログラムを実行することで、前述した処理内容を実現する。また、ＨＤ８０９は、プログラム以外に、例えばＷＥＢサービスフロー記述文書、ＷＥＢサービスインターフェース記述文書などを格納する。

尚、本発明は複数の機器（例えば、ホストコンピュータ、インターフェース機器、リーダ、プリンタなど）から構成されるシステムに適用しても、１つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用しても良い。

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

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

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

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

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

第１の実施形態におけるＷＥＢサービスフロー処理装置の概略を示す図である。 メッセージ生成及び構造検証部１０３における内部処理構成の一例を示す図である。 第１の実施形態におけるＷＥＢサービスフロー記述文書１０６の構成の一例を示す図である。 第１の実施形態におけるＳＯＡＰメッセージの具体例を示す図である。 第２の実施形態におけるメッセージ生成及び構造検証部１０３の内部処理構成を示す図である。 第２の実施形態におけるＳＯＡＰメッセージの具体例を示す図である。 第３の実施形態における識別情報の一例を説明するための図である。 ＷＥＢサービスフロー処理装置として機能させる情報処理装置のハードウェア構成の一例を示す図である。

符号の説明

１０１ 複合機
１０２ ＷＥＢサービスフロー処理装置
１０３ ＸＰａｔｈによる構造化文書形式のメッセージ生成及び構造検証部
１０４ 外部ＷＥＢサービスＡ
１０５ 外部ＷＥＢサービスＢ
１０６ ＷＥＢサービスフロー記述文書
１０７ 外部ＷＥＢサービスＡ用ＷＥＢサービスインターフェース記述文書
１０８ 外部ＷＥＢサービスＢ用ＷＥＢサービスインターフェース記述文書
１０９ リクエストＳＯＡＰメッセージＡ
１１０ レスポンスＳＯＡＰメッセージＡ
１１１ リクエストＳＯＡＰメッセージＢ
１１２ レスポンスＳＯＡＰメッセージＢ
２０１ メッセージ受信処理部
２０２ データ抽出処理部
２０３ ＸＰａｔｈ式関連づけ処理部
２０４ メッセージ生成処理部

Claims (9)

1. サービスフロー記述文書に基づいてフロー処理を実行するサービスフロー処理装置にて外部サービスへのメッセージを生成するメッセージ生成処理方法であって、
   フロー処理を実行中に前記外部サービスに対して行ったリクエストに対するレスポンスのメッセージを受信する受信工程と、
   前記サービスフロー記述文書に記述された、メッセージ内の特定の場所を指し示す識別情報を利用して前記レスポンスのメッセージからデータを抽出する抽出工程と、
   前記抽出したデータと前記識別情報とを対応づけて保持する保持工程と、
   前記識別情報に対応づけて保持したデータから次の外部サービスへリクエストするためのメッセージを生成する生成工程と、
   を有することを特徴とするメッセージ生成処理方法。
2. 前記サービスフロー記述文書は、ＷＥＢサービスを順次呼び出すための手順を記述したＷＥＢサービスフロー記述文書であることを特徴とする請求項１に記載のメッセージ生成処理方法。
3. 前記サービスフロー記述文書は、構造化文書であることを特徴とする請求項１に記載のメッセージ生成処理方法。
4. 前記識別情報は、ＸＰａｔｈであることを特徴とする請求項１に記載のメッセージ生成処理方法。
5. 前記メッセージは、ＳＯＡＰメッセージであることを特徴とする請求項１に記載のメッセージ生成処理方法。
6. 前記外部サービスが解釈可能なメッセージの構造を示す構造定義文書の記述に基づいて前記生成したメッセージの構造を検証する工程を更に有することを特徴とする請求項１に記載のメッセージ生成処理方法。
7. サービスフロー記述文書に基づいてフロー処理を実行するサービスフロー処理装置にて外部サービスへのメッセージを生成するメッセージ生成処理装置であって、
   フロー処理を実行中に前記外部サービスに対して行ったリクエストに対するレスポンスのメッセージを受信する受信手段と、
   前記サービスフロー記述文書に記述された、メッセージ内の特定の場所を指し示す識別情報を利用して前記レスポンスのメッセージからデータを抽出する抽出手段と、
   前記抽出したデータと前記識別情報とを対応づけて保持する保持手段と、
   前記識別情報に対応づけて保持したデータから次の外部サービスへリクエストするためのメッセージを生成する生成手段と、
   を有することを特徴とするメッセージ生成処理装置。
8. 請求項１乃至６の何れか１項に記載のメッセージ生成処理方法をコンピュータに実行させるためのプログラム。
9. 請求項８に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images