intra-mart Accel Platform / イントロダクション

第4版 2014-04-01

«  3.1. im-BizAPI(Java業務コンポーネント群)概要   ::   コンテンツ   ::   3.3. intra-mart のシステムアーキテクチャ  »

3.2. intra-mart のアプリケーション開発概要

intra-mart Accel Platform を使ったアプリケーションの開発において、開発者はブラウザ上に表示されるユーザインタフェースと、Webサーバ上で動作するビジネスロジックを作成することになります。

スクリプト開発モデルではプレゼンテーション・ページ(HTMLファイル)とファンクションコンテナ(サーバサイドJavaScriptファイル)の2つのファイルを作成します。この際、フレームワークで用意されているモジュール群(im-BizAPI)を活用することでさらに生産性を 向上させることができます。
../../_images/app_dev_jssp.png
JavaEE開発モデルでは、JSPファイルとServletなどのJavaコンポーネントで開発します。この際にも、フレームワークで用意されているモジュール群(im-BizAPI)をJavaEEフレームワーク(Seasar2(SAStruts+S2JDBC))とともに利用することで、煩雑なJavaEEによるWebシステム開発をさらに効率化するとともに、業務コンポーネントの再利用を促進することができます。
../../_images/app_dev_java.png

コラム

2つの開発モデルの使い分け

  • JavaEE開発モデル

    コンポーネント再利用や並行分散開発により、大規模システム開発において開発生産性を発揮します。

  • スクリプト開発モデル

    コンポーネントアーキテクチャではなく、1ファイルに業務処理を記述していくスタイルであるため、少人数システム開発において生産性は高くなります。

    • ただし大規模開発においても、コンポーネント再利用性の低い画面(マスタメンテナンスなど)においては軽量プログラミングを使用するなど、双方を組み合わせることでコスト削減が可能(すべてをJavaEEで開発することはオーバーヘッドが大きくなります)
    • im-BizAPI(Java業務コンポーネント)は両モデルから共通で利用することが可能です。

3.2.1. スクリプト開発モデルによるアプリケーション開発

「ファンクションコンテナ」の中には、ビジネスロジックがJavaScriptで記述されており、「プレゼンテーション・ページ」から呼び出され実行されます。その橋渡しの機能をintra-martが実現しています。

3.2.1.1. プレゼンテーションページ

プレゼンテーションページは、ユーザインタフェース部分に相当します。拡張子は「.html」で固定となります。
開発者またはエンドユーザは、“e Builder(スクリプト開発機能)”を利用して、Webベースのプレゼンテーションページを作成していきます。さらに、プレゼンテーションページはHTMLファイルであるため、Webシステムの開発において、ユーザインタフェース部分のみを切り出してホームページデザイナに作業を依頼することもできます。
ホームページ作成ツールなどから生成されるHTMLファイルに<IMART>タグを追加していくことで、ファンクションコンテナにあるJavaScriptを関連付けて、呼び出すことが可能になります。また、ユーザ定義関数を呼び出す<IMART>拡張タグも追加できます。
完成したHTMLファイルは、ページ登録をすることで、すぐにデータベースと連動して高速動作します。
../../_images/app_dev_jssp-pp.png

3.2.1.2. ファンクションコンテナ

多階層アーキテクチャのうちのApplication Runtime上で稼動するビジネスロジック部分に相当します。拡張子は「.js」で固定となります。ファンクションコンテナとプレゼンテーションページはワンセットとなっているため、ファイルラベル名は同一のものを使用します。

開発者は、プレゼンテーションページから呼び出されるJavaScriptを、ファンクション・コンテナの中に記述し作成していきます。
具体的には、 intra-mart Accel Platform に用意されている機能の中から必要なオブジェクトや関数群を選び出し、“e Builder(スクリプト開発機能)”で、それらオブジェクトや関数群を利用したサーバサイドで稼動するビジネスロジックをJavaScriptで記述し作成していきます。データベースへのSQL文もファンクション・コンテナの中に記述していきます。
実際のRDBとの接続やSQL発行は、 intra-mart Accel Platform から実行されるため、細かなセッション管理やトランザクション管理を開発者は意識する必要はありません。

作成されたビジネスロジックは、プレゼンテーションページの<IMART>タグから呼び出され実行されることになります。 intra-mart Accel Platform に用意されている機能の詳細は、「intra-mart APIリスト」に一覧記述されています。
これらスクリプトの記述はJavaScriptで行えるため、習得が難しいといわれるJavaを用いることなく、これまでのホームページ作成の延長でデータベースと連動した本格的なWebシステムの開発が可能になります。
また、 intra-mart Accel Platform ではスクリプト開発モデルにおいて、以下の生産性と保守性の向上に向けた大幅な機能強化を実施しました。
  • JavaScriptエンジンの最新化による高速化の実現
  • シンプルなURLになり、各画面への他システムからの連携が容易に。
  • 例外処理対応
  • Validation機能追加
  • ファイル処理時のStream対応(大容量のファイルの取り扱いを可能にしました)
  • 新Databaseアクセス用APIの提供(SQL文の外出し機構を実現しました)

3.2.2. JavaEE開発モデルによるアプリケーション開発

OSやWebアプリケーションサーバに依存しない共有プラットフォームとして、JavaEEによるWebシステム開発が普及してきました。
しかし、JavaEEによる開発はJavaをベースにしているため、オブジェクト指向などの高度な知識と経験が要求される点や、JavaEEでの前提知識が必要になる点など、敷居の高さが問題になってきています。さらに、JavaEE開発の規約にさえ準拠させれば、あとはいかようにでも組める自由さが、初心者にとってはかえって負担となり、SEによってバラバラな開発スタイルとなってしまう原因ともなります。
intra-mart Accel Platform では、これらの問題をJavaEEフレームワーク(Seasar2(SAStruts+S2JDBC))を利用することで解決し、JavaEE開発モデルの生産性を大幅に向上させています。

3.2.2.1. JavaEE開発のフレームワーク

JavaEEでのWebシステム開発には、構造的に共通な部分が多く、その事実を利用すると、開発生産性をさらに大きく向上させることができます。 intra-mart Accel Platform では、JavaEE開発で必要になる共通的な処理は、すべてJavaEEフレームワークとして用意して、開発者に委ねられる箇所はコンポーネントを作成してもらう形態となっています。

3.2.2.1.1. JavaEE開発モデルにおいてフレームワークを活用した際のメリット

JavaEE開発時にJavaEEフレームワークを利用することで以下のメリットがでてきます。

JavaEEベースの開発基盤
高度な知識が必要となる部分は隠蔽し、開発者はアプリケーションロジックを
コンポーネントとして作成する。前提知識がなくても完成したシステムはJavaEE
モデルの推奨型となり、MVCモデルの実現が容易(プログラム構造が統一でき
メンテナンス性向上)。
生産性の向上
共通的なものはすべてフレームワーク中に用意されているので、コンポーネントの
再利用性が高まりチーム全体の生産性が向上(コンポーネントのチーム共有と
並行分散開発による期間短縮)。
保守性の向上
コンポーネントの新規追加時にも元のアプリケーションにはまったく変更が
入らない仕組み。また機能変更時も該当コンポーネントのみの修正とし、
他の箇所への影響がない機構となる。
../../_images/app_dev_fw-custom.png
テスト工程期間の短縮と品質向上
テスト工程でフレームワーク部分の確認が不要、また問題発生時の切り分けが容易。
またDIコンテナにより、テスト用のモック (模型、仮実装)と正式コンポーネントの
入れ替えが簡単になるため、楽にモックを使えるようになる。
しかし、導入に際し、フレームワークを利用する以下のようなルールがあります。
  • 各コンポーネントの役割、実装すべき内容が決まっている。

    ルールに従うことで、部品化・共通化等の仕組みを設計時に考える必要がない
  • 一つのコンポーネントに様々な機能を実装することは極力避ける

    機能を詰め込みすぎると、プログラムの可読性・メンテナンス性・再利用性が低下してしまう

このルールを順守することにより、アプリケーションの構造を統一化が可能になり、フレームワークさえ理解していれば、誰でもメンテナンスが可能な構造になります。

3.2.2.2. Seasar2

Seasar2はJ2EE/JavaEEによる大規模開発を効率的に行うためのフレームワークで、従来より必要な設定ファイルを削減し、依存性を分離して記述することで生産性の高いプログラム開発を可能にします。
DIコンテナの「S2Container」とAOP機能を提供する「S2AOP」を中心に、データベースアクセスのための「S2Dao」、「S2JDBC」 Strutsフレームワークとの連携を容易にする「S2Struts」、「SAStruts」。動的なWebページ生成のための「S2JSF」など、関連する様々なソフトウェアやツールが開発・公開されています。
intra-mart Accel Platform では、このSeasar2プロダクトの中で、以下の2つをJavaEE開発フレームワークとして採用しています。
  • SAStruts(Super Agile Struts)
プレゼンテーション層(画面周り)のフレームワークWebフレームワークのデファクトスタンダードであるStrutsをラップし、より使いやすくしたもの
  • S2JDBC
Seasar2標準のデータベースアクセスフレームワークデータベースプログラミングの生産性を10倍以上高めることを目標として作成されたO/R Mapper

3.2.2.2.1. SAStrutsとS2JDBCの位置づけ

SAStrutsとS2JDBCは、Javaシステムアーキテクチャ(JavaEE BluePrint)上、以下の領域をカバーします。

../../_images/blueprints_seasar.png

コラム

  • JavaEE Blue Printとは

    JavaEEアプリケーションの開発ガイドラインで、機能面の仕様を解説したものではなく、どういった設計にてシステムを構築していけばよいかを、サンプルアプリケーションを例題として解説している「お手本」や「教科書」的なもの。

3.2.2.3. SAStrutsとS2JDBCによるアプリケーション開発

SAStrutsとS2JDBCによるアプリケーション開発では、Action、Form、JSP、DTO、Logic、Service、Entityなどのコンポーネントを作成して、クライアントからのリクエスト要求を以下の流れで処理されます。
../../_images/sa_s2jdbc.png

3.2.2.4. TERASOLUNA Global Framework

TERASOLUNA Global Framworkとは、NTTデータが公開しているJava開発フレームワークスタックです。( http://terasoluna.org/ )
フレームワークスタックとしては、以下の図のような、「SpringMVC 3.2+SpringFramework 3.2+JPA2.0、MyBATIS2.3.5+共通ライブラリ群」の構成になっております。
../../_images/tgfw_stack_on_iap.png

«  3.1. im-BizAPI(Java業務コンポーネント群)概要   ::   コンテンツ   ::   3.3. intra-mart のシステムアーキテクチャ  »