問題タブ [eai]

Service Bus Connect EAI と EDI の調査を開始したばかりで、次のシナリオを満たすソリューション/ミドルウェアを探しています。

当社には製品があり、当社の製品をオンプレミスのクライアントで SAP/Oracle Business Suite/Sieble/Oracle/SQL Server と統合することを検討しています。そのため、オンプレミスのクライアントでエンドポイントを公開するための構成と最小限のインストールのみを行う必要があります。

この場合、「Service Bus Connect EAI and EDI」はどのように役立ちますか?

"Service Bus Connect EAI and EDI" について理解している限り、多くのインストールを行う必要がありますが、私の理解は正しいですか?

そうでない場合、このミドルウェアをどのように使用できますか?

前もって感謝します。-リパル

私はすでにSOAPを使用しましたが、SOA、ESB、およびその他のエンタープライズアプリケーション統合パターンを使用したことはありません。そして、ESBに関するドキュメントは非常に紛らわしいと思います。

ESBで理解できないことがあります。企業のネットワークをバスとして表現するという概念であり、具体的なものではないことは承知していますが、それでもなおです。

ESBがレガシーサービスでプロトコルとメッセージの変換を提供し、オーケストレーションを可能にし、メッセージの宛先のロジックがESBによって行われることを理解できます。しかし、私はESBを異なるESBサーバー間のミドルウェアとしても考えました（Webサービスインターフェイスだけではありません）。

ServiceMixを例にとると、共通のバス/プロトコル（NMR？JMS？）を介して相互作用する異なるサーバー上に複数のServiceMixプラットフォームがあるのは自然なことだと思いました。したがって、CAMELで作成されたServiceMix（a）のサービス（たとえば、いくつかのWebサービスを使用）は、同じくCAMELで作成されたServiceMix（b）のサービスを消費する可能性があります。

したがって、サービスに別のサービスが必要な場合は、その識別子を指定するだけで、ESBがリクエストを正しいServiceMixプラットフォームにルーティングします。

しかし、ServiceMixの例について読んだとき、ServiceMixはスタンドアロンのアプリケーションサーバーとして主に使用されているように思われます。サーバーのクラスターではありません。

ESBは単にブーストされたアプリケーションサーバーですか？（それが提供する統合機能は別として）

実際にSOAには複数のESBがありますか？ESB内部のプロトコルにリンクされていますか？または、ESB（a）に実装されたサービスは、ESB（b）がそのサービスを使用できるように、SOAPなどの外部インターフェイスを提供する必要がありますか？

非常に高速（> 100,000 /秒）で入力されるJMSキューがあります。

同じエンティティに関連する複数のメッセージが毎秒存在する可能性もあります。（エンティティに対するいくつかの更新。更新ごとに異なるメッセージとして表示されます。）

一方、このメッセージを処理して他のアプリケーションに送信するコンシューマーが1つあります。

現在、消費者は着信メッセージの速度に対応できないため、セットアップ全体の速度が低下しています。

コンシューマーがメッセージを処理する速度にはSLAがあるため、プロセスを高速化するために複数のコンシューマーを並行して動作させるというアイデアを検討してきました。

だから、私がやろうと思っているのは

• キューで独立して動作する複数のコンシューマー。
• 各消費者は自由にメッセージを取得できます。
• メッセージを取得したら、エンティティの最新バージョンであることを確認してください。このため、一部、このエンティティを処理するアプリケーションで確認できます。
• 最新でない場合は、バージョンを上げて再試行してください。

私はこれまで統合パターン、JMSドキュメントを調べてきましたが成功しませんでした。

既知のAPI、Javaの世界のパターンとともに、よりエレガントな方法でこの問題に取り組むためのアイデアを歓迎します。

私は Spring Integration を使用しており、子アイテムのコレクションを含む大きな XML ファイルを持っています。ファイルを一連のメッセージに分割したいのですが、各メッセージのペイロードは子 XML フラグメントの 1 つになります。

スプリッターを使用することは明らかですが、これにはメッセージのコレクションを返す必要があり、これによりメモリが使い果たされます。ファイルを個々のメッセージに分割する必要がありますが、一度に 1 つずつ処理する必要があります (または、マルチスレッドのタスク実行プログラムを使用する可能性が高くなります)。

サブメッセージをプログラムでチャネルに書き込むカスタムコンポーネントを作成せずにこれを行う標準的な方法はありますか?

Webアプリケーションがサードパーティのアプリケーションと通信する必要がある統合ソリューションを開発しています。Webアプリケーションは、特定のパラメーターを使用して実行可能ファイルを呼び出すことによってのみ、サードパーティアプリケーションのサービスを呼び出すことができます。次に、サードパーティのアプリケーションは、インストールされているサーバーに保存されているファイルの形式で結果を生成します。これらのファイルは、Webアプリケーションによって使用および処理されます。Webアプリケーションとサードパーティアプリケーションは、必ずしも同じサーバー上にあるとは限りません。WebアプリケーションはSpringフレームワークで構築されています。

現在、この統合を実行するために使用する必要のある最良の方法論とベストプラクティスを検索しようとしています。私はこの分野に慣れていないので、検索に使用する必要のある正確な用語がわかりません。また、Webアプリケーションがそのようなサードパーティアプリケーションと統合されているような設定を表す正確な用語もわかりません。

検索する情報の種類と、検索中に使用する用語についてのガイダンスが必要です。これは私にとって重要です。なぜなら、現在の方法論とベストプラクティスに基づいて、検索プロセス全体とソリューションを文書化する必要があるからです。

よろしくお願いします！

ぜんそく

データを送受信するために、すべての主要なCRMおよびERPシステムと対話する必要があるWebアプリケーションがあります。

あなたによると、より良いアプローチになります。

1. このロジック全体をWebアプリケーション内で設計します。おそらく、各インターフェイスのコンポーネントです。
2. ESBを使用します。

これを実装するための最良のアプローチを提案してください。他の回避策、設計も歓迎します。

環境内のシステム間でデータとビジネス プロセスを調整するために、企業内でサービス バス アーキテクチャを採用することを検討しています。

私たちの状況は典型的です。請求、在庫などのために内部システムにメッセージを送信する顧客向け Web アプリケーションです。これらのシステムのほとんどまたはすべてに共通するビジネス エンティティがいくつかあります。これらの各システムは、独自のデータベースでこれらのエンティティの独自のバージョンを維持します。

サービス バスの概念に適用すると、顧客の Web ポータルから注文を表すメッセージをバスに発行できます。このメッセージは、関連する各システム (請求、在庫など) によって消費され、対応する顧客レコードが独自のデータベースに作成されます。ただし、これらの内部システムの 1 つが注文ステータスに関するメッセージを発行する必要がある場合、独自のデータベースから注文 ID を保持します。Web ポータルがそのメッセージを消費する必要がある場合、内部システムから送信された注文 ID を Web ポータル データベースに保存された注文 ID と関連付ける方法がわかりません。

同等のエンティティがシステム間でどのように相関しているかを本質的に認識しているシステムは他にないため、システムがメッセージに含まれる ID をそれに関連する ID に変換できるようにするために、何らかのタイプのマッピング メカニズムを導入する必要があるようです。たとえば、あるシステムから別のシステムに ID をマップするデータベース テーブルを作成できます。このテーブルを照会して、ターゲット システムの適切な ID を取得できます。私たちのビジネスは現在、エンティティ集約やその他の「360ビュー」タイプのリポジトリを利用して、共通のエンティティ情報の単一の信頼できるソースとして機能し、そこからユニバーサルIDをすべてのシステム間で受け渡し、使用することはできません.

このようなエンティティ マッピング アプローチをサービス バスの実装に使用することは有効なアプローチですか? もしそうなら、設計を導くための確立されたガイドラインはありますか? そうでない場合は、サービス バスを介した統合を促進するために、システム全体でエンティティをリンクするための代替アプローチについて聞くことに興味があります。

PS: それが役に立てば、私は現在、バスを構築するための MassTransit フレームワークを評価しているので、それに固有の情報があれば、それも大歓迎です。

WSO2 ESB には、EAI パターンを実装するためのメディエーション シーケンスとプロキシ サービスがあります。私は現在初心者であり、メディエーション シーケンスまたはプロキシ サービスをいつ使用するかを区別できませんでした。どちらもほとんどのユースケースでうまく機能するようです。それぞれをいつ使用する必要がありますか？

アーキテクチャに関する質問：多くの異なる顧客に展開することを目的としたJavaEEエンタープライズアプリケーションがあります。構成は次のとおりです。

• 標準のバックエンド：すべての顧客に同じコア
• EAIアダプター用の個別のモジュール：すべての顧客固有の統合（財務、CRM、ERPなど）を含むことを目的としています-顧客ごとに1つの異なる実装

私は2つのオプションを見ることができます：

• core.jarとadapter-cust1.jarを含むbackend-cust1.earは1つだけです。
• アダプター用の個別のWAR。つまり、core.jarのみを含むbackend.earがあります。これは、すべての顧客に同じ配信であり、個別のアダプターcust1.warです。

問題は、最初のソリューションでは、コアが単純なJavaメソッド呼び出しでアダプターを呼び出すことができ、顧客固有の実装にCDIコードを挿入できることです。

ただし、2番目のソリューションでは、コアとアダプターの間で通信するためのリモーティング手法が必要です。たとえば、JMSやWSなどです。それは私にはかなり重い方法のようです。

ただし、アダプターはあらゆるもの（MQ、SAPクライアント、実際にはあらゆるもの）に依存する可能性があると考えており、これらの依存関係が共通のコアに影響を与えないようにしたいので、別の戦争を検討します。

それについて何か考えはありますか？