JP5200721B2

JP5200721B2 - 制御方法、制御装置、及びプログラム

Info

Publication number: JP5200721B2
Application number: JP2008185108A
Authority: JP
Inventors: 登車井; 武男安川
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2008-07-16
Filing date: 2008-07-16
Publication date: 2013-06-05
Anticipated expiration: 2028-07-16
Also published as: US20100017415A1; GB2461803A; GB0912172D0; GB2461803B; JP2010026653A

Description

本発明は、制御方法、制御装置、及びプログラムに関し、データベースに対する制御方法、制御装置、及びプログラムに関する。

従来、ＡＳＰ（Application Service Provider）と等において提供されるＷｅｂアプリケーションについては、利用者に応じたニーズに対応するため、Ｗｅｂサーバ側において、一つのアプリケーションを利用者ごとにカスタマイズし、それぞれを別個に管理及び動作させる必要があった。なお、ここでいう利用者とは、企業、団体、官公庁等、ＡＳＰの提供者とサービスの利用契約を結んでいる組織をいう。

一方、昨今注目されているＳａａＳ（Software as a Service）と呼ばれるシステム形態では、同一のＷｅｂアプリケーションを同一のサーバ上で動かし、複数の利用者に同一のＷｅｂアプリケーションを利用させることで、運用コストの削減を図っている。
特開２００４−３１０３５６号公報

しかしながら、例えば、データベースを利用した情報管理系のＷｅｂアプリケーションがＳａａＳの形態によって提供される場合、データベースによって管理される情報は、セキュリティ上の観点等より利用者ごとに適切に区分されて管理されることが望ましい。具体的には、利用者ごとに異なるデータ領域が用意されることが望ましい。

但し、データベースを利用するＷｅｂアプリケーションは各種存在する。したがって、利用者に応じたデータ領域を判定し、当該データ領域にアクセスするためのロジックをＷｅｂアプリケーションごとに実装するのは開発作業の煩雑化、開発コストの増大等を招くという問題があった。

本発明は、上記の点に鑑みてなされたものであって、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることのできる制御方法、制御装置、及びプログラムの提供を目的とする。

そこで上記課題を解決するため、制御方法は、受信する処理要求に関連付けられたユーザ識別情報を取得する取得手順と、受信した前記処理要求に応じ、アプリケーションからデータベースへのアクセス要求を受信したときに、該アクセス要求、および、取得された前記ユーザ識別情報に応じて、前記データベースにおける複数のデータ領域であって、取得された前記ユーザ識別情報に対応するデータ領域に対するアクセスを要求する命令を生成し、該命令を前記データベースに出力するアクセス手順と、をコンピュータが実行し、前記アクセス要求は、アクセス対象のデータ領域を特定する情報を含まないことを特徴とする。

このような制御方法では、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることができる。

本発明によれば、利用者ごとに異なるデータ領域を有するデータベースにアクセスするアプリケーションの開発を簡便化させることのできる制御方法、制御装置、及びプログラムを提供することができる。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。

同図において、Ｗｅｂサーバ１０及びＤＢ（Data Base）サーバ２０は、例えば、ＳａａＳ（Software as a Service）と呼ばれる形態によってインターネットを介してアプリケーションソフトウェア（以下、説明の便宜上単に「アプリケーション」という。）の機能によるサービスをテナント（後述する）に提供するサービス提供者側に属するコンピュータである。また、クライアント装置３０ａ、３０ｂ、及び３０ｃ等（以下、総称する場合「クライアント装置３０」という。）は、サービス利用者側に属するコンピュータである。クライアント装置３０ａ、クライアント装置３０ｂ、クライアント装置３０ｃは、それぞれテナントＡ、テナントＢ、テナントＣに属する。本実施の形態においてテナントとは、サービス提供者との間でサービスの利用契約を結んだ企業又は団体等の組織をいう。したがって、テナントは一人以上のユーザの集合であるといえる。

ＤＢサーバ２０は、ＤＢＭＳ（DataBase Management System）２１及び業務ＤＢ２２等を有する。

業務ＤＢ２２は、業務アプリケーション１３によって管理対象とされる情報を体系的に管理するデータベースである。同図において、業務ＤＢ２２は、テーブルＡ２２１ａ、テーブルＢ２２１ｂ、及びテーブルＣ２２１ｃ（以下、総称する場合「テーブル２２１」という。）を含む。テーブルＡ２２１ａはテナントＡに対応するテーブル（データ管理領域）である。テーブルＢ２２１ｂはテナントＢに対応するテーブルである。テーブルＣ２２１ｃはテナントＣに対応するテーブルである。このように、業務ＤＢ２２においては、テナント毎にデータ領域が明確に区別されている。

例えば、図２は、業務ＤＢにおけるテーブルの構成例を示す図である。同図では、便宜上、テーブルＡ２２１ａ及びテーブルＢ２２１ｂの構成例が示されている。同図では、各テーブルのスキーマ（構造）は同じ例が示されている。すなわち、テーブルＡ２２１ａ及びテーブルＢ２２１ｂのいずれのレコードも項目Ａ及び項目Ｂより構成される。但し、各テーブル２２１のスキーマは必ずしも同一でなくてもよい。

ＤＢＭＳ２１は、いわゆるＤＢＭＳ（データベース管理部）であり、例えば、ＳＱＬ（Structured Query Language）文の入力に応じ、当該ＳＱＬ文に従った処理を業務ＤＢ２２に対して行う。

Ｗｅｂサーバ１０は、データアクセス制御装置の一例であり、ＨＴＴＰ（HyperText Transfer Protocol）サーバ１１、アプリケーションサーバ１２、業務アプリケーション１３、及びマルチテナント制御部１４等のソフトウェアを有する。

ＨＴＴＰサーバ１１は、クライアント装置３０との通信を制御する。例えば、ＨＴＴＰサーバ１１は、クライアント装置３０からの要求（ＨＴＴＰリクエスト）を受信し、当該要求に対する応答（ＨＴＴＰレスポンス）を返信する。

アプリケーションサーバ１２は、クライアント装置３０からの要求に応じた（ＵＲＬ（Uniform Resource Locator）に対応した）業務アプリケーション１３を起動させる（呼び出す）。

業務アプリケーション１３は、いわゆるＷｅｂアプリケーションであり、機能に応じて複数存在する。本実施の形態において、各業務アプリケーション１３は、ＤＢサーバ２０を利用した情報管理機能を提供する。また、各業務アプリケーション１３は、それぞれ複数のテナントより共通的に利用される。

マルチテナント制御部１４は、各テナントに属するクライアント装置３０からの要求に応じ、業務ＤＢ２２内のテーブル２２１のうちいずれをアクセス先とするかを制御する。マルチテナント制御部１４は、斯かる制御の仕組みを各業務アプリケーション１３に対して共通に提供する。換言すれば、各業務アプリケーション１３は、マルチテナント制御部１４によって提供される仕組みによって、テナントとテーブル２２１との対応関係を意識する必要はない。

マルチテナント制御部１４は、テナント判定部１４１、データベースアクセス部１４２、及びセッションスコープアクセスＡＰＩ（Application Program Interface）１４３等を含む。テナント判定部１４１は、ＨＴＴＰサーバ１１によって受信されるＨＴＴＰリクエストに含まれている情報に基づいて当該ＨＴＴＰリクエストの送信元のクライアント装置３０（ユーザ）が属するテナントを判定する。データベースアクセス部１４２は、業務アプリケーション１３に対してＤＢＭＳ２１へのアクセス用のインタフェース（関数又はメソッド）を提供する。データベースアクセス部１４２は、当該インタフェースを介したＤＢＭＳ２１へのアクセス要求に応じ当該アクセス要求に対応するＳＱＬ文を生成し、ＤＢサーバ２０に送信する。この際、データベースアクセス部１４は、テナント判定部１４１によって判定されたテナントに対応するテーブル２２１をアクセス対象とする。セッションスコープアクセスＡＰＩ１４３は、セッションスコープ１５に対するアクセス手段を提供する関数群である。本実施の形態において「セッションスコープ」とは、クライアント装置３０とのセッション（又はセッション情報）を管理するためにメモリ装置１０３内に生成されるデータをいい、例えば、一般的にセッションオブジェクトと呼ばれる。例えば、テナント判定部１４１は、セッションスコープアクセスＡＰＩ１４３を利用して、判定結果としてのテナントの識別情報（以下、「テナントＩＤ」という。）をセッションスコープ１５に記録（登録）する。なお、テナントＩＤは、テナントごとに一意となるように割り当てられている。また、データベースアクセス部１４２は、セッションスコープ１５に登録されているテナントＩＤをセッションスコープアクセスＡＰＩ１４３を利用して取得する。

なお、Ｗｅｂサーバ１０とＤＢサーバ２０とは、ＬＡＮ（Local Area Network）又はインターネット等のネットワーク（有線又は無線の別は問わない。）を介して接続されている。また、クライアント装置３０とＷｅｂサーバ１０とはインターネット等を介して接続されている。

図３は、本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。図３のＷｅｂサーバ１０は、それぞれバスBで相互に接続されているドライブ装置１００と、補助記憶装置１０２と、メモリ装置１０３と、ＣＰＵ１０４と、インタフェース装置１０５とを有する。

Ｗｅｂサーバ１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等のコンピュータ読み取り可能な記録媒体１０１によって提供される。プログラムを記録した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２から読み出されたプログラムが格納される。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってＷｅｂサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

以下、Ｗｅｂサーバ１０の処理手順について説明する。図４は、Ｗｅｂサーバによる処理手順を説明するためのフローチャートである。

ＨＴＴＰサーバ１１によるクライアント装置３０からのＨＴＴＰリクエストの受信に応じ（Ｓ１０１）、テナント判定部１４１は、当該クライアント装置３０とのセッションに対応するセッションスコープ１５にテナントＩＤが登録されているか否かを判定する（Ｓ１０２）。

なお、各セッションはセッションＩＤによって識別される。セッションＩＤは、セッションの開設時にアプリケーションサーバ１２によって割り当てられ、クライアント装置３０に送信される。クライアント装置３０は、セッションＩＤをＣｏｏｋｉｅ等に保持しておき、ＨＴＴＰリクエストの度にＷｅｂサーバ１０に対して送信する。また、セッションスコープ１５は、セッションの開設時にセッションＩＤと共にアプリケーションサーバ１２によって生成され、セッションＩＤに関連付けられて管理されている。したがって、テナント判定部１４１は、セッションＩＤに基づいて現在のセッションに対応するセッションスコープ１５を取得することができる。

ところで、本実施の形態においてセッションスコープ１５にテナントＩＤが登録されていないという状態は、受信されたＨＴＴＰリクエストがログイン要求である場合に相当する。ログイン要求には、クライアント装置１０のＷｅｂブラウザに表示されているログイン画面に対して入力されたユーザＩＤ（各ユーザを識別するＩＤ）及びパスワードが含まれている。そこで、この場合（Ｓ１０２でＮｏ）、テナント判定部１４１は、テナントＩＤ管理テーブルに基づいて、ＨＴＴＰリクエスト（ログイン要求）に含まれているユーザＩＤに対応するテナントＩＤを判定する（Ｓ１０３）。

図５は、テナントＩＤ管理テーブルの構成例を示す図である。同図に示されるように、テナントＩＤ管理テーブル１６には、ユーザＩＤとテナントＩＤとの対応情報が登録されている。例えば、ログイン要求に含まれているユーザＩＤが「ｕｓｅｒ０１」であった場合、テナント判定部１４１は、対応するテナントＩＤは「ＡＡＡ」であると判定する。

続いて、テナント判定部１４１は、判定結果としてのテナントＩＤをセッションスコープ１５に登録する（Ｓ１０４）。

一方、セッションスコープにテナントＩＤが既に登録されている場合（すなわち、ＨＴＴＰリクエストがログイン要求以外の業務ロジックの実行要求の場合）（Ｓ１０２でＹｅｓ）、ステップＳ１０３及びＳ１０４の処理は行われない。

続いて、アプリケーションサーバ１２は、ＨＴＴＰリクエストの内容（例えば、ＨＴＴＰリクエストに含まれるＵＲＬ等）に応じた業務アプリケーション１３を判定し、当該業務アプリケーション１３を呼び出す（又は起動する）（Ｓ１０５）。ＨＴＴＰリクエストの内容に応じた業務アプリケーション１３の判定は、例えば、補助記憶装置１０２に記録されている、ＵＲＬと業務アプリケーション１３との対応情報等に基づいて行えばよい。

続いて、呼び出された業務アプリケーション１３は、自らに実装されている業務ロジックを実行する（Ｓ１０６）。業務アプリケーション１３は、業務ロジックを実行する過程において業務ＤＢ２２に対するアクセス（データの検索、登録、更新、又は削除等の操作）をデータベースアクセス部１４２に要求する（Ｓ１０７）。この際、業務アプリケーション１３は、いずれのテナントに対するテーブルをアクセス対象とするかについては関与しない。例えば、図１又は図２に示されるように、テナントごとに一つのテーブル２２１が存在する場合は、業務アプリケーション１３はアクセス対象とするテーブル名は指定しない。また、テナントごとに複数のテーブル２２１が存在する場合（例えば、テナントごとに商品情報テーブル及び顧客情報テーブル等が有る場合）、業務アプリケーション１３は、アクセス対象が商品情報テーブルか顧客情報テーブルかを指定するのみで、いずれのテナントのテーブル２２１であるかは指定しない。

続いて、データベースアクセス部１４２は、セッションスコープ１５よりテナントＩＤを取得する（Ｓ１０８）。ここで、テナント判定部１４１及びデータベースアクセス部１４２は同一スレッド内において動作する。したがって、データベースアクセス部１４２は、テナント判定部１４１によって当該スレッド空間内に取得されたセッションスコープ１５を参照すればよい。

続いて、データベースアクセス部１４２は、取得されたテナントＩＤに対応するテーブル２２１に基づいてアクセス対象とするテーブル２２１を判定する。データベースアクセス部１４２は、アクセス対象とされたテーブル２２１に対して業務アプリケーション１３より要求されたアクセスを実行するためのＳＱＬ文を生成し、当該ＳＱＬ文をＤＢＭＳ２１に送信する（Ｓ１０９）。なお、テナントＩＤに基づくアクセス対象とするテーブル２２１の判定は、補助記憶装置１０２に保存されている各テナントＩＤと各テーブル２２１のテーブル名との対応情報に基づいて行えばよい。また、各テーブル名が各テナントＩＤと一致する場合、テナントＩＤをそのままＳＱＬ文におけるテーブル名として判定すればよい。

当該ＳＱＬ文に応じてＤＢＭＳ２１は、業務ＤＢ２２に対するアクセス（操作）を行う。したがって、ＨＴＴＰリクエストの送信元のテナントに対応するテーブル２２１に対してアクセスが行われる。

続いて、データベースアクセス部１４２は、業務ＤＢ２２へのアクセス結果（例えば、検索結果等）をＤＢＭＳ２１より受信すると、当該アクセス結果を業務アプリケーション１３に通知する（Ｓ１１０）。続いて、業務アプリケーション１３は、当該アクセス結果を利用して業務ロジックの続きを実行し、当該業務ロジックの結果を表示させるＨＴＭＬ（HyperText Markup Language）データを生成する（Ｓ１１１）。続いて、ＨＴＴＰサーバ１１は、業務アプリケーション１３によって生成されたＨＴＭＬデータをＨＴＴＰレスポンスに含めてクライアント装置３０に送信する（Ｓ１１２）。

上述したように、本実施の形態におけるＷｅｂサーバ１０によれば、マルチテナント制御部１４が、ＨＴＴＰリクエストの要求元のテナントＩＤの判定及び当該テナントＩＤに対応するテーブル２２１の判定を行う。したがって、複数のテナントから共通的に利用される各業務アプリケーション１３にはこれらの判定を行うためのロジックを実装する必要はない。よって、各業務アプリケーション１３の開発作業を簡便化させることができる。

なお、上記においては、ユーザＩＤに対応するテナントＩＤの判定をテナント判定部１４１が行う例を説明したが、当該判定をデータベースアクセス部１４２が行うようにしてもよい。この場合、テナント判定部１４１はユーザＩＤをセッションスコープ１５に登録しておけばよい。データベースアクセス部１４２は、セッションスコープ１５に登録されているユーザＩＤとテナントＩＤ管理テーブル１６とに基づいてテナントＩＤを判定すればよい。

また、テナント管理テーブル１６においてテナントＩＤと対応付ける情報は、ユーザＩＤでなくてもよい。クライアント装置３０ごとの任意の識別情報であってもよい。

更に、ログイン時において、ユーザＩＤ及びパスワードが指定されるのではなく、テナントＩＤ及びパスワードが指定される場合（すなわち、同一のテナントに属するユーザは、同一のテナントＩＤによってログインする場合）、テナント管理テーブル１６は必要ではない。

ところで、テナント間に親子関係（従属関係）が存在する場合がある。例えば、各テナントが企業である場合、親会社に対応するテナントと、当該親会社の複数の子会社に対応する複数のテナントが存在しうる。また、テナントが一つの企業内の組織である場合、事業部に対応するテナントと、当該事業部に属する複数の部に対応する複数のテナントが存在しうる。このようにテナント間に親子関係が存在する場合において、親テナントが複数の子テナントのテーブル２２１にまとめてアクセスすることができると便利である。

斯かる機能を実現する場合、図４のステップＳ１０９を次のように変更すればよい。図６は、テナント間に親子関係が存在する場合のデータベースアクセス部による業務ＤＢへのアクセス処理を説明するための図である。

ステップＳ１０９１において、セッションスコープ１５より取得されたテナントＩＤに係るテナントに子テナントが存在するか否かを判定する。当該判定は、補助記憶装置１０２に記録されている親子関係管理テーブルに基づいて行えばよい。

図７は、親子関係管理テーブルの構成例を示す図である。同図において親子関係管理テーブル１７には、子テナントを有するテナントのテナントＩＤ（親テナントＩＤ）ごとに、子テナントのテナントＩＤ（親テナントＩＤに従属するテナントＩＤ）の一覧が登録されている。

したがって、ステップＳ１０９１において、セッションスコープ１５より取得されたテナントＩＤが親テナントＩＤとして親子関係管理テーブル１７に登録されている場合、子テナントは存在すると判定する。また、セッションスコープ１５より取得されたテナントＩＤが親テナントＩＤとして親子関係管理テーブル１７に登録されていない場合、子テナントは存在しないと判定する。

子テナントが存在すると判定した場合、親子関係管理テーブル１７に登録されている各子テナントＩＤに対応する各テーブル２２１に対して、図４のステップＳ１０９と同じ処理を実行する（Ｓ１０９２）。

子テナントが存在しないと判定した場合、セッションスコープ１５より取得されたテナントＩＤに対応するテーブル２２１に対して、ステップＳ１０９と同じ処理を実行する（Ｓ１０９３）。

なお、子テナントが複数存在した場合、アクセス要求が検索であるときは各子テナントに対応するそれぞれのテーブル２２１に対して検索が実行され、その検索結果が取得される。この場合、データベースアクセス部１４２は、当該検索結果をそのまま業務アプリ２２１に出力してもよいし、検索結果の内容をマージ（統合）した結果を業務アプリ２２１に出力してもよい。

検索結果の内容をマージする例としては、例えば、親会社（又は事業部）が子会社（又は部）の売り上げ等の合計値を親テナントに提供する場合等に便利である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態におけるシステム構成例を示す図である。業務ＤＢにおけるテーブルの構成例を示す図である。本発明の実施の形態におけるＷｅｂサーバのハードウェア構成例を示す図である。Ｗｅｂサーバによる処理手順を説明するためのフローチャートである。テナントＩＤ管理テーブルの構成例を示す図である。テナント間に親子関係が存在する場合のデータベースアクセス部による業務ＤＢへのアクセス処理を説明するための図である。親子関係管理テーブルの構成例を示す図である。

符号の説明

１０Ｗｅｂサーバ
１１ＨＴＴＰサーバ
１２アプリケーションサーバ
１３業務アプリケーション
１４マルチテナント制御部
１５セッションスコープ
２０ＤＢサーバ
２１ＤＢＭＳ
２２業務ＤＢ
１００ドライブ装置
１０１記録媒体
１０２補助記憶装置
１０３メモリ装置
１０４ＣＰＵ
１０５インタフェース装置
１４１テナント判定部
１４２データベースアクセス部
１４３セッションスコープアクセスＡＰＩ
Ｂバス

Claims

受信した処理要求に関連付けられたユーザ識別情報を取得する取得手順と、
受信した前記処理要求に応じ、アプリケーションからデータベースへのアクセス要求を受信したときに、該アクセス要求、および、取得された前記ユーザ識別情報に応じて、前記データベースにおける複数のデータ領域であって、取得された前記ユーザ識別情報に対応するデータ領域に対するアクセスを要求する命令を生成し、該命令を前記データベースに出力するアクセス手順と、をコンピュータが実行し、
前記アクセス要求は、アクセス対象のデータ領域を特定する情報を含まない、
ことを特徴とする制御方法。
前記アクセス手順は、ユーザ識別情報と、ユーザが属するグループを識別するグループ識別情報とを対応付けて記憶した識別情報記憶手段から、取得した前記ユーザ識別情報と対応付けて記憶されたグループ識別情報を参照し、該グループ識別情報に対応するデータ領域に対するアクセスを要求する命令を生成する、
ことを特徴とする請求項１記載の制御方法。
前記アクセス手順は、グループの従属関係を特定する情報を記憶する関係記憶手段から、参照された前記グループ識別情報で識別されるグループに従属する子グループのグループ識別情報を参照し、前記子グループ識別情報に対応するデータ領域に対する命令を生成して、前記データベースに送信し、該命令に対する応答結果をマージして前記アプリケーションに出力する請求項２記載の制御方法。
受信した処理要求に関連付けられたユーザ識別情報を取得する取得手段と、
受信した前記処理要求に応じ、アプリケーションからデータベースへのアクセス要求を受信したときに、該アクセス要求、および、取得された前記ユーザ識別情報に応じて、前記データベースにおける複数のデータ領域であって、取得された前記ユーザ識別情報に対応するデータ領域に対するアクセスを要求する命令を生成し、該命令を前記データベースに出力するアクセス手段と、を備え、
前記アクセス要求は、アクセス対象のデータ領域を特定する情報を含まない、
ことを特徴とする制御装置。
受信した処理要求に関連付けられたユーザ識別情報を取得する取得手順と、
受信した前記処理要求に応じ、アプリケーションからデータベースへのアクセス要求を受信したときに、該アクセス要求、および、取得された前記ユーザ識別情報に応じて、前記データベースにおける複数のデータ領域であって、取得された前記ユーザ識別情報に対応するデータ領域に対するアクセスを要求する命令を生成し、該命令を前記データベースに出力するアクセス手順と、をコンピュータに実行させ、
前記アクセス要求は、アクセス対象のデータ領域を特定する情報を含まない、
ことを特徴とするプログラム。