netty編解碼器vs smooks編組

Question

在直接TCP，HTTP或SOAP或其他傳輸協議上使用基於文本的EDI X12消息負載（例如http://examples.x12.org/）時，任何人都沒有任何例子或智慧詞：

1）使用netty進行簡單傳輸協議幀編碼（如TCP STX/ETX成幀，HTTP成幀），然後將原始有效載荷轉發到另一個工具，如Smooks進行解析/編組。 （如果還有其他替代品，請分享！）

2）或者使用Netty和自定義創建的編解碼器來解析複雜的循環內容（段，字段，組件等）。

在任何一種情況下，看起來都是可能的，但要尋找足夠的性能（1000條消息/秒），低延遲（10毫秒或更低），低延遲標記（如最小GC）以及創建編解碼器或解析器/編組器它可以移植到其他傳輸協議/其他（Java）系統。

部分無知/混亂是編解碼器與編組/解析器的消息，特別是當消息可以通過TCP直接傳輸時。

感謝您的任何指導！

Answer 1

回答我自己的問題：使用camel解決方案，其中netty4-http是端點（用於HTTP成幀），以及用於EDI有效負載解析的smook（作爲駱駝數據格式）。

對於〜1.5kb大小的X12有效載荷，Smooks似乎處於EDI-to-Java解組impl的20-40ms延遲範圍內。編組我使用java對象的直接編寫器，因爲對smooks camel dataformat使用元帥沒有功能。

雖然延遲較高，但很快就設置了edi xml文件映射，並使用maven-ejc插件從edi xml創建java綁定對象。爲了快速週轉，而不是長期的運行時間性能，對於我的場景來說是非常好的折衷。