受信した SOAP メッセージを適切なサービスにディスパッチする方法は多数あります。 2 つの最も簡単なメカニズムは、トランスポート レベルのディスパッチと、アドレスとアクションのディスパッチです。
トランスポート レベルのディスパッチ
トランスポート レベルのディスパッチでは、基になる HTTP サーバー ( HTTP API など) を使用して、デバイスとそのサービスへの要求のルーティングを管理します。 サーバーはサービスごとに異なる URL を提供し、デバイスには異なる URL を提供し、URL ごとに異なるシンクが登録されます。 これにより、同じプロセス内で個別のコンポーネントとして実行されるか、個別のプロセスとして実行されるように、各サービスが他のサービスから分離されるようにコードを設計できます。
トランスポート レベルのディスパッチには、いくつかの利点があります。 メッセージは、最初に SOAP エンベロープまたはメッセージ本文を解析することなく、適切なコンポーネントにディスパッチできます。 また、ほとんどの HTTP サーバー実装によって提供されるメッセージをルーティングするための既存のメカニズムを再利用できます。つまり、カスタム ディスパッチ コードは不要です。 また、セキュリティで保護されたサービスが共通コードを通過するメッセージを回避するため、サービス間で SOAP 処理コードを分離し、セキュリティ レベルを提供します。
住所とアクションのディスパッチ
アドレスとアクションのディスパッチは、メッセージがディスパッチされる適切なサービスを決定するために SOAP ヘッダーに依存します。 このモデルでは、ディスパッチに役立つ追加情報 (参照パラメーターなど) を使用することもできます。
このモデルでは、SOAP プロセッサまでのすべてのコードがすべてのサービスによって共有されるため、階層化されたメッセージング スタック全体でコードの再利用が促進されます。 また、サービスの個別のトランスポート アドレスは必要ありません。つまり、UUID アドレスをサービス エンドポイントに使用できます。 アドレスとアクションのディスパッチも、プログラミング モデルにより直接的に変換されます。 開発者は、サービスとデバイスを、HTTP レイヤーに結び付けたり、サービスごとに個別のコンポーネントを作成したりする必要なく、ルーティングを管理する 1 つのコンポーネントに接続できます。