目次


クラウドに最適化した 4GL アプリケーションを開発してデプロイする

皆さんのデータ駆動型クラウド・アプリケーションに最適なプラットフォームは 3GL ですか、それとも 4GL ですか、あるいはその両方ですか?

Comments

クラウドを対象にアプリケーションを開発およびデプロイするとしても、従来の環境に応じたアプリケーションを開発、デプロイする場合より難しいことになるとは限りません。それは、開発者がクラウド対応の機能をそのまますぐに提供できるツールを選択する場合には、なおさら言えることです。

データ駆動型アプリケーションの場合、開発者は一般に、次の 2 つのタイプのプラットフォームから選択します。

  • 第 4 世代プログラミング言語 (4GL)
  • 第 3 世代プログラミング言語 (3GL)

いずれのタイプも、技術全体のなかでそれぞれに役割があり、ソフトウェア開発の歴史を通じて比較的人気のある時代がありました。

この記事では、プログラミング言語の主流が 3GL から 4GL に移り、最近になって再び 3GL に戻った経緯と理由を説明します。さらに、クラウド・アプリケーションを開発するにあたって、今日の開発者が直面する課題と、開発者に与えられる選択肢を探り、この課題に対する私たち独自の試みを紹介します。それは、4GL ツールと 3GL プラットフォームそれぞれの長所を組み合わせたプラットフォームです。

アプリケーション開発に使われるプログラミング言語の変遷

1990年代に登場した 4GL ツール (FoxPro、Delphi、Progress、Oracle Forms、Informix 4GL など) は、アプリケーションの開発と保守の全般的な複雑さを大幅に軽減するとともに、開発者の生産性を向上させることから、多大な人気を博しました。

4GL ツールは一般に、データ・アクセス、データ・バインディング、ネイティブ GUI コンポーネントのアセンブリーなど、ほとんどのアプリケーションの基礎となる共通層を自動化します。これらに関する懸念が軽減されれば、開発者はユーザー・エクスペリエンスと具体的なビジネス・ロジックに専念することができます。その結果、開発サイクルが短縮されるとともに、コード・ベースは無駄が省かれて単純化されます。しかも、コード・ベースを保守するチームは小規模にすることができ、その保守のみを専門で行うチームにする必要もなくなります。これは明らかに、3GL プラットフォームに勝る点です。

ところが、1990年代の終わり頃になると、4GL の限界が見え始めてきます。インターネットが急成長する真っ只中にあった当時、パラダイム・シフトを迎えていました。それは、ファット・クライアント、クライアント・サイドでの処理、そしてネイティブ・ウィンドウのインターフェースから離脱し、サーバー・サイドで計算処理を行い、通常はプレゼンテーション層からビジネス・ロジックを切り離すというパラダイムへの転換です。

興味深いことに、昔ながらの 4GL のなかで、インターネット・ベースのコンピューティングという新しいパラダイムに対する答えを提示したものは 1 つもありませんでした。このことから、多くの開発者は Web アプリケーションへの需要の高まりに応えるために、3GL プラットフォーム (主として Java および C#) に再び転向する結果となりました。

現在、新しい技術がさらに別のパラダイム・シフトを促していることにより、開発者は数々の新たな課題に直面しています。それは、新しいSaaS (Software as a Service) およびクラウド・ベースのアプリケーションに対する圧倒的な需要です。この新しく登場した SaaS アプリケーションは、Web ベースで配信しなければなりません。その配信は、セキュアかつエラスティック (弾力的) でフォルト・トレラントな性質を兼ね備えている必要があります。それに加え、SaaS アプリケーションにはネイティブ・アプリケーションの堅牢なユーザー・エクスペリエンスを提供することも求められます。こうした要求を満たすためには、あらゆる新しい手段が必要になります。以下に、その一部を記載します。

  • Ajax による完全な双方向性のサポート
  • クロスブラウザー・サポート
  • セキュリティー
  • マルチテナンシー
  • クラスタリングとロード・バランシング
  • 自動デプロイメント
  • 本番アプリケーションのライフサイクル管理 (バージョン管理)
  • 強力な Linux サポート

これらの要件がさらに追加されることから、開発者は難しい選択に迫られます。また、3GL と 4GL のどちらを選択するかという議論も、新しい様相を帯びてきます。それぞれの選択肢について、これらから詳しく説明します。

3GL によるクラウド・アプリケーションの構築

3GLに伴う基本的な問題は、生産性および保守の問題です。3GL 環境では、アプリケーションの基礎となる層を構築して保守するのは、開発者の責任です。この手法では、Web ベースの環境をきめ細かく制御できるとは言え、開発者の生産性が損なわれ、複雑さが増すという犠牲が伴います。

クラウド・アプケーションを構築するとなると、生産性の問題はさらに悪化してきます。クラウド・アプリケーションの場合に追加される要件は、さらに多くの基礎となる層を構築して保守しなければならないことです。そのため、コード・ベースは膨れ上がってくるものの、その大半は接続に対処するだけのコードが占め、実際のアプリケーションに固有の機能に関わるコードはほんの少しだけという事態になりかねません。

クラウド・ベースのアプリケーションが持つ特徴を開発者の観点でいくつか考えてみてください。

  • 開発者は、データ・アクセス層を実装するコードを作成する必要があります。これには、SQL クエリーを最適化し、結果をキャッシングして、アプリケーションのフットプリントを危険にさらすことなくパフォーマンスを最適化することも含まれます。
  • プレゼンテーション層を実装するのも、開発者の仕事です。ブラウザー・ベースのシステムの場合、プレゼンテーション層を実装するには、マークアップ、CSS、およびクライアント・サイドの JavaScript も生成する必要があります。
  • さらに、開発者は Ajax 層も構築して保守し、ブラウザーの DOM イベントをクライアント・サイドのスクリプトにバインドして、サーバー・サイドのビジネス・ロジックが呼び出されるようにする必要があります。そしてこのすべてを、毎回ビルドするたびに、ブラウザーおよびモバイル機器でテストし、デバッグしなければなりません。
  • 開発者は、エラスティック性 (弾力性)、キャパシティーの追加/削除、クラスタリング技術、ロード・バランシングなどのクラウド特有のトピックについても慎重に検討する必要があります。

開発者が行わなければならないタスクをここまで挙げましたが、アプリケーション固有の機能を開発し、効果的なユーザー・エクスペリエンスを明確に表現するという本命のタスクにはまだ辿り着いていません。

実際のところ、3GL チームはアプリケーションの基礎となる層に特化してフォーカスしたチームでなければならないため、アプリケーションのコア機能を提供する能力が損なわれてしまう可能性があります。

この問題に対する一般的なソリューションは、サード・パーティーのフレームワークを利用することです。つまり、具体的な機能を上位レベルで抽象化した本質的に再利用可能なコードとクラスを利用することです。この手法によって開発の負担は軽くなりますが、このソリューションに欠点がないわけではありません。

ソフトウェア・チームは、互換性のあるバージョンの評価、統合、保守を行い、それに関するトレーニングを行うなどの作業を行わなければなりません。例えば、最近の ERP アプリケーションをクラウド対応にするには、基礎となる層に対処するために、10 から 30 のフレームワークが必要となってきます。

開発と保守の負担が増えることを考えると、4GL を再検討したほうが有益かもしれません。そこで、従来の 4GL ツールがクラウド・ベースのアプリケーションには適していない理由、そしてその欠点を解消するために考えられる方法を詳しく検討します。

従来の 4GL によるクラウド・アプリケーションの構築

アーキテクチャーの観点から見ると、4GL は、アプリケーションの基礎となる層に対処するようにあらかじめ選択されて適切にオーケストレーションされた一連のフレームワークです。これらのフレームワークを保守する負担は 4GL ベンダーが引き受けるため、開発者は再びユーザー・インターフェースとコアのビジネス・ロジックに専念できるようになります。それに加え、4GL は開発者の作業を楽にするために、通常は GUI を視覚的に設計するためのグラフィカル・エディター、そしてユーザー駆動型のイベントを特定のビジネス・ロジックに結び付ける専用のスクリプト言語および API を提供します。

その利点は言うまでもなく、生産性の向上と複雑さの軽減です。そして、そのために支払う犠牲は、柔軟性です。4GL ベンダーが拡張性のオプションだけでなく、ソース・コードまで提供するのでない限り、開発者はツールの制限内でしか操作することができません。開発者にとっては、この点がフラストレーションとなるはずです。拡張するにしても、従来の 4GL では多くの場合、独自仕様の言語、プロトコル、さらにはデータベースを使用しているという点が、統合および拡張をさらに難しくします。けれどもクラウド・アプリケーションのコンテキストで最大の制約となるのはスケーラビリティーです。

最大の制約: スケーラビリティー

従来の 4GL ツールでスケーラビリティーが限られている根本原因は、4GL が基礎とするアーキテクチャーにあります。従来の 4GL は、2 層設計を使用します。これは本質的に、ネイティブ・クライアントがデータベースに直接接続することを意味します。このセットアップは、ローカル・エリア・ネットワーク (LAN) で実行される小規模なインストール・ベースを対象に最適化されています。4GL ツールは、大規模な並行性をサポートすることができません。なぜなら、追加するクライアントごとに独自のデータベース接続が必要となるからです。アプリケーションにアクセスするユーザーが増えて接続が多くなりすぎると、データベースに負担がかかり、データベースシステム全体のパフォーマンスが低下する結果となります。

広域ネットワーク (WAN) を介して 4GL ツールを実行できない理由は、以下のとおり、セキュリティーおよびパフォーマンスに関連します。

  • 組織が企業ファイウォールを介してデータベースを公開することはできないため。
  • ファット・クライアントが WAN を介してデータベースに接続しなければならない場合、2 層システムのパフォーマンスは低下するため。

フェイク・クラウド手法

この WAN との不適合を克服するためによく使用される方法に「フェイク・クラウド」手法があります。フェイク・クラウド手法は、一般に、ターミナル・サービスや Citrix、あるいは VDI などのビデオ・ストリーミング技術を使用して、ネイティブ・クライアントを LAN 内で実行し、そのビデオ・イメージを WAN を介してリモート・クライアントに投影するというものです。

この手法ではリモート・ユーザーに対してネイティブ・クライアントを複製することから、2 層システムを WAN を介してデプロイする際のセキュリティー問題は解消されます。さらに、既存のアプリケーションを変更する必要はないため、単純なソリューションになります。

それでもやはり、フェイク・クラウド手法は、2 層システムに伴うスケーラビリティーの問題に対処するわけではありません。この手法によってデータベース並行処理の負担が軽減されることはなく、必要となる技術には、多くの場合、法外な費用がかかります。要するに、フェイク・クラウド手法は間に合わせの手法なのです。

結局のところ、2層システムではクラウド・アプリケーションの要件に対応することができません。

だからと言ってブラウザーがネイティブ・クライアントに勝っているというわけではありません

ネイティブ・クライアントは過去の遺物であり、新しいアプリケーションのすべてがブラウザー・ベースでなければならないと言っているわけではありません。ほとんどの開発者は、「クラウド」と言うと、ブラウザー・ベースのアプリケーションを意味すると決めかかっていますが、n 層技術を使用すれば、ネイティブ・クライアントでも WAN を介してデプロイすることは可能です。

実際、クライアント・サイドのファイルシステム、ハードウェア、ソフトウェアなどを扱うといった、ブラウザーではどうしても対処できないタスクには、ネイティブ・クライアントが必要です。けれども従来の 4GL のアーキテクチャーは、このような「スマート・クライアント」技術を実現するには適していません。

従来の 4GL に備わっている生産性および単純さと、クラウドに最適化した一連の 3GL フレームワークの柔軟性およびスケーラビリティーを 1 つのプラットフォームに統合することはできないのでしょうか?

新しい 4GL によるクラウド・アプリケーションの構築

新しいプラットフォームを選択する際に、開発者が考慮しなければならないことはたくさんあります。以下に、クラウドに最適な新しい 4GL が満たすべき要件のいくつかを要約します。

  • 次世代の 4GL プラットフォームは、サーバー・サイドのコンピューティングの需要に応じるために、n 層アーキテクチャーを提供しなければなりません。この設計パターンは、クライアントとデータ層との間の接続を仲介する中間層にアプリケーション・サーバーを組み込みます。この手法だと、データベース接続をプールしてクライアント間で共有できるため、高度な並列処理への対応能力が飛躍的に向上します。さらに、n 層アーキテクチャーでは、データベースを企業のファイアウォールで保護しつつ、アプリケーションをセキュアに WAN を介してデプロイすることができます。アプリケーション・サーバー層もクラウドへのデプロイメントに応じて最適化し、セキュリティー、マルチテナンシー、クラスタリング、ロード・バランシング、自動デプロイメント、本番アプリケーションのライフサイクル管理 (バージョン管理) を組み込む必要があります。
  • 新しい 4GL プラットフォームは、ネイティブ・クライアントのデプロイメントに対しても、ブラウザー・ベースのデプロイメントに対しても、堅牢に対応できる方法を提供しなければなりません。プラットフォームがこれらの方法を、単一のコード・ベースから何も作成し直すことなく提供できれば、開発にかかる時間と保守作業が大幅に減ることになります。

    真のスマート・クライアントは、インターネット経由で標準プロトコル (具体的には HTTP と SSL) を使用して、プロキシーおよびファイアウォールの問題を回避して動作します。真のスマート・クライアントは、ローカルで実行されるアプリケーションやブラウザー・ベースのアプリケーションと同じように応答性に優れており、どのオペレーティング・システムに対してもインストールすることなくデプロイされ、自らを自動的に更新し、ローカルのファイルシステム、ハードウェア、ソフトウェアとの統合を行います。

  • 堅牢なブラウザー・ベースのデプロイメントを可能にするために、4GL は最近のすべてのブラウザーを、プラグインや独自仕様の技術を使用することなく、サポートできなければなりません
    • プラットフォームは、マークアップ、CSS、およびクライアント・サイドの JavaScript を動的に生成する必要があります。
    • 開発者が簡単に GUI イベントをキャプチャーしてビジネス・ロジックにバインドし、ページを最新の表示に更新しなくてもそれらのビジネス・ロジックが実行されるように、Ajax 層を完全に自動化する必要があります。
    • ビジネス・ロジックとプレゼンテーションが、明確に分離されなければなりません。アプリケーション固有のコードをブラウザーに公開しないようにすることで、セキュリティーとパフォーマンスを改善します。そしておそらく最も重要な点として、ブラウザー・ベースのアプリケーションをネイティブ・アプリケーションと同じぐらい簡単にデバッグできるようにする必要があります。
  • クラウドに最適化されたプラットフォームは、業界標準をサポートすると同時に、データベース・ベンダーとオペレーティング・システムに関して中立を維持しなければなりません。例えば、MSSQL データベースを使用して Windows マシンで開発およびテストしたアプリケーションを、クラウドの本番環境では Postgresql データベースを使用して Linux インスタンス上で実行できるようでなければなりません。したがって、新しい 4GL プラットフォームは、あらゆるリレーショナル・データベースとオペレーティング・システムをサポートする必要があります。
  • 次世代の 4GL プラットフォームは、堅牢かつ拡張可能な統合開発環境 (IDE) を提供する必要があります。従来の 4GL とは異なり、新しいプラットフォームは独自仕様の言語やプロトコルを導入するべきではありません。新しいプラットフォームは、SVN (Subversion) などの標準的なバージョン管理システムをサポートし、すべてのコードの自動補完、文書化、デバッグ、リファクタリング、プロファイリング、およびユニット・テストに対応可能でなければなりません。

以上、さまざまな要件を取り上げましたが、クラウドに最適化された新しい 4GL は、従来のセットアップとはかなり異なることが明らかになったはずです。ただし、概念に違いはありません。それは、開発者の生産性を大幅に向上させる一方、デプロイメントと保守の複雑さを軽減するためのツールを提供することです。

ここからは、以上の要件に対処するために 4GL を基に新たに作成した実際のプラットフォームを見て行きましょう。

これまでにないプログラミング言語の組み合わせによるクラウド・アプリケーションの構築

私たちが使用している、3GL と 4GL の機能を組み合わせた手法は、従来の 4GL に伴う制約のいくつかを解消し、以下の利点をもたらします。

  • 複合ビジネス・アプリケーションを短時間で開発できます。
  • ローカルにデプロイすることも、インターネットを介してデプロイすることもできます。
  • スケーラブルなスマート・クライアント技術を提供します。
  • 標準ベースのプラットフォームになります。

開発、デプロイメント、および統合用スイートとして私たちが開発したプラットフォームでは、ネイティブ・クライアントでもブラウザー・アプリケーションでも、開発者が単一のコード・ベースから素早くビルドして、パブリック・クラウドやオンプレミス・クラウド、さらには内部システムに迅速にデプロイすることができます (図 1 を参照)。

図 1. アーキテクチャー
アーキテクチャー
アーキテクチャー

この記事の残りでは、このアーキテクチャーについて説明し、3GL と 4GL の機能を使用してアプリケーションをクラウドにデプロイする単純な開発環境の例を紹介します。

n 層デプロイメント・アーキテクチャー

この Servoy 環境が使用するのは、クロスデータベース・サポート、拡張アプリケーション・サーバー、そしてプレゼンテーション層に多種多様なデプロイメント・オプションを組み込んだ n 層アーキテクチャーです。それぞれの層について、以下に詳しく説明します。

データ・アクセス層
このアーキテクチャーを構成するデータ・アクセス層 (図 1 の一番下の層) は、データベースにとらわれません。特定のデータベースに依存しないように、JDBC、Hibernate、および Servoy 拡張機能の組み合わせを使用しているため、IBM DB2、Microsoft SQL Server、Oracle、Sybase、MySQL、Postgresql などで稼働します。そのために開発者が特定のコードを作成する必要はありません。

アプリケーション・サーバー層
Servoy Application Server (図 1 の下から 2 番目の層) は、接続されたクライアントに代わってデータ・トランザクションを管理する、高度なアプリケーション・コンテナーです。このサーバーが受け持つ数多くの任務には、例えば以下に挙げるものがあります。

  • デプロイメントおよびライフサイクル管理
  • セキュリティーの実施
  • HTML、CSS、およびクライアント・サイド JavaScript の生成
  • 接続されたクライアントとの双方向通信
  • 状態管理
  • クラスタリング
  • ロード・バランシング
  • データベースのコネクション・プーリング
  • データのブロードキャスト

ビジネス・ルール層
ビジネス・ルール層 (図 1 の下から 3 番目の層) は、すべてのロジックを実行する層です。ロジックは、クライアント・サイドとサーバー・サイドの両方で実行可能です。

Web クライアントの場合、ロジックが実行されるのは常にサーバー・サイドです。ビジネス・ルールをブラウザーにデプロイすると、エンド・ユーザーにこれらのルールが公開されるため、実行およびパフォーマンスの制御が制限され、デバッグが非常に複雑な作業になります。ビジネス・ルールをサーバー・サイズに保持することで、これらの問題がすべて回避されます。

スマート・クライアントは、コードをローカルでも、サーバー・サイドでも実行することができます。コードをローカルで実行すると、サーバーから負荷が取り除かれるため、大抵は対話性が向上することになります。コストのかかる処理やデータ量の多い処理でも、ヘッドレス・クライアントを使用すればサーバー・サイドで実行することができます。サーバー・サイドで継続的に、あるいは決められた時間間隔で、もしくは特定の時刻に、タスクが実行されるようにスケジューリングするには、バッチ・プロセッサーを使用することができます。

プレゼンテーション層
プレゼンテーション層 (図 1 の一番上の層) は、エンド・ユーザーに対してアプリケーションを視覚化するために使用します。ネイティブ・クライアントの場合、アプリケーションはネイティブ・オペレーティング・システムのルック・アンド・フィールでレンダリングされます。ブラウザー・アプリケーションの場合には、このプラットフォームがマークアップ、CSS、JavaScript、さらに Ajax を生成し、ユーザー・インターフェースを動的エクスペリエンスに対応させます。そのために Apache Wicket フレームワークを採用したことから、私たちはこのオープソース・プロジェクトに大きく貢献しました。

このプラットフォームは、HTTP、SOAP、および REST 接続のミドルウェア・サーバーとして機能する Web サービスをパブリッシュする機能も備えています。

開発環境

私たちの開発環境には、WYSIWYG (What-You-See-Is-What-You-Get) グラフィカル・フォーム・ビルダーが統合されています。これは大半の 4GL プラットフォームでは通常のことで、GUI コンポーネントを生成するのに大量のコードが必要となる 3GL 環境に比べて生産性に優れています。

この環境には、高度なデータ・モデリング・ツール、スクリプト/デバッグ・エンジン、堅牢な API も用意されています。これらのコンポーネントは、従来の 4GL と同じように本質的に単純でありながら、最新のアプリケーションを構築するために必要な高度な機能を提供します。アプリケーション全体は、多数の単純なメタデータ・テキスト・ファイルとして保管されるため、開発者のお好みのバージョン管理システムと簡単に同期します。

開発ツールは、オープンソースの業界標準 Eclipse 統合 IDE のプラグインとして提供されます。

このプラットフォームでの基本的な開発単位は、「ソリューション」と呼ばれます。ソリューションには、1 つのアプリケーションのフォーム、スクリプト、およびデータ・モデリング要素のすべてが含まれます。その一方、ソリューションには、別のソリューションをモジュールとして含めることも可能です。モジュール方式を使用することで、開発者はコンポーネントおよびコードを複数のアプリケーションで再利用することができます。

データ接続
このプラットフォームは、JDBC (Java Database Connectivity) 技術を使用して、あらゆるリレーショナル・データベースに接続します。接続を確立するために必要なのは、JDBC ドライバーと接続パラメーターだけです。

開発者は、このプラットフォームの IDE 内でデータベースを設計することも、あるいは任意の DB 管理ツールを使ってデータベースを設計することもできます。実行時のデータベース・トランザクションは、すべてプラットフォームが管理します。プラットフォームが SQL クエリーを発行し、結果をキャッシュに入れて、フォームおよび API オブジェクトにバインドします。ユーザーに SQL を扱った経験がなくても構いません。

図 2. デザイナーで視覚的にデータベース接続を構成します
デザイナーで視覚的にデータベース接続を構成します
デザイナーで視覚的にデータベース接続を構成します
図 3. データ接続が構成されるとプラットフォームがテーブル構造をイントロスペクトします
データ接続が構成されるとプラットフォームがテーブル構造をイントロスペクトします
データ接続が構成されるとプラットフォームがテーブル構造をイントロスペクトします

フォームの作成
開発者は、GUI 要素を生成するためのコードを作成する必要も一切ありません。プラットフォームが包括的なコンポーネントのパレットを提供し、これらのコンポーネントをそのままフォームに配置できるようになっています。コンポーネントには、標準的なあらゆるコントロール (ボタン、テキスト・フィールド、コンボ・ボックス、ラジオ・ボタン) だけでなく、特殊なコントロール (先行入力フィールド、ツリー・ビュー・コントロール、状況依存ポップアップ・メニュー) もあります。

さらに、開発者は、ソリューションの中でイメージ・メディアやアイコンを自由に使用することもできます。すべてのコンポーネントは CSS を使用してスタイル設定されているため、スタイル・シートを調整するだけで、アプリケーション全体のスキンを簡単に変更することができます。このプラットフォームは、フォーム継承によるオブジェクト指向の設計もサポートするので、コンポーネントおよびフォームレベルのコードを継承したり、オーバーライドしたりできるようになっています。

フォームは指定されたデータベース・テーブルにバインドされます。テーブルの列を表示および編集するには、コードや SQL を作成しなくても、フォームに含まれるすべてのデータ・コントロールを使用することができます。その一方、フォームは 1 つのテーブルの中での動作に制限されるわけではありません。リレーション・オブジェクトを使用して、1 つのフォームで複数のテーブルからのデータを表示し、編集することも可能です。

図 4. ユーザーはフォーム・ウィザードでデータ・ソース、CSS などを指定することができます
ユーザーはフォーム・ウィザードでデータ・ソース、CSS などを指定することができます
ユーザーはフォーム・ウィザードでデータ・ソース、CSS などを指定することができます
図 5. フォームを変更するにはフォーム・エディターを使用します
フォームを変更するにはフォーム・エディターを使用します
フォームを変更するにはフォーム・エディターを使用します

データ・リレーションのモデリング
2 つのテーブルの間のリレーションを定義するには、2 つのテーブルをリンクするキー列を指定します。通常のリレーションとして最も一般的な例は、顧客と注文のリレーションですが、このプラットフォームは、複数のキーと (「=」以外の) 複数の演算子を使用するリレーションをサポートするように設計されています。リレーションのキー定義の一部としてスクリプト変数を使用し、リレーションを動的にすることもできます (例えば、指定した 7 日の間に発生した顧客と注文のリレーションなど)。

図 6. リレーションはリレーション・デザイナーで構成します
リレーションはリレーション・デザイナーで構成します
リレーションはリレーション・デザイナーで構成します

コードを作成することなく、グラフィックで定義するリレーションは、アプリケーションでいくつもの目的を果たします。

  • まず何よりも、フォーム上のデータを表示/編集するために使用することができます。
  • それに加え、リレーションによってフォーム全体を別のフォームの中に表示することができます。

この場合、フォームにネストされる別のフォームのレコード・セットは、リレーションによって制約されます。前述の例で言うと、リレーションを使用して顧客フォームに 2 つ目のフォームとして注文を追加することにより、顧客フォームの中に顧客の最近の注文のリストを表示することができます。このプロセスを重ねれば、コードや SQL を一切作成することなく、完全にデータで駆動される高度なユーザー・インターフェースを作成することができます。

図 7. リレーションを使用して、フォーム全体を別のフォームの中に組み込むことができます
フォームに収容されたフォーム
フォームに収容されたフォーム
図 8. 実行時にブラウザーのフォームに表示された顧客の注文
表示された顧客の注文
表示された顧客の注文

データの検索とフィルタリング
SQL を作成しなくても高度なデータ検索を実行できるように、このプラットフォームには「検索モード」という機能が用意されています。検索モードでは、フォーム内のデータがバインドされたフィールドのすべてを、検索基準として使用することができます。検索が実行されると、レコードを返すために必要な SQL が生成されます。検索基準は、ユーザーが手動で入力することも、プログラムによって入力することもできます。このプラットフォームの検索モードは、広範な演算子、論理演算子、ワイルドカード文字列検索などに対応可能です。

図 9. 3 行のコードだけで、SQL を使わない高度なデータ検索
SQL を使用しないデータ検索
SQL を使用しないデータ検索

ビジネス・ロジックの実装
私たちの環境が主要なプログラミング言語として使用するのは JavaScript です。この環境によって公開される自己文書化された堅牢な JavaScript API を使用することで、ほとんどのプログラミング・タスクを実現します。

従来、スクリプト言語は常に、コンパイル型言語を大幅に上回る柔軟性と生産性を提供してきましたが、インタープリター型の性質を持つことから、スクリプト言語には以下の点に関連する欠点も持ち合わせています。

  • デバッグが困難であること
  • パフォーマンス上の問題
  • 弱い型付けと強い型付け
  • コードのリファクタリング

これらの問題に対処するために、私たちは Mozilla の Rhino プロジェクトを実装して拡張しました。Rhino は Java ベースの JavaScript エンジンです。その内部では、プラットフォームで使用するすべての JavaScript 関数が Java クラスにマッピングされます。この手法は、Pure Java コードのパフォーマンスを実現するとともに、JavaScript の生産性を高めて複雑さを軽減します。さらに、開発者が Java に慣れているとしたら、Java でコードを作成することもできます。このことは通常、サード・パーティーの Java ライブラリーを統合する際に重宝します。

さらに大きな問題の 1 つとなったのは、デバッグです。その解決法として私たちが共同で創設したのが、動的言語のデバッグ用ツールを提供する DLTK (Dynamic Language Toolkit) という名前の Eclipse プロジェクトです。最近、このプロジェクトは、コードの高度なリファクタリングを可能にする拡張機能を追加して、強い型付けもサポートするように拡張されました。詳細については、「参考文献」を参照してください。

図 10. この JavaScript メソッドは、選択されたテキスト・フィールドの設計時にデータ変更イベントにバインドされます
変更イベントにバインドされた JavaScript メソッド
変更イベントにバインドされた JavaScript メソッド
図 11. データ変更イベントを処理する JavaScript コード
データ変更イベントを処理する JavaScript コード
データ変更イベントを処理する JavaScript コード
図 12. この JavaScript メソッドは、実行時にフィールドのデータが変更されると実行されます。
JavaScript メソッドの実行
JavaScript メソッドの実行

デプロイメント環境

開発が完了したアプリケーションは、私たちが使用しているアプリケーション・サーバーに簡単にデプロイすることができます。このプロセスにかかる時間は、わずか数秒です。数回のクリック操作で、プロジェクトを開発環境からエクスポートして、アプリケーション・サーバーにインポートすることができます。

インポートが完了すると、アプリケーションはクロスプラットフォームのセルフインストール・ネイティブ・クライアント兼クロスブラウザー Web アプリケーションとして、世界中で使用できるようになります。その後のビルド作業は常に同じステップに従い、1 回のクリックでロール・バックおよびロール・フォワードできるアプリケーション・サーバーが、同じアプリケーションの多数の本番バージョンを管理します。

その上、このインポート・プロセスではオプションでデータ・モデルを更新して、開発データベースのスキーマ変更を自動的に本番環境にプッシュすることもできます。

アプリケーションのライフサイクル管理が大幅に単純化されることによって、開発者は思いのままに、さらに意欲的なビルド・スケジュールを追求し、ユーザーを満足させ続けることができます。

まとめ

クラウドに対応したアプリケーションを開発するのは、従来の環境を対象としたアプリケーションを開発する以上に難しいことではないはずです。

この記事では、3GL プラットフォームと 4GL プラットフォームの従来のバージョンおよび最近のバージョンでのクラウド・アプリケーションの開発について概説した後、私たちが独自に開発したプラットフォーム内部での作業について詳しく説明しました。このプラットフォームは、3GL と 4GL 両方のクラウド指向のベスト・プラクティスを利用するように設計されています。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=825799
ArticleTitle=クラウドに最適化した 4GL アプリケーションを開発してデプロイする
publish-date=07192012