|
第2回 EJBとはどこがどう違うの？ それでは、CORBAはEJBと何が違うのでしょうか。この両者の相違点を端的に表しているのが図1です。 CORBAとEJBは、多くの共通する機能を提供しています。分散オブジェクト呼び出し機能、ネーミング?サービス、トランザクション?サービス、イベント?サービス、セキュリティ?サービスなど、各サービスの名称は異なることがありますが、機能的には類似しています。この両者が大きく異なるのは、EJBアプリケーションはEJBコンテナの中で実行されるという点です。このため、EJBアプリケーションは、リモート?メソッドの実装だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド?アロンで実行されます。 この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潜んでいるのです。
上の図からも推測できるように、機能的にCORBAはEJBのスーパーセットになっています。これは、EJBで可能なことはCORBAですべて実現できることを意味します。実際に、iPortal Application ServerやBorland AppServerなどの比較的新しいEJB製品の多くはCORBA上に構築されています。EJB 2.0では、CORBAのプロトコルIIOPや幾つかのCORBAサービスが必須になっているため、この傾向は今後さらに加速するでしょう。 逆の見方をすると、CORBAではアプリケーション?プログラマーが書かなければならなかった定型的な処理の多くの部分をEJBコンテナが担ってくれるので、プログラミングは簡単になります。例えば、連載第１回「まずはCORBAを復習しよう」で使ったAccountの例では、AccountHomeオブジェクトのインスタンスを作成して、そのオブジェクト?リファレンスをネーミング?サービスに登録するという処理は、EJBコンテナが自動的に行ってくれます。しかし、その一方で、アプリケーションのプログラミングは、EJBコンテナがサポートする範囲に縛られることになります。 従って、EJBとJ2EEが想定しているモデルに収まるアプリケーションの場合には、EJB本来の開発生産性の高さを享受することができますが、この枠を超える場合には、逆に非常に苦労することになります。例えば、ある装置の状態を常に監視して、それを上位のサーバに通知したり、上位サーバからの指示に応じて装置を制御するアプリケーションの場合、装置独自のプロトコルと上位サーバと通信するためのRMI/IIOPプロトコルを同時にサポートする必要があります。これをEJBで実現するのは、不可能ではないにしても、かなりトリッキーな実装が要求されるため、生産性が大幅に下がることになるでしょう。
上の例はかなり極端ですが、要はCORBAとEJBの長所と短所をよく理解して、適材適所で使い分けることが重要だということです。それでは、どのような場合にCORBAを選択して、どのような場合にEJBを選択すべきなのでしょうか。 まず、EJBのメリットは、アプリケーションのコーディング量が少なくなる点と、コンポーネント?プログラミングに向いている点です。上でも説明しましたが、EJBではmainプログラムを実装することなく、リモート?メソッドの実装だけでアプリケーションが作れてしまいます。また、使用するエンタープライズBeanの種類にもよりますが、トランザクションやオブジェクトの永続性の制御をコンテナに任せてしまうことも可能です。従って、EJBのモデルにぴったり当てはまるアプリケーションの場合、EJBを使用することで、比較的簡単に、しかも短期間にアプリケーションを構築することが可能になります。ただし、これはあくまでも一般論であり、実際の生産性は、個々のプログラマーのスキルやプロジェクトの性格にかなり依存します。 それでは、EJBのモデルにぴったり当てはまるのは、どのようなアプリケーションでしょうか。典型的なのは、既存のバックエンド?システムとの統合を必要としないWebアプリケーションです。特に、既存のEJBコンポーネントが利用できる場合には、さらなる生産性の向上が期待できます。バックエンド?システムと接続する必要がある場合には、次の3つのアプローチが考えられます。1つ目は、JNI（Java Native Interface）などを使って、接続相手ごとにコネクタを作成する方法です。2つ目は、接続相手側のパッケージ?ベンダが提供しているコネクタ?コンポーネントを使用する方法です。3つ目の方法は、次項で説明する方法ですが、CORBA/IIOP基盤にすべてのバックエンド?システムを統合し、EJBアプリケーションサーバもこの基盤に接続する方法です。この最後の方法が、汎用的で、最も拡張性に富んだ方法です。
CORBAはどのようなシステムに向いているのでしょうか？ この質問に対する私の答えは明確で、 「CORBAは、ほとんどの分散システムに向いています。ただし、開発生産性とプロジェクトの成否は、プロジェクト?マネージャとプログラマー、そしてアーキテクトのスキルにかかっています」 と答えています。もっとも、この後半部分はCORBAに限った話ではありませんが……。 CORBAは、EJBとは異なり、オブジェクトのライフサイクルをアプリケーション自身で管理する必要があります。例えば、オブジェクトのメモリへのページインやページアウトの処理（イビクションと呼んでいます）は、必要に応じてアプリケーション?プログラマーが自分でコーディングする必要があります。その代わり、柔軟でスケーラブルなアプリケーションを構築することが可能になります。また、トランザクションを使用する場合には、トランザクション?サービスのインターフェイスを使って、トランザクションの開始から終了までを自分で制御しなければなりません。このため、CORBAで高度なアプリケーションを開発するためには、ある程度のスキルが要求されます。 成功している多くのユーザー企業やシステム?インテグレータを見ると、ビジネス?ロジックを実装するプログラマーがその都度、基盤になるこれらのコードをスクラッチから書いているわけではありません。これらの企業では、優れたアーキテクトによってデザインされた、プロジェクトまたはその企業に共通のフレームワークが整備されており、プログラマーは基盤部分のコーディングに悩まされることなく、ビジネス?ロジックの実装に専念することができます。従って、ここでの開発生産性は、EJBに決して引けを取りません。さらに、こうしたフレームワークは、EJBコンテナのような一般的なものではなく、そのプロジェクトの用途に最適化されており、しかも拡張性に優れています。 逆に、次のような分野は、CORBAでなければ実現が困難です。 ■さまざまなプログラミング言語や多種多様なアーキテクチャで構築されたシステムの統合
■複数のネットワーク?プロトコルをサポートする必要のあるシステム ■さまざまなフロント?エンドから共通に利用されるアプリケーションサーバ
以上で、CORBAとEJBの長所と短所を理解していただけたと思います。次回は、フォード、ボーイング、DLJ direct SFG証券等の先進的な事例をご紹介しながら、CORBAが実際にどのように使われているのか、 CORBAベースのアプリケーションサーバの優位点はどこにあるのか、について解説する予定です。 |
|
|
