1

テキストベースの EDI X12 メッセージ ペイロード ( http://examples.x12.org/など) をストレート TCP、HTTP、SOAP、またはその他のトランスポート プロトコルで処理する場合、次のいずれかに関する例や知恵を持っている人はいますか?

1) 単純なトランスポート プロトコル フレーム エンコーディング (つまり、TCP STX/ETX フレーミング、HTTP フレーミング) に netty を使用し、解析/マーシャリングのために生のペイロードを Smooks などの別のツールに転送します。(smooks 以外の代替案がある場合は、共有してください!)

2) または Netty とカスタム作成されたコーデックを使用して、洗練されたループ コンテンツ (セグメント、フィールド、コンポーネントなど) を解析します。

どちらのシナリオでも可能と思われますが、十分なパフォーマンス (1000 メッセージ/秒)、低レイテンシ (10 ミリ秒以下)、最小限の GC などの低レイテンシ マーカーを探しています。他のトランスポート プロトコル/他の (Java) システム。

無知/混乱の一部は、特にメッセージがTCP経由で直接転送される可能性がある場合、メッセージのコーデックとマーシャラー/パーサーです。

ご指導ありがとうございます。

4

1 に答える 1

0

私自身の質問に答えるには：netty4-httpがエンドポイント（HTTPフレーミング用）であり、EDIペイロード解析用のsmooks（ラクダデータ形式として）であるキャメルソリューションを使用しました。

Smooks は、最大 1.5kb サイズの X12 ペイロードの EDI-to-Java unmarshal impl で 20 ～ 40 ミリ秒のレイテンシ範囲にあるようです。マーシャリング smooks camel データ形式でのマーシャリングの使用は機能しなかったため、Java オブジェクトからのダイレクト ライターを使用しました。

待ち時間は長くなりますが、edi xml ファイル マッピングのセットアップは非常に迅速で、maven-ejc プラグインを使用して edi xml から Java バインディング オブジェクトを作成します。私のシナリオでは、迅速なターンアラウンドと長期的なランタイム パフォーマンスのかなり良いトレードオフが得られます。

于 2015-07-07T16:32:43.387 に答える