JP4574197B2 - データ処理方法、プログラム、及び、装置 - Google Patents

Description

本発明は、データ処理方法、プログラム、及び、装置に関するものである。

図１は従来技術におけるクライアントサーバ方式のメッセージを用いた分散処理の概要を示したものである。

サーバＳ１、Ｓ２とクライアントＣ１は、それぞれに処理プログラムＰ１、Ｐ２、Ｐ３を有しており、内部にこの処理プログラムの処理対象となるデータＤ１のみを格納したメッセージＭ１が、クライアントＣ１とサーバＳ１、Ｓ２の間で送受信されることで、分散的に処理が実行される。

この時に送受信されるのはデータのみであるので、サーバＳ１とＳ２が相互に異なる計算機言語あるいはオペレーティングシステムやサーバソフトウエアなどの実行環境で構成されている場合においても、同一のメッセージＭ１をクライアントＣ１とサーバＳ１あるいはＳ２は用いることができるのがメッセージを基本とした分散処理のメリットの一つである。この図では、実行環境Ｅ１と実行環境Ｅ２の二つの相互に異なる実行環境を有するノードがクライアントとサーバにおいて混在している。

しかしながら、この方式でそのままメッセージにデータだけではなくプログラムも入れて送受信しようとするとサーバ側とクライアント側での実行環境、特にプログラム処理環境が同一でなければならないという問題が発生する。これはデータの解釈は任意のプログラミング言語・計算機環境で行うことが可能であるが、プログラムの実行はそのプログラムの記述計算機言語に依存した実行環境を必要とするからである。これにより、プログラムの送受信を行うことを可能とした場合、異種環境での混在処理というメリットを失うという問題がメッセージ交換を基本とした分散処理技術にはあった。

このような背景から成立している従来技術としては、例えば特許文献１がある。これはクライアントとサーバにおける処理の呼び出しにおいて、パラメータ（データ）をＸＭＬ変換することでインターネット環境との連携を容易にしようというものである。しかしながら、当該技術ではリクエストのパラメータのみがＸＭＬ化されているに過ぎず、最終的にデータとプログラムを合わせた存在であるオブジェクトを実行する環境が送信側と受信側で一致していなければならないという問題の解決にはなっていない。

こうした問題を解決する手段として、実行環境の上にさらに仮想的な実行環境（バーチャルマシン・ＶＭ）を重ねることで共通した実行環境を構築する手法がある。しかしながら、これは結局のところ実行環境を同一にすることを容易にしているのに過ぎず、また計算機言語自体の仕様は従来型の記法を用いたものであるため、現実的には次項に述べるメッセージの中におけるデータとプログラムの記述方式のミスマッチを発生させるという問題があった。

また、計算機における分散処理の構築手法であるＷｅｂサービス技術がある。Ｗｅｂサービス技術においては、メッセージは拡張可能なマークアップ言語であるＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）によって記述される。ＸＭＬとはＷＷＷコンソーシアム（Ｗ３Ｃ）が１９９８年にインターネット上で構造化文書を活用することを目標として制定したものである。ＸＭＬについてはｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＸＭＬ／で仕様を参照することができる。また、こうしてＸＭＬによって記述されたメッセージの仕様をＷｅｂサービス技術ではＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）と呼称する。ＳＯＡＰはメッセージの記述仕様を定めたものであり、どのようなデータをどのように表現するかと言った方法について規定する。Ｗｅｂサービス技術におけるＳＯＡＰを用いることで図１における分散処理は容易に実現できることとなる。ＳＯＡＰもＸＭＬと同様にＷＷＷコンソーシアム（Ｗ３Ｃ）が仕様を公開しており、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ＳＯＡＰ／にてその内容を参照することができる。

Ｗｅｂサービス技術を用いたメッセージ送受信においてはＸＭＬで記述されたＳＯＡＰを用いるのが基本である。ＸＭＬを用いたＳＯＡＰは、またメッセージを構造化文書として取り扱うことを可能としている。これはメッセージを文書とみなし、その任意の部分に関して処理を自由に行うことが可能となっているということである。
特開２００３−１５７１７８号公報

このようにＳＯＡＰを用いたメッセージ送受信においては、ＸＭＬ文書という枠組みをメッセージの書式として維持することが非常に重要になってくる。しかしながら、前述の仮想的な実行環境をお互いに有することによってＳＯＡＰの仕組みの中でプログラムを送受信しようとすると、プログラムの記述箇所部分のみがＸＭＬの枠組みから外れることになるという問題が顕在化する。

なぜならば、プログラムの記述方法そのものは特にＸＭＬとの親和性を勘案したものではない、従来型の記法を用いる必要があるからであるである。これは、特にＳＯＡＰあるいはＸＭＬ文書が流通することを前提として構築されているＷｅｂサービス技術を用いた各ノードにおいて、メッセージの内容に解釈不能な部分が内包されているという状況を作り出すことになり、前述した部分的な暗号化や署名などのＸＭＬを用いたメッセージングというＳＯＡＰのメリットを失わせることになってしまう。

また、仮想的な環境を作成してプログラムを動作させる方式においては、仮想的な環境がその計算機言語において記述可能なプログラム全般の実行を想定しなければならないため比較的巨大なものとならざるを得ず、潤沢な計算機資源を要求するという問題点も存在する。すなわち、本来の計算機環境とは別の多重な計算機環境を構築する必要からくるオーバヘッドが無視できないという問題もある。

また、本格的な処理の記述までをカバーしようとする言語であればコンパイラ方式を採用する場合も多く、この場合は実行時にコンパイル処理という負荷をさらに支払う必要がある。もしコンパイル済みのオブジェクトをバイナリー形式で送信した場合は、実行前に実行内容が確認できないという問題が発生してしまう。

上記課題を解決するため、本発明のデータ処理方法は、データ部と、前記データ部を処理するサービスの仕様を示す仕様部と、前記仕様部を参照する命令を含むプログラム部とを備えるＳＯＡＰメッセージを受信し、受信した前記ＳＯＡＰメッセージ中のＢＰＥＬ４ＷＳで記述されたプログラム部に含まれる命令の実行時に、実行する命令が参照し、前記仕様部により仕様が示されるサービスにより、前記ＳＯＡＰメッセージに備えられた前記データ部を処理することを特徴とする。

以上説明したように、本発明によれば、データ部と、前記データ部を処理するサービスの仕様を示す仕様部と、前記仕様部を参照する命令を含むプログラム部とを備えるＳＯＡＰメッセージを受信し、受信した前記ＳＯＡＰメッセージ中のＢＰＥＬ４ＷＳで記述されたプログラム部に含まれる命令の実行時に、実行する命令が参照し、前記仕様部により仕様が示されるサービスにより、前記ＳＯＡＰメッセージに備えられた前記データ部を処理することで、メッセージを記述する枠組みの範囲内で、プログラム及び必要なデータを記述することができる。

また、本発明によれば、プログラムを少ない計算機資源で実行することが可能である。

以下、図面を参照して本発明の一実施形態を詳細に説明する。具体的な処理例の記載を併記しているが、本発明はこの具体的な処理例に限定されるものではない。

まず、ＳＯＡＰメッセージの概要について説明する。全体の構成はエンベローブ部、ヘッダー部、ボディー部で構成される。また、エンベローブ部、ヘッダー部は従来技術と同様の内容で構成されており、ＳＯＡＰを処理対象とする既存の処理系に対して変更を要求しない。本形態では、ボディー部においては、通常のＳＯＡＰで格納するデータ部Ｄ１以外に、仮想サービス部Ｓ１およびプログラム部Ｐ１を格納する。

図２は本形態でのメッセージ送受信について概要を示したものである。まずクライアントＣ１が外部の処理系（サーバＳ１）にて行いたい処理を決定し、ＳＯＡＰ処理プログラムＰ３においてＳＯＡＰメッセージＭ１を生成する。この時、データＤ１のみを格納するのではなく、そのデータＤ１をどのように処理して欲しいかを示したプログラムＰ１も同時に格納して生成する。この時、プログラムＰ１はＸＭＬを用いたＳＯＡＰメッセージと親和性の高い計算機言語であるサービス連携記述言語により記述される。この点は詳細に後述する。

その後、クライアントＣ１はメッセージＭ１をサーバＳ１に送信する。受信したサーバＳ１は通常のＳＯＡＰメッセージであればＳＯＡＰ処理プログラムＰ２にて処理を行うが、プログラムＰ１が内包されたＳＯＡＰメッセージの場合は仮想サービス処理プログラムＰ４に処理を移行する。仮想サービス処理プログラムＰ４はメッセージに格納されている仮想サービス部Ｓ１を通じて、プログラム部Ｐ１と処理対象のデータであるデータＤ１を結びつける。そしてサービス連携処理プログラムＰ５にてプログラムＰ１の実行を行う。その後、実行後の結果がサーバＳ１からクライアントＣ１に返却される。

図３は上記の処理ステップをフローチャートにて表現したものである。まず、図３（Ａ）のステップＳ３０１にてクライアントＣ１が外部の処理系にて行いたい処理を決定する。次にＳＯＡＰ処理プログラムＰ３においてＳＯＡＰメッセージＭ１を生成する。すなわち、ステップＳ３０２にてデータＤ１をＳＯＡＰメッセージＭ１に格納し、ステップＳ３０３にてそのデータＤ１をどのように処理して欲しいかを示したプログラムＰ１と仮想サービス部Ｓ１を生成してＳＯＡＰメッセージＭ１に格納する。次にステップＳ３０４にてクライアントＣ１はＳＯＡＰメッセージＭ１をサーバＳ１に送信する。ステップＳ３０３の処理については、さらに詳細に後述する。なお、仮想サービス部Ｓ１は、データＤ１を処理する仕様を示す仕様部である。

サーバＳ１は、図３（Ｂ）のステップＳ３０５にてＳＯＡＰ処理プログラムＰ２により当該メッセージを受信し、ステップＳ３０６にて通常のＳＯＡＰメッセージであるかどうかを判別し、もし通常であればステップＳ３０７にて通常のＳＯＡＰ処理プログラムＰ２にて処理を行う。プログラム部Ｐ１が内包されていれば、仮想サービス処理プログラムＰ４に処理を移行する。ステップＳ３０８で仮想サービス処理プログラムＰ４は仮想サービスを構成するために必要な情報を、メッセージに格納されている仮想サービス部Ｓ１の情報から取得し、ステップＳ３０９でプログラム部Ｐ１と処理対象のデータであるデータＤ１を結びつけるための仮想サービスを構築する。そして、その情報をステップＳ３１０でサービス連携処理プログラムＰ５に送る。ステップＳ３１１でサービス連携処理プログラムＰ５はプログラムＰ１の実行を行う。その後、ステップＳ３１２にて実行後の結果がサーバＳ１からクライアントＣ１に返却される。ステップＳ３０９においては、さらに詳細な処理を後述する。

以下に、上記形態にてクライアントＣ１にてＳＯＡＰメッセージＭ１が生成されるときにプログラムＰ１の記述言語として採用されるサービス連携記述言語について説明する。本形態においては、サービス連携記述言語とはＷｅｂサービス技術においてサービス連携に供される連携記述言語を称している。すなわち、Ｗｅｂサービス技術において複数のサービスを提供する側の機能を逐次呼び出していき、あるいはその処理結果において条件分岐を行いながら特定のより大きな処理を実行することを記述するために用いられる技術である。具体的な技術としてはＢＰＥＬ４ＷＳあるいはＷＳＣＩといったものが挙げられる。

ＢＰＥＬ４ＷＳとはＢｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ ｆｏｒ Ｗｅｂ Ｓｅｒｖｉｃｅｓ（ＢＰＥＬ４ＷＳ）の略であり、複数のサービスを連携させた複合サービス記述のための標準として位置付けられているサービス連携記述言語である。仕様はＯＡＳＩＳ（ｈｔｔｐ：／／ｗｗｗ．ｏａｓｉｓ−ｏｐｅｎ．ｏｒｇ／）のＯＡＳＩＳ Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｅｘｅｃｕｔｉｏｎ Ｌａｎｇｕａｇｅ ＴＣが管理している。ＢＰＥＬ４ＷＳを使用すると、例えば、Ｗｅｂサービス呼び出しの実行、データの操作、障害（ｆａｕｌｔ）の通知、またはプロセスの終了などのさまざまなアクティビティーを作成し、それらを結び合わせることによって、複雑なプロセスを作成することが可能である。これらのアクティビティーは、その実行方法 （例えば、順番に実行するのか、並列して実行するのか、あるいは特定の条件に基づいて実行するのか）を定義する、構造化されたアクティビティーの中でネストさせることができるようになっている。

また、ＷＳＣＩはＷｅｂ Ｓｅｒｖｉｃｅ Ｃｈｏｒｅｏｇｒａｐｈｙ Ｉｎｔｅｒｆａｃｅの略であり、やはり同様に複合サービスを連携させたサービス記述のためのサービス連携記述言語である。仕様はＷＷＷコンソーシアム（Ｗ３Ｃ）が管理しており、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＴＲ／ｗｓｃｉ／で参照することができる。

これらのサービス連携記述言語はどれもＸＭＬで記述されるという特徴を有しており、従来型の計算機言語を仮想的な計算機環境を用いる従来技術に比較してＳＯＡＰメッセージに格納する際の問題が無い。すなわち、従来言語をＸＭＬ文書であるＳＯＡＰメッセージに格納する際に生じていたＸＭＬの利点である部分的な処理が可能であるメリットの消失という問題が発生しない。また、プログラムを格納してもなおメッセージ全体を通して処理可能なＸＭＬ文書という状態を維持できるため、従来の通常のＳＯＡＰメッセージとの互換性が非常に高く、例えばメッセージの転送等と言った中間処理を実行するノードなどに新たな処理プログラムなどの追加を強いる必要がない。

しかしながらサービス連携記述言語を用いる場合には、そもそもこれらはみなＷｅｂサービス技術においてサービスを提供するノードの機能を連携させることを主目的としており、ＳＯＡＰメッセージに格納されているデータを操作することを目的としていないという問題がある。すなわち、サービス連携記述言語は通常Ｗｅｂサービス技術を用いたサーバ（サービス提供ノード）への働きかけを行うための能力しか有しておらず、特定のＳＯＡＰメッセージに格納されているデータに対する働きかけを行うことができない。従って、そのままではＳＯＡＰメッセージに格納されたデータを対象とした処理を記述するための計算機言語として用いることは困難である。

こうした問題の対処方法として、まずサービス連携記述言語を当該問題に対処した形で拡張するという解決策が考えられる。これはサービス連携記述言語の仕様にＳＯＡＰメッセージ内におけるデータへの参照手段を拡張的に設けるというものである。しかしながら、こうした手法では本来のサービス連携記述言語として不要な拡張を行うという言語仕様上の問題以外にも、従来存在したサービス連携記述言語の処理系実装においても当該拡張仕様のサポートを要求するという問題がある。また、言語仕様の変更はサービス連携記述言語毎に行わなければならないため、使用するサービス連携記述言語が変更するたびに実施する必要が発生してしまう。

そこで、本形態では、さらにサービス連携記述言語の仕様および処理系には一切修正を加えずに、ＳＯＡＰメッセージ内に格納されたデータの参照を実現するために、メッセージＭ１内に仮想サービス部Ｓ１を設けるとともに、サーバ部Ｓ１に仮想サービス処理プログラムＰ４を設けることで対処する。

以下に、メッセージＭ１内における仮想サービス部Ｓ１と、サーバＳ１における仮想サービス処理プログラムＰ４の本形態における具体的な機能と処理について示す。前述のようにサービス連携記述言語の処理対象はＷｅｂサービス技術におけるサービスのみとなっており、ＳＯＡＰメッセージに同時に格納されるデータ等への参照あるいは操作機能は有さない。従って、本形態においてはサービス連携記述言語の仕様および処理系には一切修正を加えずにＳＯＡＰメッセージ内にあるデータ部への参照あるいは操作を実現するために、当該ＳＯＡＰメッセージ処理中にのみ適用できる仮想的なＷｅｂサービスのサービス提供部を、サービス連携記述言語の実行処理部（Ｐ５）に対して与えることで、サービス連携記述言語の処理部（Ｐ５）は通常通りＷｅｂサービスに対する処理を実行すれば、実際には当該ＳＯＡＰメッセージに格納されたデータへの参照あるいは操作に変換されるという仕組みを実現する。

より具体的には、図２におけるＳＯＡＰメッセージＭ１を構成する際に格納したデータ部Ｄ１を参照するための仮想的なサービスの記述をサービス部Ｓ１として格納しておき、プログラム部Ｐ１とデータ部Ｄ１との関係をサーバＳ１にある仮想サービス処理プログラムＰ４が処理できるようにしておく。仮想サービス処理プログラムＰ４は、これらの情報を基に仮想的なＷｅｂサービス提供部を構築し、これをサービス連携処理プログラムＰ５へ与えることで、通常のサービス連携処理と同様の実行をサービス連携処理プログラムＰ５が行うだけで、実際には仮想サービス処理プログラムＰ４を通じてデータＤ１への操作が実施されるということになる。このサービス部Ｓ１は、データ部Ｄ１を処理する仕様を示す仕様部である。

図４は本処理を説明するために、図３（Ａ）のフローチャート内におけるステップＳ３０３をさらに詳細化した処理をフローチャートにて示したものである。ステップＳ４０１において、ステップＳ３０２において格納されたデータＤ１を取得する。ステップＳ４０２において、ステップＳ３０１において決定された内容に基づいた処理プログラムＰ１を生成しメッセージＭ１に格納する。この時生成されるプログラムＰ１は、図２におけるサービス連携処理プログラムＰ５が処理可能なサービス連携記述言語にて記述される。ステップＳ４０３において、データＤ１のうち、ステップＳ４０２において生成されたプログラムＰ１が使用（参照あるいは操作）しているデータを抽出する。そしてステップＳ４０４において、これらのデータを変更する機能をもつ仮想的なＷｅｂサービスの仕様を求め、これをステップＳ４０５にて図２の仮想サービス部Ｓ１として作成しメッセージＭ１に格納する。

このように動的にプログラムを生成し、かつそれをメッセージに組み込むという行為を行う従来技術としては、例えば、特開２００３−２２３３７６号公報がある。これはメッセージの内容を、アプリケーションプログラミングモデルを用いて構築し、これによりコードジェネレータがクライアントとサーバ間のプロトコルを処理する個別のプログラムを自動的に生成するというものである。当該技術はメッセージの転送部分であるプロトコルに処理をしぼったプログラムの自動生成を目的としており、本形態におけるステップＳ４０２のプログラムの生成は、あくまでも当該メッセージの内容を処理する方法の計算機言語による記述を実現するものである点が異なる。

図５は本処理を説明するために、図３（Ｂ）のフローチャート内におけるステップＳ３０９をさらに詳細化した処理をフローチャートにて示したものである。仮想サービス処理プログラムＰ４はステップＳ３０８でメッセージに格納されている仮想サービス部Ｓ１の情報を取得し、ステップＳ４１１でその情報を受け取る。ステップＳ４１２では仮想サービス部Ｓ１から仮想的に生成すべきＷｅｂサービスの提供機能の仕様を決定し、ステップＳ４１３で仮想サービスが提供する実際の機能を構成してＷｅｂサービスの実行を開始する。これにより、プログラム部Ｐ１と処理対象のデータであるデータＤ１を結びつけることが可能となる。次にその情報をステップＳ３１０でサービス連携処理プログラムＰ５に送る。ステップＳ３１１でサービス連携処理プログラムＰ５はプログラムＰ１の実行を行うことになる。

図６はデータのみで構成されたメッセージの例である。これは従来技術であるＷｅｂサービス技術で処理されるものであり、ＸＭＬ技術を用いたＳＯＡＰによるメッセージとなっている。ＳＯＡＰメッセージなのでエンベローブ部の中にヘッダー部とボディー部があり、さらにボディー部の中にここでは、データとしてｖａｌｕｅ１とｖａｌｕｅ２という名称をもった内容が格納されている。

図７は本形態により生成されたメッセージの例である。従来技術であるＷｅｂサービス技術で処理することができる互換性を保ちながら、データだけではなくプログラムも同時に格納しているということが示されている。図６と同様にＳＯＡＰメッセージなのでエンベローブ部の中にヘッダー部とボディー部があり、さらにボディー部の中にここでは、データとしてｖａｌｕｅ１とｖａｌｕｅ２という名称をもった内容が格納されている。また、仮想サービス部とプログラム部が追加されている。仮想サービス部は、データ部を処理する仕様を示す仕様部である。

以下に図７におけるＳＯＡＰメッセージを処理する場合の実際の流れを説明する。この例は２つの値を受領し合計を演算して返却するという単純な処理を示したものである。

まず送信されるＳＯＡＰメッセージであるが、図２においてクライアントＣ１上にある実行環境Ｅ１で動作するＳＯＡＰ処理プログラムＰ３にて生成されるＳＯＡＰメッセージＭ１に相当する。

まず、図３のステップＳ３０１にて外部の処理系（サーバＳ１）にて実行したい処理とは２つの数字の合計を演算する処理であるということが決定される。次に、ステップＳ３０２でＳＯＡＰ処理プログラムＰ３において、通常のＳＯＡＰメッセージ生成処理と同様に、図７における＜ｅｎｖ：Ｅｎｖｅｌｏｐｅ＞要素で構成されるエンベロープ部、＜ｅｎｖ：Ｈｅａｄｅｒ＞要素で構成されるヘッダー部、＜ｅｎｖ：Ｂｏｄｙ＞要素で構成されるボディー部、そして＜ｍ：ｄａｔａ＞要素で構成されるデータ部Ｄ１が生成される。さらにデータ部Ｄ１の中には、＜ｍ：ｖａｌｕｅ１＞および＜ｍ：ｖａｌｕｅ２＞という要素内に１００と２００という２つの値が格納される。

さらにステップＳ３０３にて図７におけるプログラム部Ｐ１および仮想サービス部Ｓ１が追加される。プログラム部Ｐ１は上記２つの値の合計を算出する内容のものであり、＜ｐ：ｐｒｏｇｒａｍ＞要素の中に追加される。このプログラムはＸＭＬで表現されたサービス連携記述言語であるＢＰＥＬ４ＷＳで記述される。この時対象とするデータはこのＳＯＡＰメッセージのデータ部Ｄ１に記述された＜ｍ：ｖａｌｕｅ１＞および＜ｍ：ｖａｌｕｅ２＞要素の中身であるため、これらの要素の情報をアクセスするためにプログラム部Ｐ１の＜ｐ：ｐａｒｔｎｅｒＬｉｎｋ＞要素に仮想サービスである“ｖｉｒｔｕａｌＳｅｒｖｉｃｅ”への参照を埋め込んでおく。

次に仮想サービス部Ｓ１が生成される。仮想サービス部Ｓ１は＜ｖ：ｖｉｒｔｕａｌＳｅｒｖｉｃｅ＞要素にて示され、さらに内部の＜ｖ：ｄｅｆｉｎｉｔｉｏｎｓ＞要素におけるｎａｍｅ属性によって先ほどの参照を受ける形で“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”という名称が付与される。また、仮想サービス内のアクセス手段が返却するデータの型を示すｖａｌｕｅ１という名称のメッセージが＜ｖ：ｍｅｓｓａｇｅ＞要素として定義される。さらに、データ部Ｄ１が保持する＜ｍ：ｖａｌｕｅ１＞および＜ｍ：ｖａｌｕｅ２＞というデータへのアクセス手段であるｇｅｔＶａｌｕｅ１およびｇｅｔＶａｌｕｅ２が＜ｖ：ｐｏｒｔＴｙｐｅ＞要素の中で定義される。なお、ｇｅｔＶａｌｕｅ２は、図７では、省略されている。仮想サービス部Ｓ１は、データ部Ｄ１を処理する仕様を示す仕様部である。図７では、データ部、仮想サービス部（仕様部）、プログラム部のそれぞれは、ｄａｔａ、ｖｉｒｔｕａｌＳｅｒｖｉｃｅ、ｐｒｏｇｒａｍの名前が付けられたタグで定義される。

こうして図７に示されたＳＯＡＰメッセージが作成されたら、ステップＳ３０４にて送信される。

送信されたＳＯＡＰメッセージは図２におけるサーバＳ１におけるＳＯＡＰ処理プログラムＰ２が受信する。受信されたＳＯＡＰメッセージは図３（Ｂ）におけるステップＳ３０５以降の処理に回される。ステップＳ３０６でプログラム部Ｐ１がメッセージＭ１のボディー部にあるかどうかが判定される。図７におけるＳＯＡＰメッセージは＜ｅｎｖｅｌｏｐｅ：Ｂｏｄｙ＞要素内に＜ｖ：ｖｉｒｔｕａｌＳｅｒｖｉｃｅ＞要素および＜ｐ：ｐｒｏｇｒａｍ＞要素を含んでいるため、仮想サービス部Ｓ１およびプログラム部Ｐ１を含むＳＯＡＰメッセージであると判断される。

ここで図２における仮想サービス処理プログラムＰ４に制御が移行する。次にステップＳ３０８で仮想サービス構築に必要な情報が取得される。そして、ステップＳ３０９で図７のＳＯＡＰメッセージＭ１のボディー部にある仮想サービス部Ｓ１である＜ｖ：ｖｉｒｔｕａｌＳｅｒｖｉｃｅ＞要素の内容から構築すべき仮想サービスの仕様を決定していく。例えば＜ｖ：ｄｅｆｉｎｉｔｉｏｎｓ＞要素のｎａｍｅ属性から仮想サービスの名称は“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”となる。その後、獲得した仕様をもとに図２における仮想サービスプログラムＰ４が仮想サービスの提供を開始する。

そしてステップＳ３１０において仮想サービス処理プログラムＰ４は、サービス連携処理プログラムＰ５に対し、こうして構築した仮想サービスの情報とＳＯＡＰメッセージＭ１に格納されていたプログラム部Ｐ１の情報を合わせて送信する。この場合ではサービス連携処理プログラムＰ５はＷｅｂサービス連携言語であるＢＰＥＬ４ＷＳを実行することができるので、プログラム部Ｐ１に記述された処理の逐次実行をステップＳ３１１として開始する。この時、処理プログラム部Ｐ１中にある＜ｐ：ｐａｒｔｎｅｒＬｉｎｋ＞で示されたサービスである“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”はさきほど構築された仮想サービスである。例えば処理プログラム部Ｐ１中にある＜ｐ：ｉｎｖｏｋｅ ｐａｒｔｎｅｒＬｉｎｋ＝“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ” ｏｐｅｒａｔｉｏｎ＝“ｇｅｔＶａｌｕｅ１”＞が実行され、サービス連携処理プログラムＰ５が通常のサービスへのアクセス手順を行っていくと、実際には仮想サービス処理プログラムＰ４によってその要求が受け入れられ、ＳＯＡＰメッセージＭ１のデータ部Ｄ１で記述された＜ｍ：ｖａｌｕｅ１＞１００＜／ｍ：ｖａｌｕｅ＞から１００が実行結果として返却される。

すなわち、＜ｐ：ｉｎｖｏｋｅ ｐａｒｔｎｅｒＬｉｎｋ＝“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ” ｏｐｅｒａｔｉｏｎ＝“ｇｅｔＶａｌｕｅ１”＞の実行時に、まず、サービス連携処理プログラムＰ５がサービスの名前（“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”）からサービスのアドレスを解決するための問い合わせを発行し、もしそれが“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”という名前の問い合わせであれば、仮想処理プログラムＰ４はローカルホストのアドレスを回答する。このローカルホストのアドレスは、例えば、ＩＰｖ４では１２７．０．０．１である。複数の仮想サービスを仮想サービス処理プログラムＰ４がホスティング（提供）する場合には、ＩＰアドレスと仮想サービスの識別子の組み合わせ、例えばｈｔｔｐ：／／１２７．０．０．１／ｖｉｒｔｕａｌＳｅｒｖｉｃｅになる。すなわち、受信したメッセージＭ１中のプログラム部に含まれる命令＜ｐ：ｉｎｖｏｋｅ ｐａｒｔｎｅｒＬｉｎｋ＝“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ” ｏｐｅｒａｔｉｏｎ＝“ｇｅｔＶａｌｕｅ１”＞の実行時に、実行する命令により行われる処理の仕様を示す仕様部を決定するが（サービスの名前（“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”）からサービスのアドレス解決）、ここでは、メッセージＭ１中の仮想サービス部Ｓ１が、実行する命令＜ｐ：ｉｎｖｏｋｅ ｐａｒｔｎｅｒＬｉｎｋ＝“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ” ｏｐｅｒａｔｉｏｎ＝“ｇｅｔＶａｌｕｅ１”＞により行われる処理の仕様を示すと決定される。

なお、“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”は、この命令により行われる処理の仕様を示す仕様部を識別するための仕様部識別子であり、“ｇｅｔＶａｌｕｅ１”は、データを処理する仕様を識別するための仕様識別子であり、それぞれ、メッセージＭ１中に仮想サービス部Ｓ１、及び、仮想サービス都Ｓ１中で規定されたデータの処理仕様を示す。“ｇｅｔＶａｌｕｅ１”は、データ識別子がＶａｌｕｅ１であるデータをデータＤ１から取得することを示す。

この回答を受けて、サービス連携処理プログラムＰ５は、そのローカルホストのアドレスに向かって当該サービス（“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ”）内にある特定の処理（“ｇｅｔＶａｌｕｅ１”）の実行を要求する。その要求は仮想サービス処理プログラムＰ４によって受け入れられる。仮想サービス処理プログラムＰ４は、処理名として“ｇｅｔ”が前置されるもの（例えばｇｅｔＶａｌｕｅ１）の処理が要求された場合、ｇｅｔを取ったあとの値（この場合はＶａｌｕｅ１）という名前の要素（データ）がメッセージＭ１のデータＤ１内に存在するかどうかをチェックし、あればそれの値（１００）をサービス連携処理プログラムＰ５に返却する。すなわち、受信したメッセージＭ１中のプログラム部Ｐ１に含まれる命令＜ｐ：ｉｎｖｏｋｅ ｐａｒｔｎｅｒＬｉｎｋ＝“ＶｉｒｔｕａｌＳｅｒｖｉｃｅ” ｏｐｅｒａｔｉｏｎ＝“ｇｅｔＶａｌｕｅ１”＞の実行時に、実行する命令により行われる処理の仕様を、受信したメッセージ中の仮想サービス部Ｓ１（仕様部）が示す場合、仮想サービス部Ｓ１により示される仕様により、データ部Ｄ１を処理する。ここでは、サービスの仕様は、“ｇｅｔＶａｌｕｅ１”なので、データ識別子がＶａｌｕｅ１であるデータの値（１００）をデータ部Ｄ１から取得する。

このようにしてＳＯＡＰメッセージＭ１内に存在するデータ部Ｄ１に格納されたデータに対する処理を実行した後に、ステップＳ３１２として結果が返却される。このＳＯＡＰメッセージの処理目的は２つの値を受領し合計を演算することなので、１００＋２００なので３００が返却されることとなる。

上記実施の形態ではメッセージ中に格納するプログラム部のプログラムを記述する計算機言語としてサービス連携記述言語であるＢＰＥＬ４ＷＳを用いたが、これはＷＳＣＩ等の他のサービス連携記述を目的とした計算機言語であってもかまわない。その際には、当該計算機言語はＷｅｂサービスをその操作の対象とすること、および記述にＸＭＬ形式を採用する。

上記実施の形態においては、単一のクライアントと単一のサーバの関係についてのみ記載したが、これは複数のクライアントと複数のサーバの関係について適用してもかまわない。

なお、本発明は複数の装置（例えばＡＶ装置、家庭用電化製品装置、コンピュータ装置、インタフェース装置など）から構成される装置に適用しても、一つの装置からなる装置に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した媒体を、装置あるいは装置に供給し、その装置あるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読みだし実行することによっても達成される。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することとなる。

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

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

本発明を上記記憶媒体に適用する場合には、その記憶媒体には先に説明したフローチャートに対応する処理を実行するプログラムコードを格納することになる。

従来技術における計算機間における分散処理について示した図である。 本発明の実施の形態にかかるメッセージの処理の概要について示した図である。 本発明の実施の形態にかかる処理の概要についてフローチャートにおいて示した図である。 本発明の実施の形態にかかる処理の詳細についてフローチャートにおいて示した図である。 本発明の実施の形態にかかる処理の詳細についてフローチャートにおいて示した図である。 メッセージの構成について具体的な例によって示した図である。 本発明の実施の形態にかかるメッセージの構成について具体的な例によって示した図である。

符号の説明

Ｐ１ プログラム部
Ｓ１ 仮想サービス部
Ｄ１ データ部
Ｐ２ ＳＯＡＰ処理風呂グラム
Ｐ４ 仮想サービス処理プログラム
Ｐ５ サービス連携処理プログラム

Claims (3)

1. データ部と、前記データ部を処理するサービスの仕様を示す仕様部と、前記仕様部を参照する命令を含むプログラム部とを備えるＳＯＡＰメッセージを受信し、
   受信した前記ＳＯＡＰメッセージ中のＢＰＥＬ４ＷＳで記述されたプログラム部に含まれる命令の実行時に、実行する命令が参照し、前記仕様部により仕様が示されるサービスにより、前記ＳＯＡＰメッセージに備えられた前記データ部を処理することを特徴とするデータ処理方法。
2. コンピュータに、
   データ部と、前記データ部を処理するサービスの仕様を示す仕様部と、前記仕様部を参照する命令を含むプログラム部とを備えるＳＯＡＰメッセージを受信する手順と、
   受信した前記ＳＯＡＰメッセージ中のＢＰＥＬ４ＷＳで記述されたプログラム部に含まれる命令の実行時に、実行する命令が参照し、前記仕様部により仕様が示されるサービスにより、前記ＳＯＡＰメッセージに備えられた前記データ部を処理する手順を実行させるためのデータ処理プログラム。
3. データ部と、前記データ部を処理するサービスの仕様を示す仕様部と、前記仕様部を参照する命令を含むプログラム部とを備えるＳＯＡＰメッセージを受信する受信手段と、
   受信した前記ＳＯＡＰメッセージ中のＢＰＥＬ４ＷＳで記述されたプログラム部に含まれる命令の実行時に、実行する命令が参照し、前記仕様部により仕様が示されるサービスにより、前記ＳＯＡＰメッセージに備えられた前記データ部を処理する処理手段を有することを特徴とするデータ処理装置。

Images