JRcServer プロジェクトの背景

  以前のエンタープライズ・システムは、メインフレームを利用した大規模な環境でのみ実現可能でしたが、とても高価なハードウェアであるため、限られた条件でしか導入出来ませんでした。 このことが、エンタープライズ・システムの利用範囲を狭める事になり、あまり発展しなかった原因であると考えられます。しかし現在では、下記のように通信インフラやハードウェアの高速化によって、 エンタープライズ・システムを安価に構築することができるようになりました。
      ・  インターネットなど通信インフラの普及。
      ・  WindowsやLinuxのサーバOS環境の登場。
      ・  ギガ単位のCPUや大容量化したメモリやハードディスクのハード面の強化。
      ・  Linuxに代表されるオープンソースの台頭。
  この変化はネットバブルが始まる前(1995年頃)から現在に至るまで、急速に発展を遂げており、その中で最も発展しているものとして「Webアプリケーション」があります。これは、 従来のように専用線やメインフレームなどの高価な環境でなくとも、インターネット回線やPC／Unixなどの安価な環境で構築可能であることから、多くの利用者が生まれ、 その結果急速に発展していったものと考えられます。しかしエンタープライズ・システムとしてのWebアプリケーションを開発する場合、多くの利点がある反面、難点も存在するようになりました。

  さらに、実際のWebアプリケーション開発は「短期間で開発できる」と言うイメージが定着している事から、少ない予算と少ない期間で開発することが多く、このことが、 豊富な経験を持つ開発者を導入し辛い状態を生み出しています。これらの要素が集約した結果、WAS環境によるエンタープライズ・システムの開発は、導入する側が考えられるよりも、難しいものになっています。 これらの要素が集約した結果WAS環境によるエンタープライズ・システムの開発は難しいものになっています。

  オープンプロジェクトJRcServer(Java-RemoteCommand-Server)

   本プロジェクトは、現在の WAS 環境におけるエンタープライズ・システム開発の問題を解決するための、ミドルウェアを目指しています。 特徴として JRcServer は以下のような問題を解決できます。

  (1) エンタープライズ・システムのWAS開発をやさしく、シンプルに

  J2EEは、EJBを利用するための環境であると言えます。しかし、EJBを利用する場合、JNDIや、JTAの機能と密接に絡み合っているため、複数のルールや取り決めに従う必要があります。たとえば、EJBを実際にプログラム実装する場合、以下のように５つのファイルを作成しなければいけません。
      ・  Enterprise-Beanクラス.
      ・  Componentインターフェイス.
      ・  Homeインターフェイス.
      ・  EJB-DDファイル.
      ・  各ベンダ固有のEJB-DDファイル.
  さらに、作成したEJBをWASに反映するために、EJB-JARファイルに変換してから、WASにデプロイしなければならず、１つの分散環境を利用するだけなのに、多くの作業が必要となります。 また、WebコンテナなどからEJBを呼び出す場合は、JNDIやJTAが強く関与するため、以下のように、スマートでない呼び出し手順を踏まなければなりません。

1:try{ 2: Context ctx = new InitialContext() ; 3: TestBeanHome th = ( TestBeanHome )ctx.lookup( "java:comp/env/ejb/test" ) ; 4: TestBean tb = th.create() ; 5:}catch( Exception e ){}

このように、EJBを分散環境として利用する場合、多くの作業やルールに縛られることで、開発効率が悪くなり、更にEJBを理解するには、J2EEの大半を理解しないと使いこなせない背景がある事から、これらかEJBを始める人にとって、大変な重荷となります。

そこで、JRcServerは上記のようなEJBの問題を解決し、より多くの環境で、やさしい開発環境を提供することが出来ます。具体的に言うと、EJBとは違って、JRcServerのコンポーネント実装は、５つのファイルを作成する必要はなく、１つのファイルだけで、実装が可能です。
その代わりに、JRcServerは作成コンポーネントを登録する時、EJBと比べて、１つの作業が増えます。増える内容として、JRcServerのJRcCNS[Java-RemoteCommand-Component-Naming-Service]に呼び出しコマンド名を登録しなければいけません。
また、JRcComponentをWebコンテナなどから呼び出す場合は、以下のように、一見JDBCを利用するような手順で呼び出す事が出来ます。

1:try{ 2: JRcConnection conn = JRcClientDriver.get( "username","passwd" ) ; 3: String ret = conn.execution( "serverName@ComponentName args" ) ; 4:}catch( Exception e ){}

上記の内容をまとめると、JRcServerは、EJBと比べ、以下の利点があります。

• ややこしいルールを実装レベルではなくJRcServerが吸収。
  ややこしいルール(JNDIやJTA)はJRcServer側が吸収しており、利用者はそれを気にせず、開発することが出来ます。
• 比較的馴染み深いインターフェイスを採用。
  JRcComponentのインターフェイスは、Mainメソッドによく似ています。 これにより、既に知っている環境で開発することが出来ます。

  Webの技術はJ2EEに限らないので、固定観念をあまり持たず、自由に発想できることがエンジニアの資質ではないかと思います。そのためJRcServerは、あえてJ2EEの規格に対応せず独自の規格によって、この問題を解決しています。

  (2) 多種多用の環境から利用が可能に

  EJBはORBであるため、対応していない環境からの呼び出しが出来ません。しかし、JRcServerは、コマンドライン形式であることから、多くの環境から呼び出すことが出来ます。そのため、Webコンテナでは、Perl、Ruby、PHPからも利用が可能で、他の環境として、Shell-Scriptからも利用できます。
  これにより、JRcServerは、呼び出し側の環境を考慮せずとも良いため、より良い開発環境を選択することができます。例えば、既にEJBに対応しているPHPで、エンタープライズ・システムを開発した場合、EJBより、JRcServerを選択したほうが、開発効率が向上します。また、J2EEが未経験で、他のWebコンテナの開発実績がある場合、 J2EEでないと開発困難な案件は、通常受注することは出来ませんが、JRcServerを利用すれば、受注できる可能性も上がります。
  このように、JRcServerは、従来のWAS環境とは違って、より良い開発環境を選択でき、対象案件の内容に応じた、利用ができるため、従来の開発手法を大きく変えることが可能です。さらに、１度作成したJRcComponentは、多くの条件から利用できるので、効率の良い再利用ができます。

  (3) セキュリティ面の強化

  現在のWebアプリケーションは、SQLインジェクション攻撃に代表されるハッキング行為によって、情報を改ざん／不正取得されることがあります。 しかし、この問題は開発側が安易にシステムを構築していることが原因で発生することがあることと、事がおきてからでないと対処出来ないことが大きな問題です。 JRcServerでは、以下の対策で個人情報やデータ操作などの攻撃を、未然に防ぐことが可能になります。

• 実行内容が全てログに記録される。
  インジェクション攻撃にあった場合、攻撃内容をいち早く把握できるので即座に対処／次回の防衛策も可能です。
• SQLインジェクション攻撃を引き起こさない。
  JRcServerは、SQLインジェクション攻撃の主な原因となる、java. sql.Statement を標準では利用出来ないようにしています。

このような単純な攻撃を防ぐには、単純な制約と単純な保守管理によって、防ぐことが出来ます。

もっと詳細を知りたい方に！ 是非、こちらをご覧下さい。