JPWO2011118003A1 - ウェブアプリケーション構築システム、ウェブアプリケーション構築方法、ウェブアプリケーション構築プログラムおよびウェブアプリケーション構築プログラムを記録した記録媒体 - Google Patents

Abstract

ウェブアプリケーション構築システムの一実施形態は、各種データを記憶するデータベースの管理を行うデータベース部（１３）と、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をサービス（１２ｓ）として提供するサ−ビス提供部（１２）と、このサ−ビス提供部（１２）で提供される１つ以上のサービス（１２ｓ）を組み合わせて利用者毎のビジネスロジックをプロセス（１２ｐ）として作成するプロセス作成部（１２）と、このプロセス作成部（１２）で作成されたプロセス（１２ｐ）に応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築部（１２）とを備え、プロセス作成部（１２）で作成されたプロセス（１２ｐ）とそのプロセス（１２ｐ）に組み合わされているサービス（１２ｓ）が１つの仮想マシン上で動作し、それらのトランザクション制御がデータベース部（１３）によって行われる。

Description

本発明は、いわゆるマルチテナント型ウェブアプリケーションを構築する際に、テナント毎の要件に対応したビジネスロジック構築についての柔軟性を向上させるとともにウェブアプリケーション画面のカスタマイズ容易性をも向上させるウェブアプリケーション構築システム、ウェブアプリケーション構築方法、ウェブアプリケーション構築プログラムおよびウェブアプリケーション構築プログラムを記録した記録媒体に関する。

従来、企業業務におけるデータエントリシステム、ワークフローシステムなどのビジネスアプリケーションでは、データベースサーバの管理するデータをクライアントからアプリケーションサーバを介して操作するという方式がとられてきた。近年、このようなビジネスアプリケーションはＷｅｂアプリケーションとして実現されるようになった。

このようなＷｅｂアプリケーションを実行するアプリケーションサーバを開発する際にデータ、ロジック、画面の各モジュールに分けて記述するフレームワークを提供することにより、Ｗｅｂアプリケーションの開発効率と保守性を向上するための技術が提案されている（例えば、特許文献１参照）。

さらに、複数の利用者によって同一のアプリケーションおよびハードウェア環境が共有されるとともに、データベースやウェブページなどの設定を利用者毎にカスタマイズすることが可能なマルチテナント型アプリケーションも提供されるようになってきた。

このようなマルチテナント型アプリケーションでは、利用者毎に専用の環境を構築する必要がないことから、アプリケーションの迅速な導入と、ＴＯＣ（Ｔｏｔａｌ Ｃｏｓｔ ｏｆ Ｏｗｎｅｒｓｈｉｐ）の削減が可能である。また、複数の利用者で同一の環境を利用することで、バージョンアップなどのメンテナンス時の対応が共通化されるため、アプリケーションのメンテナンスを容易に実行することが可能である。

なお、このようなマルチテナント型アプリケーションでは、複数の全ての利用者に対して、同一バージョンのアプリケーションを提供することになるが、利用者毎に微妙に異なる仕様要求を満たすために、利用者の仕様要求に応じて、利用者自身がアプリケーションのカスタマイズや機能の新規追加を行う機能（即ち、利用者カスタマイズ機能）を持たせることが一般的となっている。

しかし、利用者による様々な種類のアプリケーションのカスタマイズや追加が行われた際に、例えば、それらの変更を理解するための仕組みを全てアプリケーション側で保持する必要があり、アプリケーション自体が大きく複雑になってしまうという問題点があった。

そこで、マルチテナント型アプリケーションのカスタマイズ機能に拡張性を持たせると共にメンテナンス時の対応が容易なアプリケーションプログラムの提供システムを提供する技術も提案されている（例えば、特許文献２参照）。

さらに、Ｗｅｂアプリケーションにおける業務アプリケーションの開発に関し、特に、ビジネスロジック構築における柔軟性とカスタマイズの容易性を担保したマルチテナント型アプリケーションについての技術は他にも提案されている（例えば、特許文献３〜５参照）。

特開２００８−１１２４６０号公報 特開２００９−２８２７７７号公報 特表２００７−５３１９４１号公報 特開２００９−１４５９７２号公報 特開２００３−２８０８９８号公報

しかしながら、上述したようなマルチテナント形式のサービス提供をＷｅｂアプリケーションで構築する場合、テナント毎の要件に対応したビジネスロジック構築について柔軟性に欠けている。具体的には、次のような問題点が挙げられる。

・ビジネスロジックの組み合わせ
・ビジネスロジックの順序入れ替え
・ビジネスロジックの追加
・ビジネスロジック組み合わせの条件分岐
・ビジネスロジック内へのテナント判定の混入
テナント毎の要件を満たすために、これらを個々に実装することでＷｅｂアプリケーションの肥大化と複雑化を招いていた。

ＳａａＳ基盤やＢＰＭＳｅｒｖｅｒでは、Ｗｅｂサービスを組み合わせてビジネスロジックを構成できる。しかし、個々のサービスが分離独立しておりサービス間は疎結合である。このことにより、組み合わせによる複数ロジック実行時のトランザクションがサービス毎に分離される。トランザクションを連携する規格（Ｗｅｂサービス・トランザクション）はあるが、あまり利用されていない状況であり、エラー処理などに複雑な実装を織り込まなければならない。

さらに、Ｗｅｂサービスでビジネスロジックを組み合わせると、個々のサービスがネットワークを経由するため、軽快なレスポンスを得にくい。

一方、上述したようなマルチテナント形式でのＷｅｂアプリケーション画面を構築する場合、入力項目の設定や項目タイトルなどはテナント毎に全く同一ではなく、多少の相違点があることが多い。具体的には、例えば次のようなものが挙げられる。

・名称が「部署」か「部所」の違い
・数量の上限値違い
・文字列長の制限
・専用項目の用意
・必須入力の指定の有無
また、これらの入力項目とデータベースのテーブル・カラム構成とが密接に連携していることが多く、テナント毎に用意せざるを得なかった。

本発明の第１の目的は、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できるウェブアプリケーション構築システム、ウェブアプリケーション構築方法、ウェブアプリケーション構築プログラムおよびウェブアプリケーション構築プログラムを記録した記録媒体を提供することである。

本発明の第２の目的は、テナント毎に入力項目の設定や項目タイトルなどが多少異なっている場合であっても、データベースをテナント毎に用意することなくマルチテナント型のＷｅｂアプリケーション画面を構築できるウェブアプリケーション構築システム、ウェブアプリケーション構築方法、ウェブアプリケーション構築プログラムおよびウェブアプリケーション構築プログラムを記録した記録媒体を提供することである。

本発明のウェブアプリケーション構築システムは、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築システムであって、各種データを記憶するデータベースの管理を行うデータベース部と、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をサービスとして提供するサ−ビス提供部と、このサ−ビス提供部で提供される１つ以上のサービスを組み合わせて利用者毎のビジネスロジックをプロセスとして作成するプロセス作成部と、このプロセス作成部で作成されたプロセスに応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築部とを備え、前記プロセス作成部で作成されたプロセスとそのプロセスに組み合わされているサービスが１つの仮想マシン上で動作し、それらのトランザクション制御が前記データベース部によって行われることを特徴とする。

ここで、例えば、前記サ−ビス提供部で提供されるサービスはＪａｖａで実装され、前記プロセス作成部で作成されるプロセスはスクリプト言語のＪＲｕｂｙまたはＲｕｂｙで実装され、前記仮想マシンはＪａｖａ仮想マシンであってもよい。

このような構成のウェブアプリケーション構築システムによれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。仮想マシン上で全てが動作するため、組み合わせたサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。なお、前記プロセス作成部で作成されるプロセスをＪＲｕｂｙまたはＲｕｂｙで実装する場合は、組み合わせを簡単に記述できる。

また、本発明のウェブアプリケーション構築システムにおいて、前記サ−ビス提供部によって提供されるサービスは、業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスとを備え、前記エンティティは前記データベース上のテーブルとオブジェクトをマッピングし、前記エンティティサービスの追加／参照／更新／削除操作機能部分が自動生成されることを特徴としてもよい。

このような構成のウェブアプリケーション構築システムによれば、エンティティサービスの追加／参照／更新／削除操作機能部分が自動生成されるので、冗長になりやすいデータベースアクセスの記述を単一化でき、管理がしやすくなる。

また、本発明のウェブアプリケーション構築システムにおいて、前記プロセスに対応した画面表示を行う画面表示部をさらに備え、この画面表示部は、テナント毎に割り当てられたテナント識別子と、業務アプリケーションの機能分類毎に割り当てられたアプリケーション識別子と、テナント別に業務アプリケーション画面毎に割り当てられた画面識別子と、業務機能の画面パターンにあわせて用意された専用アクセスパスとの組み合わせから画面表示デザインを決定するとともに、画面の入力項目およびラベル毎に割り当てられた項目識別子毎に設定されたパラメータに基づいて表示制御が行われることを特徴としてもよい。

ここで、前記パラメータの内容に基づく表示制御には、例えば、表示の種類、値の書式、文言、幅、最大最小値、必須チェックの有無などが挙げられる。

このような構成のウェブアプリケーション構築システムによれば、テナント毎に入力項目の設定や項目タイトルなどが多少異なっている場合であっても、パラメータを設定することで対応可能なので、データベースをテナント毎に用意することなくマルチテナント型のＷｅｂアプリケーション画面を構築でき、データベースとの構成依存もなくなる。

また、本発明のウェブアプリケーション構築システムにおいて、前記画面表示部は、項目識別子毎に設定されたパラメータの内容を画面表示に動的に反映させることを特徴としてもよい。さらに、前記パラメータの内容は前記データベースに記憶され、前記画面表示部が画面表示を行う際にその画面に必要な項目識別子の設定を前記画面識別子をキーにしてまとめて取得可能であることを特徴としてもよい。

このような構成のウェブアプリケーション構築システムによれば、画面のデザインを静的な物として用意しておき、表示時に動的に変化させることができるため、カスタマイズ対応がしやすくなる。

あるいは、本発明のウェブアプリケーション構築方法は、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築方法であって、各種データを記憶するデータベースの管理を行うデータベース管理工程と、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をサービスとして提供するサ−ビス提供工程と、このサ−ビス提供部で提供される１つ以上のサービスを組み合わせて利用者毎のビジネスロジックをプロセスとして作成するプロセス作成工程と、このプロセス作成部で作成されたプロセスに応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築工程とを備え、前記プロセス作成工程で作成されたプロセスとそのプロセスに組み合わされているサービスが１つの仮想マシン上で動作し、それらのトランザクション制御が前記データベース管理工程によって行われることを特徴とする。

このような構成のウェブアプリケーション構築方法によれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。仮想マシン上で全てが動作するため、組み合わせたサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。

また、本発明のウェブアプリケーション構築方法において、前記サ−ビス提供工程によって提供されるサービスは、業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスとを備え、前記エンティティが前記データベース上のテーブルとオブジェクトをマッピングするマッピング工程と、前記エンティティサービスの追加／参照／更新／削除操作機能部分を自動生成する自動精製工程とをさらに備えることを特徴としてもよい。

このような構成のウェブアプリケーション構築方法によれば、エンティティサービスの追加／参照／更新／削除操作機能部分が自動生成されるので、冗長になりやすいデータベースアクセスの記述を単一化でき、管理がしやすくなる。

また、本発明のウェブアプリケーション構築方法において、前記プロセスに対応した画面表示を行う画面表示工程をさらに備え、この画面表示工程は、テナント毎に割り当てられたテナント識別子と、業務アプリケーションの機能分類毎に割り当てられたアプリケーション識別子と、テナント別に業務アプリケーション画面毎に割り当てられた画面識別子と、業務機能の画面パターンにあわせて用意された専用アクセスパスとの組み合わせから画面表示デザインを決定するとともに、画面の入力項目およびラベル毎に割り当てられた項目識別子毎に設定されたパラメータに基づいて表示制御を行うことを特徴としてもよい。

このような構成のウェブアプリケーション構築方法によれば、テナント毎に入力項目の設定や項目タイトルなどが多少異なっている場合であっても、パラメータを設定することで対応可能なので、データベースをテナント毎に用意することなくマルチテナント型のＷｅｂアプリケーション画面を構築でき、データベースとの構成依存もなくなる。

また、本発明のウェブアプリケーション構築方法において、前記画面表示工程は、項目識別子毎に設定されたパラメータの内容を画面表示に動的に反映させることを特徴としてもよい。さらに、前記パラメータの内容は前記データベースに記憶され、前記画面表示部が画面表示を行う際にその画面に必要な項目識別子の設定を前記画面識別子をキーにしてまとめて取得可能であることを特徴としてもよい。

このような構成のウェブアプリケーション構築方法によれば、画面のデザインを静的な物として用意しておき、表示時に動的に変化させることができるため、カスタマイズ対応がしやすくなる。

あるいは、本発明のウェブアプリケーション構築プログラムは、上記ウェブアプリケーション構築方法をコンピュータに実行させることを特徴とする。

このような構成のウェブアプリケーション構築プログラムによれば、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明のウェブアプリケーション構築方法を実現することができる。さらに、このウェブアプリケーション構築プログラムを汎用的なコンピュータで実行可能なものにしておけば、本発明のウェブアプリケーション構築方法を実現するために専用のコンピュータ環境を準備する必要もなくなり、本発明のウェブアプリケーション構築プログラムの有用性が高まる。

あるいは、本発明のウェブアプリケーション構築プログラムを記録した記録媒体は、コンピュータ読み取り可能な記録媒体であって、上記ウェブアプリケーション構築プログラムを記録していることを特徴とする。

このような構成のウェブアプリケーション構築プログラムを記録した記録媒体によれば、本発明のウェブアプリケーション構築方法を様々な場所や環境で実現することが容易になり、本発明のウェブアプリケーション構築方法の汎用性を高めることができる。

本発明のウェブアプリケーション構築システムおよびウェブアプリケーション構築方法によれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。仮想マシン上で全てが動作するため、組み合わせたサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。

本発明のウェブアプリケーション構築プログラムによれば、プログラムが実行可能なコンピュータ環境さえあれば、どこにおいても本発明のウェブアプリケーション構築方法を実現することができる。さらに、このウェブアプリケーション構築プログラムを汎用的なコンピュータで実行可能なものにしておけば、本発明のウェブアプリケーション構築方法を実現するために専用のコンピュータ環境を準備する必要もなくなり、本発明のウェブアプリケーション構築プログラムの有用性が高まる。

また、本発明のウェブアプリケーション構築プログラムを記録した記録媒体によれば、本発明のウェブアプリケーション構築方法を様々な場所や環境で実現することが容易になり、本発明のウェブアプリケーション構築方法の汎用性を高めることができる。

図１は本発明の第１実施形態に係るＷｅｂアプリケーション構築システム１０のサーバ構成などを示す機能ブロック図である。 図２はＷｅｂアプリケーション構築システム１０の各サーバ上で動作する各モジュールとクライアント装置２０上で動作するブラウザ２０ｂとの間の呼び出し関係などの説明図である。 図３はいくつかの共通ＪａｖａＳｃｒｉｐｔ関数とＨＴＭＬ要素の記述ルールである。 図４（ａ）および図４（ｂ）はＵＩパラメータのイメージを示す表であり、図４（ａ）はＵＩ＿ＰＡＲＡＭを示し、図４（ｂ）はＵＩ＿ＩＮＰＵＴを示す。 図５はＪＲｕｂｙによるＤＳＬ（Ｄｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ：ドメイン固有言語）として記述されたプロセス１２ｐの例である。 図６は図５に例示されたプロセス１２ｐで使用されているＤＳＬ関数の概略説明図である。 図７はプロセス、アクションおよびサブアクションについての説明図である。 図８（ａ）および図８（ｂ）はＵＩ−ＤＢパラメータ変換についての説明図であり、図８（ａ）が変換前を示し、図８（ｂ）が変換後を示す。 図９はエンティティサービス１２ｓ１およびビジネスサービス１２ｓ２の関係の概略説明図である。 図１０はサービス１２ｓのドキュメントの記述例である。 図１１はＷｅｂアプリケーション構築システム１０における標準的な入力系画面処理の概略シーケンス図である。 図１２はテナント１用の標準受注入力画面の見出入力タブの画面表示例である。 図１３は図１２と同じ標準受注入力画面の明細入力タブの画面表示例である。 図１４はテナント２用の標準受注入力画面の見出入力タブの画面表示例である。 図１５は図１４と同じ標準受注入力画面の明細入力タブの画面表示例である。 図１６はテナント１用の受注一覧条件設定画面の表示例である。 図１７はテナント２用の受注一覧条件設定画面の表示例である。

以下、本発明の実施形態を、図面を参照して説明する。

本発明の第１実施形態に係るマルチテナント型Ｗｅｂアプリケーションを構築するＷｅｂアプリケーション構築システム１０では、ＳＯＡ（Ｓｅｒｖｉｃｅ Ｏｒｉｅｎｔｅｄ Ａｒｃｈｉｔｅｃｔｕｒｅ：サービス指向アーキテクチャ）の考え方を取り入れ、ビジネスロジックを「プロセス」と「サービス」に分離することとしている。そして、標準的な機能はサービスとして部品化するとともに、テナント（会社など）毎のビジネスロジックは必要な１つ以上のサービスを組み合わせることでプロセスとして作成する。

将来発生するテナント毎のビジネスロジックの違いは、プロセスをテナント毎にコピーしてからそれを変更することで対応する。サービスの作成には保守性の高いＪａｖａ（登録商標、以下も同様）を使用し、プロセスの作成には記述性および柔軟性の高いスクリプト言語であるＲｕｂｙ（ＪＲｕｂｙ）を使用する。

以下では、次のような項目毎に詳細な説明を行う。

Ａ．Ｗｅｂアプリケーション構築システム１０
Ａ１．機能ブロック
Ａ１１．サーバ構成
Ａ１２．モジュール呼び出し関係
Ａ２．処理詳細
Ａ２１．画面（ＪＳＰ）
Ａ２２．プロセス（ＪＲｕｂｙ）
Ａ２３．サービス（Ｊａｖａ）
Ａ３．処理シーケンス
Ａ４．画面表示例
Ｂ．プログラムおよび記録媒体としての実施形態
＜Ａ１１．機能ブロック／サーバ構成＞
図１は本発明の第１実施形態に係るＷｅｂアプリケーション構築システム１０のサーバ構成などを示す機能ブロック図である。

この図に示すように、Ｗｅｂアプリケーション構築システム１０は、画面に関する処理などが主に実装されるフロントサーバ１１と、ビジネスロジックなどに関する処理が主に実装されるロジックサーバ１２と、各種データを記憶・管理するデータベースに関する処理が主に実装されるデータベースサーバ１３とを備えている。このＷｅｂアプリケーション構築システム１０は、フロントサーバ１１およびインターネットなどのネットワークを介して、外部の１台以上のクライアント装置２０と接続される。

なお、この図１では、Ｗｅｂアプリケーション構築システム１０は３台のサーバ１１、１２、１３を組み合わせて構成された場合が示されているが、実際のハードウェア構成としては１台のサーバ装置のみで実現することも可能である。

次にこれらのサーバ１１、１２、１３などで利用されるプロダクトを例示するが、各プロダクトについてはまとめて後述する。

フロントサーバ１１に利用されるプロダクトとしては、例えば、ｉｎｔｒａ−ｍａｒｔ、Ｓ２Ｓｔｒｕｔｓ、Ｓ２ＤＡＯなどが挙げられる。画面は標準的なＪＳＰ（ＪａｖａＳｅｒｖｅｒ Ｐａｇｅｓ）を利用して実装される。

ロジックサーバ１２に利用されるプロダクトとしては、例えば、Ｔｏｍｃａｔ、Ｓ２ＪＤＢＣなどが挙げられる。プロセスはＪＲｕｂｙを利用して実装される。サービスおよびエンティティはＪａｖａを利用して実装される。

データベースサーバ１３に利用されるプロダクトとしては、例えば、リレーショナルデータベースマネージメントシステム（ＲＤＢＭＳ）として市販されているＯｒａｃｌｅが挙げられる。

フロントサーバ１１からロジックサーバ１２への通信はＨＴＴＰで行われ、ロジックサーバ１２からフロントサーバ１１へはＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ）が返信される。

フロントサーバ１１からデータベースサーバ１３への通信はＳ２ＤＡＯによって参照のみが行われ、データベースサーバ１３からフロントサーバ１１へはＵＩパラメータ、アクセス権限、ｉｎｔｒａ−ｍａｒｔマスタが返信される。

ロジックサーバ１２からデータベースサーバ１３への通信はＳ２ＪＤＢＣによって参照および更新が行われ、データベースサーバ１３からロジックサーバ１２へはＵＩパラメータ、業務データ、実行ログが返信される。

クライアント装置２０上で動作するブラウザ２０ｂでは、例えば、ＨＴＭＬ、ＪａｖａＳｃｒｉｐｔ、ｊＱｕｅｒｙなどが利用される。クライアント装置２０からフロントサーバ１１への通信はＨＴＴＰまたはＨＴＴＰＳで行われ、フロントサーバ１１からクライアント装置２０へはＨＴＭＬ、ＪＳＯＮが返信される。

ｉｎｔｒａ−ｍａｒｔは、ＮＴＴデータイントラマート社のＷｅｂアプリケーションフレームワークであり、Ｗｅｂアプリケーション構築システム１０では、主にユーザ、権限管理とＷ／Ｆ機能を利用する。

ｊＱｕｅｒｙは、ＪａｖａＳｃｒｉｐｔのライブラリであり、ＨＴＭＬやＣＳＳの動的な変更処理を簡略化する。

Ｓ２Ｓｔｒｕｔｓは、Ｓｅａｓａｒ２（ＤＩコンテナ）を使用してＳｔｒｕｔｓ（Ｗｅｂフレームワーク） を拡張したオープンソースフレームワークであり、Ｓｔｒｕｔｓの設定作業を簡略化する。

Ｓ２ＤＡＯおよびＳ２ＪＤＢＣは、Ｓｅａｓａｒ２を使用してデータベース１３ｄ上のテーブルとＪａｖａのオブジェクトをマッピングするＯ／Ｒマッパーツールであり、テーブルのＣＲＵＤ（追加／参照／更新／削除）操作実装を簡略化する。なお、Ｓ２ＪＤＢＣで統一しないのはｉｎｔｒａ−ｍａｒｔでの制限のためである。

ＪＲｕｂｙは、ＪａｖａＶＭ上で動作するＲｕｂｙ言語の処理系実装である。ＪａｖａからＲｕｂｙ言語で書かれたスクリプトを動作させたり、ＲｕｂｙのスクリプトからＪａｖａのクラス、メソッドを利用することが可能である。

＜Ａ１２．機能ブロック／モジュール呼び出し関係＞
図２はＷｅｂアプリケーション構築システム１０の各サーバ上で動作する各モジュールとクライアント装置２０上で動作するブラウザ２０ｂとの間の呼び出し関係などの説明図である。

この図に示すように、ブラウザ２０ｂはＨＴＴＰまたはＨＴＴＰＳで画面１１ｄ（ＪＳＰ）を呼び出すが、ブラウザ２０ｂからプロセス１２ｐ（ＪＲｕｂｙ）を直接利用することはない。

画面１１ｄ（ＪＳＰ）はＨＴＴＰでプロセス１２ｐ（ＪＲｕｂｙ）を呼び出すが、画面１１ｄ（ＪＳＰ）からサービス１２ｓ（Ｊａｖａ）を直接利用することはない。

プロセス１２ｐ（ＪＲｕｂｙ）はＪａｖａメソッド呼び出しによってサービス１２ｓ（Ｊａｖａ）を呼び出すが、プロセス１２ｐ（ＪＲｕｂｙ）からデータベース１３ｄを直接利用することはない。

サービス１２ｓ（Ｊａｖａ）はデータベース１３ｄに記憶・管理されている各種データの参照および更新処理を行う。

なお、これらのプロセス１２ｐおよびサービス１２ｓは、１つのＪＶＭ（Ｊａｖａ Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）上で動作させ、個々の組み合わせのトランザクション制御をデータベース１３ｄと連動できるようにする。

＜Ａ２１．処理詳細／画面（ＪＳＰ）＞
画面１１ｄは標準的なＪＳＰを使用して実装する。図３はいくつかの共通ＪａｖａＳｃｒｉｐｔ関数とＨＴＭＬ要素の記述ルールである。図４（ａ）および図４（ｂ）はＵＩパラメータのイメージを示す表であり、図４（ａ）はＵＩ＿ＰＡＲＡＭを示し、図４（ｂ）はＵＩ＿ＩＮＰＵＴを示す。

図３に示すように、ＨＴＭＬの入力とラベルの各要素にｉｄを指定する。

指定したＩＤがＵＩパラメータのキー（項目ＩＤ）となる。画面からｆｒｏｎｔ１１ｄを経由してｌｏｇｉｃ１２ｐ（プロセス） に送られるパラメータも項目ＩＤをキーとする。ラベルの内容や入力項目の型・桁情報、各要素の幅などはＵＩパラメータからＪａｖａＳｃｒｉｐｔを使用して動的に設定する。なお、フレームワークの共通ＪａｖａＳｃｒｉｐｔ関数を使用する。

図４に示すように、ＵＩ＿ＰＡＲＡＭとＵＩ＿ＩＮＰＵＴとは、いずれもが有するフィールド「入力ＩＤ」に同じ値をもつレコード同士が互いにマッピングされる。

画面１１ｄの論理構成についてさらに説明すると次の通りである。

（１）マルチテナント対応として、テナント毎に会社ＣＤ（ＣＯＤＥ、以下も同様）を割り当てる。

（２）業務アプリケーションの機能分類（受注管理・仕入管理など）毎にアプリケーションＣＤを割り当てる。

（３）業務機能の画面パターン（伝票入力パターン・一覧表示パターンなど）にあわせて専用のアクセスパス（ＵＲＩ）を用意する。

（４）テナント別（会社ＣＤ別）で業務アプリケーション画面毎に画面ＩＤを割り当てる。

（５）会社ＣＤ・アプリケーションＣＤ・画面ＩＤとＵＲＩの組み合わせから表示したい画面のデザインを決定する。

（６）画面の入力項目・ラベル毎に、項目ＩＤを割り当てる。

ここでは、項目ＩＤ毎に、表示の種類、値の書式、文言、幅、最大最小値、必須チェックの有無などの設定をＵＩパラメータとして用意する。画面表示時には、各項目ＩＤのＵＩパラメータの内容を動的に反映する。ＵＩパラメータの内容は、データベース１３ｄに保存し、画面ＩＤをキーに画面１１ｄに必要な項目ＩＤの設定をまとめて一式取得可能にする。

（７）ＵＩ−ＤＢパラメータ変換を行う。

画面ＩＤ＋項目ＩＤでデータベース１３ｄのテーブル・カラムをマッピングして、画面ＩＤ＋項目ＩＤとマッピングを相互変換できるようにする。業務データ取得時はテーブル・カラムから項目ＩＤに変換し、業務データ保存時には、項目ＩＤからテーブル・カラムに変換する。

また、このような論理構成のための実現方式は次の通りである。

（１）データベース１３ｄを会社ＣＤ毎に分割する。

（２）会社ＣＤ・アプリケーションＣＤ・画面ＩＤとＵＲＩをキーに、画面デザインを記述したＪＳＰファイルを特定する。

（３）ＪＳＰファイルには、入力項目やラベルにｉｄ＝“項目ＩＤ”を指定して記述する。

（４）ＪａｖａＳｃｒｉｐｔで動的にＵＩパラメータの内容を各入力項目やラベルに反映する。

ここでは、ＵＩパラメータの内容をデータベースに保持する。画面ＩＤをキーにデータベース１３ｄより項目ＩＤのＵＩパラメータ一式をまとめて取得する。そして、ＵＩパラメータの内容を反映するＪａｖａＳｃｒｉｐ （ｊＱｕｅｒｙ）のソースを自動生成する。
ブラウザ２０ｂにおける表示時には、自動生成したＪａｖａＳｃｒｉｐｔを動作させ、動的に反映させる。

（５）ＵＩ−ＤＢパラメータ変換ライブラリを実装し、画面ＩＤ＋項目ＩＤとマッピングを相互変換できるようにする。

＜Ａ２２．処理詳細／プロセス（ＪＲｕｂｙ）＞
図５はＪＲｕｂｙによるＤＳＬ（Ｄｏｍａｉｎ Ｓｐｅｃｉｆｉｃ Ｌａｎｇｕａｇｅ：ドメイン固有言語）として記述されたプロセス１２ｐの例である。図６は図５に例示されたプロセス１２ｐで使用されているＤＳＬ関数の概略説明図である。なお、図５の行末に示されている［１］などの数字が、図６で同じ数字を有する関数への対応を示している。

ＤＳＬとは特定の問題やタスクのために設計されたプログラム言語のことである。プロセス１２ｐでは、文法としてはＲｕｂｙの文法を使用する。図５には、「初期値取得」、「確認処理」および「登録処理」が例示されている。また、Ｗｅｂアプリケーション構築システム１０の業務ロジックを記述するために、例えば、図６に示したような特別な関数（ＤＳＬ関数）を予め用意しておく。

図７はプロセス、アクションおよびサブアクションについての説明図である。

画面１１ｄからは、ａｃｔｉｏｎメソッドで定義した「アクション」というブロック単位で処理を呼び出す。プロセス１２ｐは複数のアクションからなり、画面１１ｄからの呼出は原則としてアクションを指定する。更新系の画面は原則として、１つの画面１１ｄに対して１つのプロセス１２ｐを持つが、参照のみのプロセス１２ｐは複数の画面１１ｄから共用される。なお、複数のプロセス１２ｐ間で処理を共通化するためにＤＳＬのファイル単位で切り出したものを「サブアクション」と呼ぶ。

また、サーバから画面項目に値を設定する処理を「入力支援」、サーバで画面項目のエラーチェックを行う処理を「項目チェック」と呼ぶ。これらの入力支援および項目チェックは、予め用意したチェック部品をデータベース１３ｄのパラメータで設定することで、プログラムなしに行うことを可能とする。

図８（ａ）および図８（ｂ）はＵＩ−ＤＢパラメータ変換についての説明図であり、図８（ａ）が変換前を示し、図８（ｂ）が変換後を示す。

ｅｎｔｉｔｙメソッドで画面１１ｄから送られてきたパラメータをＪａｖａのエンティティクラスのインスタンスに変換する。ここで、エンティティとは、データベース１３ｄのテーブルと１対１に対応するオブジェクトである。

画面１１ｄから送られた画面項目（ｕｉＮｏ、ｃ０４、等）からデータベース１３ｄ項目（ｊｕｃｈｕ．ｓ＿ｊｕｃｈｕ、ｊｕｃｈｕ．ｄ＿ｊｕｃｈｕ、など）への変換は、フレームワークがＵＩパラメータを参照して自動的に行う。

例えば、図８（ａ）および図８（ｂ）に示した場合、ｅｎｔｉｔｙ（：Ｊｕｃｈｕ）では、ＪｕｃｈｕオブジェクトのｓＪｕｃｈｕプロパティとｄＪｕｃｈｕプロパティに、画面１１ｄから送信された値（キーｕｉＮｏ、ｃ０４それぞれの値）を自動的に設定する。ただし、実際には、変換前のハッシュに変換後のキー／値を追加するため、変換前のキー／値も残っている。

＜Ａ２３．処理詳細／サービス（Ｊａｖａ）＞
サービス１２ｓはＪａｖａで作成する。このサービス１２ｓが提供する機能はＷｅｂアプリケーション構築システム１０の標準機能とし、テナント（会社）毎のロジックはプロセス１２ｐで吸収するものとする。

図９はエンティティサービス１２ｓ１およびビジネスサービス１２ｓ２の関係の概略説明図である。

この図に示すように、サービス１２ｓの種類としては以下の２種類がある。なお、業務データや制御データをエンティティとする。

（１）エンティティサービス
特定のエンティティの１つと結び付くビジネスロジックを実装するサービスであり、基本的なＣＲＵＤ操作とビジネスロジックを実装するメソッドを持つ。なお、このエンティティサービスは、データベース１３ｄのＣＲＵＤ操作におけるＳ２ＪＤＢＣ機能部分を自動生成する。

（２）ビジネスサービス
特定の１つのエンティティと結び付かないビジネスロジックを実装するサービスであり、基本的なＣＲＵＤ操作は持たず、エンティティサービスを使用する。

また、サービス１２ｓのメソッドの引数には、原則としてエンティティクラスのインスタンスやエンティティクラスのリスト、または、マップ（キーと値の組）やマップのリストを指定することとし、引数の数が多くなることを避ける。

図１０はサービス１２ｓのドキュメントの記述例である。

この図ではサービス名「受注明細サービス」の例が示されているが、このようにサービス１２ｓのドキュメントはＪａｖａｄｏｃ形式で記述する。

＜Ａ３．処理シーケンス＞
図１１はＷｅｂアプリケーション構築システム１０における標準的な入力系画面処理の概略シーケンス図である。なお、図２などを参照して上述したように、ブラウザ２０ｂはクライアント装置２０上で動作し、画面１１ｄ（ＪＳＰ）はフロントサーバ１１上で動作し、プロセス１２ｐおよびサービス１２ｓはロジックサーバ１２上で動作し、データベース１３ｄはデータベースサーバ１３上で動作する。また、図１１では、ログイン処理やＵＩ−ＤＢパラメータ変換処理などは省略されている。

まず、ユーザ３０がキーボードなどを利用してブラウザ２０ｂにＵＲＬを入力すると、これがＨＴＴＰとなって画面１１ｄへ送信され、さらに画面１１ｄからＳ２ＤＡＯによってデータベース１３ｄの参照が行われる。データベース１３ｄからはＵＩパラメータ（項目の幅、型、桁情報、ラベル名称、イベント処理など）が返される。

返ってきたＵＩパラメータに応じて画面１１ｄからプロセス１２ｐに対してプロセス呼出（ＩＮＩＴ）が行われ、さらにプロセス１２ｐからサービス１２ｓに対して入力支援サービス呼出（ＩＮＩＴ）が行われ、さらにサービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が行われる。データベース１３ｄからはチェックパラメータが返される。この後、サービス１２ｓにおいてビジネスサービス１２ｓ２（図９参照）からエンティティサービス１２ｓ１（図９参照）呼出を行ってから、サービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が再び行われる。データベース１３ｄからは業務データが返される。返ってきた業務データに応じてサービス１２ｓからプロセス１２ｐに対して画面項目初期値が返され、さらにプロセス１２ｐから画面１１ｄに対してＪＳＯＮ（画面項目初期値）が返され、これがＨＴＭＬとなってブラウザ２０ｂへ送信され、ブラウザ２０ｂにおいて画面の表示が行われることでユーザ３０に認識される。

ユーザ３０がキーボードなどを利用して画面内のいずれかの項目へ入力を行い、さらにマウスなどを利用して画面内の登録ボタンをクリックすると、これがＨＴＴＰ（Ａｊａｘ）となって画面１１ｄへ送信される。さらに画面１１ｄからプロセス１２ｐに対してプロセス呼出（ＣＯＮＦＩＲＭ）が行われ、さらにプロセス１２ｐからサービス１２ｓに対して入力支援サービス呼出（ＴＯＲＯＫＵ）が行われ、さらにサービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が行われる。データベース１３ｄからはチェックパラメータが返される。この後、サービス１２ｓにおいてビジネスサービス１２ｓ２からエンティティサービス１２ｓ１呼出を行ってから、サービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が再び行われる。データベース１３ｄからは業務データが返される。返ってきた業務データに応じてサービス１２ｓからプロセス１２ｐに対して入力支援項目値が返される。

返ってきた入力支援項目値に応じてプロセス１２ｐからサービス１２ｓに対して入力チェックサービス呼出（ＴＯＲＯＫＵ）が行われ、さらにサービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が行われる。データベース１３ｄからはチェックパラメータが返される。この後、サービス１２ｓにおいてビジネスサービス１２ｓ２からエンティティサービス１２ｓ１呼出を行ってから、サービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が再び行われる。データベース１３ｄからは業務データが返される。返ってきた業務データに応じてサービス１２ｓからプロセス１２ｐに対してチェック結果が返される。さらにプロセス１２ｐから画面１１ｄに対してＪＳＯＮ（入力支援値＋チェック結果）が返され、さらに画面１１ｄからブラウザ２０ｂへ入力支援項目値＋チェック結果が返され、ブラウザ２０ｂにおいて確認画面の表示が行われることでユーザ３０に認識される。

確認画面の表示を認識したユーザ３０がマウスなどを利用して画面内の登録ボタンをクリックすると、これがＨＴＴＰ（Ａｊａｘ）となって画面１１ｄへ送信される。さらに画面１１ｄからプロセス１２ｐに対してプロセス呼出（ＴＯＲＯＫＵ）が行われ、さらにプロセス１２ｐからサービス１２ｓに対して入力チェックサービス呼出（ＴＯＲＯＫＵ）が行われ、さらにサービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が行われる。データベース１３ｄからはチェックパラメータが返される。この後、サービス１２ｓにおいてビジネスサービス１２ｓ２からエンティティサービス１２ｓ１呼出を行ってから、サービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が再び行われる。データベース１３ｄからは業務データが返される。返ってきた業務データに応じてサービス１２ｓからプロセス１２ｐに対してチェック結果が返される。

チェック結果が返ってきた後、プロセス１２ｐにおいてパラメータがエンティティに変換される。次に、プロセス１２ｐからサービス１２ｓに対して登録サービス呼出（エンティティ）が行われ、さらにサービス１２ｓからＳ２ＪＤＢＣによってデータベース１３ｄの参照が行われる。データベース１３ｄからは登録結果が返され、さらにサービス１２ｓからプロセス１２ｐに対して登録結果が返される。

さらにプロセス１２ｐから画面１１ｄに対してＪＳＯＮ（登録結果）が返され、さらに画面１１ｄからブラウザ２０ｂへ登録結果が返され、ブラウザ２０ｂにおいて登録結果が表示されることでユーザ３０に認識される。

＜Ａ４．画面表示例＞
Ｗｅｂアプリケーション構築システム１０の画面１１ｄによる画面表示例をいくつか示す。

図１２はテナント１用の標準受注入力画面の見出入力タブの画面表示例であり、図１３は同じ標準受注入力画面の明細入力タブの画面表示例である。

図１４はテナント２用の標準受注入力画面の見出入力タブの画面表示例であり、図１５は同じ標準受注入力画面の明細入力タブの画面表示例である。

図１２および図１４の見出入力タブの画面表示例同士を比較すると、販売店の検索用入力欄は図１２にのみ存在しており、得意先注文Ｎｏ．、得意先ご連絡欄、受付担当者の各欄は図１４にのみ存在している。一方、図１３および図１５の明細入力タブの画面表示例同士を比較すると、図１５の画面表示では右の方に図１３には存在しない複数の欄が存在しているのがわかる。

図１６はテナント１用の受注一覧条件設定画面の表示例であり、図１７はテナント２用の受注一覧条件設定画面の表示例である。

図１６および図１７の受注一覧条件設定画面の表示例同士を比較すると、図１７の受注一覧条件設定画面にのみ拡張項目欄が設けられているのがわかる。このような拡張項目欄を設けておけば、テナント毎に拡張項目欄の利用箇所が増えても、対応するプロセスを追加することにより、他のプロセスに依存せずに、安全に機能が追加できる。

以上で説明した第１実施形態の構成によれば、プロセス１２ｐがスクリプト言語のＲｕｂｙによって実装されているため、組み合わせを簡単に記述することができる。ＪＶＭ（Ｊａｖａ仮想マシン）上で全てが動作するため、組み合わせがネットワーク経由にならず、軽快な動作が可能になる。エンティティサービス１２ｓ１のＣＲＵＤ操作機能部分を自動生成することにより、冗長になりやすいデータベースアクセスの記述を単一化でき、管理がしやすくなる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要が無くなる。また、マルチテナント対応として、テナント毎の入力桁、幅、名称等については、ＵＩパラメータを設定することで対応が可能となる。画面のデザインを静的な物として用意しておき、表示時に動的に変化させることができるため、カスタマイズ対応がしやすくなる。データベース１３ｄとの構成依存もなくなる。

＜Ｂ．プログラムおよび記録媒体としての実施形態＞
また、本発明はコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体に、上述したＷｅｂアプリケーション構築方法を記録するものとすることもできる。この結果、Ｗｅｂアプリケーション構築方法を実行するプログラムを記録した記録媒体を持ち運び自在に提供することができる。

なお、本実施の形態では、この記録媒体としては、マイクロコンピュータで処理が行われるために図示していないメモリ、例えばＲＯＭのようなものがプログラムメディアであってもよいし、また、図示していないが外部記憶装置としてプログラム読み取り装置が設けられ、そこに記録媒体を挿入することで読み取り可能なプログラムメディアであっても良い。いずれの場合においても、格納されているプログラムはマイクロプロセッサがアクセスして実行させる構成であってもよいし、あるいは、いずれの場合もプログラムを読み出し、読み出されたプログラムは、マイクロコンピュータの図示されていないプログラム記憶エリアにダウンロードされて、そのプログラムが実行される方式であってもよい。このダウンロード用のプログラムは予め本体装置に格納されているものとする。

ここで、上記プログラムメディアは、本体と分離可能に構成される記録媒体であり、磁気テープやカセットテープ等のテープ系、フレキシブルディスクやハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ等の光ディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュＲＯＭなどによる半導体メモリを含めた固定的にプログラムを担持する媒体であってもよい。

また、本実施の形態においては、インターネットを含む通信ネットワークを接続可能なシステム構成であることから、通信ネットワークからプログラムをダウンロードするように流動的にプログラムを担持する媒体であってもよい。なお、このように通信ネットワークからプログラムをダウンロードする場合には、そのダウンロード用のプログラムは予め本体装置に格納しておくか、あるいは別な記録媒体からインストールされるものであってもよい。上記記録媒体は、Ｗｅｂアプリケーション構築システム１０が備える３台のサーバ１１、１２、１３に備えられるプログラム読み取り装置のいずれかによって読み取られることで上述したＷｅｂアプリケーション構築方法が実行される。

なお、本発明は、その主旨または主要な特徴から逸脱することなく、他のいろいろな形で実施することができる。そのため、上述の実施形態はあらゆる点で単なる例示にすぎず、限定的に解釈してはならない。本発明の範囲は特許請求の範囲によって示すものであって、明細書本文にはなんら拘束されない。さらに、特許請求の範囲の均等範囲に属する変形や変更は、全て本発明の範囲内のものである。

１０ Ｗｅｂアプリケーション構築システム
１１ フロントサーバ
１１ｄ 画面
１２ ロジックサーバ
１２ｐ プロセス
１２ｓ サービス
１２ｓ１ エンティティサービス
１２ｓ２ ビジネスサービス
１３ データベースサーバ
１３ｄ データベース
２０ クライアント装置
２０ｂ ブラウザ
３０ ユーザ

本発明のウェブアプリケーション構築システムは、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築システムであって、各種データを記憶するデータベースの管理を行うデータベース部と、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をウェブサービスとして提供するウェブサービス提供部と、このウェブサービス提供部で提供される１つ以上のウェブサービスを組み合わせて利用者毎のビジネスロジックをプロセスとして作成するプロセス作成部と、このプロセス作成部で作成されたプロセスに応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築部とを備え、前記プロセス作成部で作成されたプロセスとそのプロセスに組み合わされているウェブサービスとが１つの仮想マシン上で動作、それらのトランザクション制御が前記データベース部によって行われることを特徴とする。

ここで、例えば、前記ウェブサービス提供部で提供されるウェブサービスはＪａｖａで実装され、前記プロセス作成部で作成されるプロセスはスクリプト言語のＪＲｕｂｙまたはＲｕｂｙで実装され、前記仮想マシンはＪａｖａ仮想マシンであってもよい。

このような構成のウェブアプリケーション構築システムによれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。１つの仮想マシン上で全てが動作するため、組み合わせたウェブサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。なお、前記プロセス作成部で作成されるプロセスをＪＲｕｂｙまたはＲｕｂｙで実装する場合は、組み合わせを簡単に記述できる。

また、本発明のウェブアプリケーション構築システムにおいて、前記ウェブサービス提供部によって提供されるウェブサービスは、業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスとを備え、前記エンティティは前記データベース上のテーブルとオブジェクトをマッピングし、前記エンティティサービスの追加／参照／更新／削除操作機能部分が自動生成されることを特徴としてもよい。

あるいは、本発明のウェブアプリケーション構築方法は、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築方法であって、各種データを記憶するデータベースの管理を行うデータベース管理工程と、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をウェブサービスとして提供するウェブサービス提供工程と、このウェブサービス提供工程で提供される１つ以上のウェブサービスを組み合わせて利用者毎のビジネスロジックをプロセスとして作成するプロセス作成工程と、このプロセス作成工程で作成されたプロセスに応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築工程とを備え、前記プロセス作成工程で作成されたプロセスとそのプロセスに組み合わされているウェブサービスとが１つの仮想マシン上で動作、それらのトランザクション制御が前記データベース管理工程によって行われることを特徴とする。

このような構成のウェブアプリケーション構築方法によれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。１つの仮想マシン上で全てが動作するため、組み合わせたウェブサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。

また、本発明のウェブアプリケーション構築方法において、前記ウェブサービス提供工程によって提供されるウェブサービスは、業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスとを備え、前記エンティティが前記データベース上のテーブルとオブジェクトをマッピングするマッピング工程と、前記エンティティサービスの追加／参照／更新／削除操作機能部分を自動生成する自動精製工程とをさらに備えることを特徴としてもよい。

また、本発明のウェブアプリケーション構築方法において、前記画面表示工程は、項目識別子毎に設定されたパラメータの内容を画面表示に動的に反映させることを特徴としてもよい。さらに、前記パラメータの内容は前記データベースに記憶され、前記画面表示工程が画面表示を行う際にその画面に必要な項目識別子の設定を前記画面識別子をキーにしてまとめて取得可能であることを特徴としてもよい。

本発明のウェブアプリケーション構築システムおよびウェブアプリケーション構築方法によれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。１つの仮想マシン上で全てが動作するため、組み合わせたウェブサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。

本発明のウェブアプリケーション構築システムは、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築システムであって、各種データを記憶するデータベースに関する処理を行うデータベースサーバと、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能がサービスとして実装されるとともに、１つ以上のサービスを組み合わせた利用者毎のビジネスロジックがプロセスとして実装され、このプロセスに応じた利用者毎のウェブアプリケーションが動作するロジックサーバとを備え、前記プロセスとそのプロセスに組み合わされているサービスとが前記ロジックサーバ内の１つの仮想マシン上で動作し、それらのトランザクション制御が前記データベースサーバによって行われることを特徴とする。

ここで、例えば、前記サービスはＪａｖａで実装され、前記プロセスはスクリプト言語のＪＲｕｂｙまたはＲｕｂｙで実装され、前記仮想マシンはＪａｖａ仮想マシンであってもよい。

このような構成のウェブアプリケーション構築システムによれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。１つの仮想マシン上で全てが動作するため、組み合わせたサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。なお、前記プロセス作成部で作成されるプロセスをＪＲｕｂｙまたはＲｕｂｙで実装する場合は、組み合わせを簡単に記述できる。

また、本発明のウェブアプリケーション構築システムにおいて、前記サービスは、業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスとを備え、前記エンティティは前記データベース上のテーブルとオブジェクトをマッピングし、前記エンティティサービスの追加／参照／更新／削除操作機能部分が自動生成されることを特徴としてもよい。

また、本発明のウェブアプリケーション構築システムにおいて、画面表示をクライアント装置に行わせるフロントサーバをさらに備え、このフロントサーバは、テナント毎に割り当てられたテナント識別子と、業務アプリケーションの機能分類毎に割り当てられたアプリケーション識別子と、テナント別に業務アプリケーション画面毎に割り当てられた画面識別子と、業務機能の画面パターンにあわせて用意された専用アクセスパスとの組み合わせから画面表示デザインを決定するとともに、画面の入力項目およびラベル毎に割り当てられた項目識別子毎に設定されたパラメータに基づいて表示制御を行うことを特徴としてもよい。

あるいは、本発明のウェブアプリケーション構築方法は、同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築方法であって、データベースサーバが、各種データを記憶するデータベースに関する処理を行うデータベース処理工程と、業務上の一処理に相当する単位で部品化された１つ以上の標準的機能がサービスとして実装されるとともに１つ以上のサービスを組み合わせた利用者毎のビジネスロジックがプロセスとして実装されたロジックサーバが、このプロセスに応じた利用者毎のウェブアプリケーションを動作させるウェブアプリケーション動作工程とを備え、前記プロセスとそのプロセスに組み合わされているサービスとが前記ロジックサーバ内の１つの仮想マシン上で動作し、それらのトランザクション制御が前記データベースサーバによって行われることを特徴とする。

このような構成のウェブアプリケーション構築方法によれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。１つの仮想マシン上で全てが動作するため、組み合わせたサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。

また、本発明のウェブアプリケーション構築方法において、前記サービスは、業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスとを備え、前記エンティティサービスが、前記ロジックサーバに、前記エンティティを介する前記データベース上のテーブルの追加／参照／更新／削除操作機能部分を自動生成させる自動生成工程とをさらに備えることを特徴としてもよい。

また、本発明のウェブアプリケーション構築方法において、フロントサーバが、画面表示をクライアント装置に行わせる画面表示工程をさらに備え、この画面表示工程は、テナント毎に割り当てられたテナント識別子と、業務アプリケーションの機能分類毎に割り当てられたアプリケーション識別子と、テナント別に業務アプリケーション画面毎に割り当てられた画面識別子と、業務機能の画面パターンにあわせて用意された専用アクセスパスとの組み合わせから画面表示デザインを決定するとともに、画面の入力項目およびラベル毎に割り当てられた項目識別子毎に設定されたパラメータに基づいて表示制御を行うことを特徴としてもよい。

本発明のウェブアプリケーション構築システムおよびウェブアプリケーション構築方法によれば、ビジネスロジックを個々に独立した部品として扱えたり、簡単に組み合わせられたりするとともに、組み合わせたビジネスロジックでトランザクションを統一できる。１つの仮想マシン上で全てが動作するため、組み合わせたサービス同士がネットワーク経由にならないため、軽快な動作が可能になる。トランザクション制御が従来のアプリケーションと同等となり、データベースの機能を使ってデータの整合性を保つことができるので、新しい制御方法を覚える必要がない。

Claims (15)

1. 同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築システムであって、
   各種データを記憶するデータベースの管理を行うデータベース部と、
   業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をサービスとして提供するサ−ビス提供部と、
   このサ−ビス提供部で提供される１つ以上のサービスを組み合わせて利用者毎のビジネスロジックをプロセスとして作成するプロセス作成部と、
   このプロセス作成部で作成されたプロセスに応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築部と
   を備え、
   前記プロセス作成部で作成されたプロセスとそのプロセスに組み合わされているサービスが１つの仮想マシン上で動作し、それらのトランザクション制御が前記データベース部によって行われることを特徴とするウェブアプリケーション構築システム。
2. 請求項１に記載のウェブアプリケーション構築システムにおいて、
   前記サ−ビス提供部によって提供されるサービスは、
   業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、
   ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスと
   を備え、
   前記エンティティは前記データベース上のテーブルとオブジェクトをマッピングし、
   前記エンティティサービスの追加／参照／更新／削除操作機能部分が自動生成されることを特徴とするウェブアプリケーション構築システム。
3. 請求項１または２に記載のウェブアプリケーション構築システムにおいて、
   前記プロセス作成部で作成されるプロセスはＲｕｂｙで実装されていることを特徴とするウェブアプリケーション構築システム。
4. 請求項１〜３のいずれか１項に記載のウェブアプリケーション構築システムにおいて、
   前記サ−ビス提供部で提供されるサービスはＪａｖａで実装されており、
   前記プロセス作成部で作成されるプロセスはＪＲｕｂｙで実装されており、
   前記仮想マシンはＪａｖａ仮想マシンであることを特徴とするウェブアプリケーション構築システム。
5. 請求項１〜４のいずれか１項に記載のウェブアプリケーション構築システムにおいて、
   前記プロセスに対応した画面表示を行う画面表示部をさらに備え、
   この画面表示部は、
   テナント毎に割り当てられたテナント識別子と、
   業務アプリケーションの機能分類毎に割り当てられたアプリケーション識別子と、
   テナント別に業務アプリケーション画面毎に割り当てられた画面識別子と、
   業務機能の画面パターンにあわせて用意された専用アクセスパスと
   の組み合わせから画面表示デザインを決定するとともに、
   画面の入力項目およびラベル毎に割り当てられた項目識別子毎に設定されたパラメータに基づいて表示制御が行われることを特徴とするウェブアプリケーション構築システム。
6. 請求項５に記載のウェブアプリケーション構築システムにおいて、
   前記画面表示部は、項目識別子毎に設定されたパラメータの内容を画面表示に動的に反映させることを特徴とするウェブアプリケーション構築システム。
7. 請求項５または６に記載のウェブアプリケーション構築システムにおいて、
   前記パラメータの内容は前記データベースに記憶され、前記画面表示部が画面表示を行う際にその画面に必要な項目識別子の設定を前記画面識別子をキーにしてまとめて取得可能であることを特徴とするウェブアプリケーション構築システム。
8. 請求項５〜７のいずれか１項に記載のウェブアプリケーション構築システムにおいて、
   前記パラメータの内容に基づく表示制御には、表示の種類、値の書式、文言、幅、最大最小値、必須チェックの有無の少なくとも１つ以上を含むことを特徴とするウェブアプリケーション構築システム。
9. 同一のサーバ環境を使用する複数の利用者の各々が任意の仕様にカスタマイズして使用することができるマルチテナント型ウェブアプリケーションを構築するウェブアプリケーション構築方法であって、
   各種データを記憶するデータベースの管理を行うデータベース管理工程と、
   業務上の一処理に相当する単位で部品化された１つ以上の標準的機能をサービスとして提供するサ−ビス提供工程と、
   このサ−ビス提供部で提供される１つ以上のサービスを組み合わせて利用者毎のビジネスロジックをプロセスとして作成するプロセス作成工程と、
   このプロセス作成部で作成されたプロセスに応じて利用者毎のウェブアプリケーションを構築するウェブアプリケーション構築工程と
   を備え、
   前記プロセス作成工程で作成されたプロセスとそのプロセスに組み合わされているサービスが１つの仮想マシン上で動作し、それらのトランザクション制御が前記データベース管理工程によって行われることを特徴とするウェブアプリケーション構築方法。
10. 請求項９に記載のウェブアプリケーション構築方法において、
    前記サ−ビス提供工程によって提供されるサービスは、
    業務データまたは制御データをエンティティとし、そのエンティティのうちで特定の１つと結び付いて、前記データベースに対するデータ操作やエンティティ専用のロジックを有するエンティティサービスと、
    ビジネスロジックの個々の機能を実装し、データ操作は前記エンティティサービスを介して行うビジネスサービスと
    を備え、
    前記エンティティが前記データベース上のテーブルとオブジェクトをマッピングするマッピング工程と、
    前記エンティティサービスの追加／参照／更新／削除操作機能部分を自動生成する自動精製工程とをさらに備えることを特徴とするウェブアプリケーション構築方法。
11. 請求項９または１０に記載のウェブアプリケーション構築方法において、
    前記プロセスに対応した画面表示を行う画面表示工程をさらに備え、
    この画面表示工程は、
    テナント毎に割り当てられたテナント識別子と、
    業務アプリケーションの機能分類毎に割り当てられたアプリケーション識別子と、
    テナント別に業務アプリケーション画面毎に割り当てられた画面識別子と
    業務機能の画面パターンにあわせて用意された専用アクセスパスと
    の組み合わせから画面表示デザインを決定するとともに、
    画面の入力項目およびラベル毎に割り当てられた項目識別子毎に設定されたパラメータに基づいて表示制御を行うことを特徴とするウェブアプリケーション構築方法。
12. 請求項１１に記載のウェブアプリケーション構築方法において、
    前記画面表示工程は、項目識別子毎に設定されたパラメータの内容を画面表示に動的に反映させることを特徴とするウェブアプリケーション構築システム。
13. 請求項１１または１２に記載のウェブアプリケーション構築方法において、
    前記パラメータの内容は前記データベースに記憶され、前記画面表示部が画面表示を行う際にその画面に必要な項目識別子の設定を前記画面識別子をキーにしてまとめて取得可能であることを特徴とするウェブアプリケーション構築方法。
14. 請求項９〜１３のいずれか１項に記載のウェブアプリケーション構築方法をコンピュータに実行させるウェブアプリケーション構築プログラム。
15. コンピュータ読み取り可能な記録媒体であって、
    請求項１４に記載のウェブアプリケーション構築プログラムを記録した記録媒体。

Images