神马文学网第2回 EJBとどこが違うの？
来源：百度文库 编辑：神马文学网 时间：2024/04/17 05:12:46
第2回 EJBとはどこがどう違うの？
前回は、CORBAの基礎を復習しました。 今回は、CORBAとEJBの違いについて説明します。CORBAとEJBは、e-ビジネスを構築する上でともに重要で、しかも仲のいい兄弟のような存在です。この2つの技術を適材適所でうまく使い分けることが、システム構築の成功の鍵になっています。
それでは、CORBAはEJBと何が違うのでしょうか。この両者の相違点を端的に表しているのが図1です。
CORBAとEJBは、多くの共通する機能を提供しています。分散オブジェクト呼び出し機能、ネーミング?サービス、トランザクション?サービス、イベント?サービス、セキュリティ?サービスなど、各サービスの名称は異なることがありますが、機能的には類似しています。この両者が大きく異なるのは、EJBアプリケーションはEJBコンテナの中で実行されるという点です。このため、EJBアプリケーションは、リモート?メソッドの実装だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド?アロンで実行されます。
この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潜んでいるのです。
図1 CORBAとEJBの関係
EJBで可能なことはすべてCORBAで実現可能
上の図からも推測できるように、機能的に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の長所と短所をよく理解して、適材適所で使い分けることが重要だということです。それでは、どのような場合に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に限った話ではありませんが……。
CORBAは、EJBとは異なり、オブジェクトのライフサイクルをアプリケーション自身で管理する必要があります。例えば、オブジェクトのメモリへのページインやページアウトの処理（イビクションと呼んでいます）は、必要に応じてアプリケーション?プログラマーが自分でコーディングする必要があります。その代わり、柔軟でスケーラブルなアプリケーションを構築することが可能になります。また、トランザクションを使用する場合には、トランザクション?サービスのインターフェイスを使って、トランザクションの開始から終了までを自分で制御しなければなりません。このため、CORBAで高度なアプリケーションを開発するためには、ある程度のスキルが要求されます。
成功している多くのユーザー企業やシステム?インテグレータを見ると、ビジネス?ロジックを実装するプログラマーがその都度、基盤になるこれらのコードをスクラッチから書いているわけではありません。これらの企業では、優れたアーキテクトによってデザインされた、プロジェクトまたはその企業に共通のフレームワークが整備されており、プログラマーは基盤部分のコーディングに悩まされることなく、ビジネス?ロジックの実装に専念することができます。従って、ここでの開発生産性は、EJBに決して引けを取りません。さらに、こうしたフレームワークは、EJBコンテナのような一般的なものではなく、そのプロジェクトの用途に最適化されており、しかも拡張性に優れています。
逆に、次のような分野は、CORBAでなければ実現が困難です。
■さまざまなプログラミング言語や多種多様なアーキテクチャで構築されたシステムの統合
今後、企業内のバックエンド?システムとWebシステムをリアルタイムで統合して、取引先や顧客にサービスを提供するシステムが増えていきます。こうしたシステム統合には、2つのアプローチが考えられます。システムを１対１でアドホックに接続していくアプローチと、企業のバックボーンをCORBAのような汎用的な基盤で統一し、すべてのシステムをこの共通バスに接続していくアプローチです。ボーイングやフォードといった企業は、後者のアプローチを採用して成功しています。この場合、EJBを採用したフロント?エンドのWebアプリケーションも、IIOPを使用して共通基盤に接続することができます（下図参照）。
図2 CORBA/IIOPを基盤としたシステム統合
■複数のネットワーク?プロトコルをサポートする必要のあるシステム
先ほど、固有プロトコルで装置を監視制御するシステムの例を挙げましたが、CORBAはほかのプロトコル?スタックやイベント?ループとの統合をサポートしているため、こうしたシステムに柔軟に対応することができます。この分野での典型的な例は、ネットワーク管理システム、製造ライン監視制御システム、交通監視制御システムなどです。
■さまざまなフロント?エンドから共通に利用されるアプリケーションサーバ
フロント?エンド（クライアント）側の技術トレンドは、サーバ側に比べてめまぐるしく変化しています。現在でも、フロント?エンド側は、サーブレット、JSP、ASP、CGI、NSAPIやISAPIなどのWebサーバ固有のサーバ拡張API、Visual Basic、C++やJavaのスタンドアロン?プログラムと多種多様です。フロント?エンド側のこうした急速な変化は今後も十分予想されます。こうしたフロント?エンドの変化に引っ張られることなく、サーバ側のビジネス?ロジックの実装を長持ちさせたいのは、当然の要求です。DLJ direct SFG証券では、アプリケーションサーバをCORBAで実装することで、Webブラウザ、iモード端末、専用インターネット?ソフト（MARKETSPEED(TM) ）などの多様なフロント?エンドに対応しています（これらは、サーブレット、CGI、C++スタンドアロン?アプリケーションなどで実装されています）。
次回のテーマは導入事例
以上で、CORBAとEJBの長所と短所を理解していただけたと思います。次回は、フォード、ボーイング、DLJ direct SFG証券等の先進的な事例をご紹介しながら、CORBAが実際にどのように使われているのか、 CORBAベースのアプリケーションサーバの優位点はどこにあるのか、について解説する予定です。
_xyz
前回は、CORBAの基礎を復習しました。 今回は、CORBAとEJBの違いについて説明します。CORBAとEJBは、e-ビジネスを構築する上でともに重要で、しかも仲のいい兄弟のような存在です。この2つの技術を適材適所でうまく使い分けることが、システム構築の成功の鍵になっています。
それでは、CORBAはEJBと何が違うのでしょうか。この両者の相違点を端的に表しているのが図1です。
CORBAとEJBは、多くの共通する機能を提供しています。分散オブジェクト呼び出し機能、ネーミング?サービス、トランザクション?サービス、イベント?サービス、セキュリティ?サービスなど、各サービスの名称は異なることがありますが、機能的には類似しています。この両者が大きく異なるのは、EJBアプリケーションはEJBコンテナの中で実行されるという点です。このため、EJBアプリケーションは、リモート?メソッドの実装だけからなり、自分自身のmainメソッドを持ちません。これに対して、CORBAアプリケーションは、自分自身でmainメソッドを持ち、スタンド?アロンで実行されます。
この違いは非常に重要で、ここにCORBAとEJBのそれぞれの長所と短所が潜んでいるのです。
図1 CORBAとEJBの関係
EJBで可能なことはすべてCORBAで実現可能上の図からも推測できるように、機能的に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の長所と短所をよく理解して、適材適所で使い分けることが重要だということです。それでは、どのような場合に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に限った話ではありませんが……。
CORBAは、EJBとは異なり、オブジェクトのライフサイクルをアプリケーション自身で管理する必要があります。例えば、オブジェクトのメモリへのページインやページアウトの処理（イビクションと呼んでいます）は、必要に応じてアプリケーション?プログラマーが自分でコーディングする必要があります。その代わり、柔軟でスケーラブルなアプリケーションを構築することが可能になります。また、トランザクションを使用する場合には、トランザクション?サービスのインターフェイスを使って、トランザクションの開始から終了までを自分で制御しなければなりません。このため、CORBAで高度なアプリケーションを開発するためには、ある程度のスキルが要求されます。
成功している多くのユーザー企業やシステム?インテグレータを見ると、ビジネス?ロジックを実装するプログラマーがその都度、基盤になるこれらのコードをスクラッチから書いているわけではありません。これらの企業では、優れたアーキテクトによってデザインされた、プロジェクトまたはその企業に共通のフレームワークが整備されており、プログラマーは基盤部分のコーディングに悩まされることなく、ビジネス?ロジックの実装に専念することができます。従って、ここでの開発生産性は、EJBに決して引けを取りません。さらに、こうしたフレームワークは、EJBコンテナのような一般的なものではなく、そのプロジェクトの用途に最適化されており、しかも拡張性に優れています。
逆に、次のような分野は、CORBAでなければ実現が困難です。
■さまざまなプログラミング言語や多種多様なアーキテクチャで構築されたシステムの統合
今後、企業内のバックエンド?システムとWebシステムをリアルタイムで統合して、取引先や顧客にサービスを提供するシステムが増えていきます。こうしたシステム統合には、2つのアプローチが考えられます。システムを１対１でアドホックに接続していくアプローチと、企業のバックボーンをCORBAのような汎用的な基盤で統一し、すべてのシステムをこの共通バスに接続していくアプローチです。ボーイングやフォードといった企業は、後者のアプローチを採用して成功しています。この場合、EJBを採用したフロント?エンドのWebアプリケーションも、IIOPを使用して共通基盤に接続することができます（下図参照）。
図2 CORBA/IIOPを基盤としたシステム統合
■複数のネットワーク?プロトコルをサポートする必要のあるシステム
先ほど、固有プロトコルで装置を監視制御するシステムの例を挙げましたが、CORBAはほかのプロトコル?スタックやイベント?ループとの統合をサポートしているため、こうしたシステムに柔軟に対応することができます。この分野での典型的な例は、ネットワーク管理システム、製造ライン監視制御システム、交通監視制御システムなどです。
■さまざまなフロント?エンドから共通に利用されるアプリケーションサーバ
フロント?エンド（クライアント）側の技術トレンドは、サーバ側に比べてめまぐるしく変化しています。現在でも、フロント?エンド側は、サーブレット、JSP、ASP、CGI、NSAPIやISAPIなどのWebサーバ固有のサーバ拡張API、Visual Basic、C++やJavaのスタンドアロン?プログラムと多種多様です。フロント?エンド側のこうした急速な変化は今後も十分予想されます。こうしたフロント?エンドの変化に引っ張られることなく、サーバ側のビジネス?ロジックの実装を長持ちさせたいのは、当然の要求です。DLJ direct SFG証券では、アプリケーションサーバをCORBAで実装することで、Webブラウザ、iモード端末、専用インターネット?ソフト（MARKETSPEED(TM) ）などの多様なフロント?エンドに対応しています（これらは、サーブレット、CGI、C++スタンドアロン?アプリケーションなどで実装されています）。
次回のテーマは導入事例以上で、CORBAとEJBの長所と短所を理解していただけたと思います。次回は、フォード、ボーイング、DLJ direct SFG証券等の先進的な事例をご紹介しながら、CORBAが実際にどのように使われているのか、 CORBAベースのアプリケーションサーバの優位点はどこにあるのか、について解説する予定です。
_xyz