JP7157716B2 - データベースサーバ装置、サーバシステム及びリクエスト処理方法 - Google Patents

Description

本発明は、データベースサーバ装置、サーバシステム及びリクエスト処理方法に関し、Ｗｅｂシステムにおいてデータベースに対するデータ処理のリクエストを処理するデータベースサーバ装置、サーバシステム及びリクエスト処理方法に適用して好適なものである。

従来、一般的なＷｅｂシステムでは、Ｗｅｂサーバ装置がデータベース管理システム（ＤＢＭＳ：DataBase Management System）に直接接続するように構成され、Ｗｅｂサーバ装置からＤＢＭＳに対してＳＱＬ文を投げることによってデータ処理を要求する。ＤＢＭＳは様々なベンダが提供しているが、ＤＢＭＳによってＳＱＬの表現方法やデータ型等が異なる。そのため、従来の一般的なＷｅｂシステムでは、あるＤＢＭＳに向けて作成したＷｅｂシステムを他のＤＢＭＳに対応するように切り替えることは容易でないという問題があった。

ここで、ユーザ側が準備するＤＢＭＳに容易に対応可能なＷｅｂシステムとして、Ｗｅｂサーバ装置とＤＢＭＳとの間にデータベース（ＤＢ）サーバ装置を備える構成が知られている。ＤＢサーバ装置を備えたＷｅｂシステムでは、Ｗｅｂサーバ装置が、ＨＴＴＰ（Hypertext Transfer Protocol）プロトコルを利用してＤＢＭＳに対するデータの操作処理の実行をＤＢサーバ装置に依頼し、ＨＴＴＰサーバで構成されるＤＢサーバ装置が、ＤＢＭＳに対応するＳＱＬ文を生成し、ＤＢＭＳに対してデータ処理を要求することにより、ＤＢＭＳの構成を気にすることなくＤＢＭＳに処理を依頼することができる。

特表２００１－５２２０８６号公報

ところで、Ｗｅｂシステムをベースとしたプラットフォームを構築しようとする場合、Ｗｅｂシステムには、ＤＢＭＳに容易に対応可能という上述した要件に加えて、主にＷｅｂシステムを修正することによって異なる適用先（案件）にも適用可能であることが求められる。この場合、データベースのデータ項目やＤＢＭＳに対するデータ処理等は適用先によって異なるため、適用先の内容に応じてＷｅｂクライアントやＷｅｂシステムを修正する必要がある。例えばＤＢサーバ装置はＷｅｂサーバ装置に対してＡＰＩ（Application Programming Interface）を提供するが、通常１つのＡＰＩは一連のＤＢＭＳの処理を行うものとして提供されるため、現在の案件特有のＡＰＩとなる傾向がある。つまり、Ｗｅｂシステムを異なる案件に対応する場合には、ＤＢサーバ装置が提供するＡＰＩを修正する必要が生じ、これはＤＢサーバ装置側の修正負担を大きくしてしまう。この結果、適用先の案件の内容に応じた実装修正の負荷が大きくなると、当該案件に早急に対応することができなくなる、という問題があった。

ここで、例えば特許文献１には、分割したＡＰＩを組み合わせて一連の処理の実行を要求し、トランザクションの開始やコミット等の際にＤＢサーバ装置が指定したＵＲＬ（Uniform Resource Locator）を送ることによって、一連の処理に跨ってロック、コミット、またはロールバックの処理を実行可能にする実行する方法が開示されている。特許文献１に開示された方法を利用すれば、一連の処理を１つのＡＰＩで表さずに、複数のＡＰＩに分割することができるため、Ｗｅｂシステムを異なる適用先に適用しようとする場合に、ＤＢサーバ装置側の修正負担を低減する効果に期待できる。しかし、特許文献１に開示された方法の場合、分割したＡＰＩの組み合わせによってＤＢＭＳに対する一連の処理を実行しようとする場合に、ＨＴＴＰ通信が何回も実行されることになり、その間ロックが継続するため、ロックを取得する時間（ロック時間）が長くなるという問題があった。ロック時間が長くなることがデータベースの利用において好ましくないことは周知の事実であり、これを解消してロックに必要な時間を短縮しようとすると、単一のＡＰＩ内で一連の処理を実施する必要がある。すなわち、特許文献１に開示された方法では、一連の処理の実行においてロック時間を短縮しようとすると、Ｗｅｂシステムを異なる適用先に適用しようとする場合にＤＢサーバ装置側の修正負担を低減し得るという効果が失われてしまう。

本発明は以上の点を考慮してなされたもので、一連の処理の実行時にデータベースのロック時間の長期化を抑制するとともに、Ｗｅｂシステムの適用先を変更する際にデータベースサーバ装置の実装修正に関する負荷を低減することが可能なデータベースサーバ装置、サーバシステム及びリクエスト処理方法を提案しようとするものである。

かかる課題を解決するため本発明においては、データベースシステムに対してデータの操作処理を行う以下のデータベースサーバ装置が提供される。このデータベースサーバ装置は、所定の単純なＡＰＩを提供し、前記単純なＡＰＩを利用したリクエストをＷｅｂサーバ装置から受信し、前記受信したリクエストに含まれるリクエストデータを解析して処理を振り分けるリクエスト処理部と、前記リクエスト処理部によって振り分けられた前記リクエストに基づいて、ＳＱＬ文を生成するＳＱＬ作成部と、前記ＳＱＬ作成部によって生成された前記ＳＱＬ文に対して所定の処理を行ってＳＱＬ全体文を作成し、前記作成したＳＱＬ全体文を前記データベースシステムに送信するＳＱＬ処理部と、を備える。さらに、このデータベースサーバ装置では、前記リクエスト処理部が、前記Ｗｅｂサーバ装置から一連の処理を要求する前記リクエストとして、分割された複数のリクエストを受信した場合に、前記ＳＱＬ処理部は、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了するまで、前記複数のリクエストの各リクエストに基づいて前記ＳＱＬ作成部によって生成された前記ＳＱＬ文を一時保存し、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了した後に、前記一時保存した複数の前記ＳＱＬ文を結合及び編集して前記ＳＱＬ全体文を作成するＳＱＬ統合処理を実行する。

また、かかる課題を解決するため本発明においては、データベースシステムに対してデータの操作処理を行う以下のサーバシステムが提供される。このサーバシステムは、所定の単純なＡＰＩを提供するデータベースサーバ装置と、Ｗｅｂクライアントからの要求に応じて、前記データベースシステムに対するデータの操作処理の実行を前記データベースサーバ装置に依頼するＷｅｂサーバ装置と、を備える。そして、前記Ｗｅｂサーバ装置は、前記データベースサーバ装置が提供する前記単純なＡＰＩを利用したリクエストを作成し、前記データベースサーバ装置に送信するリクエスト作成部を有し、前記データベースサーバ装置は、前Ｗｅｂサーバ装置から前記リクエストを受信し、前記受信したリクエストに含まれるリクエストデータを解析して処理を振り分けるリクエスト処理部と、前記リクエスト処理部によって振り分けられた前記リクエストに基づいて、ＳＱＬ文を生成するＳＱＬ作成部と、前記ＳＱＬ作成部によって生成された前記ＳＱＬ文に対して所定の処理を行ってＳＱＬ全体文を作成し、前記作成したＳＱＬ全体文を前記データベースシステムに送信するＳＱＬ処理部と、を有する。このようなサーバシステムでは、前記Ｗｅｂクライアントから一連の処理の実行が要求された場合に、前記リクエスト作成部は、前記一連の処理に対応するリクエストを、前記単純なＡＰＩを用いて複数のリクエストに分割して作成して送信し、前記ＳＱＬ処理部は、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了するまで、前記複数のリクエストの各リクエストに基づいて前記ＳＱＬ作成部によって生成された前記ＳＱＬ文を一時保存し、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了した後に、前記一時保存した複数の前記ＳＱＬ文を結合及び編集して前記ＳＱＬ全体文を作成するＳＱＬ統合処理を実行する。

また、かかる課題を解決するため本発明においては、データベースシステムに対してデータの操作処理を行うサーバシステムによる以下のリクエスト処理方法が提供される。ここで、前記サーバシステムは、所定の単純なＡＰＩを提供するデータベースサーバ装置と、Ｗｅｂクライアントからの要求に応じて、前記データベースシステムに対するデータの操作処理の実行を前記データベースサーバ装置に依頼するＷｅｂサーバ装置と、を有する。そして、このリクエスト処理方法は、前記Ｗｅｂサーバ装置が、前記データベースサーバ装置が提供する前記単純なＡＰＩを利用したリクエストを作成し、前記データベースサーバ装置に送信するリクエスト作成ステップと、前記データベースサーバ装置が、前記リクエスト作成ステップで送信された前記リクエストを受信し、前記受信したリクエストに含まれるリクエストデータを解析して処理を振り分けるリクエスト処理ステップと、前記データベースサーバ装置が、前記リクエスト処理ステップで振り分けられた前記リクエストに基づいて、ＳＱＬ文を生成するＳＱＬ作成ステップと、前記データベースサーバ装置が、前記ＳＱＬ作成ステップで生成された前記ＳＱＬ文に対して所定の処理を行ってＳＱＬ全体文を作成し、前記作成したＳＱＬ全体文を前記データベースシステムに送信するＳＱＬ処理ステップと、を備える。このようなリクエスト処理方法では、前記Ｗｅｂクライアントから一連の処理の実行が要求された場合に、前記リクエスト作成ステップにおいて、前記一連の処理に対応するリクエストを、前記単純なＡＰＩを用いて複数のリクエストに分割して作成して送信し、前記ＳＱＬ処理ステップにおいて、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成ステップによる前記ＳＱＬ文の生成が終了するまで、前記複数のリクエストの各リクエストに基づいて前記ＳＱＬ作成ステップで生成された前記ＳＱＬ文を一時保存し、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成ステップによる前記ＳＱＬ文の生成が終了した後に、前記一時保存した複数の前記ＳＱＬ文を結合及び編集して前記ＳＱＬ全体文を作成するＳＱＬ統合処理を実行する。

本発明によれば、一連の処理の実行時にデータベースのロック時間の長期化を抑制するとともに、Ｗｅｂシステムの適用先を変更する際にデータベースサーバ装置の実装修正に関する負荷を低減することができる。

本発明の一実施形態に係るサーバシステムを含むＷｅｂシステムの全体構成例を示すブロック図である。 図１に示したサーバシステムの機能構成例を示すブロック図である。 ＳＱＬ処理の処理手順例を示すフローチャートである。 応答データとして生成されるＪＳＯＮデータの具体例を説明するための図である。 ＳＱＬ統合処理の処理手順例を示すフローチャートである。 Ｗｅｂシステムにおける一連の処理の流れを示すシーケンス図である。 ＤＢＭＳに含まれるテーブルの一例を示す図である。 ＡＰＩに関するＳＱＬ文とＪＳＯＮデータの具体例を示す図である。 ＳＱＬ統合処理の具体例を説明するための図である。

以下、図面を参照して、本発明の一実施形態を詳述する。なお、一般にＷｅｂシステムは、Ｗｅｂサーバ装置とアプリケーション（ＡＰ）サーバ装置とが別々に存在する場合と、Ｗｅｂサーバ装置だけでＡＰサーバ装置の役割も担う（機能を有する）場合とがある。しかし、何れの構成であっても本発明に影響はなく、説明を簡略にするため、以下では、Ｗｅｂサーバ装置はＡＰサーバ装置の役割も担うとして説明する。

図１は、本発明の一実施形態に係るサーバシステムを含むＷｅｂシステムの全体構成例を示すブロック図である。

図１に示したように、Ｗｅｂシステム１０は、本実施形態に係るサーバシステム１００とＤＢＭＳ１３０とを備えて構成され、サーバシステム１００は、Ｗｅｂサーバ装置１１０及びデータベース（ＤＢ）サーバ装置１２０を備える。Ｗｅｂサーバ装置１１０はＷｅｂクライアント２０に接続され、ＤＢサーバ装置１２０はデータベース管理システム（ＤＢＭＳ）１３０に接続される。なお、本実施形態において、ＤＢＭＳ１３０はユーザ側が準備してもよいことを想定して一般的なＤＢＭＳとし、Ｗｅｂシステム１０は、プラットフォーム的な位置付けであり、Ｗｅｂシステム１０の構成を修正することによって、異なる適用先（案件）にも適用され得るものとする。

Ｗｅｂクライアント２０は、データベースに対するデータ処理をＷｅｂシステム１０に要求するクライアントであって、当該要求はＷｅｂサーバ装置１１０に入力される。Ｗｅｂシステム１０ではＷｅｂクライアント２０からの要求に応じて後述する処理を実行し、その結果として得られたデータを、Ｗｅｂサーバ装置１１０からＷｅｂクライアント２０に返す。

サーバシステム１００において、ＤＢサーバ装置１２０はＨＴＴＰサーバであり、Ｗｅｂサーバ装置１１０はＨＴＴＰによる通信を行うサーバである。Ｗｅｂサーバ装置１１０及びＤＢサーバ装置１２０は、ＣＰＵ（Central Processing Unit）等のプロセッサ、ＲＡＭ（Random Access Memory）等の主記憶装置、及びＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等の補助記憶装置を有する。

Ｗｅｂサーバ装置１１０は、任意のネットワークを介してＷｅｂクライアント２０と接続され、ＤＢサーバ装置１２０とＨＴＴＰ通信で接続される。本実施形態では、Ｗｅｂサーバ装置１１０とＤＢサーバ装置１２０との間は、例えばＪＳＯＮ（JavaScript（登録商標） Object Notation）形式データで通信が行われる。詳細は後述するが、Ｗｅｂサーバ装置１１０は、Ｗｅｂクライアント２０からの要求に応じて、ＤＢＭＳ１３０に対するデータの操作処理（データ処理）の実行をＤＢサーバ装置１２０にＨＴＴＰ通信経由で依頼する。この依頼を以下ではリクエストと呼ぶ。

ＤＢサーバ装置１２０は、比較的単純なＡＰＩを提供する。本実施形態において「単純なＡＰＩ」とは、具体的には例えば、１つのデータグループに対して更新、保存、または取得のうちの１処理を行うＡＰＩを意味する。なお、本実施形態の変形例として、ＤＢサーバ装置１２０が提供する「単純なＡＰＩ」を必ずしも１処理を行うＡＰＩに限定せず、比較的単純な実装が可能な範囲で、少数の処理を行うＡＰＩを「単純なＡＰＩ」として提供するようにしてもよい。

ＨＴＴＰサーバで構成されるＤＢサーバ装置１２０は、Ｗｅｂサーバ装置１１０との間をＨＴＴＰプロトコルで通信し、ＨＴＴＰプロトコル上でＪＳＯＮ等の汎用的なデータフォーマットを利用してデータの送受信を行う。そして、ＤＢサーバ装置１２０は、Ｗｅｂサーバ装置から受信したリクエストに基づいて、利用するＤＢＭＳ１３０に対応するＳＱＬ文を生成し、ＤＢＭＳ１３０に対してデータ処理を要求する。なお、ＤＢサーバ装置１２０とＤＢＭＳ１３０との間は、例えばＪＤＢＣ（Java（登録商標） DataBase Connectivity）ライブラリ等を利用して接続される。

ＤＢＭＳ１３０は、データベースシステムの運用及び管理を行う。ＤＢＭＳ１３０は、Ｗｅｂシステム１０（ＤＢサーバ装置１２０）から受信したＳＱＬ文に応じて、データベースに記録されているデータを用いたデータ処理を実行し、その処理結果をＷｅｂシステム１０に返す。本実施形態においてＤＢＭＳ１３０はユーザ側が準備することを想定するため、様々なベンダによって提供される一般的なＤＢＭＳであると考えてよい。

なお、一般にデータベースシステムは、厳密には、データを保存するデータベースとそれを管理するＤＢＭＳとに分けられるが、本発明においてデータベースシステムの構成を詳細に区別する意味はあまりない。そのため、本発明の説明では、ＤＢＭＳ１３０をデータベースシステムと同義に用いることがある。具体的には例えば、「ＤＢＭＳ１３０に保存されているデータ」や「ＤＢＭＳ１３０のデータ」は、データベースシステム（データベース）に保存されているデータを意味する。また例えば、「ＤＢＭＳ１３０に変更を加える」とは、データベースシステム（データベース）に保存されているデータを変更することを意味する。

また、図１においてＤＢＭＳ１３０は独立した装置のように示されているが、本実施形態はこれに限定されるものではなく、例えばＤＢＭＳ１３０がＤＢサーバ装置１２０と同一の装置内に設けられてもよい。

本実施形態のＷｅｂシステム１０は、上記のようにＷｅｂサーバ装置１１０とＤＢＭＳ１３０との間にＤＢサーバ装置１２０が設けられて構成されることにより、Ｗｅｂサーバ装置１１０（サーバシステム１００）が、ＤＢＭＳ１３０の構成を考慮することなく、ＤＢＭＳ１３０に処理を依頼することが可能となる。また、このような構成は、Ｗｅｂサーバ装置がＤＢＭＳに直接接続されるＷｅｂサーバの構成と比較したとき、異なるＤＢＭＳに対応する際にＷｅｂサーバ装置側の修正が不要であるという利点がある。

次に、本実施形態に係るサーバシステム１００の機能的な構成について詳しく説明する。

図２は、図１に示したサーバシステムの機能構成例を示すブロック図である。図２に示したように、サーバシステム１００において、Ｗｅｂサーバ装置１１０は、リクエスト作成部１１１を有し、ＤＢサーバ装置１２０は、リクエスト処理部１２１、ＳＱＬ作成部１２２、及びＳＱＬ処理部１２３を有する。

Ｗｅｂサーバ装置１１０のリクエスト作成部１１１は、Ｗｅｂクライアント２０からの要求に応じて、ＤＢＭＳ１３０に対する処理要求をＤＢサーバ装置１２０にＨＴＴＰ通信経由で依頼する機能を有する。また、リクエスト作成部１１１は、ＤＢサーバ装置１２０から応答として受信したデータの中に含まれる動的パラメータ名を利用して、ＤＢＭＳ１３０に対する次の処理要求を生成し、ＤＢサーバ装置１２０に送信する機能を有する。

リクエスト作成部１１１によるＤＢサーバ装置１２０に対する依頼（リクエスト）は、ＨＴＴＰリクエストによって行われる。このＨＴＴＰリクエストの中には、データとしてリクエストＩＤと終了フラグのデータが渡される。このデータはＵＲＬの一部として含めてもよいし、ＨＴＴＰ通信において送受信するＪＳＯＮデータの一部として含めてもよい。

リクエストＩＤは、ＤＢＭＳ１３０に関する一連の処理を識別するためのＩＤであり、一連の処理に対して同一のリクエストＩＤが付与される。言い換えれば、異なるリクエストＩＤであれば、ＤＢＭＳ１３０に関して異なる一連の処理であることを意味する。リクエストＩＤは、後述するＳＱＬ処理部１２３において、複数の処理リクエストを同じグループとして識別するために用いられる。

終了フラグは、例えば「ｔｒｕｅ」または「ｆａｌｓｅ」のように２つの識別可能な値で構成され、当該ＨＴＴＰリクエストがＤＢＭＳ１３０に関する一連の処理の最後のリクエストであるか否かを示す情報である。具体的には、同一のリクエストＩＤを有する複数のＨＴＴＰリクエスト（すなわち、一連の処理を示す複数のＨＴＴＰリクエスト）において、終了フラグが「ｆａｌｓｅ」であれば、当該ＨＴＴＰリクエストは一連の処理の最後のリクエストではないことを意味し、終了フラグが「ｔｒｕｅ」であれば、当該ＨＴＴＰリクエストは一連の処理の最後のリクエストであることを意味する。この終了フラグも、後述するＳＱＬ処理部１２３による処理で用いられる。

ＤＢサーバ装置１２０のリクエスト処理部１２１は、ＤＢサーバ装置１２０が提供するＡＰＩを介してＤＢＭＳ１３０に対する複数の処理要求（リクエスト）をＷｅｂサーバ装置１１０から受け取り、各リクエストに含まれるリクエストデータを解析し、処理を対応するＳＱＬ作成部１２２に振り分ける（割り当てる）機能を有する。より詳しくは、リクエスト処理部１２１は、Ｗｅｂサーバ装置１１０のリクエスト作成部１１１からＨＴＴＰリクエストを受信する。ＨＴＴＰリクエストの主なメソッドとして、ＧＥＴ、ＰＵＴ、ＰＯＳＴ、ＤＥＬＥＴＥがあり、リクエスト処理部１２１は、ＨＴＴＰメソッド及びＵＲＬに基づいて、対応するＳＱＬ作成部１２２にＨＴＴＰリクエストの処理を割り当てる。

なお、リクエスト処理部１２１による上記の処理、すなわち、ＨＴＴＰメソッド及びＵＲＬに応じて処理を振り分ける処理は、一般的なＷｅｂサーバで一般的に用いられる処理であるため、詳細な説明を省略する。

ＤＢサーバ装置１２０のＳＱＬ作成部１２２は、リクエスト処理部１２１によって割り当てられたＨＴＴＰリクエストに対応するＳＱＬ文を生成し、生成したＳＱＬ文をＳＱＬ処理部１２３に送る機能を有する。また、ＳＱＬ作成部１２２は、ＳＱＬ処理部１２３で処理した結果を含む応答（ＨＴＴＰレスポンス）をＷｅｂサーバ装置１１０のリクエスト作成部１１１に返信する機能を有する。ＨＴＴＰレスポンスを受信したリクエスト作成部１１１は、受信したデータを加工処理したうえで、Ｗｅｂクライアント２０に応答を返す。なお、上記のＷｅｂクライアント２０に応答を返す処理は、さらにリクエスト処理部１２１を介して行ってもよいし、またはＳＱＬ処理部１２３が単独で行うようにしてもよい。

ＳＱＬ作成部１２２による上記処理は、各ＨＴＴＰリクエストに対応するＳＱＬ文を単純に生成する処理であり、これは一般的なＷｅｂサーバで一般的に用いられる処理であるため、詳細な説明を省略する。但し、ＳＱＬ作成部１２２の処理に関して以下の点を補足する。ＨＴＴＰリクエストに対応するＳＱＬ文の生成においてＨＴＴＰリクエストに含まれる値（数字や文字列等の固定値）によりＳＱＬ文の条件節（ＷＨＥＲＥ節）等の値を可変にする場合、これらの値（固定パラメータ）をＷｅｂサーバ装置１１０がＨＴＴＰリクエストに含めることがある。この固定パラメータに関して、本実施形態ではＳＱＬ作成部１２２は処理を行わずにＳＱＬ処理部１２３に渡し、ＳＱＬ処理部１２３が固定パラメータを処理するものとする。このような処理も一般的に用いられている処理であるため、さらに詳細な説明は省略する。以降の説明では、特に断りのない限り、動的パラメータ及び固定パラメータを区別する必要がない場合に、単にパラメータと記述する。

ＤＢサーバ装置１２０のＳＱＬ処理部１２３は、大別して以下の第１～第３のＳＱＬ処理機能を有する。第１のＳＱＬ処理機能は、Ｗｅｂクライアント２０からの要求に対応してＤＢサーバ装置１２０の内部（ＳＱＬ作成部１２２）で生成された複数のＳＱＬ文を連結したり編集したりしたうえで、ＤＢＭＳ１３０に送信する機能である。第２のＳＱＬ処理機能は、ＤＢＭＳ１３０からのデータ取得要求に対して、数字や文字列の固定値とは別に動的パラメータ名を定義してＷｅｂサーバ装置１１０に返す機能である。第３のＳＱＬ処理機能は、Ｗｅｂクライアント２０からの要求に対応してＳＱＬ作成部１２２で生成されたＳＱＬ文に含まれる動的パラメータ名と、Ｗｅｂサーバ装置１１０のリクエスト作成部１１１からＡＰＩを介して受信したＤＢＭＳ１３０への処理要求に含まれる動的パラメータ名とを対応付けてＳＱＬ文を編集する機能である。

これら第１～第３のＳＱＬ処理機能を有するＳＱＬ処理部１２３によって実行されるＳＱＬ処理について、以下に詳しく説明していく。

図３は、ＳＱＬ処理の処理手順例を示すフローチャートである。ＳＱＬ処理部１２３は、ＨＴＴＰリクエスト及び当該ＨＴＴＰリクエストに関してＳＱＬ作成部１２２で生成されたＳＱＬ文を受信するごとに、図３に示すＳＱＬ処理を実行する。

図３によればまず、ＳＱＬ処理部１２３は、受信したＨＴＴＰリクエストに含まれるリクエストＩＤを確認することによって、当該ＨＴＴＰリクエストに関して生成されたＳＱＬ文が属する一連の処理のグループを識別する（ステップＳ１１）。前述したようにリクエストＩＤはＤＢＭＳ１３０に対する一連の処理に対して同一値が設定されるため、ＳＱＬ処理部１２３は、リクエストＩＤに基づいてグループを識別することで、以前に受信したＨＴＴＰリクエストによって生成済みのＳＱＬ文が今回の一連の処理に用いられるものであるか否かを判断することができる。

次に、ＳＱＬ処理部１２３は、受信したＨＴＴＰリクエストに含まれる終了フラグを確認する（ステップＳ１２）。ステップＳ１２において終了フラグが「ｔｒｕｅ」ではない、すなわち「ｆａｌｓｅ」であった場合は（ステップＳ１２のＮＯ）、一連の処理が当該ＨＴＴＰリクエストで終了しないことを意味し、この場合はステップＳ１３に移行する。一方、ステップＳ１２において終了フラグが「ｔｒｕｅ」であった場合は（ステップＳ１２のＹＥＳ）、一連の処理が当該ＨＴＴＰリクエストで終了することを意味し、この場合は後述するステップＳ１６に移行する。

ステップＳ１３では、ＳＱＬ処理部１２３は、当該ＨＴＴＰリクエストに関してＳＱＬ作成部１２２で生成されたＳＱＬ文を、当該ＨＴＴＰリクエストに含まれているリクエストＩＤ及びパラメータ情報とともに（リクエストＩＤに関連付けて）、ＳＱＬ処理部１２３の内部バッファに保存する。

ステップＳ１３の処理に次いで、ＳＱＬ処理部１２３は、当該ＨＴＴＰリクエストに関して生成されたＳＱＬ文に対して、当該ＨＴＴＰリクエストに含まれている固定パラメータ値を適用した上で、適用後のＳＱＬ文をＤＢＭＳ１３０に送る処理を実行してもよい（ステップＳ１４）。ステップＳ１４の処理は、ＤＢＭＳ１３０からの取得処理に限定される。言い換えれば、ＤＢＭＳ１３０に対して変更を加えない処理に限定して、ＳＱＬ処理部１２３は、ステップＳ１４の処理を実行してもよい。ステップＳ１４の処理の実行可否は、実装するＳＱＬ処理部１２３側が毎回判断するようにしてもよいし、あるいは、ステップＳ１４の処理を実行するか否かを判断するためのフラグをＨＴＴＰリクエストに別途追加し、ＳＱＬ処理部１２３がこのフラグに基づいて判断するようにしてもよい。何れにしても、ステップＳ１４の処理を実行した場合には、ＳＱＬ処理部１２３は、ＤＢＭＳ１３０に対して変更を加えることなく、ＤＢＭＳ１３０に保存されているデータを参考として取得することができる。

そして、ステップＳ１３またはＳ１４の処理後、ＳＱＬ処理部１２３は、当該ＨＴＴＰリクエストに対する応答データを生成し、生成した応答データを含むＨＴＴＰレスポンスをＷｅｂサーバ装置１１０に送信し（ステップＳ１５）、ＳＱＬ処理を終了する。

ここで、ステップＳ１５で返すＨＴＴＰレスポンスについて具体的に説明する。例えばＰＵＴ、ＰＯＳＴ、またはＤＥＬＥＴＥメソッドのＨＴＴＰリクエストに対しては、ＳＱＬ処理部１２３は、単にそのＨＴＴＰリクエストを受け付けたことを示す「ＨＴＴＰ ２００」の応答を返すとしてもよいし、応答データとしてＪＳＯＮデータを付加することによって、ＨＴＴＰリクエストを正しく受け付けたことを示す応答を返すとしてもよい。但し、一般的なＷｅｂシステムにおけるＨＴＴＰ通信では、上記の応答を返すことによってＨＴＴＰリクエストに含まれる処理がＤＢＭＳ１３０に対して完了することを意味するが、本実施形態のＷｅｂシステム１０の場合は、上記の応答を返したステップＳ１５の段階では、ＤＢＭＳ１３０に対して何ら変更は加えられていない点で異なる。

一方、ＧＥＴメソッドのＨＴＴＰリクエストに対しては、ＳＱＬ処理部１２３は、当該ＨＴＴＰリクエストで取得する各データに対応する動的パラメータ名を含む形式で、Ｗｅｂサーバ装置１１０にＨＴＴＰレスポンスを返す。後述する図４には、このようなＨＴＴＰレスポンスに含まれる応答データの具体例として、ＪＳＯＮデータが示されている。ＳＱＬ処理部１２３は、生成したＪＳＯＮデータを含むＨＴＴＰレスポンスをＷｅｂサーバ装置１１０に送信して、ＳＱＬ処理を終了する。

図４は、応答データとして生成されるＪＳＯＮデータの具体例を説明するための図である。図４に示したＳＱＬ文２１０は、ＧＥＴメソッドのＨＴＴＰリクエストを受けて、ＳＱＬ作成部１２２が生成するＳＱＬ文の一例である。そしてＪＳＯＮデータ２２０は、図３のステップＳ１５において、ＳＱＬ文２１０を基に、ＳＱＬ処理部１２３が生成するＪＳＯＮデータの一例である。

ＪＳＯＮデータ２２０について詳しく説明する。図４に示したように、ＪＳＯＮデータ２２０は、「ｄａｔａ」ブロックと「ｐａｒａｍ」ブロックの２つのブロックに大別できる。

このうち、ｄａｔａブロックは、文字列または数字の固有値が記述されている。このようなｄａｔａブロックは、当該ＨＴＴＰリクエストが単独でＤＢＭＳ１３０によって処理される場合に、ＤＢサーバ装置１２０からＷｅｂサーバ装置１１０に返すデータである。つまり、当該ＨＴＴＰリクエストの終了フラグが「ｔｒｕｅ」に設定された単独リクエストの場合には、ＨＴＴＰレスポンスに含める応答データとして当該ｄａｔａブロック（具体的には、「Ａ」や「１」等）が含まれる。

一方、ｐａｒａｍブロックは、ｄａｔａブロックの各データ項目に対応する動的パラメータ名が記述されている。具体的には、ＳＱＬ文２１０のＳＥＬＥＣＴ文のなかに含まれるカラム名（「Ａ」，「Ｂ」等）か、ＳＥＬＥＣＴ文のなかでＡＳで指定されたカラムの別名（「ＡＰＩ＿Ａ＿ＰＡＲＡＭ＿Ａ」等）が記述されている。そして、ＧＥＴメソッドのＨＴＴＰリクエストに対するＨＴＴＰレスポンスの場合、応答データとして生成されるＪＳＯＮデータには、上記のような動的パラメータ名を記述したｐａｒａｍブロックが必ず含まれる。さらに、ＳＱＬ処理部１２３によってステップＳ１４の処理が行われた場合に限り、生成されるＪＳＯＮデータにｄａｔａブロックも含まれる。なお、図４に示したＪＳＯＮデータ２２０のｄａｔａブロックやｐａｒａｍブロックは例示に過ぎず、本実施形態による実際のフォーマットは、これに限定されるものではない。

図３のＳＱＬ処理の説明に戻る。前述したように、ステップＳ１２において終了フラグが「ｔｒｕｅ」であった場合には（ステップＳ１２のＹＥＳ）、一連の処理が当該ＨＴＴＰリクエストで終了することを意味し、ステップＳ１６～Ｓ１９の処理が実行される。

このときまず、ステップＳ１６において、ＳＱＬ処理部１２３は、内部バッファから、以前のＳＱＬ処理で実行されたステップＳ１３の処理で内部バッファに一時保存したＳＱＬ文のうち、当該ＨＴＴＰリクエストと同じリクエストＩＤが付与されたＨＴＴＰリクエストに含まれるＳＱＬ文やパラメータを全て取得する。

次に、ＳＱＬ処理部１２３は、ステップＳ１６で取得した複数のＳＱＬ文を、変数名やロック関係の処理に着目して結合する（ステップＳ１７）。ステップＳ１７の処理はＳＱＬ統合処理と称し、その詳細な処理手順は図５を参照しながら後述する。

さらに、ＳＱＬ処理部１２３は、ステップＳ１７のＳＱＬ統合処理で結合したＳＱＬ文をＤＢＭＳ１３０に送信してデータ処理を依頼する（ステップＳ１８）。そしてＳＱＬ処理部１２３は、ＤＢＭＳ１３０からのデータ処理の応答に基づいて、応答データであるＪＳＯＮデータを生成し、生成した応答データを含むＨＴＴＰレスポンスをＷｅｂサーバ装置１１０に送信し（ステップＳ１９）、ＳＱＬ処理を終了する。

なお、前述したステップＳ１５の場合と異なり、ステップＳ１９の段階では、当該ＨＴＴＰリクエストのリクエストＩＤが示す一連の処理についてのＳＱＬ処理が完了するため、ステップＳ１９においてＷｅｂサーバ装置１１０に返す応答データは、一般的なＷｅｂシステムにおける一連の処理の応答データと同様である。

図５は、ＳＱＬ統合処理の処理手順例を示すフローチャートである。図５に示したＳＱＬ統合処理は、図３のステップＳ１７の処理に相当し、ＳＱＬ処理部１２３によって実行される。

図５によればまず、ＳＱＬ処理部１２３は、図３のステップＳ１６で取得した複数のＳＱＬ文に対して、ＨＴＴＰリクエストに含まれるパラメータを代入した後、これらを時系列順に単純に連結する（ステップＳ２１）。以降、ステップＳ２１で連結したＳＱＬ文をＳＱＬ全体文と称する。

次に、ＳＱＬ処理部１２３は、ステップＳ２１で連結したＳＱＬ全体文のなかに、特定の処理（例えば、ロック処理やコミット処理）が存在するか否かを確認し（ステップＳ２２）、上記特定の処理が存在する場合には（ステップＳ２２のＹＥＳ）、ステップＳ２３に移行し、上記特定の処理が存在しない場合には（ステップＳ２２のＮＯ）、ステップＳ２３をスキップしてステップＳ２４に移行する。

ステップＳ２３では、ＳＱＬ処理部１２３は、ＳＱＬ全体文に含まれる上記特定の処理に関するＳＱＬ文の順序を入れ替えて整列する。具体的には、ＳＱＬ処理部１２３は、ロック処理に関する処理の文をＳＱＬ全体文の最初に移動し、コミット処理の文をＳＱＬ全体文の最後に移動する。ステップＳ２３で整列されることにより、ＳＱＬ全体文は、一連の処理全体に跨ってロック及びコミット処理を行うＳＱＬ文となる。

ステップＳ２３の処理後またはステップＳ２２でＮＯと判定された場合、ＳＱＬ処理部１２３は、ＨＴＴＰリクエストに動的パラメータ名が含まれているか否かを確認する（ステップＳ２４）。ステップＳ２４において動的パラメータ名が含まれていない場合には（ステップＳ２４のＮＯ）、ＳＱＬ処理部１２３はＳＱＬ統合処理を終了する。なお、ＨＴＴＰリクエストに含まれるパラメータが固定パラメータであれば、ＳＱＬ処理部１２３はそのパラメータをＳＱＬ全体文に適用する。

一方、ステップＳ２４においてＨＴＴＰリクエストに動的パラメータ名が含まれる場合には（ステップＳ２４のＹＥＳ）、ＳＱＬ処理部１２３は、当該動的パラメータのデータ取得に関するＳＥＬＥＣＴ関連のＳＱＬ文をＳＱＬ全体文から探し、該当するＳＱＬ文を上記動的パラメータ名が用いられている箇所に組み込む（ステップＳ２５）。なお、ＳＱＬ文のなかには、複数の値を取得するＳＥＬＥＣＴ文が存在することがあるが、このような場合、ＳＱＬ処理部１２３は、当該動的パラメータ名の値に限定して取得するように、ＳＥＬＥＣＴ文を修正する。ステップＳ２５の処理後、ＳＱＬ処理部１２３はＳＱＬ統合処理を終了する。

以上に説明したように、本実施形態に係るサーバシステム１００を含むＷｅｂシステム１０では、Ｗｅｂクライアント２０からの要求に応じて、Ｗｅｂサーバ装置１１０が、ＤＢサーバ装置１２０が提供する単純なＡＰＩを利用して、ＤＢＭＳ１３０に対する一連の処理のリクエストを複数の処理リクエストに分割してＤＢサーバ装置１２０に依頼することができる。そして、ＤＢサーバ装置１２０が、分割して渡された複数の処理リクエストに基づいて生成したＳＱＬ文を統合してからＤＢＭＳ１３０にデータ処理を依頼することによって、一連の処理のリクエストが処理全体に跨ってロック処理やコミット処理を実行するものであっても、適切に対応したデータ処理をＤＢＭＳ１３０に依頼することができる。

図６には、Ｗｅｂシステム１０における一連の処理の流れがシーケンス図に示されている。繰り返しになるため、図６の個々の処理について詳述することは省略し、ＤＢサーバ装置１２０による処理の対応だけ示す。図６において、Ｗｅｂサーバ装置１１０からステップＳ３１のＨＴＴＰリクエスト（ＡＰＩ＿Ａリクエスト、終了フラグはｆａｌｓｅ）を受けてＤＢサーバ装置１２０が実行する処理（ステップＳ３２～Ｓ３３）は、図３のＳＱＬ処理のステップＳ１１～Ｓ１５の処理に相当する。また、図６において、Ｗｅｂサーバ装置１１０からステップＳ３４のＨＴＴＰリクエスト（ＡＰＩ＿Ｂリクエスト、終了フラグはｔｒｕｅ）を受けてＤＢサーバ装置１２０が実行する処理（ステップＳ３５～Ｓ３６）は、図３のＳＱＬ処理のステップＳ１１～Ｓ１２，Ｓ１６～Ｓ１９の処理に相当する。図６に示す処理が行われる。ここで特に、ステップＳ３５では、ＳＱＬ結合処理が行われた後のＳＱＬ全体文を用いてＤＢＭＳ１３０への処理依頼が行われることによって、複数のＨＴＴＰリクエストに基づく複数の処理（ＡＰＩ＿Ａ及びＡＰＩＢ）を、一連の処理を跨いで実行することができる。

上述した本実施形態に係るサーバシステム１００を含んで構成されるＷｅｂシステム１０は、開発したプラットフォームを用いて異なる案件に適用する際にＷｅｂサーバ装置１１０の修正量が大きいシステム、かつＤＢサーバ装置１２０の主目的がデータ保存であるシステムに対して特に有効である。この特に有効なシステムの具体例として、ＫＰＩ（Key Performance Indicator）計算システムやシミュレーションシステムが挙げられる。これらのシステムでは、主に複雑な計算を伴うため、ＤＢサーバ装置１２０よりもＷｅｂサーバ装置１１０側で計算を行うことが一般的である。また、これらのシステムでは一般的に、ＤＢサーバ装置１２０よりもＷｅｂサーバ装置１１０の方が実装規模が大きくなること、及び、ＤＢサーバ装置１２０側に求められる機能が比較的単純なものになる傾向がある。

以下では、このようなシステムにおける用途を例として、図７～図９の具体例を参照しながら、本実施形態のＷｅｂシステム１０による実施例を説明する。

図７は、ＤＢＭＳに含まれるテーブルの一例を示す図である。図７に例示したテーブル２３０において、行２３１には各カラムの名称が記載され、行２３２以降の各行には、テーブル２３０の各カラムに対応する値が設定されている。本実施例では、「一連の処理」の一例として、テーブル２３０の行２３２の値を別の行にコピーし、さらに一部のカラムの値を変更するケースについて、具体的な処理手順を説明する。

図８は、ＡＰＩに関するＳＱＬ文とＪＳＯＮデータの具体例を示す図である。図８には、ＤＢサーバ装置１２０に対するＨＴＴＰリクエストに伴って生成されるＳＱＬ文２４０，２６０と、これらのＨＴＴＰリクエストに伴う入力または出力のＪＳＯＮデータ２５０，２７０が示されている。詳細は後述するが、ＳＱＬ文２４０は、ＧＥＴメソッドのＨＴＴＰリクエストに応じて生成されるＳＱＬ文の具体例であり、ＳＱＬ文２６０は、ＰＵＴメソッドのＨＴＴＰリクエストに応じて生成されるＳＱＬ文の具体例である。

本実施例における「一連の処理」に応じたＤＢＭＳ１３０に対する処理は、テーブル２３０の行２３２の値を取得する処理と、テーブル２３０の特定の行の値を更新する処理と、に分割することができ、それぞれＧＥＴメソッドとＰＵＴメソッドのＨＴＴＰリクエストという形で定義することができる。

そこでまず、Ｗｅｂサーバ装置１１０のリクエスト作成部１１１は、リクエストＩＤを１００とし、終了フラグをｆａｌｓｅとしたＧＥＴメソッドであるＨＴＴＰリクエストを、ＤＢサーバ装置１２０に送信する。このとき、上記ＨＴＴＰリクエストにテーブル２３０の行２３２を識別するために、「ＣｏｌｕｍｎＡ」の「１」の値も、固定パラメータとしてＤＢサーバ装置１２０に送信される。なお、Ｗｅｂサーバ装置１１０側は、一連の処理内容を把握しているため、リクエストＩＤや終了フラグを適切に設定することが可能である。

次に、ＤＢサーバ装置１２０では、リクエスト作成部１１１からのＨＴＴＰリクエストを受けて、リクエスト処理部１２１による処理の振り分けと、ＳＱＬ作成部１２２によるＳＱＬ文（図８のＳＱＬ文２４０）の生成が行われるが、これらは一般的な処理を流用可能であるため、詳細な説明を省略する。

次に、ＳＱＬ処理部１２３は、ＳＱＬ文２４０に対して、図３に示したＳＱＬ処理を実行する。まずＳＱＬ処理部１２３は、ステップＳ１１で、ＳＱＬ文２４０がリクエストＩＤが１００のＳＱＬ文であることを把握し、ステップＳ１２で、終了フラグがｆａｌｓｅである（ｔｒｕｅではない）ことを確認する。終了フラグがｆａｌｓｅであるため、ＳＱＬ処理部１２３は、ステップＳ１３で、ＳＱＬ文２４０とリクエストＩＤとパラメータを内部バッファに保存する。

さらに、ＳＱＬ処理部１２３は、ステップＳ１４で、ＳＱＬ文２４０の「＠ＶＡＬＵＥ」の箇所に、ＨＴＴＰリクエストで渡された固定パラメータを設定し、ＤＢＭＳ１３０に処理を依頼する。ＧＥＴメソッドにより生成されたＳＱＬ文２４０は、図３で前述したステップＳ１４の実行に関する条件「ＤＢＭＳ１３０からの取得処理に限定される」を満たすためである。

その後、ＳＱＬ処理部１２３は、ステップＳ１５の処理として、ＤＢＭＳ１３０からの応答とＳＱＬ文２４０とに基づいて、ＪＳＯＮデータ２５０を生成する。図８に示すように、ＪＳＯＮデータ２５０は、ｄａｔａブロックとｐａｒａｍブロックを含む形式となっているが、ｄａｔａブロックが含まれるのは、ステップＳ１４の処理が行われたためである。一方、ｐａｒａｍブロックには、ＳＱＬ文２４０において各カラム名（「ＣｏｌｕｍｎＡ」や「ＣｏｌｕｍｎＢ」等）に対して「ＡＳ」を用いて示された、各カラム名の別名（「ＧＥＴＡＰＩ＿ＣＯＬＡ」や「ＧＥＴＡＰＩ＿ＣＯＬＢ」等）が、動的パラメータ名として記載されている。そして、ＳＱＬ処理部１２３は、このＪＳＯＮデータ２５０を、ＨＴＴＰレスポンスとしてＷｅｂサーバ装置１１０（リクエスト作成部１１１）に返す。この応答は、ＧＥＴメソッドのＨＴＴＰレスポンスであるが、この段階では、ＤＢＭＳ１３０に対して変更は加えられていない。

次に、Ｗｅｂサーバ装置１１０のリクエスト作成部１１１は、ＧＥＴメソッドのＨＴＴＰレスポンスを受けて、リクエストＩＤを同じく１００とし、終了フラグをｔｒｕｅとしたＰＵＴメソッドであるＨＴＴＰリクエストを、ＤＢサーバ装置１２０に送信する。このとき、リクエスト作成部１１１は、先のＧＥＴメソッドのＨＴＴＰレスポンスに基づいて、ＪＳＯＮデータ２７０を生成し、これをＨＴＴＰリクエストに含めてＤＢサーバ装置１２０に送信する。ここで動的パラメータ名として指定するパラメータについては、動的パラメータ名であることを明記するために「ｐａｒａｍ（）」を付与する。なお、本発明の派生例として、このとき単に動的パラメータを生成するのみならず、例えばＭＡＸ（）関数等を動的パラメータを引数として指定する方式でＪＳＯＮデータ２７０を生成し、後述するＳＥＬＥＣＴ文のなかでＭＡＸ（）関数を使うことで、その最大値を指定するような方法を採用してもよいし、動的パラメータを含む四則演算の数式として表現する方法を採用してもよい。

次に、ＤＢサーバ装置１２０では、リクエスト作成部１１１からのＨＴＴＰリクエストを受けて、リクエスト処理部１２１によって処理が振り分けられ、ＳＱＬ作成部１２２によってＳＱＬ文２６０が生成されてＳＱＬ処理部１２３に渡される。ここで、図８に示すＳＱＬ文２６０の「＠ＶＡＬＵＥ＿Ｂ」、「＠ＶＡＬＵＥ＿Ｘ」、「＠ＶＡＬＵＥ＿Ａ」は、ＪＳＯＮデータ２７０に含まれる、対応するアルファベット（Ｂ，Ｘ，Ａ）のパラメータを設定することを意味する。

次に、ＳＱＬ処理部１２３は、ＳＱＬ文２６０に対して、図３に示したＳＱＬ処理を実行する。具体的には、ＳＱＬ処理部１２３は、ステップＳ１１で、ＳＱＬ文２６０が「１００」のリクエストＩＤに紐付いたＳＱＬ文であることを把握し、ステップＳ１２で、終了フラグがｔｒｕｅであることを確認する。終了フラグがｔｒｕｅであるため、ＳＱＬ処理部１２３は、ステップＳ１６で、同じリクエストＩＤ「１００」をキーとして、ＳＱＬ文２４０及びそれに関連するパラメータを内部バッファから取得する。そして、ステップＳ１７で、ＳＱＬ処理部１２３は、ＳＱＬ文２４０とＳＱＬ２６０とを統合する。このＳＱＬ統合処理の具体的手順は、図９を参照しながら後述する。

さらに、ＳＱＬ処理部１２３は、ステップＳ１８において、ステップＳ１７で統合したＳＱＬ文をＤＢＭＳ１３０に送信してデータ処理を依頼する。そしてステップＳ１９では、ＤＢＭＳ１３０からの応答を基に、ＳＱＬ処理部１２３はＨＴＴＰレスポンスを作成してＷｅｂサーバ装置１１０（リクエスト作成部１１１）に返す。この応答は、リクエストＩＤ「１００」を付与した一連の処理のリクエストに対するＨＴＴＰレスポンスであり、一連の処理のリクエストに応じてＤＢＭＳ１３０のデータは変更されている。但し、上記応答に、ＰＵＴメソッドのＨＴＴＰレスポンスという意味を別途持たせてもよい。

図９は、ＳＱＬ統合処理の具体例を説明するための図である。図９には、図８に示したＳＱＬ文２４０及びＳＱＬ２６０に対してＳＱＬ処理部１２３がＳＱＬ統合処理（図５参照）を実行したときの、統合途中のＳＱＬ文２８０と、統合後のＳＱＬ文２９０とが示されている。

ＳＱＬ統合処理においてまず、ＳＱＬ処理部１２３は、ステップＳ２１で、ＳＱＬ文２４０及びＳＱＬ文２６０に対して、ＨＴＴＰリクエストに含まれるパラメータを代入し、さらに時系列に基づいて単純連結する。なお、ここで動的パラメータ名として指定されているパラメータについては、動的パラメータ名であることを明記するために「ｐａｒａｍ（）」を付与する。以上の処理の結果、ＳＱＬ文２８０が生成される。

具体的には図９を参照すると、ＳＱＬ文２８０の前半部２８１には、ＧＥＴメソッドによって生成されたＳＱＬ文２４０をベースとするＳＱＬ文が記載されており、「＠ＶＡＬＵＥ」のパラメータには、「ＣｏｌｕｍｎＡ」の固定パラメータとして送信された「１」が代入されている。また、後半部２８２には、ＰＵＴメソッドによって生成されたＳＱＬ文２６０をベースとするＳＱＬ文が記載されている。さらに、後半部２８２においては、「＠ＶＡＬＵＥ＿Ａ」のパラメータには、ＪＳＯＮデータ２７０を参照して「２」の固定パラメータが代入される一方、「＠ＶＡＬＵＥ＿Ｂ」や「＠ＶＡＬＵＥ＿Ｘ」等のパラメータには、ＪＳＯＮデータ２７０を参照して、動的パラメータ名を用いた「ｐａｒａｍ（ＧＥＴＡＰＩ＿ＣＯＬＢ）」や「ｐａｒａｍ（ＧＥＴＡＰＩ＿ＣＯＬＸ）」が付与されていることが分かる。

次に、ＳＱＬ処理部１２３は、ＳＱＬ文２８０に対して、ステップＳ２２～Ｓ２５の処理を実行する。具体的には、ＳＱＬ文２８０に存在する「ＳＥＬＥＣＴ ＊」で始まる文は、ロック取得のための文であるから、ＳＱＬ文２８０の最初に移動させる。また、「ＣＯＭＭＩＴ」文は、既にＳＱＬ文２８０の最後のみに存在するため、移動させずにこの位置を維持する。さらに、ＳＱＬ処理部１２３は、ＳＱＬ文２８０の後半部２８２に含まれる「ｐａｒａｍ（）」中の動的パラメータについて、動的パラメータを取得するＳＱＬ文をＳＱＬ文２８０から探し、当該ＳＱＬについて上記動的パラメータのみを取得するように、すなわち、他のパラメータを取得しないように、ＳＱＬ文を編集してｐａｒａｍ（）の箇所を置き換える。以上の処理の結果、ＳＱＬ文２９０が生成される。

そして、ＳＱＬ処理部１２３は、図５のステップＳ１８で説明したように、統合後のＳＱＬ文２９０をＤＢＭＳ１３０に送信してデータ処理を依頼することにより、複数のＡＰＩに跨って、適切にロック及びコミット処理を実行させることができる。

なお、上記の実施例では、単一のテーブル２３０を例にとって説明したが、本実施形態は複数のテーブルに対する処理を含む場合でも同様に実現可能である。例えば、複数のテーブルに対して値の取得や更新を行う場合、各テーブルに対してＧＥＴメソッド及びＰＵＴ、若しくはＰＯＳＴメソッドをそれぞれ準備し、上記説明と同様に処理を実行することにより、複数のテーブルに対しても、正常にロック及びコミットの処理を実行することができる。

また、上記の実施例において、特定のテーブル（例えばテーブルＡ）の値のみを取得して、別のテーブル（例えばテーブルＢ）に値をコピーする場合には、テーブルＡに対するロックが働かない。これに対してテーブルＡに対するロックを確保したい場合には、ＧＥＴメソッドにおいて、値の取得元のテーブルＡのロックを取得しないバージョンのＡＰＩとは別に、値の取得元のテーブルＡに対してロックを取得するバージョンのＡＰＩを準備すればよい。このような複数のバージョンのＡＰＩを提供することで、テーブルＡに対するロックを働かせることも可能であることは、これまでの説明から容易に想像できる。

以上に説明したように、本実施形態に係るサーバシステム１００によれば、ＤＢサーバ装置１２０が単純なＡＰＩを提供し、Ｗｅｂサーバ装置１１０がリクエストＩＤ及び終了フラグを用いて、上記単純なＡＰＩを組み合わせて利用することで、ＤＢサーバ装置１２０側の処理を制御し、ＤＢサーバ装置１２０を介して、ＤＢＭＳ１３０に対して希望する処理を依頼することができる。

すなわち、本実施形態に係るＤＢサーバ装置１２０は、Ｗｅｂサーバ装置１１０に提供する機能を単純化しながらも、Ｗｅｂサーバ装置１１０からＤＢＭＳ１３０に対する比較的複雑な処理（具体的には一連の処理に跨ったロックやコミット等の処理）の依頼に対応することができ、一連の処理の実行時にＤＢＭＳ１３０（データベース）のロック時間を過剰に長期化することなく、必要最低限な時間に抑制することができる。

さらに、本実施形態に係るＤＢサーバ装置１２０は、比較的単純な機能の実装で済む（複雑なＡＰＩを提供可能な機能を実装しなくてよい）ことから、従来のＷｅｂシステムに用いられるＤＢサーバ装置と比べて、ＤＢサーバ装置１２０の実装規模を小さく抑えることができる。

さらに、このようなＤＢサーバ装置１２０によれば、実装する機能を単純化できることで、Ｗｅｂシステム１０を異なる案件に適用する場合に、ＤＢサーバ装置１２０における実装の修正対象を最小化することに期待でき、主にＷｅｂサーバ装置１１０側の修正によってＷｅｂシステム１０の異なる案件への適用を実現することができる。

言い換えれば、本実施形態に係るＤＢサーバ装置１２０によれば、Ｗｅｂシステム１０（あるいはサーバシステム１００）におけるＤＢサーバ装置１２０側の負荷を下げることができ、Ｗｅｂシステム１０による様々なＤＢＭＳ１３０への対応や、異なる案件への適用に際して、主にＷｅｂサーバ装置１１０側で修正を行うことによって対応することが可能となる。

一方、本実施形態に係るサーバシステム１００では、Ｗｅｂサーバ装置１１０は、複数のＡＰＩが含まれる１つのＨＴＴＰリクエストによってＤＢＭＳに対する一連の処理を依頼していた従来のＷｅｂサーバ装置とは異なり、ＤＢサーバ装置１２０から提供される単純なＡＰＩを組み合わせて、ＤＢＭＳ１３０に対する一連の処理をＤＢサーバ装置１２０に依頼できることから、Ｗｅｂシステム１０を異なる案件に適用する場合にＷｅｂサーバ装置１１０側で必要となる修正は、上記の従来のＷｅｂサーバ装置に比べて、修正規模を小さくしたり、修正難易度を低くしたりすることに期待できる。すなわち、サーバシステム１００（あるいはＷｅｂシステム１０）全体における修正規模や修正難易度を抑える効果が得られる。

また、本実施形態に係るサーバシステム１００では、Ｗｅｂサーバ装置１１０が、ＤＢＭＳ１３０に対する詳細処理を制御可能であることから、Ｗｅｂサーバ装置１１０とＤＢサーバ装置１２０との間の処理の仕様の擦り合わせを小さく抑えることができる。

なお、本発明は上記した実施形態及び実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施形態及び実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。例えば、上記実施形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、図面において制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実施には殆ど全ての構成が相互に接続されていると考えてもよい。

１０ Ｗｅｂシステム
２０ Ｗｅｂクライアント
１００ サーバシステム
１１０ Ｗｅｂサーバ装置
１１１ リクエスト作成部
１２０ データベース（ＤＢ）サーバ装置
１２１ リクエスト処理部
１２２ ＳＱＬ作成部
１２３ ＳＱＬ処理部
１３０ データベース管理システム（ＤＢＭＳ）
２１０，２４０，２６０，２８０，２９０ ＳＱＬ文
２２０，２５０，２７０ ＪＳＯＮデータ
２３０ テーブル

Claims (15)

1. データベースシステムに対してデータの操作処理を行うデータベースサーバ装置であって、
   所定の単純なＡＰＩを提供し、
   前記単純なＡＰＩを利用したリクエストをＷｅｂサーバ装置から受信し、前記受信したリクエストに含まれるリクエストデータを解析して処理を振り分けるリクエスト処理部と、
   前記リクエスト処理部によって振り分けられた前記リクエストに基づいて、ＳＱＬ文を生成するＳＱＬ作成部と、
   前記ＳＱＬ作成部によって生成された前記ＳＱＬ文に対して所定の処理を行ってＳＱＬ全体文を作成し、前記作成したＳＱＬ全体文を前記データベースシステムに送信するＳＱＬ処理部と、
   を備え、
   前記リクエスト処理部が、前記Ｗｅｂサーバ装置から一連の処理を要求する前記リクエストとして、分割された複数のリクエストを前記受信した場合に、
   前記ＳＱＬ処理部は、
   前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了するまで、前記複数のリクエストの各リクエストに基づいて前記ＳＱＬ作成部によって生成された前記ＳＱＬ文を一時保存し、
   前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了した後に、前記一時保存した複数の前記ＳＱＬ文を結合及び編集して前記ＳＱＬ全体文を作成するＳＱＬ統合処理を実行する
   ことを特徴とするデータベースサーバ装置。
2. 前記Ｗｅｂサーバ装置から前記受信する前記リクエストに含まれる前記リクエストデータには、前記一連の処理を要求するリクエストごとに同一の値が付与されるリクエストＩＤ、パラメータ名、及び前記一連の処理の最後のリクエストであるか否かを示す終了フラグが含まれ、
   前記ＳＱＬ処理部は、前記ＳＱＬ作成部によって生成された前記ＳＱＬ文に対応する前記リクエストに含まれる前記終了フラグが前記一連の処理の最後のリクエストであることを示す場合に前記ＳＱＬ統合処理を実行し、
   前記ＳＱＬ統合処理には、前記一時保存した前記複数のＳＱＬ文のうち、前記リクエストＩＤの値が同一である前記リクエストに基づいて前記生成された全ての前記ＳＱＬ文を前記ＳＱＬ全体文に結合する結合処理が含まれる
   ことを特徴とする請求項１に記載のデータベースサーバ装置。
3. 前記ＳＱＬ統合処理には、前記ＳＱＬ文と前記リクエストに含まれる前記パラメータ名との対応関係を判断し、前記判断した結果に基づいて、それぞれの前記ＳＱＬ文または前記結合した前記ＳＱＬ全体文を編集する編集処理が含まれる
   ことを特徴とする請求項２に記載のデータベースサーバ装置。
4. 前記ＳＱＬ処理部は、前記ＳＱＬ統合処理の前記結合処理において、前記ＳＱＬ全体文への結合の対象となる前記全てのＳＱＬ文を時系列に基づいて連結する
   ことを特徴とする請求項２に記載のデータベースサーバ装置。
5. 前記ＳＱＬ処理部は、前記ＳＱＬ統合処理の前記編集処理において、前記結合処理が行われた後の前記ＳＱＬ全体文のなかで、特定の処理に関するＳＱＬ文の順序を所定の規則に従って整列する
   ことを特徴とする請求項３に記載のデータベースサーバ装置。
6. 前記ＳＱＬ処理部は、前記ＳＱＬ統合処理の前記編集処理において、前記結合処理が行われた後の前記ＳＱＬ全体文のなかで、ロック処理に関するＳＱＬ文を最初に移動させ、コミット処理に関するＳＱＬ文を最後に移動させる
   ことを特徴とする請求項５に記載のデータベースサーバ装置。
7. 前記ＳＱＬ処理部は、前記ＳＱＬ統合処理の前記編集処理において、前記ＳＱＬ文と前記パラメータ名との対応関係の判断結果に基づいて、前記ＳＱＬ文の固定パラメータにはパラメータ値を代入するとともに、動的パラメータを用いる前記ＳＱＬ文に対しては、当該動的パラメータのみを取得するように前記ＳＱＬ文または前記ＳＱＬ全体文を編集する
   ことを特徴とする請求項３に記載のデータベースサーバ装置。
8. 前記リクエスト処理部が、前記Ｗｅｂサーバ装置から一連の処理を要求する前記リクエストとして、前記分割された複数のリクエストを前記受信した場合に、
   前記ＳＱＬ処理部は、前記ＳＱＬ統合処理によって前記ＳＱＬ全体文を作成するまでの間、前記データベースシステムに保存されているデータを変更する前記操作処理を行わない
   ことを特徴とする請求項１に記載のデータベースサーバ装置。
9. 前記データベースサーバ装置は、前記データベースシステムに保存される１つのデータグループに対して、更新、保存、または取得のうちの１処理を行うＡＰＩを、前記単純なＡＰＩとして提供する
   ことを特徴とする請求項１に記載のデータベースサーバ装置。
10. データベースシステムに対してデータの操作処理を行うサーバシステムであって、
    所定の単純なＡＰＩを提供するデータベースサーバ装置と、
    Ｗｅｂクライアントからの要求に応じて、前記データベースシステムに対するデータの操作処理の実行を前記データベースサーバ装置に依頼するＷｅｂサーバ装置と、
    を備え、
    前記Ｗｅｂサーバ装置は、
    前記データベースサーバ装置が提供する前記単純なＡＰＩを利用したリクエストを作成し、前記データベースサーバ装置に送信するリクエスト作成部を有し、
    前記データベースサーバ装置は、
    前Ｗｅｂサーバ装置から前記リクエストを受信し、前記受信したリクエストに含まれるリクエストデータを解析して処理を振り分けるリクエスト処理部と、
    前記リクエスト処理部によって振り分けられた前記リクエストに基づいて、ＳＱＬ文を生成するＳＱＬ作成部と、
    前記ＳＱＬ作成部によって生成された前記ＳＱＬ文に対して所定の処理を行ってＳＱＬ全体文を作成し、前記作成したＳＱＬ全体文を前記データベースシステムに送信するＳＱＬ処理部と、を有し、
    前記Ｗｅｂクライアントから一連の処理の実行が要求された場合に、
    前記リクエスト作成部は、前記一連の処理に対応するリクエストを、前記単純なＡＰＩを用いて複数のリクエストに分割して作成して送信し、
    前記ＳＱＬ処理部は、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了するまで、前記複数のリクエストの各リクエストに基づいて前記ＳＱＬ作成部によって生成された前記ＳＱＬ文を一時保存し、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成部による前記ＳＱＬ文の生成が終了した後に、前記一時保存した複数の前記ＳＱＬ文を結合及び編集して前記ＳＱＬ全体文を作成するＳＱＬ統合処理を実行する
    することを特徴とするサーバシステム。
11. 前記リクエスト作成部は、前記リクエストを作成する際に、当該リクエストに含める前記リクエストデータに、前記一連の処理を要求するリクエストごとに同一の値が付与されるリクエストＩＤ、パラメータ名、及び前記一連の処理の最後のリクエストであるか否かを示す終了フラグを含め、
    前記ＳＱＬ処理部は、前記ＳＱＬ作成部によって生成された前記ＳＱＬ文に対応する前記リクエストに含まれる前記終了フラグが前記一連の処理の最後のリクエストであることを示す場合に前記ＳＱＬ統合処理を実行し、
    前記ＳＱＬ統合処理には、前記一時保存した前記複数のＳＱＬ文のうち、前記リクエストＩＤの値が同一である前記リクエストに基づいて前記生成された全ての前記ＳＱＬ文を前記ＳＱＬ全体文に結合する結合処理が含まれる
    ことを特徴とする請求項１０に記載のサーバシステム。
12. 前記ＳＱＬ統合処理には、前記ＳＱＬ文と前記リクエストに含まれる前記パラメータ名との対応関係を判断し、前記判断した結果に基づいて、それぞれの前記ＳＱＬ文または前記結合した前記ＳＱＬ全体文を編集する編集処理が含まれる
    ことを特徴とする請求項１１に記載のサーバシステム。
13. 前記ＳＱＬ処理部は、前記ＳＱＬ統合処理の前記編集処理において、前記結合処理が行われた後の前記ＳＱＬ全体文のなかで、特定の処理に関するＳＱＬ文の順序を所定の規則に従って整列する
    ことを特徴とする請求項１２に記載のサーバシステム。
14. データベースシステムに対してデータの操作処理を行うサーバシステムによるリクエスト処理方法であって、
    前記サーバシステムは、所定の単純なＡＰＩを提供するデータベースサーバ装置と、Ｗｅｂクライアントからの要求に応じて、前記データベースシステムに対するデータの操作処理の実行を前記データベースサーバ装置に依頼するＷｅｂサーバ装置と、を有し、
    前記Ｗｅｂサーバ装置が、前記データベースサーバ装置が提供する前記単純なＡＰＩを利用したリクエストを作成し、前記データベースサーバ装置に送信するリクエスト作成ステップと、
    前記データベースサーバ装置が、前記リクエスト作成ステップで送信された前記リクエストを受信し、前記受信したリクエストに含まれるリクエストデータを解析して処理を振り分けるリクエスト処理ステップと、
    前記データベースサーバ装置が、前記リクエスト処理ステップで振り分けられた前記リクエストに基づいて、ＳＱＬ文を生成するＳＱＬ作成ステップと、
    前記データベースサーバ装置が、前記ＳＱＬ作成ステップで生成された前記ＳＱＬ文に対して所定の処理を行ってＳＱＬ全体文を作成し、前記作成したＳＱＬ全体文を前記データベースシステムに送信するＳＱＬ処理ステップと、
    を備え、
    前記Ｗｅｂクライアントから一連の処理の実行が要求された場合に、
    前記リクエスト作成ステップにおいて、前記一連の処理に対応するリクエストを、前記単純なＡＰＩを用いて複数のリクエストに分割して作成して送信し、
    前記ＳＱＬ処理ステップにおいて、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成ステップによる前記ＳＱＬ文の生成が終了するまで、前記複数のリクエストの各リクエストに基づいて前記ＳＱＬ作成ステップで生成された前記ＳＱＬ文を一時保存し、前記分割された複数のリクエストの全てに対して前記ＳＱＬ作成ステップによる前記ＳＱＬ文の生成が終了した後に、前記一時保存した複数の前記ＳＱＬ文を結合及び編集して前記ＳＱＬ全体文を作成するＳＱＬ統合処理を実行する
    することを特徴とするリクエスト処理方法。
15. 前記リクエスト作成ステップにおいて前記リクエストを作成する際、前記Ｗｅｂサーバ装置は、当該リクエストに含める前記リクエストデータに、前記一連の処理を要求するリクエストごとに同一の値が付与されるリクエストＩＤ、パラメータ名、及び前記一連の処理の最後のリクエストであるか否かを示す終了フラグを含め、
    前記ＳＱＬ処理ステップにおいて、前記データベースサーバ装置は、前記ＳＱＬ作成ステップで生成された前記ＳＱＬ文に対応する前記リクエストに含まれる前記終了フラグが前記一連の処理の最後のリクエストであることを示す場合に前記ＳＱＬ統合処理を実行し、
    前記ＳＱＬ統合処理には、前記一時保存した前記複数のＳＱＬ文のうち、前記リクエストＩＤの値が同一である前記リクエストに基づいて前記生成された全ての前記ＳＱＬ文を前記ＳＱＬ全体文に結合する結合処理が含まれる
    ことを特徴とする請求項１４に記載のリクエスト処理方法。
    

Images