SOAP ペイロードに xsd:base64Binary 要素がある WS があります。
当初、これは最大 1MB 用に設計されていましたが、要件が変更され、現在は base64 に変換された 50 MB のアップロード ファイルを受け入れる必要があります :( Java では、これはメモリの点で巨大になります。
私の理論的な解決策は、これらの「添付ファイル」を一方の端から他方の端にストリーミングすることです（ファイルはWebアプリからアップロードされ、次にbase64に変換され、Webサービスが呼び出されてAdobeアプリに保存されます）-非常に非効率的です
Stax について読みましたが、それは WebServices 向けではありません。
Webservices と組み合わせてストリーミングを使用する方法はありますか?
( MTOM 、しかしストリーミングのサンプルは見つかりませんでした)
カスタムサーブレットとポストメソッドのオーバーライドでこれを行うことができると思います。
Stax を介して要求の InputStream を十分に読み取り、base64 を含む要素を見つけてから、要素の最後に到達するまで、ある種の Base64InputStream にパイプします。オブジェクトをレスポンスに変換して送り返すには、Stax または JaxB を使用します。
何をするにしても、リクエスト全体をバッファリングしないでください。CXF や JAXWS などの典型的な SOAP フレームワークを、バッファリングの処理方法を考慮せずに使用しないでください。ガベージ コレクターを激しく攻撃してパニックに陥り、逃げ出し、二度と電話をかけないようにします。
4GB ヒープを実行していて、HotSpot を使用していると仮定する場合は、Oracle (7u5) の最新の Java を使用していることを確認してください。次に、大きなヒープを処理するためのコレクターに切り替えます: g1gc (-XX:+UseG1GC) または CMS (-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode)
さらに、以下を追加することを検討してください。
-XX:+OptimizeStringConcat -XX:+AggressiveOpts -XX:+UseFastAccessorMethods -XX:+UseLargePages -XX:+UseStringCache -XX:+UseCompressedOops