SOAを実現させる技術

RPC指向よりもメッセージ指向に

   繰り返すようだが、レベル3の疎結合を目指すのがSOAだ。SOAP-RPCを利用したWebサービスの実装では実装に依存するインターフェースを知らなければならない。

   SOAP-RPCなどでも、確かに動的インターフェース呼び出しはできるが、それはSOAの目指す疎結合の一歩手前のレベル2の疎結合だ。DCOM やCORBAもこの一歩手前まではきていたがレベル3にはおよばなかった。レベル3の疎結合では、メッセージがあるインターフェースが受けると、クライア ントはどの実装で処理されるかわからないが、何らかの処理がなされて、メッセージが返ってくる。

   「第1回：SOAを理解する」の請求処理の例について考えてみよう。新しいビジネスプロセスの請求書を発行するプロセスは、商品とサービスで異なるが、請求処理のメッセージを請求書発行インターフェースに渡すと、各々に適したプロセスが実施され、非同期で請求書発行メッセージが返される。

   つまり、再構成された請求業務システムは、画面、入力方法、入力項目、ルールを統一して再構成し、インターフェースにメッセージを渡しさえすれば適 切な実装が呼び出され、事業部にかかわらず統合することができることになる。もちろん、事業部ごとに実装があるのが非効率な場合は少しずつ統合していけば よい。

インターフェースの堅牢性と情報構造の柔軟性を保つ

   SOAでも、外側の枠組みは堅牢でなければならないが、情報構造は柔軟に変更できるようにしなければならない。例えば、下の請求要求のメッセージ構造を見てみよう。

   このような構造にしておき、この外枠を変更しない。変更するのはInvoiceTypeに記述できる内容とInvoiceContent要素の中身だ。

   こうすることで、InvoiceRequestというルート要素を変更する必要がなくなるので、インターフェースの堅牢性は保ったままで情報構造の追加に対応できる。

同期よりも非同期

   サーバの稼働状況に依存しないために、非同期の方が疎結合といえる。また、ビジネスに適したシステムを考えると人間の動作を配慮に入れる必要があり、システムの動作時間は人間の処理時間に影響を受ける。そのため同期よりも非同期処理の方が適している。

ヘテロジニアス環境で実現する

   システム再構成をするためには、複数の環境（Linux、UNIX、Windows、ホスト）などで連携ができなければならない。現在では、システムが同じでも別のプラットフォームで構築していることはめずらしくない。