[検証実験]Webシステム開発の効率化を検証する

第3回 フレームワークの効果を検証

---

次なる課題はセキュリティと可用性

　本記事では、Webアプリケーションの開発をスムーズに立ち上げる1つの方法として、

• 構築が手軽にできるWebコンテナとしてiWS
  
• iWSと連携し、ビジュアルに開発ができる統合開発環境（IDE）としてForte
  
• Webアプリケーションの開発フレームワークとしてWDC

を使った開発をご紹介しました。このようなやり方で、無理の少ないところからスタートし、Webアプリケーション開発が立ち上がってきたら、次にはどのような課題が出てくるのでしょうか。ここでもしつこく「軽やかカロリ〜」に活躍してもらって、考えてみましょう。

■プライバシーは丸裸のまま？

　もうすっかりご存じでしょうが、現状の「軽やかカロリ〜」では身長、体重、食べたものまですべて他人にばれてしまいます。そこで必要となるのが、ユーザー認証とアクセス制御です。

　手軽にできるユーザー認証としては、DBにユーザー情報のテーブルを持ち、ログイン画面やDB参照による認証処理、権限レベルに応じたサービス内容の制御など、すべてをアプリケーションで行うという方法があります。

　企業内ではLDAP＋プライベート認証局でユーザー管理を行っている、あるいはこれから行おうとしている、というところも多いでしょう。このような場合、JNDI（Java Naming and Directory Interface）を使ってアプリケーションサーバからLDAPサーバに認証を求め、認証されたユーザーの権限レベルに応じて、アプリケーションで実行できるメソッドを制限する、といった制御ができます。また、複数のアプリケーションサーバ間でシングルサインオンを実現することも可能です。

　アクセス制御とは違いますが、ユーザーを識別することで、個々のユーザーごとに画面やサービス内容をカスタマイズできるようにしたい、というような要望も出てくるかもしれません。

■万が一、人気サイトになってしまったら

　ユーザー認証とアクセス制御機能を備えてようやく世に出られるようになった「軽やかカロリ〜」が人気サイトになってしまい、アクセス数が極端に多くなったことでレスポンスが悪い、ときどき落ちる、という状況に陥ったとしたら、どうしたらよいでしょう（もちろん、こうなる前に手を打つべきですが）。

　原因を調査したところ、特別重たい処理もしておらず、単純にアクセスを分散させればよいとなったとすると、サーバを複数台用意し、その前にロードバランサを置くことが考えられます（このとき、Webアプリケーションのセッション管理の仕組みと、ロードバランサのセッション対応機能を合わせる必要があります）。

　しかし、一部に重たい処理があって、それを切り離せばパフォーマンスが改善できるといった場合は、重たい処理をEJBで実現し、Web層とEJB層を別マシンにして負荷分散を図る、ということも考えられます。この場合は、J2EE完全準拠のアプリケーションサーバを導入することになります（例としては、iPlanet Application Server（iAS）があります）。

　また、アクセス数が多くなるとメモリの使用量が上がったままになって動作が不安定になるという場合も考えられます。原因を調べ、サーバのチューニングやアプリケーションを改善することも必要ですが、システムの堅牢性の向上という点からも、EJB環境への移行が考えられます（ちなみにWDCにはEJB版もあり、プログラミング上ほとんど意識することなくスムーズにEJB環境に移行することができます）。

■なぜか非常に重要な任務を任されたら

　人気が出ても安定して動くようになった「軽やかカロリ〜」。それを見込んでか、非常に重要な任務を任されることになりました（あまりの重要さで内容はお伝えできません）。出された要求は、24時間、365日、一瞬たりともサービスをストップさせない、ということでした。

　この場合、システムの堅牢性と耐障害性がキーになります。ここまでくると、運用や監視体制も含めてかなり大掛かりになりますが、アプリケーションサーバに限りますと、複数台のサーバをクラスタリングし、セッション情報を共有することで、1台が落ちてもほかのサーバがセッションを受け継ぐことができる、フェイルオーバーの機能を持たせることになります。現在では J2EE完全準拠のアプリケーションサーバはフェイルオーバー機能も持っていますので、これらアプリケーションサーバの導入と、アプリケーションのEJB環境への移行を行うことになります。iPlanet Application Server（iAS）の場合は、各サーバがメモリ上でセッション情報を共有してフェイルオーバーの機能を実現するのですが、アプリケーションから見ると、仮想的な1台のアプリケーションサーバ上で動いているように見えるため、基本的にはプログラミング上の特別な対応は必要ありません。

　アプリケーションの作りとしては、トランザクションをより安全確実にするために、EntityBeanを使い、トランザクションをEJBコンテナに任せるようにすることも考えられます。

■ほかのシステムと連携することになったら

　ますます重要な役割を担うようになった「軽やかカロリ〜」ですが、やはり1人だけでさまざまな業務をこなすことはできません。そこでほかのシステムとの連携が必要になりました。

　レガシーシステムなどのエンタープライズシステムとの連携では、やはりEJB環境に移行し、JMS（Java Message Service）を使うことが考えられるでしょう（例えば、JMS準拠のiPlanet Message Queueを使うといった方法があります）。

　また、ほかのWebアプリケーションとの連携ということでは、Webサービスでの実現を目指すことになるでしょう。

◆

　この第3回では、Webアプリケーションを独自に開発する場合と、WDCを使う場合について比較しましたが、これは一から自前で開発することを否定しているわけではありません。基盤部分を含めて高い技術力を持つことで、ユーザーの要求を柔軟に実現するということもあれば、ビジネスロジックに特化して新たな価値を素早くユーザーに提供するということもあり、良質のシステムをユーザーに提供する方法は目的によっていろいろなのだろうと思います。

　第1回の冒頭でも述べましたが、J2EEベースでのアプリケーション開発にこれから本格的に手を出そうという方々、手を付けてはいるが苦しんでいるという方々も多いと思います。今回の記事が、特にそのような方たちにとって、何らかの形で助けになったならば幸いです。

　皆さんのWebアプリケーションが「軽やかカロリ〜」のように成功されることを祈りつつ、終わりにいたします。

3/3

INDEX
[検証実験]Webシステム開発の効率化を検証 第3回
	Page1 データベースからのデータの取得
	Page2 DBから取得したデータをブラウザに送信 ユーザーが変更した値を受け取りビジネスロジックを実行 変更されたデータでDBを更新
	Page3 次なる課題はセキュリティと可用性

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）