EnterpriseJavaBeansの初心者向けガイド

Enterprise JavaBeans(EJB)は、1998年3月のEnterprise JavaBeans仕様バージョン1.0の発表以来、大きな興奮を生み出してきましたOracle、Borland、Tandem、Symantec、Sybase、Visigenicなどの企業は、EJB仕様に準拠した製品を発表および/または提供しています。今月は、EnterpriseJavaBeansとは何かを大まかに見ていきます。EJBが元のJavaBeansコンポーネントモデルとどのように異なるかを説明し、EJBがなぜこれほど大きな関心を生み出したのかについて説明します。

ただし、最初に、アドバイザリです。今月は、ソースコードやハウツートピックについては説明しません。この記事はチュートリアルではありません。むしろ、それはアーキテクチャの概要です。 EJBは多くの領域をカバーしており、関連する基本的な概念を最初に理解しなければ、コードスニペットやプログラミングのトリックは無意味です。JavaWorldの読者の側に関心がある場合は、今後の記事で、Enterprise JavaBeansAPIを使用して独自のEnterpriseJavaBeansを作成する方法の詳細について説明する可能性があります。

EJBが開発者にとって非常に魅力的である理由を理解するには、いくつかの歴史的背景が必要です。まず、クライアント/サーバーシステムの歴史と現在の状況を見ていきます。その後、我々は、EJBシステムのさまざまな部分について説明します:EJBコンポーネント-に住んでEJBコンテナ内で実行されているEJBサーバを-とEJBは、オブジェクトどのEJBコンポーネントの「リモコン」の一種として、クライアントの使用。セッションオブジェクトとエンティティオブジェクトの2種類のEJBについて説明します。自宅リモコンについても読むそれぞれEJBインスタンスを作成し、EJBのビジネスメソッドへのアクセスを提供するインターフェース。記事の終わりまでに、EnterpriseJavaBeansを使用して拡張可能なサーバーを構築する方法がわかります。しかし、最初に、時間を振り返ります。

クライアント/サーバーの履歴

古代史

当初、メインフレームコンピュータがありました。そして、それは良かった。(とにかく、それが得られたのと同じくらい良いです。)1960年代までの情報処理の最先端は、主に大規模な組織が日常業務をサポートするために使用する大きくて高価なマシンで構成されていました。1970年代のミニコンピューターとタイムシェアリングは、コンピューティング能力のアクセシビリティを向上させましたが、情報と処理は依然として個々のマシンに集中していました。1980年代の最初のパーソナルコンピュータは、数千の小さな情報の島で企業の風景をすぐに乱雑にし、すべてが絶え間なくさまざまな品質のレポートを作成し、クラッシュしたときに重要なデータを失い、すぐに互いに矛盾しました。

救助するクライアント/サーバー

クライアント/サーバーアーキテクチャは、一元化されたデータ制御と広範なデータアクセスの両方の必要性を処理する方法の難問に対する最も一般的なソリューションの1つです。クライアント/サーバーシステムでは、情報は比較的集中化された状態に保たれ(または分散サーバー間で分割および/または複製され)、ユーザーが必要とするデータへのアクセスを提供しながら、データの制御と一貫性を促進します。

現在、クライアントサーバーシステムは通常、さまざまな数の層で構成されています。ユーザーインターフェイスがデータベースおよびビジネスアプリケーションと同じコンピューター上で実行される、標準の古いメインフレームまたはタイムシェアリングシステムは、単一層と呼ばれます。このようなシステムは比較的管理が容易であり、データは1つの場所にしか保存されないため、データの整合性は単純です。残念ながら、単層システムはスケーラビリティが制限されており、特に通信が関係している場合は、可用性の危険が発生しやすくなります(1台のコンピューターがダウンすると、ビジネス全体がダウンします)。

最初のクライアント/サーバーシステムは2層で、ユーザーインターフェイスはクライアント上で実行され、データベースはサーバー上に存在していました。そのようなシステムはまだ一般的です。 1つのガーデンバラエティタイプの2層サーバーは、クライアントでほとんどのビジネスロジックを実行し、SQLのストリームをサーバーに送信することで共有データを更新します。クライアント/サーバーの会話はサーバーのデータベース言語のレベルで行われるため、これは柔軟なソリューションです。このようなシステムでは、サーバーがトランザクションの実行に必要なデータベーススキーマ(テーブル、ビューなど)にアクセスできる限り、サーバーを変更せずに、適切に設計されたクライアントを変更して新しいビジネスルールと条件を反映できます。このような2層システムのサーバーは、以下に示すようにデータベースサーバーと呼ばれます。

ただし、データベースサーバーにはいくつかの責任があります。多くの場合、特定のビジネス機能(たとえば、注文へのアイテムの追加)のSQLは、呼び出しごとに更新または挿入されるデータを除いて、同一です。データベースサーバーは、ビジネス機能ごとにほぼ同一のSQLを解析および再解析することになります。たとえば、注文にアイテムを追加するためのすべてのSQLステートメントは、データベースで顧客を見つけるためのSQLステートメントと同様に非常に類似している可能性があります。この解析にかかる時間は、実際にデータを処理するために費やしたほうがよいでしょう。 (SQL解析キャッシュやストアドプロシージャなど、この問題に対する解決策があります。)発生する別の問題は、クライアントとデータベースを同時にバージョン管理することです。アップグレードのためにすべてのマシンをシャットダウンする必要があります。また、ソフトウェアバージョンが遅れているクライアントやサーバーは、通常、アップグレードするまで使用できません。

アプリケーションサーバー

アプリケーションサーバーのそれはデータベースサーバが持っている問題の一部を解決しているためアーキテクチャは、(次の画像を参照)データベース・サーバ・アーキテクチャに人気の代替手段です。

データベースサーバー環境は通常、クライアント上でビジネスメソッドを実行し、主に永続性とデータ整合性の強化のためにサーバーを使用します。アプリケーションサーバーでは、ビジネスメソッドがサーバー上で実行され、クライアントはサーバーにこれらのメソッドの実行を要求します。このシナリオでは、クライアントとサーバーは通常、テーブルと行のレベルではなく、ビジネストランザクションのレベルで会話を表すプロトコルを使用します。このようなアプリケーションサーバーは、対応するデータベースよりもパフォーマンスが優れていることがよくありますが、それでもバージョン管理の問題が発生します。

アーキテクチャに層を追加することで、データベースシステムとアプリケーションシステムの両方を拡張できます。いわゆる3層システムは、クライアントとサーバーの間に中間コンポーネントを配置します。業界全体(ミドルウェア)は、2層システムの責任に対処するために成長しました。トランザクション処理モニター、1つのタイプのミドルウェアは、多くのクライアントから要求のストリームを受信し、複数のサーバー間で負荷を分散し、サーバーに障害が発生したときにフェイルオーバーを提供し、クライアントに代わってトランザクションを管理します。他のタイプのミドルウェアは、通信プロトコルの変換を提供し、クライアントと複数の異種サーバー間の要求と応答を統合し(これは、ビジネスプロセスリエンジニアリングでレガシーシステムを処理する場合に特に人気があります)、サービスメータリングとネットワークトラフィック情報を提供します。

複数の層が柔軟性と相互運用性を提供し、これら3層以上のサービスを備えたシステムを実現しました。たとえば、n層システムは、3システムを一般化したものであり、ソフトウェアの各層は、その上下の層に異なるレベルのサービスを提供します。 n層の観点では、ネットワークは、クライアントが単一のサーバーにアクセスするための単なる手段ではなく、分散サービスのプールであると見なされます。

オブジェクト指向の言語と技術が流行するにつれて、クライアント/サーバーシステムはますますオブジェクト指向に移行しています。CORBA(Common Object Request Broker Architecture)は、特定のアプリケーションのニーズに応じて、アプリケーション内のオブジェクト(異なる言語で記述されたオブジェクトも含む)を別々のマシンで実行できるようにするアーキテクチャです。数年前に作成されたアプリケーションは、CORBAサービスとしてパッケージ化し、新しいシステムと相互運用できます。CORBAと互換性があるように設計されたEnterpriseJavaBeansは、オブジェクト指向のアプリケーションサーバーリングへのもう1つのエントリです。

この記事の目的は、クライアント/サーバーシステムに関するチュートリアルを提供することではありませんが、コンテキストを定義するためにいくつかの背景を提供する必要がありました。次に、EJBが提供するものを見てみましょう。

エンタープライズJavaBeansと拡張可能なアプリケーションサーバー

少し歴史を見て、アプリケーションサーバーとは何かを理解したので、Enterprise JavaBeansを見て、そのコンテキストで何が提供されるかを見てみましょう。

Enterprise JavaBeansの背後にある基本的な考え方は、サーバーに「プラグイン」される可能性のあるコンポーネントのフレームワークを提供し、それによってそのサーバーの機能を拡張することです。Enterprise JavaBeansは、いくつかの類似した概念を使用するという点でのみ、元のJavaBeansに類似しています。EJBテクノロジは、JavaBeansコンポーネント仕様ではなく、まったく異なる(そして大規模な)エンタープライズJavaBeans仕様によって管理されています。(この仕様の詳細については、「参考文献」を参照してください。)EJB仕様は、EJBクライアント/サーバーシステムのさまざまなプレーヤーを呼び出し、EJBがクライアントおよび既存のシステムと相互運用する方法を説明し、EJBとCORBAの互換性を詳しく説明し、システム内のさまざまなコンポーネント。

エンタープライズJavaBeansの目標

EJB仕様は、一度に複数の目標を達成しようとします:

  • EJBは、開発者がアプリケーションを簡単に作成できるように設計されており、トランザクション、スレッド、負荷分散などの管理に関する低レベルのシステム詳細からアプリケーションを解放します。アプリケーション開発者は、ビジネスロジックに集中し、データ処理の管理の詳細をフレームワークに任せることができます。ただし、特殊なアプリケーションの場合は、「内部」でこれらの低レベルのサービスをカスタマイズすることは常に可能です。

  • EJB仕様は、 EJBフレームワークの主要な構造を定義し、その後、特にそれらの間の契約を定義します。クライアント、サーバー、および個々のコンポーネントの責任はすべて明確に説明されています。 (これらの構造については後ほど説明します。)Enterprise JavaBeanコンポーネントを作成する開発者は、EJB準拠のサーバーを作成する開発者とは非常に異なる役割を果たし、仕様にはそれぞれの責任が記載されています。

  • EJBは、クライアント/サーバーアプリケーションをJava言語で構築するための標準的な方法となることを目指しています。さまざまなベンダーの元のJavaBeans(またはDelphiコンポーネントなど)を組み合わせてカスタムクライアントを作成できるのと同様に、さまざまなベンダーのEJBサーバーコンポーネントを組み合わせてカスタムサーバーを作成できます。もちろん、JavaクラスであるEJBコンポーネントは、再コンパイルせずに、EJB準拠のサーバーで実行されます。これは、プラットフォーム固有のソリューションでは提供できないメリットです。

  • 最後に、EJBは他のJava APIと互換性があり、他のJava APIを使用し、Java以外のアプリと相互運用でき、CORBAと互換性があります。

EJBクライアント/サーバーシステムのしくみ

EJBクライアント/サーバーシステムがどのように動作するかを理解するには、EJBシステムの基本部分であるEJBコンポーネント、EJBコンテナ、およびEJBオブジェクトを理解する必要があります。

EnterpriseJavaBeansコンポーネント

Enterprise JavaBeanは、従来のJavaBeanと同じようにコンポーネントです。エンタープライズJavaBeansはEJBコンテナ内で実行され、EJBコンテナEJBサーバー内で実行されます。EJBコンテナをホストし、それに必要なサービスを提供できるサーバーはすべて、EJBサーバーにすることができます。(これは、多くの既存のサーバーが拡張されてEJBサーバーになる可能性があることを意味し、実際、多くのベンダーがこれを達成しているか、そうする意図を発表しています。)

EJBコンポーネントは、「エンタープライズJavaBean」と見なされる可能性が最も高いEJBクラスのタイプです。これは、EJB開発者によって作成されたJavaクラスであり、ビジネスロジックを実装します。EJBシステム内の他のすべてのクラスは、EJBコンポーネントクラスへのクライアントアクセスをサポートするか、サービス(永続性など)を提供します。

EnterpriseJavaBeansコンテナ

EJBコンテナは、EJBコンポーネントが「存在する」場所です。 EJBコンテナは、トランザクションとリソースの管理、バージョン管理、スケーラビリティ、モビリティ、永続性、セキュリティなどのサービスを、含まれるEJBコンポーネントに提供します。 EJBコンテナはこれらすべての機能を処理するため、EJBコンポーネントの開発者はビジネスルールに集中し、データベース操作やその他の詳細をコンテナに任せることができます。たとえば、単一のEJBコンポーネントが、現在のトランザクションを中止する必要があると判断した場合、そのコンテナに(EJB仕様で定義された方法で)通知するだけで、コンテナはすべてのロールバックを実行するか、キャンセルに必要なことをすべて実行します。進行中のトランザクション。通常、複数のEJBコンポーネントインスタンスが単一のEJBコンテナ内に存在します。

EJBオブジェクトとリモートインターフェース

クライアントプログラムは、EJBオブジェクトを介してリモートEJBでメソッドを実行します。EJBオブジェクトは、サーバー上のEJBコンポーネントの「リモートインターフェース」を実装します。リモートインターフェースは、EJBコンポーネントの「ビジネス」メソッドを表します。リモートインターフェースは、注文フォームの作成や患者の専門医への延期など、EJBオブジェクトの実際の便利な作業を実行します。リモートインターフェイスについては、以下で詳しく説明します。