第2回　EJBとはどこがどう違うの？

　それでは、CORBAはEJBと何が違うのでしょうか。この両者の相違點(diǎn)を端的に表しているのが図1です。

　CORBAとEJBは、多くの共通する機(jī)能を提供しています。分散オブジェクト呼び出し機(jī)能、ネーミング?サービス、トランザクション?サービス、イベント?サービス、セキュリティ?サービスなど、各サービスの名稱は異なることがありますが、機(jī)能的には類似しています。この両者が大きく異なるのは、EJBアプリケーションはEJBコンテナの中で実行されるという點(diǎn)です。このため、EJBアプリケーションは、リモート?メソッドの実裝だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド?アロンで実行されます。

　この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潛んでいるのです。

図1　CORBAとEJBの関係

EJBで可能なことはすべてCORBAで実現(xiàn)可能

　上の図からも推測(cè)できるように、機(jī)能的にCORBAはEJBのスーパーセットになっています。これは、EJBで可能なことはCORBAですべて実現(xiàn)できることを意味します。実際に、iPortal Application ServerやBorland AppServerなどの比較的新しいEJB製品の多くはCORBA上に構(gòu)築されています。EJB 2.0では、CORBAのプロトコルIIOPや幾つかのCORBAサービスが必須になっているため、この傾向は今後さらに加速するでしょう。

　逆の見方をすると、CORBAではアプリケーション?プログラマーが書かなければならなかった定型的な処理の多くの部分をEJBコンテナが擔(dān)ってくれるので、プログラミングは簡単になります。例えば、連載第１回「まずはCORBAを復(fù)習(xí)しよう」で使ったAccountの例では、AccountHomeオブジェクトのインスタンスを作成して、そのオブジェクト?リファレンスをネーミング?サービスに登録するという処理は、EJBコンテナが自動(dòng)的に行ってくれます。しかし、その一方で、アプリケーションのプログラミングは、EJBコンテナがサポートする範(fàn)囲に縛られることになります。

　従って、EJBとJ2EEが想定しているモデルに収まるアプリケーションの場合には、EJB本來の開発生産性の高さを享受することができますが、この枠を超える場合には、逆に非常に苦労することになります。例えば、ある裝置の狀態(tài)を常に監(jiān)視して、それを上位のサーバに通知したり、上位サーバからの指示に応じて裝置を制御するアプリケーションの場合、裝置獨(dú)自のプロトコルと上位サーバと通信するためのRMI/IIOPプロトコルを同時(shí)にサポートする必要があります。これをEJBで実現(xiàn)するのは、不可能ではないにしても、かなりトリッキーな実裝が要求されるため、生産性が大幅に下がることになるでしょう。

CORBAとEJBの適材適所が重要

　上の例はかなり極端ですが、要はCORBAとEJBの長所と短所をよく理解して、適材適所で使い分けることが重要だということです。それでは、どのような場合にCORBAを選択して、どのような場合にEJBを選択すべきなのでしょうか。

　まず、EJBのメリットは、アプリケーションのコーディング量が少なくなる點(diǎn)と、コンポーネント?プログラミングに向いている點(diǎn)です。上でも説明しましたが、EJBではmainプログラムを?qū)g裝することなく、リモート?メソッドの実裝だけでアプリケーションが作れてしまいます。また、使用するエンタープライズBeanの種類にもよりますが、トランザクションやオブジェクトの永続性の制御をコンテナに任せてしまうことも可能です。従って、EJBのモデルにぴったり當(dāng)てはまるアプリケーションの場合、EJBを使用することで、比較的簡単に、しかも短期間にアプリケーションを構(gòu)築することが可能になります。ただし、これはあくまでも一般論であり、実際の生産性は、個(gè)々のプログラマーのスキルやプロジェクトの性格にかなり依存します。

　それでは、EJBのモデルにぴったり當(dāng)てはまるのは、どのようなアプリケーションでしょうか。典型的なのは、既存のバックエンド?システムとの統(tǒng)合を必要としないWebアプリケーションです。特に、既存のEJBコンポーネントが利用できる場合には、さらなる生産性の向上が期待できます。バックエンド?システムと接続する必要がある場合には、次の3つのアプローチが考えられます。1つ目は、JNI（Java Native Interface）などを使って、接続相手ごとにコネクタを作成する方法です。2つ目は、接続相手側(cè)のパッケージ?ベンダが提供しているコネクタ?コンポーネントを使用する方法です。3つ目の方法は、次項(xiàng)で説明する方法ですが、CORBA/IIOP基盤にすべてのバックエンド?システムを統(tǒng)合し、EJBアプリケーションサーバもこの基盤に接続する方法です。この最後の方法が、汎用的で、最も拡張性に富んだ方法です。

CORBAはどんなシステムに向いているのか

　CORBAはどのようなシステムに向いているのでしょうか？ この質(zhì)問に対する私の答えは明確で、

「CORBAは、ほとんどの分散システムに向いています。ただし、開発生産性とプロジェクトの成否は、プロジェクト?マネージャとプログラマー、そしてアーキテクトのスキルにかかっています」

と答えています。もっとも、この後半部分はCORBAに限った話ではありませんが……。

　CORBAは、EJBとは異なり、オブジェクトのライフサイクルをアプリケーション自身で管理する必要があります。例えば、オブジェクトのメモリへのページインやページアウトの処理（イビクションと呼んでいます）は、必要に応じてアプリケーション?プログラマーが自分でコーディングする必要があります。その代わり、柔軟でスケーラブルなアプリケーションを構(gòu)築することが可能になります。また、トランザクションを使用する場合には、トランザクション?サービスのインターフェイスを使って、トランザクションの開始から終了までを自分で制御しなければなりません。このため、CORBAで高度なアプリケーションを開発するためには、ある程度のスキルが要求されます。

　成功している多くのユーザー企業(yè)やシステム?インテグレータを見ると、ビジネス?ロジックを?qū)g裝するプログラマーがその都度、基盤になるこれらのコードをスクラッチから書いているわけではありません。これらの企業(yè)では、優(yōu)れたアーキテクトによってデザインされた、プロジェクトまたはその企業(yè)に共通のフレームワークが整備されており、プログラマーは基盤部分のコーディングに悩まされることなく、ビジネス?ロジックの実裝に専念することができます。従って、ここでの開発生産性は、EJBに決して引けを取りません。さらに、こうしたフレームワークは、EJBコンテナのような一般的なものではなく、そのプロジェクトの用途に最適化されており、しかも拡張性に優(yōu)れています。

　逆に、次のような分野は、CORBAでなければ実現(xiàn)が困難です。

■さまざまなプログラミング言語や多種多様なアーキテクチャで構(gòu)築されたシステムの統(tǒng)合

　今後、企業(yè)內(nèi)のバックエンド?システムとWebシステムをリアルタイムで統(tǒng)合して、取引先や顧客にサービスを提供するシステムが増えていきます。こうしたシステム統(tǒng)合には、2つのアプローチが考えられます。システムを１対１でアドホックに接続していくアプローチと、企業(yè)のバックボーンをCORBAのような汎用的な基盤で統(tǒng)一し、すべてのシステムをこの共通バスに接続していくアプローチです。ボーイングやフォードといった企業(yè)は、後者のアプローチを採用して成功しています。この場合、EJBを採用したフロント?エンドのWebアプリケーションも、IIOPを使用して共通基盤に接続することができます（下図參照）。

図2　CORBA/IIOPを基盤としたシステム統(tǒng)合

■複數(shù)のネットワーク?プロトコルをサポートする必要のあるシステム

　先ほど、固有プロトコルで裝置を監(jiān)視制御するシステムの例を挙げましたが、CORBAはほかのプロトコル?スタックやイベント?ループとの統(tǒng)合をサポートしているため、こうしたシステムに柔軟に対応することができます。この分野での典型的な例は、ネットワーク管理システム、製造ライン監(jiān)視制御システム、交通監(jiān)視制御システムなどです。

■さまざまなフロント?エンドから共通に利用されるアプリケーションサーバ

　フロント?エンド（クライアント）側(cè)の技術(shù)トレンドは、サーバ側(cè)に比べてめまぐるしく変化しています?，F(xiàn)在でも、フロント?エンド側(cè)は、サーブレット、JSP、ASP、CGI、NSAPIやISAPIなどのWebサーバ固有のサーバ拡張API、Visual Basic、C++やJavaのスタンドアロン?プログラムと多種多様です。フロント?エンド側(cè)のこうした急速な変化は今後も十分予想されます。こうしたフロント?エンドの変化に引っ張られることなく、サーバ側(cè)のビジネス?ロジックの実裝を長持ちさせたいのは、當(dāng)然の要求です。DLJ direct SFG証券では、アプリケーションサーバをCORBAで実裝することで、Webブラウザ、iモード端末、専用インターネット?ソフト（MARKETSPEED(TM) ）などの多様なフロント?エンドに対応しています（これらは、サーブレット、CGI、C++スタンドアロン?アプリケーションなどで実裝されています）。

次回のテーマは導(dǎo)入事例

　以上で、CORBAとEJBの長所と短所を理解していただけたと思います。次回は、フォード、ボーイング、DLJ direct SFG証券等の先進(jìn)的な事例をご紹介しながら、CORBAが実際にどのように使われているのか、 CORBAベースのアプリケーションサーバの優(yōu)位點(diǎn)はどこにあるのか、について解説する予定です。