Javaアプリケーションミドルウェアの状態、パート1

クライアント/サーバーが停止しています。新しいインターネットベースのテクノロジーが繁栄している今、それは話題です。しかし、これらの新しいテクノロジーは、以前のアプローチの自然な進化に過ぎず、より新しい、よりオープンなプロトコルで実装され、より優れたスケーラビリティ、管理性、および多様性を提供するように設計されています。

この進化の大きさは驚くべきものです。主要なクライアント/サーバーベンダーのほとんどは、製品を最新化しており、現在、マーケティング費用を3層テクノロジーに振り向けています。ほとんどの場合、新しい製品はJava中心およびインターネットプロトコル中心です。たとえば、私は最後に少なくとも46のJavaミドルウェア製品を特定しました。2年前は、その半分の数を思い付くのは困難でした。

これは、汎用Javaミドルウェアを現在の形式で説明することを目的とした2部構成のシリーズの最初の記事です。この最初の記事では、現在の製品の機能を調べ、これらの機能が重要である理由を説明します。第2部では、Anil HemrajaniがエンタープライズJavaBeans(EJB)を調べ、現世代のJavaミドルウェア製品がこの重要なコンポーネント標準にどのように関連してサポートするかを示します。

バックグラウンド

まず、Javaミドルウェアを定義しましょうこの用語には、BEA WebLogicなどのアプリケーションサーバー、ActiveSoftwareのActiveWorksやPushTechnologiesのSpiritWAVEなどのメッセージング製品、DBMSレガシーに基づいてサーバーベースのJavaオブジェクト実行機能を追加するハイブリッド製品が含まれます。アプリケーションサーバーなど、より狭いセグメントに焦点を当てることもできましたが、このカテゴリに正確に当てはまらない多くの製品には不公平でしたが、それでも多層アプリケーションについては検討する必要があります。さらに、アプリケーションサーバー間でも、主にサーブレットサーバーであるサーバーや、ORBベースまたはOODBベースであるサーバーなど、かなりの範囲があります。これらすべての製品の間に線を引くことはますます困難になっています。ただし、統合機能それらはすべて、Javaおよびインターネットテクノロジを使用して多層アプリケーションの展開の問題を解決しようとしているということです。

ミドルウェアでJavaを使用するビジネスケースは説得力があります。Javaミドルウェアが提供する利点には次のものがあります。

  • オフィスや組織を経済的に相互接続するインターネットの機能

  • データとビジネスプロセスを共有することによって組織が協力する必要性

  • ジェネリックサービスとこれらのサービスの管理を統合したいという願望

  • 起動、シャットダウン、メンテナンス、リカバリ、負荷分散、監視など、一元化されたアプリケーション管理を提供したいという要望

  • オープンなサービスとプロトコルを使用したいという願望

  • ビジネスロジックを自由に再展開し、インフラストラクチャに制約されないようにしたいという願望。これには、ほとんどのインフラストラクチャ製品で広くサポートされているオープンAPIとプロトコルを使用する必要があります

  • 協調する混合アーキテクチャアプリケーションをサポートする必要性

  • ネットワークとサービスインフラストラクチャの決定をアプリケーションスペースの外に移動して、システム管理者が独自のプロトコルや機能に依存するアプリケーションに邪魔されることなくインフラストラクチャの決定を行えるようにしたいという要望

  • 必要なプログラマースタッフのスキルの多様性とレベルを減らし、プロジェクト内での高度なツール構築の専門知識の必要性を最小限に抑えたいという願望

  • オブジェクト指向の専門知識をサーバー領域に拡張することで活用したいという願望-したがって、より新しいオブジェクト指向サーバー製品とオブジェクトからリレーショナルへのブリッジ

ミドルウェアの目標は、ソフトウェアインフラストラクチャとその展開を一元化することです。クライアント/サーバーは、単一の部門内の統合の時代に端を発しています。現在、組織は通常、部門の境界を越えて統合を試みています。組織間でも統合を試みています。部門とパートナーが効率的かつ迅速に相互接続できるようにするグローバルネットワークとして機能する能力で企業を魅了するインターネットは、この統合に対する需要を生み出しました。

Javaは、組織の境界を越えてデータとアプリケーションを簡単に相互接続するための共通語を提供します。パートナーが行うテクノロジーの選択を制御できない分散型グローバル環境では、スマート企業はオープンでプラットフォームに中立な標準を選択します。企業は、2年後に誰が顧客、パートナー、または子会社になるかを予測できないため、パートナーとの共通インフラストラクチャを常に計画できるとは限りません。この不確実な状況では、最善の決定は、可能な限り最も普遍的で適応性のあるテクノロジーを使用することかもしれません。

Javaを使用すると、スタッフが理解する必要のあるプログラミング言語とプラットフォームの数を減らすことができます。どうして? Javaは現在、インターネットブラウザ、データベース内のストアドプロシージャ、ミドルウェア製品内のビジネスオブジェクト、クライアント側アプリケーションなど、さまざまなコンテキストで展開されているためです。

ただし、3歳の時点では、Javaテクノロジはまだやや未成熟であり、これはこの記事で説明する製品にも当てはまります。一方で、製品の基盤となる技術は急速に変化しているため、製品が真に成熟することのない時代になっているかもしれません。実際、私が使用したほぼすべてのミドルウェア製品には重大な問題があります。これには、数年前から市場に出回っていて、最近重要な新機能が登場したと思われる成熟した製品も含まれます。重要なのは、ベンダーが問題を修正するまでに、新しい機能が追加されているということです。新しい機能を追加するサイクルはこれまでよりもはるかに短くなっているため、製品が次の主要な機能セットを含む前に安定するのに十分な時間がありません。これは私たちが慣れなければならないことかもしれません。私たちが選択する製品の長所と短所を学ぶことは、アプリケーションの設計とプロトタイプのサイクルの重要な部分です。

ミドルウェアの目標

EJBミドルウェアコンポーネント標準は、次の目標を持って開発されました。

  • コンポーネントの相互運用性を提供します。さまざまなツールで開発されたエンタープライズBeanは連携して機能します。また、さまざまなツールで開発されたBeanは、どのEJB環境でも実行できます。

  • 低レベルAPIへのアクセスを維持しながら、使いやすいプログラミングモデルを提供するため。

  • 開発、展開、実行時間を含むライフサイクルの問題に対処するため。

  • 既存のプラットフォームとの互換性を提供するため。これにより、既存の製品を拡張してEJBのサポートを提供できます。

  • 他のJavaAPIとの互換性を維持するため。

  • EJBアプリケーションと非Javaアプリケーション間の相互運用性を提供するため。

  • CORBAと互換性があるため。

したがって、EJB標準の焦点は、Javaミドルウェアの相互運用性標準の作成にあり、分散アプリケーションの開発時に発生する多くの困難な問題にプログラマーが対処する必要がないようにします。これにより、ソフトウェア開発者は、高度な自社開発のインフラストラクチャやツールを作成する代わりに、ビジネスロジックに集中できます。その結果、企業は教育リソースのほとんどをビジネスプロセスのトレーニングスタッフに投入できます。これは通常、最大の見返りを提供するものです。

上記のリストに、エンタープライズクラスのJavaミドルウェアに関する次の追加の目標を追加します。これらの製品機能は、ミドルウェアベースの環境を正常に実行および維持するために長期的に必要です。

  • セキュリティを損なったり混乱を招いたりすることなく、分散インフラストラクチャ内の複数のビジネスユニット、企業、および顧客の相互接続に対応する必要があります。

  • 柔軟でありながら信頼性の高いアクセス制御メカニズムにより、ビジネスパートナーのデータに意図した方法でのみ、意図した関係者のみがアクセスできるようにする必要があります。

  • これにより、システム管理者は、特定のコンポーネントに固有の手順を理解したり適用したりすることなく、多数のビジネスロジックコンポーネントを含む分散コンピューティング環境を統一された方法で管理できるようになります。

  • これにより、システム管理者は、アプリケーションに影響を与えることなくインフラストラクチャコンポーネントを選択し、それらのコンポーネントを調整およびスケーリングし、すべてのアプリケーションのパフォーマンスとリソースのニーズを測定するための統一された汎用的な手段を持つことができます。

  • どちらのアーキテクチャにも影響を与えることなく、ビジネスコンポーネントをクライアントとサーバー間で再配置できるようにする必要があります。

  • サーバー管理者にすべてのコンポーネントとデータソースへのアクセスを許可することなく、特定のユーザーが新しいコンポーネントを追加できるようにするセキュリティメカニズムを提供する必要があります(これは、エクストラネットおよびパートナーシップアプリケーションにとって重要であるため、付加価値機能の絶好の機会です。 )

Javaミドルウェアプラットフォームのコンポーネントと機能

今日最も急速に成長しているJavaミドルウェアのカテゴリは、おそらくアプリケーションサーバーです。ただし、存在する多種多様なアプリケーションサーバー(およびその他の種類のミドルウェア製品)を実現することが不可欠です。今日のJavaミドルウェア製品カテゴリー間の区別は、線ではなく、広大なミドルウェアの連続体によって表されます。ここで、私が知っているJavaミドルウェア製品のすべてのクラスを網羅する、私自身の作業比較に基づいて、Javaミドルウェアの機能について説明します。

オブジェクト、コンポーネント、およびコンテナモデル

アプリケーションコンポーネントは、コンポーネントがその環境と通信する方法を指定するランタイムデプロイメントモデルに準拠する必要があります。 (おそらく)それがどのようにインストールされ、開始され、停止され、そして呼び出されるか。また、環境にとって重要なサービスにアクセスする方法。一般的なJava中心のサーバーコンポーネントランタイムおよびコンテナモデルには、RMI、EJB、CORBA、DCOM、サーブレット、JSP(Java Server Pages)、およびJavaストアドプロシージャが含まれます。さらに、コンポーネントモデルは、Java、IDL、C ++、その他多くの基礎となるさまざまな言語で表現できます。

さまざまなコンポーネントモデルとの重複があります。たとえば、RMIは、オブジェクトのアクティブ化と場所に関する非常に基本的な機能を備えた簡単なコンポーネントモデルであり、主にリモート呼び出し標準ですが、EJBはRMIを活用し、RMIをプライマリオブジェクト呼び出しモデルとして指定します。 EJBはCORBAもサポートしています。実際、これらのモデルはいずれも排他的ではなく、多くのJavaアプリケーションサーバーは上記のモデルのほとんどまたはすべてをサポートしています。

多くのJavaミドルウェアサーバーは、単一のJava仮想マシン(JVM)内で複数のビジネスオブジェクトインスタンス(CORBAの世界では現在サーバントと呼ばれています)を実行します。 Java言語の型安全性により、単一のJVMプロセスが複数のクライアントからの要求を処理し、プログラムデータ構造とクラスローダーを使用してクライアントデータを分離することができます。使用人が独自のネイティブメソッドを使用しない限り、1人の使用人がクラッシュした場合(JVM自体にバグが発生した場合を除く)、他の使用人をダウンさせたり、他のクラスにプライベートなデータにアクセスしたりすることはできません。 。適切に設計されたオブジェクトサーバーは、そのプライベートオブジェクトを保護し、誤ったオブジェクトが他のオブジェクトに属するものにアクセスするのを防ぎます。

ただし、Javaクラスで静的と宣言されたデータは、クライアントが同じクラスローダーを使用する場合、同じJVM内のクライアント間で共有できるため、別のJVM(またはメモリを使用する別のJVMと同等のもの)をいつ指定するかを指定するルールを定義する必要があります。クライアントに独自の静的データスペースを提供するには、パーティショニング手法)または個別のクラスローダーが必要です。このようなルールはアプレットに指定されていますが、他の実行環境には指定されていません。 SunのJavaWebサーバーは、すべてのサーブレットに単一のJVMを使用し、コードベースが異なるサーブレットに個別のクラス名前空間を使用します。 EJBは、非最終的な静的データを禁止することでこの問題を回避します。

オブジェクトが使用されていないときに非アクティブ化または非アクティブ化されると、パフォーマンスが向上し、データベース接続などのリソースが解放されます。このため、多くのサーバーは必要に応じてオブジェクトを不動態化し、再アクティブ化します。同様に、一部の製品は、頻繁に作成されるオブジェクトをプールまたはキャッシュに初期化された状態で保持し、すぐに使用できるようにします。オブジェクトコンテナは、パッシベーションと再アクティブ化、およびパッシベーションの影響を受けるプールされたリソースを管理する必要があります。

EJB互換性(バージョン)

EJBモデルはすでに広くサポートされています。ほぼすべてのミドルウェアベンダーがそれをサポートすることを約束しており、多くはすでにサポートしています。さらに、Object Management Group(OMG)は、提案されたCORBAコンポーネント仕様の一部としてEJBへのマッピングを組み込んでいます。唯一の確固たる支持者であるMicrosoftでさえ、最終的にDCOM用のEJBコンテナを生成して提供しないとは想像しがたいです。

異なるEJB互換ミドルウェアは、同じアプリケーションコンポーネントをデプロイして操作できますが(それらのコンポーネントが標準の必要なEJB機能のみを使用する限り)、EJB準拠のサーバー間で大きなばらつきがあります。一つには、EJB仕様自体が進化しています。したがって、Javaミドルウェア製品を評価する際の重要な質問は、サーバーが最新バージョンのEJBをサポートしているのか、それとも以前のバージョンのみをサポートしているのかということです。もう1つの重要な質問は次のとおりです。製品はEJB中心ですか、それともEJBサポートは製品の付加価値機能にのみ含まれていますか(したがって、EJBサービスまたはAPIが使用されている場合は利用できません)?そして最後に:どのオプションのEJB機能が含まれていますか(たとえば、エンティティBeanやコンテナ管理の永続性)?