SOA　Q&A

2007.06.28

　要求開発方法論は，SOAでの利用も想定している。その根拠は，サービス構造を明確にすることで，そのサービス構造を実現するための，プロセス構造と情報構造をモデリングするからである。

　SOAになぜ要求開発方法論のような手法が必要なのか？それを考えるためには，SOAの本質を理解することが必要だ。そこで今回は，「SOA Q&A」という形でまとめてみた。

　SOAを単なる実装技術として考えるのではなく，手法として考えてみる。その本質が理解できれば，要求開発方法論がいかに適した手法であるかをご理解いただけるであろう。

　なお，Q&A作成にあたり，アーキテクタスの細川努さん，豆蔵の岩崎浩文さんにアドバイス＆加筆をいただきました。この場を借りて，感謝します。

Q. SOAとは何ですか？

A. Service Oriented Architecture（サービス指向アーキテクチャ）とは，サービス単位を明確にした方法でシステムを構築する手法と，それを支えるWSDL，SOAPなど，ベンダー/製品非依存でサービスを呼び出すための技術です。ここで言うサービスとは，何らかの業務機能を提供する単位のことを指します。

　より正確には，次の三つに分類されます。

(1)最適化手法としてのSOA
　政府や企業の業務をサービスとして定義し，最適化（内部的な重複の排除，外部へのアウトソース）を行う手法。

(2)設計手法としてのSOA
　業務機能を提供する単位として，サービスを設計し，システム構築する手法。

(3)実装技術としてのSOA
　サービスをベンダー/製品非依存で呼び出すための技術。

　初期のSOAでは，システム間での疎結合な連携を行うための技術（SOAP，WSDL）だけでしたが，現在では，BPEL（業務プロセス制御），セキュリティ（WS-Securityなど），分散処理（WS-Coordinationなど），サービス内部のコンポーネント技術（SCAなど）といった各種の技術を含めてSOAととらえる必要があります。

Q. SOAのメリット，目指している方向性は何ですか？

A. SOAを適用することには，次の二つのメリットがあります。

　SOAの最も普遍的な評価すべきメリットは，ビジネス主導でIT化するために，ビジネスに必要な，ユーザーから見た機能単位に，ソフトウエアを構築するというアプローチや手法を取れることです。このようなアプローチを取ることにより，技術主導でビジネスに不必要なソフトウエア部品（コンポーネント）を作ってしまうといった失敗は少なくなるでしょう。

　もう一つは，技術的な側面でのメリットです。SOAでは，サービスを部品化して追加・変更・再利用可能な設計ができるように，サービスの単位の独立性，汎用性，可搬性を保持する必要があります。そのために，XMLを最大限活用したリモート呼び出しの技術体系（Webサービス：SOAP，WSDL，WS-*）を基盤技術としています。これによって，サービスの疎結合を実現しやすくなっています。

Q. SOAの技術としてWebサービスを使うのと，通常のメソッド（機能）呼び出しとはどう違うのですか？

A. SOAでは，サービスはインターネット上でネットワーク呼び出しされるのが基本です。そのため，呼び出しの定義（インタフェース：WSDL）も，呼び出しのプロトコル（方式：SOAP）もXMLを活用した標準化技術を利用しています。この点が，通常のメソッド呼び出しとは根本的に違います。

　通常のメソッド呼び出しでは，.NET同士，Java同士などのように，技術基盤内での呼び出しが大前提ですが，Webサービスでは各実装基盤独自の呼び出しプロトコルではなく，XMLを利用します。これにより，特に異種混在環境内でも相互接続が可能となります。

Q. SOAの技術としてWebサービスを使うメリットは何ですか？

A. ベンダーや製品から独立した標準技術（Webサービス）を使うことにより，分散化されたサービスを利用できるようになります。そして，ビジネス・システムの構築・拡張において，柔軟な対応が取りやすくなり，ビジネスの変化に対応しやすいシステムを構築できる可能性が高まります。

Q. では，SOAの技術としてWebサービスを使えば，サービスの汎用化や，拡張可能なサービスなどを構築できるのでしょうか？

A. いいえ，それは違います。サービスの汎用化や，拡張可能なサービスを実現するには，ビジネスを見える化し，それをサービスという単位に区切っていく手法が必要です。SOAは，このような手法としては未成熟です。

　SOAはこれまで，技術的な側面で除々に発展をとげていますが，残念ながらこのような手法的な側面はほとんど未発展です。Webサービスといった技術に頼らず，しっかりとビジネスの機能を，誰（ロール）に提供するのか，何のために提供するのかという観点でサービスに分離していく必要があります。

　また，実装面でも特にトランザクション境界を意識した設計や，WS-*プロトコルの正確な把握と特性を意識した設計が必要になります。そのため，場当たり的な末端プログラマによる実装は困難であり，正確なアーキテクチャ設計を担うITアーキテクトの責務がなおいっそう重要度を増す点に注意する必要があります。

Q. SOAを適用しやすい領域はありますか？

A. 単純に考えると，使用したいリソースが分散している場合に有効です。SOAは，分散システムを構築するための手法と技術です。分散システムは，使いたいデータなどのリソースが分散しているから分散システムを構築するのです。

　最近のビジネス・システムは，すでに構築・利用されているサービスを組み合わせ利用するようなビジネス統合的なソリューションが必要とされます。そのような場合に，SOAは非常に有効な手段でしょう。

　また，実装面では，SOA製品自身がメッセージング・サーバー（MQサーバー）を基盤技術としている点から，現在MQシステムをベースに稼働している場合は，SOAをそのまま適用しやすい領域となります。この場合，パブリッシャ側をSOAクライアント，サブスクライバ側をSOAサーバーとみなすことが可能です。さらに，このメッセージングをルーティングするには，ESB（Enterprise Service Bus）と呼ぶ製品が有用です。

　一方，もう一つのアプローチとして，リソースをあえて分散させるということも考えられます。サービスを切って「ビジネスプロセス層」「ビジネスリソース層」などのレイヤーをWebサービスを使って実現する方法です。

　これは，一つのものを分散化するアプローチであり，高度な設計技術と，なぜ分散させるかという明確な根拠が必要となる点に注意しましょう。残念ながら，現状のSOAの適用には，根拠がなく，かつ，技術的リスクを考慮しない分散化が見られます。これは，SOAの発展にとって悲しい現実です。

Q. SOAの技術としてWebサービスを使うことに，何かリスクがありますか？

A. 次のようなリスクを考慮しなければなりません。

　一つは，サービスを使うプログラムとサービスを提供するプログラムが分散されることです。WebサービスをWebシステムで使用する場合，Web層のマシンとは別にビジネスサービス層を実現するマシンを用意してWebサービスを実現します。これによって，システムの冗長性が増し，信頼性が損なわれる可能性があります。ただ，構築方法によってはビジネスサービス層をWeb層から独立させるために，保守性の向上につながることもあります。そこは設計者の腕の見せどころです。

　二つ目は，Webサービスによる呼び出しは，通常のメソッド呼出しの数千倍・数万倍遅くなる可能性があることです。例えば，通常のメソッド呼び出しでは0.1ミリ秒（1秒に10,000回呼び出せる）のところが，0.1秒～1秒というオーダーとなり，人間が遅いなあと実感するレベルの速度になります（これはあくまで例であり，マシンスペックによって結果は異なります）。このように遅くなる要因は，リモート呼び出しに加え，一回一回の呼び出しごとにXMLを解釈する時間が必要となるからです。

　三つ目として，これまでのORB（Object Request Broker）などを利用した密結合のシステムより，トランザクションのきり方が難しくなります。簡単に言うと，ロングトランザクションに対応しにくいのです。例えば，どこかのノードにあるサービスを更新系で利用していて，連続して次のサービスを更新しようとした際に問題が発生した場合，前のサービスをロールバックしなければなりません。これをデータベースなどを頼ることなく，設計者の責任で実現しなければならないために複雑化することになります。

　もう一つ，多くのSOA製品を導入した場合，各社の標準への適応度合いが違うため，一貫性を持ちつつ情報システムを構築するには，事実上一社の製品で揃える必要があるという点も制約となります。製品間の適応度合いの違いは，バージョンが異なるプロトコルへの準拠の有無といった実装面での問題から，他社製品との接続サポートの有無という点まで多岐にわたります。現時点での制約として認識しておく必要があります。

Q. これまでの回答を聞いていると，SOAを使わないほうがよいのでは，と思うのですが。

A. それは誤解です。技術はあくまで適材適所で使うべきということなのです。疎結合なシステム構成は，同時に密結合部分を見つけ出すことが重要なのです。しっかりと密結合しなければならない個所を設計し，そこからサービスを提供する入り口をWebサービスで実現し，その中身の実装をブラックボックス化する。このアプローチを逆の視点でとらえると，しっかりと変更・拡張可能性がある個所をビジネスの視点から見つけ出し，その部分をSOAによって疎結合にしておく，そのような設計アプローチが必要となります。

　サービスを何でもかんでもWebサービス化するのでは駄目なのです。しかし，サービス単位にソフトウエアを構築するのは正しい考えです。そのようにサービス単位にソフトウエアを構成したら，データベースの依存関係も考慮して，何をWebサービス化すべきかを設計し，その設計根拠をしっかりとした設計コンセプトとして掲げてください。

　なお，サービスの独立性や共通化，再利用できるサービスの単位などは，あくまでビジネスでの利用例で検証すべきです。具体的には，ビジネスシーンを想定して，サービスを実現しているSOAの動作シーケンスをシーケンス図などで検証したり，プロトタイプによって検証しなければ，絵に描いた餅を実現してしまうことになります。