1

2 つのアプリケーション JEE6/JSF2.0 間でデータを交換したいのですが、最適なソリューションを探しています。以下の解決策を考えました：

  • JSON ファイルを使用します。
  • XMLファイルを使用して。
  • GSONファイルを使用して。
  • リモート インターフェイス (EJB 3.0) を使用して。

あなたにとって、使用するのに最適なソリューションは何ですか?

edit : この 2 つのアプリケーションは、常に同じネットワーク上で実行されます (ただし、同じ JVM 上では実行できません)。

4

3 に答える 3

3

RMIには彼が過小評価したいくつかの欠点があると感じているので、Davidの答えに代わるものを提供したいと思います。

  1. これは Java 固有のテクノロジーです。たとえば、3 台目のサーバーを導入する必要があり、それが Microsoft Reporting Services サーバーである場合、同じ言語で話すことはできません。

  2. RMI は古い技術であり、CV では特に見栄えがよくありません。Web サービスは未来です。経験豊富な RMI 開発者は、経験豊富な Web サービス開発者よりも一般的ではありません。

  3. 面倒で重いフレームワーク

私の意見では、より良い解決策は、SOAP XML ベースの Web サービスを使用することです。このアプローチには、次のような利点があります。

  1. ほぼすべての開発フレームワークで広く受け入れられています。テクノロジに関係なく、ほぼすべてのテクノロジに、Web サービスとやり取りするための便利なライブラリがあります。

  2. Java は、XML へのオブジェクトのシリアル化を適切にサポートしています。これは、オブジェクトを迅速に SOAP XML 要求にシリアライズして他のサーバーに送信し、他のアプリケーション サーバーで処理のために逆シリアライズして Java オブジェクトに戻すことができることを意味します。

  3. サービス層は、RMI と同様に、2 つのアプリケーション間の分離インターフェースを提供できます。

アプリケーションで SOAP XML ベースの Web サービスを使用することを再考していただければ幸いです。

于 2012-09-19T11:54:11.660 に答える
2

あなた自身が述べたように、実際には2つのオプションがあります。

RMI を使用して EJB に接続したり、Web サービスを使用して JSON/XML で通信したりなど...

私の経験から、アプリケーションが同じネットワーク上にある場合は RMI が有利になる可能性があります。そうでない場合は、ファイアウォールなどで問題が発生し、HTTPS を使用して RMI をトンネリングする必要が生じる可能性があります。

2 つの異なるマシンを使用している場合、Web サービスは、ファイアウォールでそれほど問題を引き起こさないため、優れています。また、HTTP プロトコルを使用するため、転送されるデータについて心配する必要はありません。

これらの例は一般化されていますが、ある程度の洞察が得られるはずです。

GSON 対 XML 対 JSON はまったく別のテーマです... 非は他のものよりも優れており、すべて人間の目でかなり簡単に読み取れます。

更新 私が理解していることから、ファイアウォールなどについて心配する必要はないので、RMI を使用することをお勧めします。これにより、通常、コードがきれいになり、パフォーマンスがいくらか向上します。

于 2012-09-19T09:14:33.553 に答える
0

両方の動作を確認したので、EJB と WebServices という 2 つのテクノロジを比較できます。EJB の方がはるかに効率的で、トランザクション (必要に応じて分散トランザクションを含む)、例外処理、バイナリ ストリーミングをサポートしていることを確認できます。パフォーマンスに関しては、EJB は速度で SOAP を 5 倍、REST を約 3 倍上回る可能性があります。

ただし、EJB は統合テクノロジではありません。実際、そうするつもりはありませんでした。EJB の最大の欠点は、Java プラットフォームと非常に結合していることです。したがって、両方のエンドポイントを Java で記述し、同じ Java EE バージョンを使用する必要があります。

もう 1 つの問題は、EJB 自体がプロトコルではないため、2 つのコンテナー/ベンダーからの実装がおそらく異なることです。Oracle WebLogic サーバー上の JBoss AS からリモート EJB にアクセスする必要がある場合は、JBoss EJB クライアント実装を持参する必要があります。

EJB との統合に関連するもう 1 つの大きな問題は、データ交換フォーマットの欠如です。通信には Java Serialized オブジェクトを使用するため、データ型は両端で共有する必要があります。アプリケーション例外として分類される新しい例外タイプをサーバー上に作成する場合、このサービスを使用するクライアントが例外をトリガーすると、そのクライアントのコードが壊れます。この場合、リモート API には違反していませんが、別の不明なタイプが導入されていることに注意してください。

そしてもちろん、交換フォーマットとしてクラス型だけに依存することで、プログラマーに非常にばかげたことをする機会を与えています。さまざまなバージョンの Java EE を使用する統合テクノロジとして EJB を使用する大規模なプロジェクトで、さまざまなチームが多数いる場合は、最大の苦痛を経験する準備をしてください。名前付きクエリ、アクセスしているテーブル、その列などで注釈が付けられたクライアント上の JPA エンティティを含むプログラマーのように見え、基本的にすべてのデータベース レイアウトをサービス コンシューマーに提供します。しかし、さらに悪化する可能性があります。私はすでに、Eclipselink 1.0 という依存関係に属するデータ構造を返すプログラマーのように見えます。ただし、JBoss サーバーからこれにアクセスする場合、Eclipselink も JPA 実装テクノロジであり、JBoss の休止状態と競合します。そう、ここで、JBoss APP クラスパスに Eclipselink jar を含め、JPA 関連パッケージをロードしないようにコンテナーを構成する必要があります。そうしないと、アプリケーションが完全に壊れてしまいます。それでも、以前よりも悪化する可能性があります。接続する必要がある他のサービスにも、同じデータ構造を使用するという優れたアイデアがありましたが、Eclipselink 1.1.1 からは実装が異なりますが、クラス署名は同じです。今、あなたは非常に悪い状況にあります。しかし、同じクラス署名。今、あなたは非常に悪い状況にあります。しかし、同じクラス署名。今、あなたは非常に悪い状況にあります。

結論: EJB を統合テクノロジとして使用することは決してありません。コントラクト ファースト アプローチを使用して SOAP を使用します。このアプローチでは、アプリケーションの正規データ モデルを定義し、Java データ構造を、任意の言語で記述されているか、異なるスタックを使用しているかに関係なく、任意のクライアントが使用できる XML 交換フォーマットにマッピングします。または、HATEOAS 原則を使用して、リソース ベースを実装する REST を使用します。最近では、EJB を使用する理由はほとんどないように思えます。CDI は現在市場に出ており、EJB がサポートする多くの機能をサポートしており、RPC 関連のテクノロジは含まれていません。

于 2014-08-12T07:52:09.170 に答える