JP2008102637A - ウェブ・サービスを提供する装置およびその方法 - Google Patents

Abstract

【課題】ウェブ・サービスを提供するシステムの開発または保守・管理を容易にする。
【解決手段】サービスを提供する提供装置は、サービス要求メッセージが、それに含めて受信する入力データのデータ構造によらず満たすべき仕様を定める共通定義データ、および、それぞれのデータ構造の入力データが満たすべき個別定義データを記憶している。そして、入力データおよび当該入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを受信すると、そのサービス要求メッセージのデータ構造が共通定義データを満たすか否かを検証する。また、受信したインターフェイスＩＤに対応する個別定義データを検索し、サービス要求メッセージがその個別定義データを満たすか否かを判断する。そして、サービス要求メッセージが共通定義データおよび個別定義データを満たせば、当該入力データのデータ構造に応じたサービスを処理する。
【選択図】図４

Description

本発明は、ウェブ・サービスを提供する装置およびその方法に関する。特に、本発明は、サービスを要求するサービス要求メッセージが仕様を満たしているかを判断した上で、そのサービス要求メッセージに応じたサービスを提供する装置およびその方法に関する。

従来、ウェブ・サービスのインターフェイスの仕様を記述する言語としてＷＳＤＬ(Web Services Description Language)が用いられている（ＷＳＤＬに関連する技術文献として特許文献１を参照。）。ウェブ・サービスを提供する提供装置は、その装置で処理することができるサービスを要求するためのメッセージのデータ構造の仕様を、ＷＳＤＬで記述する。そして、提供装置は、記述したその仕様をサービスの定義データとして公開する。ウェブ・サービスを要求する要求装置は、公開されたそのデータ構造に準拠したメッセージを生成して提供装置に対し送信する。提供装置は、受信したメッセージが仕様に準拠しているか否かを、そのメッセージ中の各要素と、ＷＳＤＬで記述されたデータ中の各要素が一致するか否かに基づき判断する。準拠していればサービスが適切に処理される。また、要求装置においては、定義データに基づいて、サービスを要求するアプリケーションプログラムをある程度自動に生成することもできる。
特開２００５−１７４１２０号公報

ウェブ・サービスを要求するメッセージは、サービスの提供装置を特定するためのＵＲＩ(Uniform Resource Identifier)と、要求するサービスの識別名称と、そのサービスの処理に与える入力データとを含む。要求するサービスは、このＵＲＩおよびサービスの識別名称によって一意に特定される。そして、特定されたサービスに対する入力データのデータ構造もそれによって定まる。ＷＳＤＬで記述された定義データは、ウェブ・サービスのインターフェイスを、このようなＵＲＩ、識別名称および入力データのデータ構造の組として定義する。

ウェブ・サービスの提供装置において相互に類似する複数のサービスを提供するときは、それらに共通の識別名称を付して管理したい場合がある。例えば、帳票を用いた申請業務をサービスとして提供する場合には、帳票の種類ごとに入力データの構造は異なるものの、帳票の種類によらず「申請する（ｓｕｂｍｉｔ）」というサービスの内容は類似する。したがって、これらのサービスに共通した識別名称を付して管理し、入力データの構造に応じて異なる処理をすることができれば、サービスを処理するプログラムの保守・管理が容易になるばかりでなく、メソッドのオーバーロード機能を提供する従来のプログラム言語との親和性も高い。

しかしながら、従来のＷＳＤＬにおいて、入力データの構造が異なる複数のサービスに同一の識別名称を定義すると、サービスが一意に特定できないため正常動作しない。サービス毎に提供装置を設ければ、同一の識別名称のサービスを複数定義することはできるが、サービスの数が多くなると提供装置が多く必要となり、システムの複雑化を招くおそれがある。

そこで本発明は、上記の課題を解決することのできる提供装置、システム、方法およびプログラムを提供することを目的とする。この目的は特許請求の範囲における独立項に記載の特徴の組み合わせにより達成される。また従属項は本発明の更なる有利な具体例を規定する。

上記課題を解決するために、本発明の一側面によれば、サービス要求メッセージを受信し、受信したサービス要求メッセージに含まれる入力データの構造に応じたサービスを提供する提供装置であって、受信するサービス要求メッセージのデータ構造が、当該メッセージに含まれる入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データを予め記憶している共通定義記憶部と、入力データおよび当該入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを、通信インターフェイスを用いて受信する受信部と、受信した当該サービス要求メッセージが仕様を満たすか否かを、受信した当該サービス要求メッセージの各要素が共通定義データの各要素にマッチするか否かに基づきＣＰＵの動作により検証する共通検証部と、インターフェイスＩＤに対応付けて、当該インターフェイスＩＤによって識別されるデータ構造の仕様であって、共通定義データのうちデータ構造が互いに異なる何れの入力データにもマッチするＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定める個別定義データを予め記憶する個別定義記憶部と、当該サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データを個別定義記憶部からＣＰＵの動作により検索して読み出す検索部と、当該サービス要求メッセージの各要素が、検索した個別定義データの各要素にマッチすることを条件に、当該サービス要求メッセージが仕様を満たしているとＣＰＵの動作により判断する個別検証部と、当該サービス要求メッセージの各要素が共通定義データおよび個別定義データの各要素にマッチしたことを条件に、当該サービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理をＣＰＵの動作により行うサービス処理部とを備える提供装置を提供する。また、当該提供装置として情報処理装置を機能させるプログラムおよび方法を提供する。
なお、上記の発明の概要は、本発明の必要な特徴の全てを列挙したものではなく、これらの特徴群のサブコンビネーションもまた、発明となりうる。

以下、発明を実施するための最良の形態（以下、実施形態と称す）を通じて本発明を説明するが、以下の実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている特徴の組み合わせの全てが発明の解決手段に必須であるとは限らない。

図１は、情報システム１０の構成概要を示す。情報システム１０は、サービス提供装置１００−１〜Ｎと、当該サービス提供装置１００−１〜Ｎのそれぞれに対応するサービス要求装置１１０−１〜Ｎとを備える。サービス提供装置１００−１〜Ｎのそれぞれは、互いにデータ構造の異なる入力データに基づき類似のサービスを提供する。例えば、サービス提供装置１００−１〜Ｎのそれぞれは、共に、ワークフロー管理に用いられる帳票のデータの提出処理を受け付ける。しかしながら、サービス提供装置１００−１〜Ｎのそれぞれは、互いに異なる種類の帳票を処理の対象とする。

サービス提供装置１００−１〜Ｎのそれぞれは、定義データ１０５−１〜Ｎのそれぞれを記憶している。定義データ１０５−１〜Ｎのそれぞれは、たとえばＷＳＤＬで記述されている。そして、サービス提供装置１００−１〜Ｎのそれぞれは、対応するサービス要求装置１１０からサービス要求メッセージを受信すると、当該サービス要求メッセージのデータ構造が仕様を満たすか否かを、対応する定義データ１０５の各要素と当該サービス要求メッセージの各要素とが一致するか否かに基づいて検証する。図１では、定義データ１０５をサービス提供装置１００に隣接して配置することで、定義データ１０５を用いた検証を模式的に示している。

また、この定義データ１０５は、対応するサービス要求装置１１０に対して公開されている。サービス要求装置１１０−１〜Ｎのそれぞれは、対応する定義データ１０５をサービス提供装置１００から取得して記憶する。そして、サービス要求装置１１０−１〜Ｎのそれぞれの利用者は、取得した定義データ１０５を閲覧しながら、サービス要求のためのアプリケーションプログラムを、その要求メッセージが仕様に準拠するように作成して、当該サービス要求装置１１０において動作させる。これに代えて、サービス要求装置１１０−１〜Ｎのそれぞれは、定義データからアプリケーションプログラムを自動生成するソフトウェアによって、サービス要求のためのアプリケーションプログラムを自動生成してよい。

このように、入力データのデータ構造が互いに異なる同種のサービスを提供するためには、サービス提供装置および定義データのそれぞれを複数設けることもできる。しかしながら、この形態では、入力データのデータ構造の種類に応じてサービス提供装置が必要となる。例えば、異なるデータ構造の入力データを追加したい場合には、その定義データとして定義データ１０５−（Ｎ＋１）を追加したうえで、新たにサービス提供装置１００−（Ｎ＋１）を追加しなければならない。サービス提供装置１００−（Ｎ＋１）の追加には、新たな装置の増設か、または、装置を増設しない場合であっても、ウェブページの構成を変更したり、サービス処理のためのアプリケーションプログラムを新たに開発する必要があって手間がかかる。

図２は、情報システム２０の構成概要を示す。情報システム２０は、サービス提供装置２００と、サービス要求装置２１０とを備える。サービス提供装置２００は、サービス要求メッセージが、互いに異なるデータ構造を有する複数の入力データの何れを含んでいる場合であっても、そのデータ構造に応じて処理を振り分けて適切なサービスを選択的に処理する。また、サービス提供装置２００は定義データ２０５を記憶している。図１と同様、定義データ２０５は、サービス要求メッセージが仕様を満たすか否かの検証に用いられる。

定義データ２０５は、データ構造が互いに異なる何れの入力データにもマッチするＡＮＹ要素を含む。即ち、サービス提供装置２００は、入力データのデータ構造によらず共通して満たすべき仕様を満たすかどうかを、定義データ２０５に基づいて判断する。一方で、サービス提供装置２００は、サービス要求メッセージに含まれる入力データが仕様を満たすかどうかについては、定義データ２０５に基づき判断しない。そして、サービス提供装置２００は、入力データ以外のデータ構造が仕様を満たすことを条件に、その入力データに基づく処理を行う。

定義データ２０５は、サービス要求装置２１０に対し通知され、サービス要求装置２１０においてアプリケーションプログラムの開発に用いられる。但し、定義データ２０５は、入力データとしてＡＮＹ要素を含むので、サービス要求のためのアプリケーションプログラムの自動生成には限界がある。即ち、プログラム開発者は、サービス提供装置２００においてデータ構造に応じた処理の振分が行われることを熟知したうえで、その処理に適合するように適切なアプリケーションプログラムを作成しなければならない。このため、本来インターフェイス定義のために用いられる定義データ２０５が、その役割を果たせないこととなる。この結果、プログラムの仕様を正確には定めにくくなり、プログラムの保守・管理や改良には多くの労力と費用がかかるおそれがある。

これらに対し、以下に示すサービス提供装置３０によれば、サービス要求装置に対しインターフェイス定義を明確に通知しつつも、異なる複数のデータ構造の入力データについて１つのサービス提供装置３０により処理をさせることを可能とする。以下、具体的に述べる。
図３は、サービス提供装置３０の機能構成を示す。サービス提供装置３０は、サービス処理ユニット３００と、インターフェイス定義ユニット３１０とを有し、サービス要求装置３２０−１〜Ｎのそれぞれからの要求に応じてサービスを処理することを目的とする。サービス処理ユニット３００は、ウェブシステム上のあるロケーションに仮想的に割当てられている。即ち、サービス処理ユニット３００は、外部から１つのＵＲＩ（Uniform Resource Identifier）によって識別可能に管理されている。そして、サービス処理ユニット３００は、サービス要求装置３２０−１〜Ｎの何れか（例えばサービス要求装置３２０−１とする）から、サービス要求メッセージを受信する。そして、サービス処理ユニット３００は、そのサービス要求メッセージが、サービス処理ユニット３００において処理可能なサービスを要求するために満たすべき仕様を満たすか否かを検証する。この検証は、入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データ、および、入力データのデータ構造が仕様を満たしているかどうかを個別的に検証する個別定義データに基づいて行われる。仕様が満たされることを条件に、サービス処理ユニット３００は、サービスの処理を行ってその結果をサービス要求装置３２０−１に返答する。

インターフェイス定義ユニット３１０は、利用者から、入力データのデータ構造についての新たな仕様の入力を受け付ける。インターフェイス定義ユニット３１０は、この仕様に基づき個別定義データを生成して、サービス処理ユニット３００に記憶させる。これにより、サービス処理ユニット３００においてはこの個別定義データに基づきサービス要求メッセージを検証することができる。また、インターフェイス定義ユニット３１０は、生成した個別定義データをサービス要求装置３２０−１〜Ｎに対し通知する。これにより、サービス要求装置３２０−１〜Ｎのそれぞれは、その個別定義データに準拠したサービス要求メッセージを生成して、サービス処理ユニット３００に送信することができる。

図４は、サービス処理ユニット３００の機能構成を示す。サービス処理ユニット３００は、共通定義記憶部４００と、受信部４１０と、共通検証部４２０と、個別定義記憶部４３０と、検索部４４０と、個別検証部４５０と、サービス処理部４６０とを有し、サービス要求装置３２０−１〜Ｎに対しウェブ・サービスを提供する。これらの各部材は、後述のＣＰＵ１０００およびＲＡＭ１０２０の動作により実現される、以下、これらの各部材の機能を、サービス処理ユニット３００がサービス要求装置３２０−１からサービスの要求を受信してサービスを処理する場合を例に説明する。

共通定義記憶部４００は、受信するサービス要求メッセージのデータ構造が、そのメッセージに含まれる入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データを予め記憶している。この共通定義データは、例えば、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）で記述されている。そして、この共通定義データは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のＡＮＹデータ型またはＡＮＹ要素を含む。これらのＡＮＹ型またはＡＮＹ要素は、データ構造が互いに異なる複数の入力データの何れにもマッチする。これにより、サービス要求メッセージのうち入力データを除外した部分のみについて、その部分が仕様を満たすか判断できる。

受信部４１０は、入力データおよびその入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを、後述の通信インターフェイス１０３０を用いてサービス要求装置３２０−１から受信する。このサービス要求メッセージは、例えば、インターフェイスＩＤを要素として含むＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）メッセージである。このインターフェイスＩＤは、サービス要求装置３２０−１において動作するサービス要求のためのアプリケーションプログラムによって、ＳＯＡＰメッセージ中の所定のタグの属性値として与えられてもよい。これに代えて、このインターフェイスＩＤは、ＳＯＡＰメッセージ内で設定されたネームスペース名であってもよい。

共通検証部４２０は、共通定義データを共通定義記憶部４００から読み出す。そして、共通検証部４２０は、受信したそのサービス要求メッセージが仕様を満たすか否かを、受信したそのサービス要求メッセージの各要素が共通定義データの各要素にマッチするか否かに基づきＣＰＵ１０００の動作により検証する。例えば、共通定義データ中のＡＮＹ要素は如何なるデータ構造の入力データにもマッチするので、サービス要求メッセージは如何なるデータ構造の入力データを含んでいたとしても共通の仕様は満たす。しかし、入力データを除く部分の各要素は、共通定義データに含まれる各要素に一致しなければ仕様を満たさない。一例として、この検証の判断は、ＷＳＤＬのバリデーション処理として、ＸＭＬスキーマの技術を用いて実現されてもよい。

個別定義記憶部４３０は、インターフェイスＩＤに対応付けて、そのインターフェイスＩＤによって識別されるデータ構造の仕様を定める個別定義データを予め記憶する。これらの個別定義データは、共通定義データのうちＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定めるものである。また、これらの個別定義データのそれぞれは、共通定義データに含まれるＡＮＹデータ型またはＡＮＹ要素を、互いにデータ型または識別情報が異なる入力データにマッチする複数の要素のそれぞれに置換することによって生成されてもよい。

検索部４４０は、サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データを個別定義記憶部４３０からＣＰＵの動作により検索して読み出す。そして、個別検証部４５０は、サービス要求メッセージの各要素が、検索したその個別定義データの各要素にマッチすることを条件に、そのサービス要求メッセージが仕様を満たしているとＣＰＵ１０００の動作により判断する。この判断も、ＷＳＤＬのバリデーション処理として、ＸＭＬスキーマの技術を用いて実現されてもよい。

サービス処理部４６０は、サービス要求メッセージの各要素が共通定義データおよび個別定義データの各要素にマッチしたことを条件に、そのサービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理をＣＰＵ１０００の動作により行う。

図５は、インターフェイス定義ユニット３１０の機能構成を示す。インターフェイス定義ユニット３１０は、入力部５００と、定義データ生成部５１０と、定義データ管理部５２０とを有する。入力部５００は、サービスの処理に対する入力データに含まれる入力項目毎に、その入力項目の項目名およびその入力項目のデータ型の入力を、キーボードやポインティングデバイスなどの入出力デバイスを介して利用者から受け取る。例えば、ワークフロー管理に用いられる帳票の提出を受け入れるサービスを提供する場合には、その帳票に記載するデータが入力データとなる。そして、帳票に含まれる各項目が、入力データの入力項目となる。そして、帳票の項目は、その項目の特性に応じて数値が入力される場合や、文字が入力される場合がある。このようなデータの特性がデータ型である。即ち、利用者は、新たな帳票についてその帳票の提出を受け入れるサービスを提供したい場合には、入力部５００に対し、その帳票に含まれる各項目の項目名やデータ型その他の情報を、キーボード等を用いて入力すればよい。

定義データ生成部５１０は、ＣＰＵ１０００の動作により共通定義データを共通定義記憶部４００から読み出して、その共通定義データに含まれるＡＮＹ要素を、入力部５００が受け取った項目名を要素名とし、かつ、入力部５００が受け取ったデータ型をデータ型属性とした要素に置換する。そして、定義データ生成部５１０は、置換したその定義データを新たな個別定義データとして生成し、定義データ管理部５２０に対し出力する。定義データ管理部５２０は、ＣＰＵ１０００の動作により、生成したその個別定義データを、置換したその要素を識別するインターフェイスＩＤに対応付けて個別定義記憶部４３０に記憶し、そのインターフェイスＩＤを、サービス要求装置３２０−１〜Ｎに通知する。インターフェイスＩＤは、例えば利用者から入力項目名等と共に入力を受けることにより生成されてもよい。また、所定の規則に従って重複の無いような文字や記号・番号などを生成してインターフェイスＩＤとしてもよい。

これに代えて、インターフェイスＩＤは個別定義データに含めて生成されてもよい。たとえば、定義データ生成部５１０は、共通定義データ内のＡＮＹ要素を項目名を要素名とする要素に置換したうえで、その要素の識別情報をネームスペース名としてその定義データに追加することで、新たな個別定義データを生成してもよい。この場合には、定義データ管理部５２０は、インターフェイスＩＤを個別定義データと区別してサービス要求装置３２０−１〜Ｎに通知する必要はない。定義データ管理部５２０は、個別定義データをサービス要求装置３２０−１〜Ｎに通知すれば、それに含まれるインターフェイスＩＤもサービス要求装置３２０−１〜Ｎに対し通知される。この場合、サービス要求装置３２０−１〜Ｎにおいては、通知を受けた個別定義データに準拠してサービス要求メッセージを生成すれば、インターフェイスＩＤに関する明示的な処理を行わなくとも、ネームスペース名として与えられたそのインターフェイスＩＤをサービス要求メッセージに含めることができる。

図６は、共通定義記憶部４００に記憶された共通定義データの一例を示す。この共通定義データは、ＷＳＤＬで記述されており、入力データのデータ構造を定める型定義のほか、メッセージ定義、バインディング定義およびサービス定義を含む。図６ではこの中の型定義を抜粋して示す。この共通定義データにおいて、３行目にはサービスの識別情報「ｓｕｂｍｉｔ」が定義されており、それに続く４行目から９行目にはそのサービスの処理に対する入力データのデータ構造が定義されている。具体的には、６行目は、ｆｉｘｅｄＰａｒａｍｅｔｅｒという要素名のデータが文字列型「ｓｔｒｉｎｇ」であることを示す。また、７行目はＡＮＹ要素であり、任意のデータ型を有する任意の個数の要素とマッチする。５行目および８行目は、６行目および７行目に示す要素がこの順に記述されることを示す。即ち、サービス「ｓｕｂｍｉｔ」に対する入力データは、文字列型の要素「ｆｉｘｅｄＰａｒａｍｅｔｅｒ」を先頭とし、その後に任意の要素が入力されるデータである場合に仕様に準拠したと判断される。

１１行目から１７行目には、識別情報「ｓｕｂｍｉｔＲｅｓｐｏｎｓｅ」のサービスを対比して示す。このサービスの入力データのデータ構造は、ＡＮＹ要素を含んでいない。このため、このサービスに対しては予め定義された所定のデータ、即ち、識別情報が「ｓｕｂｍｉｔＲｅｔｕｒｎ」であって文字列型のデータのみが入力として許可され、その他の場合には仕様を満たさないと判断される。

図７は、個別定義記憶部４３０のデータ構造の一例を示す。個別定義記憶部４３０は、インターフェイスＩＤに対応付けて、そのインターフェイスＩＤによって識別されるデータ構造の仕様を定める個別定義データを予め記憶する。個別定義データは、例えば、それぞれ独立したＷＳＤＬのファイルであり、その用途やサービスの処理内容に応じて異なるファイル名が付されていてもよい。例えば、インターフェイスＩＤが１の個別定義データは、テスト用．ｗｓｄｌというファイルに格納されている。このファイルに格納された個別定義データをテスト用ＷＳＤＬファイル７００とする。検索部４４０は、受信したサービス要求メッセージからインターフェイスＩＤを読み出したうえで、そのインターフェイスＩＤに対応するＷＳＤＬファイルを個別定義記憶部４３０から検索する。そして、検索部４４０は、検索されたそのＷＳＤＬファイルを読み出して個別検証部４５０に出力する。

図８は、テスト用ＷＳＤＬファイル７００の一例を示す。図６の説明と同様、図８には個別定義データのうちデータ型定義を抜粋して示す。この個別定義データは、共通定義データのうちＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定める。そしてそのデータ構造は、図７に示したインターフェイスＩＤの「１」によって識別されるものである。具体的には、図８の３行目は、サービス「ｓｕｂｍｉｔ」のインターフェイスを定義することを示している。そして、その定義の実体は４行目から１０行目までである。６行目に、ｆｉｘｅｄＰａｒａｍｅｔｅｒという要素名のデータが文字列型「ｓｔｒｉｎｇ」であることを示す。これは、図６の６行目と同様である。即ち６行目は、入力データのデータ構造が異なる場合であっても必ず満たすべき仕様を示している。

これに対し、７行目および８行目は、図６に示すＡＮＹ要素に代えて、具体的な要素の名称およびデータ型を定義している。７行目は、ｖａｒｉａｂｌｅＰａｒａｍｅｔｅｒ１という要素名のデータが文字列型「ｓｔｒｉｎｇ」であることを示す。８行目は、ｖａｒｉａｂｌｅＰａｒａｍｅｔｅｒ２という要素名のデータが文字列型「ｓｔｒｉｎｇ」であることを示す。即ち、サービス要求メッセージにおいてｆｉｘｅｄＰａｒａｍｅｔｅｒに続く各要素は、共通検証部４２０によっては仕様を満たすか判断されないが、個別検証部４５０によっては具体的に仕様を満たすか判断される。

図８を参照して示したように、本発明に係るデータ構造とは、例えば、ある１つの要素のデータ型のみならず、複数の要素から構成されるデータにおける要素の数、各要素の識別名、および、各要素のデータ型を含む概念である。本実施形態に係るサービス提供装置３０は、同一の識別名称を有するサービスに対し、このような様々な入力データを許容して、そのデータ構造に応じた適切な処理を選択的に実行できる。

図９は、利用者の入力に応じて個別定義データを生成する処理の流れを示す。入力部５００は、入力用画面を利用者に表示して、入力項目名およびそのデータ型の入力を利用者から受け取る（Ｓ９００）。また、入力部５００は、その入力画面上でインターフェイスＩＤの入力を受け取る（Ｓ９１０）。図１０を参照して、ワークフロー管理に用いられる帳票の提出を受け入れるサービスに関し、入力データである帳票データのインターフェイスを定義するための入力用画面を例示する。
図１０は、入力部５００によって表示される入力用画面の一例を示す。この入力用画面には、既に入力された入力項目の項目名が「フィールド名」フィールドに一覧表示されている。そして、それぞれの入力項目には、その役割を記した「コメント」と、その項目のデータ型を示す「タイプ」および「コンテナータイプ」と、その属性と、その入力項目をＷＳＤＬデータによる検証の対象とするか否かを示す情報とが対応付けて表示される。一例として、ＵｓｅｒＩｄという入力項目は、申請者の識別情報を示しており、そのデータ型はテキスト型である。そして、その項目はＷＳＤＬデータによる検証の対象となっている。

利用者はポインティングデバイスなどである入力項目を選択すると、画面下側の「フィールドのプロパティ」において、その入力項目に関する事項が編集可能となる。即ち例えば、入力部５００は、フィールドのプロパティにおける「フィールド名」の欄に入力された文字列を、入力項目の項目名として受け取る。この項目名は、個別定義データにおける入力データに含まれる要素の要素名となる。そして、入力部５００は、そのフィールドのプロパティにおける「タイプ」または「コンテナータイプ」の欄に入力されたデータ型を、その入力項目のデータ型として受け取る。このデータ型は、個別定義データにおける入力データに含まれる要素の属性値となる。

また、入力部５００は、画面上方においてインターフェイスＩＤの入力欄を表示する。即ち、入力部５００は、このインターフェイスＩＤの入力欄に入力された文字列をインターフェイスＩＤとして受け取る。入力されたこのインターフェイスＩＤは、個別定義データのネームスペース名として、個別定義データに含めて生成されてもよいし、個別定義データとは独立して生成され、個別定義データに対応付けてサービス要求装置３２０−１〜Ｎ等に対し出力されてもよい。

図９に戻る。続いて、定義データ生成部５１０は、入力された項目名やデータ型に基づいて個別定義データを生成する（Ｓ９２０）。具体的には、まず、定義データ生成部５１０は、共通定義データを共通定義記憶部４００から読み出す。そして、定義データ生成部５１０は、その共通定義データに含まれるＡＮＹ要素を、入力部５００が受け取った項目名を要素名とし、かつ、入力部５００が受け取ったデータ型をデータ型属性とした要素に置換する。そして、定義データ生成部５１０は、置換したその定義データを新たな個別定義データとする。

次に、定義データ管理部５２０は、生成したその個別定義データを、置換したその要素を識別するインターフェイスＩＤに対応付けてサービス要求装置３２０−１〜Ｎに対し通知する（Ｓ９３０）。このインターフェイスＩＤは、例えば図１０に例示したインターフェイスＩＤの入力欄に対し入力されたものである。通知を受けたサービス要求装置３２０−１〜Ｎのそれぞれは、例えば、そのインターフェイスＩＤに対応する個別定義データに基づき生成したサービス要求メッセージに、そのインターフェイスＩＤを含めてサービス提供装置３０に対し送信することができる。そして、定義データ管理部５２０は、生成したその個別定義データを、対応するインターフェイスＩＤに対応付けて個別定義記憶部４３０に記憶する（Ｓ９４０）。

図１１は、サービス要求メッセージの受信に応じてサービスを処理する流れを示す。受信部４１０は、入力データおよびその入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージをサービス要求装置３２０−１から受信する（Ｓ１１００）。次に、共通検証部４２０は、サービス要求メッセージのデータ構造が入力データのデータ構造によらず共通して満たすべき仕様を満たすか否かを検証する（Ｓ１１１０）。具体的には、共通検証部４２０は、共通定義データを共通定義記憶部４００から読み出して、受信したそのサービス要求メッセージの各要素がその共通定義データの各要素にマッチするか否かを判断する。例えば、入力データ以外の部分が仕様に反する場合や、インターフェイスＩＤが含まれていない場合には、共通して満たすべき仕様は満たされないと判断される。

検索部４４０は、サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データを個別定義記憶部４３０から検索して読み出す（Ｓ１１２０）。そのような個別定義データが検索されなければ（Ｓ１１２５：ＮＯ）、サービス処理部４６０は、サービス要求メッセージが仕様を満たさなかった旨のエラー報告を返答する（Ｓ１１５０）。個別定義データが検索された場合には（Ｓ１１２５：ＹＥＳ）、個別検証部４５０は、サービス要求メッセージがその個別定義データを満たすか否かを判断する（Ｓ１１３０）。この検証は、サービス要求メッセージの各要素と個別定義データの各要素とがマッチするか否かに基づいて行われる。

そして、サービス処理部４６０は、サービス要求メッセージの各要素が共通定義データおよび個別定義データの各要素にマッチしたことを条件に（Ｓ１１４０：ＹＥＳ）、そのサービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理を行う（Ｓ１１６０）。そして、サービス処理部４６０は、サービスの処理の処理結果を返答する（Ｓ１１７０）。一方で、サービス要求メッセージの何れかの要素が共通定義データまたは個別定義データ中の要素にマッチしなければ（Ｓ１１４０：ＮＯ）、サービス処理部４６０は、サービス要求メッセージが仕様に反する旨のエラー報告を返答する（Ｓ１１５０）。

図１２は、サービス提供装置３０として機能する情報処理装置１２００のハードウェア構成の一例を示す。情報処理装置１２００は、ホストコントローラ１０８２により相互に接続されるＣＰＵ１０００、ＲＡＭ１０２０、及びグラフィックコントローラ１０７５を有するＣＰＵ周辺部と、入出力コントローラ１０８４によりホストコントローラ１０８２に接続される通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を有する入出力部と、入出力コントローラ１０８４に接続されるＲＯＭ１０１０、フレキシブルディスクドライブ１０５０、及び入出力チップ１０７０を有するレガシー入出力部とを備える。

ホストコントローラ１０８２は、ＲＡＭ１０２０と、高い転送レートでＲＡＭ１０２０をアクセスするＣＰＵ１０００及びグラフィックコントローラ１０７５とを接続する。ＣＰＵ１０００は、ＲＯＭ１０１０及びＲＡＭ１０２０に格納されたプログラムに基づいて動作し、各部の制御を行う。グラフィックコントローラ１０７５は、ＣＰＵ１０００等がＲＡＭ１０２０内に設けたフレームバッファ上に生成する画像データを取得し、表示装置１０８０上に表示させる。これに代えて、グラフィックコントローラ１０７５は、ＣＰＵ１０００等が生成する画像データを格納するフレームバッファを、内部に含んでもよい。

入出力コントローラ１０８４は、ホストコントローラ１０８２と、比較的高速な入出力装置である通信インターフェイス１０３０、ハードディスクドライブ１０４０、及びＣＤ−ＲＯＭドライブ１０６０を接続する。通信インターフェイス１０３０は、ネットワークを介して外部の装置と通信する。ハードディスクドライブ１０４０は、情報処理装置１２００が使用するプログラム及びデータを格納する。ＣＤ−ＲＯＭドライブ１０６０は、ＣＤ−ＲＯＭ１０９５からプログラム又はデータを読み取り、ＲＡＭ１０２０又はハードディスクドライブ１０４０に提供する。

また、入出力コントローラ１０８４には、ＲＯＭ１０１０と、フレキシブルディスクドライブ１０５０や入出力チップ１０７０等の比較的低速な入出力装置とが接続される。ＲＯＭ１０１０は、情報処理装置１２００の起動時にＣＰＵ１０００が実行するブートプログラムや、情報処理装置１２００のハードウェアに依存するプログラム等を格納する。フレキシブルディスクドライブ１０５０は、フレキシブルディスク１０９０からプログラム又はデータを読み取り、入出力チップ１０７０を介してＲＡＭ１０２０またはハードディスクドライブ１０４０に提供する。入出力チップ１０７０は、フレキシブルディスク１０９０や、例えばパラレルポート、シリアルポート、キーボードポート、マウスポート等を介して各種の入出力装置を接続する。

情報処理装置１２００に提供されるプログラムは、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５、又はＩＣカード等の記録媒体に格納されて利用者によって提供される。プログラムは、入出力チップ１０７０及び/又は入出力コントローラ１０８４を介して、記録媒体から読み出され情報処理装置１２００にインストールされて実行される。プログラムが情報処理装置１２００等に働きかけて行わせる動作は、図１から図１１において説明したサービス提供装置３０における動作と同一であるから、説明を省略する。

以上に示したプログラムは、外部の記憶媒体に格納されてもよい。記憶媒体としては、フレキシブルディスク１０９０、ＣＤ−ＲＯＭ１０９５の他に、ＤＶＤやＰＤ等の光学記録媒体、ＭＤ等の光磁気記録媒体、テープ媒体、ＩＣカード等の半導体メモリ等を用いることができる。また、専用通信ネットワークやインターネットに接続されたサーバシステムに設けたハードディスク又はＲＡＭ等の記憶装置を記録媒体として使用し、ネットワークを介してプログラムを情報処理装置１２００に提供してもよい。

以上、本実施形態に係るサービス提供装置３０によれば、ＷＳＤＬなどのインターフェイス定義において、互いに異なるデータ構造のデータを入力とする複数のサービスを、同一の識別名称によって管理することができる。これにより、サービスを要求する利用者にとっては、インターフェイス定義を利用してアプリケーションプログラムの開発を効率化できる。一方、サービスを提供する利用者にとっては、新たにサービスを追加する場合でも、新たにサービス提供装置３０を追加する必要はなく、既存のサービス提供装置３０をそのまま流用できる。また、定義データの開発に際しては、既存のプログラム言語におけるメソッドのオーバーロードに相当する機能を提供できる。さらには、新たにサービスを追加するために必要な新たな個別定義データの開発には、入力項目毎にデータ入力を可能としたインターフェイス定義ユニット３１０を提供することで、利用者の利便性を向上させることができる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更または改良を加えることが可能であることが当業者に明らかである。例えば、サービス提供装置３０は、サービス処理後のメッセージの返信処理においても、共通定義データによる検証と個別定義データによる検証とをこの順に行ってもよい。即ち、共通定義データは、返信メッセージの出力データのデータ構造によらず共通して満たすべき仕様を定めている。一方、個別定義データは、返信メッセージの出力データのデータ構造が満たすべき仕様を定めている。そして、サービス提供装置３０は、あるサービスを処理した場合には、そのサービスの出力メッセージのデータ構造を識別するインターフェイスＩＤをその出力メッセージに含めて生成する。そして、サービス提供装置３０は、その出力メッセージが共通定義データを満たすか否かを判断したうえで、そのインターフェイスＩＤに対応する個別定義データを満たすか否かを判断する。それぞれ満たされれば、出力メッセージはサービス要求装置に対し返信される。この様な変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

図１は、情報システム１０の構成概要を示す。 図２は、情報システム２０の構成概要を示す。 図３は、サービス提供装置３０の機能構成を示す。 図４は、サービス処理ユニット３００の機能構成を示す。 図５は、インターフェイス定義ユニット３１０の機能構成を示す。 図６は、共通定義記憶部４００に記憶された共通定義データの一例を示す。 図７は、個別定義記憶部４３０のデータ構造の一例を示す。 図８は、テスト用ＷＳＤＬファイル７００の一例を示す。 図９は、利用者の入力に応じて個別定義データを生成する処理の流れを示す。 図１０は、入力部５００によって表示される入力用画面の一例を示す。 図１１は、サービス要求メッセージの受信に応じてサービスを処理する流れを示す。 図１２は、サービス提供装置３０として機能する情報処理装置１２００のハードウェア構成の一例を示す。

符号の説明

１０ 情報システム
２０ 情報システム
３０ サービス提供装置
１００ サービス提供装置
１０５ 定義データ
１１０ サービス要求装置
２００ サービス提供装置
２０５ 定義データ
２１０ サービス要求装置
３００ サービス処理ユニット
３１０ インターフェイス定義ユニット
３２０ サービス要求装置
４００ 共通定義記憶部
４１０ 受信部
４２０ 共通検証部
４３０ 個別定義記憶部
４４０ 検索部
４５０ 個別検証部
４６０ サービス処理部
５００ 入力部
５１０ 定義データ生成部
５２０ 定義データ管理部
７００ テスト用ＷＳＤＬファイル
１２００ 情報処理装置

Claims (8)

1. サービス要求メッセージを受信し、受信したサービス要求メッセージに含まれる入力データの構造に応じたサービスを提供する提供装置であって、
   受信するサービス要求メッセージのデータ構造が、当該メッセージに含まれる入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データを予め記憶している共通定義記憶部と、
   入力データおよび当該入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを、通信インターフェイスを用いて受信する受信部と、
   受信した当該サービス要求メッセージが仕様を満たすか否かを、受信した当該サービス要求メッセージの各要素が前記共通定義データの各要素にマッチするか否かに基づきＣＰＵの動作により検証する共通検証部と、
   インターフェイスＩＤに対応付けて、当該インターフェイスＩＤによって識別されるデータ構造の仕様であって、共通定義データのうちデータ構造が互いに異なる何れの入力データにもマッチするＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定める個別定義データを予め記憶する個別定義記憶部と、
   当該サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データを前記個別定義記憶部からＣＰＵの動作により検索して読み出す検索部と、
   当該サービス要求メッセージの各要素が、検索した前記個別定義データの各要素にマッチすることを条件に、当該サービス要求メッセージが仕様を満たしているとＣＰＵの動作により判断する個別検証部と、
   当該サービス要求メッセージの各要素が前記共通定義データおよび前記個別定義データの各要素にマッチしたことを条件に、当該サービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理をＣＰＵの動作により行うサービス処理部と
   を備える提供装置。
2. 当該提供装置はウェブ・サービスを提供する装置であり、
   前記共通定義記憶部は、共通定義データとして、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）のＡＮＹデータ型またはＡＮＹ要素を含み、ＷＳＤＬ（Ｗｅｂ Ｓｅｒｖｉｃｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）で記述されたデータを記憶しており、
   前記受信部は、サービス要求メッセージとして、インターフェイスＩＤを要素として含むＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）メッセージを受信し、
   前記共通検証部は、ＷＳＤＬのバリデーション処理として、サービス要求メッセージの各要素が共通定義データの各要素にマッチするか否かを判断し、
   前記個別定義記憶部は、共通定義データに含まれるＡＮＹデータ型またはＡＮＹ要素を、互いにデータ型または識別情報が異なる入力データにマッチする複数の要素のそれぞれに置換して得られる複数の個別定義データのそれぞれを予め記憶しており、
   前記個別検証部は、ＷＳＤＬのバリデーション処理として、サービス要求メッセージの各要素が個別定義データの各要素にマッチするか否かを判断する
   請求項１に記載の提供装置。
3. 前記受信部は、ＳＯＡＰメッセージ内で設定されたネームスペース名を、インターフェイスＩＤとして受信する
   請求項２に記載の提供装置。
4. 入力データに含まれる入力項目毎に、当該入力項目の項目名および当該入力項目のデータ型の入力を、入出力デバイスを介して利用者から受け取る入力部と、
   ＣＰＵの動作により共通定義データを前記共通定義記憶部から読み出して、当該共通定義データに含まれるＡＮＹ要素を、前記入力部が受け取った項目名を要素名とし、かつ、前記入力部が受け取ったデータ型をデータ型属性とした要素に置換し、置換した当該要素の識別情報をネームスペース名として追加することにより新たな個別定義データを生成する定義データ生成部と、
   ＣＰＵの動作により、生成した当該個別定義データを前記個別定義記憶部に記憶し、生成した当該個別定義データを、サービスを要求する要求装置に通知する定義データ管理部と
   をさらに備える請求項３に記載の提供装置。
5. 入力データに含まれる入力項目毎に、当該入力項目の項目名および当該入力項目のデータ型の入力を、入出力デバイスを介して利用者から受け取る入力部と、
   ＣＰＵの動作により共通定義データを前記共通定義記憶部から読み出して、当該共通定義データに含まれるＡＮＹ要素を、前記入力部が受け取った項目名を要素名とし、かつ、前記入力部が受け取ったデータ型をデータ型属性とした要素に置換することにより新たな個別定義データを生成する定義データ生成部と、
   ＣＰＵの動作により、生成した当該個別定義データを、置換した当該要素を識別するインターフェイスＩＤに対応付けて前記個別定義記憶部に記憶し、当該インターフェイスＩＤを、サービスを要求する要求装置に通知する定義データ管理部と
   をさらに備える請求項２に記載の提供装置。
6. サービスを要求するためにサービス要求メッセージを送信する要求装置と、当該サービス要求メッセージを受信し、受信したサービス要求メッセージに含まれる入力データの構造に応じたサービスを提供する提供装置とを備えるシステムであって、
   前記提供装置は、
   受信するサービス要求メッセージのデータ構造が、当該メッセージに含まれる入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データを予め記憶している共通定義記憶部と、
   入力データおよび当該入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを、通信インターフェイスを用いて受信する受信部と、
   受信した当該サービス要求メッセージが仕様を満たすか否かを、受信した当該サービス要求メッセージの各要素が前記共通定義データの各要素にマッチするか否かに基づきＣＰＵの動作により検証する共通検証部と、
   インターフェイスＩＤに対応付けて、当該インターフェイスＩＤによって識別されるデータ構造の仕様であって、共通定義データのうちデータ構造が互いに異なる何れの入力データにもマッチするＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定める個別定義データを予め記憶する個別定義記憶部と、
   当該サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データを前記個別定義記憶部からＣＰＵの動作により検索して読み出す検索部と、
   当該サービス要求メッセージの各要素が、検索した前記個別定義データの各要素にマッチすることを条件に、当該サービス要求メッセージが仕様を満たしているとＣＰＵの動作により判断する個別検証部と、
   当該サービス要求メッセージの各要素が前記共通定義データおよび前記個別定義データの各要素にマッチしたことを条件に、当該サービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理をＣＰＵの動作により行うサービス処理部と、
   ＣＰＵの動作により、それぞれの前記個別定義データを、当該個別定義データに含まれる入力データのデータ構造を識別するインターフェイスＩＤに対応付けて前記要求装置に通知する定義データ管理部と
   を有し、
   前記要求装置は、前記定義データ管理部から通知を受けたインターフェイスＩＤを、当該インターフェイスＩＤに対応する個別定義データに基づき生成したサービス要求メッセージに含めて前記提供装置に送信する、システム。
7. サービス要求メッセージを受信し、受信したサービス要求メッセージに含まれる入力データの構造に応じたサービスを提供する提供装置として、情報処理装置を機能させるプログラムであって、
   前記情報処理装置を、
   受信するサービス要求メッセージのデータ構造が、当該メッセージに含まれる入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データを予め記憶している共通定義記憶部と、
   入力データおよび当該入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを、通信インターフェイスを用いて受信する受信部と、
   受信した当該サービス要求メッセージが仕様を満たすか否かを、受信した当該サービス要求メッセージの各要素が前記共通定義データの各要素にマッチするか否かに基づきＣＰＵの動作により検証する共通検証部と、
   インターフェイスＩＤに対応付けて、当該インターフェイスＩＤによって識別されるデータ構造の仕様であって、共通定義データのうち構造が互いに異なる何れの入力データにもマッチするＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定める個別定義データを予め記憶する個別定義記憶部と、
   当該サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データを前記個別定義記憶部からＣＰＵの動作により検索して読み出す検索部と、
   当該サービス要求メッセージの各要素が、検索した前記個別定義データの各要素にマッチすることを条件に、当該サービス要求メッセージが仕様を満たしているとＣＰＵの動作により判断する個別検証部と、
   当該サービス要求メッセージの各要素が前記共通定義データおよび前記個別定義データの各要素にマッチしたことを条件に、当該サービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理をＣＰＵの動作により行うサービス処理部と
   して機能させるプログラム。
8. サービス要求メッセージを受信し、受信したサービス要求メッセージに含まれる入力データの構造に応じたサービスを提供する方法であって、
   受信するサービス要求メッセージのデータ構造が、当該メッセージに含まれる入力データのデータ構造によらず共通して満たすべき仕様を定める共通定義データを予め記憶し、
   入力データおよび当該入力データのデータ構造を識別するインターフェイスＩＤを要素として含むサービス要求メッセージを、通信インターフェイスを用いて受信し、
   受信した当該サービス要求メッセージが仕様を満たすか否かを、受信した当該サービス要求メッセージの各要素が前記共通定義データの各要素にマッチするか否かに基づきＣＰＵの動作により検証し、
   インターフェイスＩＤに対応付けて、当該インターフェイスＩＤによって識別されるデータ構造の仕様であって、共通定義データのうち構造が互いに異なる何れの入力データにもマッチするＡＮＹ要素とマッチした入力データが満たすべきデータ構造の仕様を定める個別定義データを予め記憶し、
   当該サービス要求メッセージに含めて受信したインターフェイスＩＤに対応する個別定義データをＣＰＵの動作により検索して読み出し、
   当該サービス要求メッセージの各要素が、検索した前記個別定義データの各要素にマッチすることを条件に、当該サービス要求メッセージが仕様を満たしているとＣＰＵの動作により判断し、
   当該サービス要求メッセージの各要素が前記共通定義データおよび前記個別定義データの各要素にマッチしたことを条件に、当該サービス要求メッセージに含まれる入力データのデータ構造に応じたサービスの処理をＣＰＵの動作により行う方法。

Images