わかりやすくするために質問を編集しました。
私はSOAPベースのJavaWebサービスを学ぼうとしています。@WebServiceアノテーションを使用して簡単なWebサービスを作成しました。ローカルマシンで公開し、ローカルマシンでサービスを利用しました。WSDLファイルが自動生成され、SOAPメッセージが「内部」にあることがわかりました。TCP/IPモニターを介してのみSOAPメッセージを追跡できました。
後で、Java SOAP APIには、SOAPメッセージを自分で作成し、MessageFactoryやSOAPMessageなどのクラス/インターフェースを使用して送信するオプションがあることがわかりました。
私の質問は、WSDLおよびSOAPメッセージが自動的に生成および処理される場合、Java SOAP APIを使用してSOAPメッセージを手動で作成および送信するためにSOAPハンドラーが必要なのはなぜですか？
私の質問は、もし WSDL と SOAP メッセージが自動的に生成され処理されるのであれば、Java SOAP API を使用して手動で SOAP メッセージを作成して送信する SOAP ハンドラーが必要になるのはなぜでしょうか?
SOAP 通信、SOAP メッセージの作成などをより詳細に制御したい場合があるためです。 MessageFactory と SOAPMessage について言及する場合、実際にはSAAJを参照しています。JAX-WS と比較すると、SAAJ は、このアプローチがもたらすすべての長所と短所を考慮して、より低いレベルで動作しています。Javaロッキングから：
JAX-WS 対 SAAJ
実用的な観点から言えば、SAAJ を使用するということは、「wsimport」や「wsdl2java」などのツールを使用しないことを意味します。これらは JAX-WS で使用するためのもので、クライアントがドメイン オブジェクトを生成し、Web サービスをまったく使用していないかのように動作する手段です。SAAJ では、サービスのドメイン ビューはありません。あなたは本当に配管を扱っています。JAX-WS を使用した開発は、はるかに迅速かつ簡単に行うことができ、通常、制御が失われることはありません。しかし、JAX-WS は便利なレイヤーであり、SAAJ のコマンドを使用すれば、WSDL インターフェースが必要とすることは何でも実行できるということを知っておくと安心できます。
個人的には、常に JAX-WS を使用します。
JAX-WS を使用する場合、明示的に Java SOAP API を使用する必要はありません。しかし、SOAP メッセージング アプリケーションを直接作成することを選択すると、これらの API が明らかになります。
架空の例として、SOAP メッセージの解析をより細かく制御したい場合があります。XML 全体を処理するのではなく、xpath を使用してその一部を処理します。