SOAPというプロトコルは、システムに対して“疎結合”という考え方をもたらしてくれます。疎結合とは何でしょうか。
アプリケーションの中には、データベースやビジネスオブジェクト、そして、ユーザーインターフェイスなどさまざまな機能が含まれています。今までのアプリケーションの作成方法を見ていくと、これらは、互いに密接な関係を持っていることがあります。例えば、「ユーザーインターフェイスの変更を行おうとしたら、ビジネスロジックの修正も余儀なくされてしまう」とか、「データベースの構造が変わったのでビジネスロジックとユーザーインターフェイスも変更しなければならない」といった状況は、アプリケーションを構成する要素が疎結合の逆である“密結合”となっているためであり、それがもたらすデメリットといえます。
単一のシステムの中では、COMやCORBAといった1つのアーキテクチャの中で完結していることが多いかもしれません。これらのアーキテクチャは、トランザクション性能などを重視した密結合ソリューションを想定しています。ある決められた目的を達成するためにこれらの選択を行っているのですから、それ自身は問題となりません。つまり、密結合ソリューションが適している場面もあるということです。しかし、インターネットなどを介した、通信によってアプリケーション間連携を行っていくとなった場合、つまり、さまざまなプラットフォームに存在するアプリケーション機能を活用していくとなった場合は、密結合が最適な選択肢であるとはいえません。
XML自身の仕様も、このような状況を打破するように策定されているのをご存じでしょうか。XMLとXSL、そしてXMLとXML Schemaの関係のように、ビューとコンテンツ、そして、コンテンツと構造は明確に分離できるようになっています。それぞれの依存関係をできるかぎり減らしていくことで、アプリケーションに対して柔軟性を高めていこうという考え方なのです。このようになっているおかげで「コンテンツが変更されてもビューには影響しない」といった、アプリケーションにおける柔軟性を獲得することができるわけです。
さて、これがSOAPとどのような関係があるのでしょうか。
インターネットの世界では、ビジネスの変革に応じて迅速なアプリケーションの更新を求められることが多いでしょう。このようなとき、システムとシステムが密接に連携してしまっていると、素早いアプリケーションの展開や更新ができません。
そこでSOAPの登場です。
例を挙げましょう。あるシステムがなんらかのサービスを提供しており、手元のアプリケーションからはこれを呼び出して利用しているとします。さて、そのサービスに関連した業務処理に変更が行われたとします。このような場合、サービスを提供しているシステムの実装に手を加えるという作業は発生するかもしれませんが、手元のアプリケーションは、そのサービスとの間で決まったXML メッセージ(つまり SOAP メッセージ)をやりとりすることでその処理を完結することができます。つまり、変更が発生したとしてもアプリケーションに与える影響を最小限にし、新しい機能や変更を加えていくことができるわけです。また、利用するサービスを動的に変更したとしても、そのメッセージ交換の内容が変更されていなければ、必要に応じたサービスの選択を行っていくことができるようになるのです。
このようにして、インターネットを介したアプリケーション間連携を動的に実現することで、時代に沿った新しいアプリケーションへと変革する際に必要最小限の更新で済むようになります。すなわち、アプリケーションの柔軟性を取り込むことができたということです。
また、SOAPというプロトコルは、ご存じのとおり、オブジェクトなどを呼び出すための手続きを、「メッセージ交換」という手法を用いて定義しています。このメッセージは、XMLをベースとしたテキストで記述されているわけです。ただ、この仕様の中には、セキュリティについての考慮やトランザクションの実装などビジネスアプリケーションに必要と思われるさまざまな機能を実現するための方法は規定されていません。
それは、SOAPエンベロープが拡張可能であるためでもあります。つまり、セキュリティについての機能やトランザクションについての情報をここに格納しておけば、あとからエンベロープを拡張するだけで新しい機能を追加できるようになっているわけです。多くのシステムでは、時がたつにつれ、よりよい機構が登場してきます。そういったときに柔軟に追加できるような構造をSOAPは備えています。
このように SOAPは、アプリケーションに柔軟性をもたらし、しかも新しい技術を迅速に取り込むことができるようになっているのです。
Copyright © ITmedia, Inc. All Rights Reserved.