特集 開発現場からの提言（前編） サービス指向アーキテクチャ（SOA）の実際 有限会社アークウェイ　黒石 高広 2005/10/15
Page1 Page2

3. Webサービスを使うだけでよいのか？

　Webサービスを使った際に起こり得る問題について説明するため、今回はバックエンドの在庫管理アプリケーション上で公開されている「在庫確認Webサービス」をECサイトから呼び出す場合を例として取り上げる。

Webサービスを使ったECサイトの構築例

バックエンドの在庫管理アプリケーション上で公開されている「在庫数確認Webサービス」をECサイトから呼び出す。

　もちろん、このWebサービスがSOAでのサービスとして適切な粒度であるかという議論もあると思うが、ここではその議論には触れない。

■ネットワーク空間の違い

　まず考えられるのが、Webサービスを呼び出す側と呼び出される側のネットワーク空間の違いによって生じる問題である。例えば、Webサービスが海外のサーバで動作している場合、常に期待される呼び出し速度でWebサービスが応答を返してくれるだろうか？

ネットワーク空間の違いによるWebサービス利用の問題点

　実際の現場では、サービスを呼び出す側と呼び出される側の間の物理的距離やネットワーク帯域などが呼び出し速度に影響を与える。最悪の場合にはタイムアウトが頻発したり、ボタンを押した後の処理結果の表示が遅かったりして、使い勝手が非常に悪いなどの問題につながってしまう。

　では、Webサービスを実行しているネットワーク空間が同じで、ネットワークも十分に速く、呼び出し速度に問題がなければどうだろうか？

■キャパシティの違い

　この場合に考えられるのが、2つのアプリケーション間のキャパシティの違い（性能差の違い）によって生じる問題である。

　通常、ECサイトではインターネットからのアクセスを想定しているので、大量のアクセスに備えて十分なキャパシティを持っている。それに対して、在庫管理アプリケーションは社内からのアクセスのみを想定して構築されているので、大量のアクセスに備えたキャパシティを持っていないケースが多い。

キャパシティの違いによるWebサービス利用の問題点

　このような場合、単純にWebサービスで連携してしまうと、ECサイトへの大量のアクセスが在庫管理アプリケーションへそのまま伝わってしまう。そして最終的には在庫管理アプリケーションのキャパシティを超えて障害が発生し、最悪の場合、両方のアプリケーションが停止する事態につながってしまうだろう。

　では、ネットワーク空間もキャパシティにも問題がなければどうだろうか？

■ライフサイクルの違い

　アプリケーションは、リリースからメンテナンスやバージョン・アップといったアプリケーション固有のライフサイクルを持っている。このため次に考えられるのが、このアプリケーションのライフサイクルの違いによって生じる問題である。

ライフサイクルの違いによるWebサービス利用の問題点

　通常、ECサイトは24時間365日での運用が求められる。しかし単純にWebサービスで連携している場合、在庫管理アプリケーションをバージョン・アップのために停止すると、ECサイトもその期間は停止する必要が生じてしまう。このため、在庫管理アプリケーションをバージョン・アップしたいだけなのに、それを行うことができないといった運用上の問題も生じる。

　これらのような問題はなぜ起きるのだろうか？ Webサービスという技術自体に何か問題があるのだろうか？ 同様の問題は、ほかの連携方法（例えば、異なるアプリケーションのデータベースへ直接接続し、クエリを発行して検索結果を取得するという方法）でも起こり得る。この問題は、Webサービスという技術ではなく、Webサービスが「同期連携（密結合）」であるという性質に起因する。

　従って、SOAの技術によって同期連携の問題を回避することはできない。これにはSOA以外の非同期連携のテクノロジを活用する必要があるわけだ。そこで次に、サービス／アプリケーション間の同期連携と非同期連携のテクノロジについて解説していこう。

4. サービス／アプリケーション間の同期連携と非同期連携

　同期連携とは、別のアプリケーションに対して要求を送信し、その要求に対する応答を受信してから次の処理を行う連携方法である。この点において、WebサービスやDCOM、Java RMI、RPCなどは同期連携のミドルウェア技術である。

　アプリケーション統合の世界では、同期連携を用いてアプリケーション間の連携を行っていることを「密結合」と呼ぶ。密結合とは、異なるアプリケーション同士が密接に依存し合っている状態のことで、片方のアプリケーションで障害が発生すると、もう片方のアプリケーションも停止してしまうという特徴がある。

　読者の方も、あるアプリケーションをメンテナンスしたいが、ほかのアプリケーションに影響が出るので止められない、あるアプリケーションに障害が発生するとほかのアプリケーションにも障害が連鎖してしまい困っている、といったシステム管理者の話を聞いたことはないだろうか？ これらは、企業内のアプリケーション同士が同期連携によって複雑に密結合されていることを示しているといえる。

　これに対して、非同期連携は別のアプリケーションに対して要求を送信すると、直ちに別の処理を行える連携方法である。IBM MQやJMS、MSMQなどのキュー技術やFTPによるファイル転送などが非同期連携のミドルウェア技術である。多くの企業で使われているバッチ処理を用いた連携も広い意味では非同期連携であるといえるだろう。

　アプリケーション統合の世界では、非同期連携を用いてアプリケーション間の連携を行っていることを「疎結合」と呼ぶ。疎結合とは、アプリケーション同士が極力依存していない「疎な状態」であることを指し、片方のアプリケーションで障害が発生しても、それに影響されることなくもう片方のアプリケーションのサービスを続行できるという特徴がある。

　たまに「Webサービス＝疎結合」という内容の記事を見掛けるが、アプリケーション連携という観点から見た場合、それは正しくない。Webサービスは、呼び出し先で障害が発生した場合は呼び出し元でも処理を続行することができない、これはまさに同期連携（密結合）の特徴である。

　では、先ほどのECサイトの例に非同期連携を適用してみよう。

非同期連携によりWebサービスを利用した場合のECサイト構築例

この例では、ECサイト側のデータベースに在庫情報を持ち、バッチ処理により在庫確認Webサービスを呼び出し、定期的に在庫情報の同期を行う。

　この例では、ECサイト側のデータベースに在庫情報を持ち、バッチ処理により在庫確認Webサービスを呼び出し、定期的に在庫情報の同期を行っている。ここではデータベースとバッチ処理を利用することで非同期連携を実現している。

　この方式では、ECサイト側でも在庫情報を持っており、ECサイト内部ではそのデータを利用しているので、ネットワーク空間やキャパシティ、ライフサイクルの違いにも影響されなくなる（もちろんお互いに影響がまったくないわけではなく、例えばバッチ処理が停止したままではアプリケーション間のデータの整合性が徐々に取れなくなるという別の問題も発生する）。

　このように、非同期連携を適用することによって、同期連携の問題を解決することができる。もちろん、非同期連携も万能の解決法というわけではなくデメリットも存在する。

　一般的に、非同期連携は同期連携よりも実装が難しく、開発コストが高いといわれている。これは同期連携と異なり、呼び出し元からの接続の失敗や呼び出し先で処理に失敗したなどの例外を検知できないためである。また、非同期連携で実装する場合、障害発生時の復旧方法が難しい問題となる。

5. 「SOA＝Webサービス」だけではうまくいかない

　以上の例からも分かるように、異なるアプリケーション間で連携を行う場合は（お互いに依存性の高いアプリケーション間の連携以外では）非同期連携で取り組んだ方がよい。

　同期連携の問題は、アプリケーションの開発中には気付きにくく、リリース後の運用段階に入ったときに表面化する問題ばかりである。同期連携を多用してしまうと、今回取り上げたような問題が運用段階に入ってから発生し、結局は使われないシステムになってしまいかねない。

　アプリケーション開発者は「SOA＝Webサービスを使う」と実装を決めつけるのではなく、この連携は本当にWebサービス（同期連携）で大丈夫か、非同期連携にできないかを、さまざまなトレード・オフを考慮して慎重に検討する必要がある。

■

　さて次回では、多くの企業でのアプリケーション統合の現状と企業内のアプリケーション間連携にどのように取り組めばよいか、アプリケーション統合の観点からどのようにSOAに取り組めばよいかをマイクロソフトのさまざまな製品や技術を使って説明していく。

INDEX
	[特集]
	開発現場からの提言（前編）
	サービス指向アーキテクチャ（SOA）の実際
	1．なぜいまSOAが求められているのか？
	2．「SOA＝Webサービス」だけではうまくいかない
	開発現場からの提言（後編）
	SOAの導入を成功させる現実的な方法とは？
	1．アプリケーション間連携の現状（AS-IS）とあるべき姿（TO-BE）
	2．メッセージ・バスによるSOAシステムの構築方法
	3．メッセージ・バスだけでは難しい問題

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）