別々のJ（2）EEアプリケーションとして開発されたJavaモジュールを統合する最良の方法は、どのようになるのだろうか。これらの各モジュールは、Javaインタフェースを公開します。 POJOエンティティ（Hibernate）は、これらのJavaインターフェイスとともに使用されていますが、DTOオブジェクトはありません。これらのモジュールを統合する最善の方法、つまり、他のモジュールのインターフェイスをリモートで呼び出すモジュールは何ですか？Javaアプリケーションのリモーティング手法をお勧めしますか？
私はEJB3、Hessian、SOAP、JMSについて考えていました。それぞれのアプローチの長所と短所があります。
あなたの意見やあなたの経験は何ですか？
リモートテクノロジのいくつかを手にして、普遍的にunfonされていることがわかったので、実装からの抽象化としてSpring remotingを使用します。 これは、あなたの機能を書くことに集中し、Springがいくつかの設定でリモート部分を処理できるようにします。いくつかの実装（RMI、SpringのHTTP呼び出し側、Hessian、Burlap、JMS）の選択肢があります。抽象化とは、1つの実装を選択し、ニーズが変わった場合に交換することを意味します。 詳細については、SpringSource docsを参照してください。
私はSOAPのために行くだろう。
JMSはより効率的ですが、インターフェイスごとにメッセージ駆動型Beanをコード化する必要があります。
SOAP一方、SOAPには、EJBが与えられたときにメッセージ定義（WSDL）と必要なすべてのハンドラ（クライアントとサーバ）を生成する多くの有用なツールキットが付属しています。
ソープでは、証明書のセキュリティとパブリックネットワーク経由の接続を保護できます（ただし、その必要はありません）。デフォルトのプロトコルはポート80を介したHTTPなので、ファイアウォールなどでは痛みが最小限に抑えられます。SOAPは、ほとんどの一般的なプラットフォームで最も一般的な言語をサポートしているヘタリアンなクライアント（場合によってはJ2EEでないもの）にも適しています。
JMSは、非同期通信（fire and forget）用に設計されています。したがって、サービスコールからの応答が必要な場合は、メッセージを受信する2つのメッセージチャネルと、応答を送信側に返すもう1つのメッセージチャネルが必要です。 – pjp
SOAPで見られる問題は、この手法を使用するには、XMLスキーマを定義してXMLをオブジェクト（JAXB）にバインドする必要があるということです。オリジナルの記事で述べたように、目標はDTOを排除し、可能であればモデルエンティティ（Hibernate/JPA）を使用することです。 DTOの問題は、DTOとエンティティの間で変換レイヤーが必要であることです。 –
@pjp：正確ではありません。プライベートキューを含むパターン（セッション用）を使用して応答を受け取ることができます。基本的に、クライアントは一時的なキューを作成し、要求メッセージに対して「ReplyTo」プロパティを設定し、メッセージをパブリック要求キューに送信します。レスポンダはリクエストメッセージを受信し、ロジックを起動し、レスポンスメッセージを作成し、リクエストメッセージの「ReplyTo」で指定されているように一時的なキューに送信します。 –
Javaのみのアプリケーション間でネットワーク通信が必要な場合は、Java RMIを使用してください。それは、最高の統合、最も透明性と最小のオーバーヘッドを持っています。
しかし、クライアントの中にはJavaベースではないものがある場合、他のオプションも考慮する必要があります（Java RMIは実際にはCORBAと対話できるIIOP-ダイアレクトを持っていますが、これは、レガシーコード統合のためのものでない限り）。あなたのニーズに応じて、Webサービスはおそらくあなたの友人です。もしあなたがネットワーク負荷を犠牲にしているなら、あなたはHessianを介してwebservicesに行くことができます。
+1 RMIは簡単で簡単な解決策です:-) – ATorras
あなたは文字通り遠隔からですか？異なる可用性特性を持つ異なる環境で稼動する場合と同じですか？ネットワークのオーバーヘッドはありますか？
「はい」と仮定すると、私の最初のステップは、サービスアプローチをとることであり、呼び出し技術を脇に置いておくことです。あなたのサービスの設計と意味を考えてみてください。あなたは、彼らが呼び出すにはコストがかかります。したがって、小さなビジーなインターフェイスは悪い傾向があります。呼び出しの間にサービスシステムが失敗する可能性があることを知っているので、ステートレスサービスを好むかもしれません。あなたは失敗後にリクエストを再試行する必要があるかもしれないので、偶然のサービスデザインを好むかもしれません。
次に、可用性の関係について検討します。リモートシステムなしでクライアントを動作させることができますか。場合によっては、リモートシステムが利用できない場合（例えば、HRシステムにアクセスできない場合は従業員を有効にすることはできません）、他の場合には「ファイアアンドアンドトーク「後の」哲学。要求をキューに入れ、後で応答を処理します。
可用性の低下がある場合は、単純に同期インタフェースを公開することが適しているようです。すべてがJava EEであれば、SLSB EJBでそれを実行できます。私は、私のサービスが有用であれば、Java EE以外のクライアントもそれらを望むかもしれないと一般化する傾向があります。 SOAP（またはREST）は便利な傾向があります。最近、あなたのSLSBにWebサービスインターフェイスを追加することはかなり簡単です。
しかし、私のペット理論は、十分に大きなITシステムであれば、同期通信を必要とするということです。可用性の制約を切り離す必要があります。ですから、私はJMSスタイルの関係を探す傾向があります。サービスの前にあるMDBファサード、つまりSOAP/JMSはそれほど難しいことではありません。このようなアプローチでは、とにかくおそらく潜んでいた障害ケースの設計上の問題が浮き彫りになる傾向があります。JMSは、「私が答えを得られないと仮定します。
標準的なアプローチは、さまざまなサービスコンポーネント間でプレーンなRMIを使用することですが、特に同じクラスを使用するコンポーネントがたくさんある場合は、Javaインターフェイスを共有してドメインモデルをバージョン管理するという問題が発生します。
実際に別のVMで各サービスを実行していますか？これらのEJBが常に相互に通信している場合、これらのEJBがLocalInterfacesを使用できるため、同じVMに配置してリモートプロシージャコールを避けることをお勧めします。
あなたが噛む可能性があるもう一つのことは、Hibernate POJOを使用することです。これらはシンプルなPOJOだと思うかもしれませんが、舞台裏ではHibernateはCGLibが怠惰な初期化を許可するようなことをしようと忙しかったです。これらのBeanがシリアル化され、リモート境界を超えて渡された場合、奇妙なHibernate Exceptionが発生して終了することがあります。個人的には、単純なDTOを作成するか、コンポーネント間を渡すためにPOJOをXMLとして書き出す方が好きです。私の同僚は一歩進んで、パフォーマンス上の理由からデータを転送するカスタムワイヤプロトコルを作成します。
最近、MULE ESBを使用してさまざまなサービスコンポーネントを統合しています。ボイラープレートコードのほとんどを書かなくても、RMI、ソケット、Webサービスなどを混在させることができます。
なぜ働く最も単純なもの以外のものとなるだろうか？
通信が同期または非同期である必要があるかどうかによって、EJB3またはJMSのように聞こえる場合があります。
EJB3は、セキュリティ、トランザクションなど、必要になる可能性のあるすべての追加機能を提供する、RMIの上に構築された最も簡単なものです。おそらく、POJOは共有jarにあり、私はバリューオブジェクトを自分自身で渡す傾向があります。 EJBのもう1つの利点は、正しく実行されたときに、最もパフォーマンスが良いことです（これは私の意見です）。
JMSもう少し複雑ですが、あまりおよび非同期通信に基づくシステムは並列タスクの面で一定の細かな点を与え、など
ウェブサービス、避けられない余分な設定や追加のパフォーマンスのオーバーヘッド私はJava以外のクライアントとの相互運用や外部の関係者へのデータ提供を検討しています。
上記の@pjpの答えは、私がDTOを好む理由を思い出させてくれました。 - Hibernateセッションを動作させるための遅延読み込みがあらゆる場所で行われ、コレクションの実装で最も顕著になりました。これらのオブジェクトがシリアライズされると、Hibernateセッションもまたクライアント側で無駄になり、呼び出されると爆発します。これを処理するために呼び出すことができるHibernate.initialize（Object）メソッドがありますが、私の環境設定はまだDTOです –
これは、クライアントからサーバーへのHTTPを持つシステムでこれを使用します（セキュリティ上の理由から必要です）。サービスコールへのサービス。 – Robin