•  22-07-2019
  •  | 
  •  

質問

.netのEJB（Enterprise Java Beans）に匹敵するテクノロジーは何ですか？

役に立ちましたか？

解決

.Net 3.5のWCFは、CMPを使用しない限り最も類似しています。 SOAPタイプのサービスエンドポイントを許可しますが、バイナリリモーティングも許可します。

他のヒント

用語の定義が重要です

比較を行う場合、用語の定義が重要です。 EJBは コンポーネントモデル。永続性、トランザクション、リモート処理、アクティベーション、および 内部で動作するコンポーネントのセキュリティ機能（およびその他の機能） コンテナ。

.NETの同等の技術を見ることができます。 after-コンポーネントモデルの技術的能力。

一方で、「EJB」を使用する人もいます。大まかに参照する用語として J2EE（またはJava EE？）。その場合、コンポーネントモデルを単に参照するのではなく、 通常サーバー側に関連付けられている一連の関連Javaテクノロジー コンポーネントモデルを含むアプリケーション。これには、もちろんツールセットも含まれる場合があります。 コンポーネントモデルに正接的にのみ関連しています。 それが 比較すると、「J2EE vs. .NET」とより適切に記述されます。

さらに他の人々は、EJBのさらにファジーな定義を使用して、 Webサービス機能、REST / XML通信、または 厳密にJava EEまたはEJBの外部にある他のもの。言い換えれば、「EJBを.NETと比較」と言うとき、 「サーバー側のJavaプラットフォームとサーバー側の.NET」を比較することを意味します。後者は、たとえばコンポーネントモデルを比較するよりも、はるかに実用的な比較として私に印象を与えます。

比較を行うときは、何を明確にすることが重要です 比較されています。

EJB-コンポーネントモデル

EJBでは、オブジェクトを定義し、セッションBeanまたはエンティティとしてマークします 豆。また、メッセージ駆動型Beanの追加が遅れています。三 EJBのコンポーネントのフレーバー。セッションBeanはアクティベーションを取得します-方法 開始され、「不動態化」される可能性があります。高いリソースの時代 サーバー/コンテナでの競合。 SBはセキュリティも確保し、 リモートサービス。

基本的な考え方は、オブジェクトを定義してから属性をアタッチすることです。 デプロイメント記述子またはコード内属性を介して、 Javaの注釈と呼ばれるアナログ。

EJBセッションBeanに最も近いものは.NETオブジェクトです。すべての.NETで アプリケーションでは、オブジェクトをトランザクション属性でマークできます。 EJB SBのように。必要に応じて、.NETでリモート可能にすることができます リモート処理およびその他の属性。 COM +以外では、パッシベーション技術はありません 。ネット; .NETは、一般的に興味深いこととして、プーリングを無視します。 インメモリオブジェクト。そのため、EJBの場合のように、.NETでアクティベーション/パッシベーションを行う方法はありません。

  

サイドバー＃1：それはまったく真実ではありません。 .NETでは、ワークフロー機能により、非アクティブ化および再アクティブ化が可能な、また実行される予定の長時間にわたるアクティビティを行う機能が提供されます。ただし、ワークフローは「サーバー側オブジェクト」とは異なるメタファーです。または「サービス」これは、.NETを使用するほとんどのサーバー側アプリケーションアーキテクチャの中心です。

  

サイドバー＃2：以前は、サーバーサイドプラットフォームの設計者は、誰もがより効率的にするためにオブジェクトプーリングを使用するつもりだと考えていました。現在、JVMと.NET CLRはオブジェクトの作成に十分な速さであり、メモリは十分に豊富であるため、一般に、オブジェクトプーリングは実用的ではありません。データベース接続などの高価なオブジェクトに対しては十分な利益をもたらしますが、一般的なケースではもはや興味深いものではありません。

EJBと同様に、.NETではセキュリティを付加できます に基づいて実行または非実行できるようにするオブジェクトの属性 発信者の身元、またはその他の「証拠」。

エンティティBeanは別の動物です。永続性とリモート処理は moで結合される実用的なガイドブックでは、推奨事項は エンティティBeanはリモートインターフェイスを公開しません。代わりに、推奨事項は エンティティBeanを呼び出すセッションBean。 EBを次のように考えてみましょう。 永続オブジェクト。

.NETには、多数の選択肢があります。 LINQ-to-SQLが提供するもの オプション-ORMおよび永続化サービス。 ADO.NETエンティティ フレームワークは、おそらくより類似したテクノロジーです。もちろん他のすべて .NETのサービス-トランザクションセキュリティやリモート処理なども可能です ADO.NET Entity FrameworkまたはLINQを使用するオブジェクトに適用されます。

一方、EJBのどこに重点を置いているかに応じて 傘、より良い比較があります。主にEJBを使用する場合 リモーティング-REST、SOAP、およびその他の軽量の出現により プロトコル、私が知る限り、これを行う人はほとんどいません。 .NETで優れているのはWCFです。

最後に、EJB MDBに匹敵するのは.NETキューコンポーネントです。

EJBリモーティング

これらすべてのタイプのEJBには、リモートインターフェースなど、いくつかの共通の側面があります。実際、ほとんどのアーキテクトは、EJBを配布しないことを推奨しています。言い換えれば、彼らは人々があまり一般的に議論されているリモーティングの側面を使用することを思いとどまらせる。代わりに、サーブレットはリモートマシンでEJBを呼び出すのではなく、ローカルのEJBを呼び出す必要があります。これはファウラーの第一法則：オブジェクトを配布しない。

一方、時にはあなたはしなければなりません。
WCFは.NET内の通信フレームワークであり、EJBリモーティングに最も匹敵する.NETの側面です。しかし、それらは同等ではありません。 WCFは、リモート通信用の非常に汎用的なフレームワークであり、同期と非同期、複数のプロトコル、拡張可能なトランスポートおよびチャネルモデルをサポートしていますが、EJBリモーティングはかなり制限されています。

EJBから始めるのは正しいアプローチですか？

EJBは、WebサービスまたはRESTについて（私が知る限り）何も言っていません。 または管理または軽量フレームワーク、あるいはHTML、または開発者ツール。開始 ＆quot; EJB vs blank ＆quot;との比較議論を人為的に制約する 若干。それはそうでないかもしれない方法で議論を組み立てます 最適な。

EJBには、たとえばHTMLページのメタファーを処理するものは何もありません。 サーブレットまたはその従兄弟（ポートレットなど）のいずれかで取得しますが、その一部は適切なJ2EEにあります。ただし、厳密に言えば、HTML出力はEJBでカバーされていません。

今、あなたは多分あなたは EJB。そのために、J2EEはWebサービスを仕様に追加しました。しかし、そうであっても、SOAP WebサービスおよびREST用のさまざまなアドオンJavaベースのフレームワークを使用して、仕様を検討することがどれほど重要かはわかりません。

同様に、ポートレット、サーブレット、AJAXなどのUI機能を検討し、それらを.NETの同等物と比較したい場合は、EJBおよびJ2EEを超えて、一般的にサーバーサイドJavaに移行しました。

それは私の以前のポイントに戻ります-あなた自身の心で明確かつ正確に 調べたり比較したりすることに興味があります。

EJBとJ2EEの仕様は野心的で、サーバーサイドアプリケーションのフレームワークを定義しようとしました。しかし、開発者が行っていること、仕様が言っていること、ベンダーが提供していることの間には常にタイムラグがありました。ご存知のように、J2EE仕様の新しいバージョンの完成とIBMからの準拠サーバーのリリースまでに1年の遅れがあったかもしれません。

このため、最終的には人工的なものになりました。仕様は、人々がすでにやっていることを記述していました。 Springのようなものが出てきて、J2EEはそれらについて何も言っていませんでした。長い間、J2EEはREST、Webサービス、またはAJAXについて何も言うことがありませんでした。 （今でも、

Spring.NETを簡単に議論できます...

Springは、JavaEE / EJBに加えて、または完全に置き換えて、Java側の標準になりつつあります。 Springの概念の多くはJavaEE / EJBに非常に似ていますが、単に優れています。 Spring.NETは、明らかに.NET実装です。

これを超えて、何年も.NETを積極的に使用していなかったため、他に何も提案できませんでした...

多くのEJB機能はすでに.net（つまりデータベーストランザクション）でネイティブですが、多くの機能を提供するエンタープライズサービス名前空間もあります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top