SOAの導入を成功させるための10のステップ――SOA導入プロジェクトの経験者から聞き出した秘訣を一挙公開 5ページ
STEP 9
サービス管理製品を導入する
稼働しているサービスの数が多い場合や、ミッション・クリティカルなサービスが存在する場合には、それらを適切に管理する必要がある。現在、複数のベンダーがダッシュボードを備えたサービス管理製品を提供している。これらの製品は、サービスの状態監視、サービス・レベルの維持、パフォーマンスの調整、フェールオーバの設定、例外処理などの管理機能を備えている。
このような管理機能は、サービス自体やアプライアンス製品に備わっている仲介機能によって実現されている。仲介機能は、サービスを仮想化することによって、その実装の詳細をクライアントから隠蔽し、強固なセキュリティを実現するという側面を備える。また、同機能によって、XMLファイアウォール機能やアクセラレーション機能、数多くの関連するサービス群を1つのコントロール・パネルから変更できるようにする製品も存在する。このような機能は、法規制の改正や新しいセキュリティ要件への対応が求められる際に威力を発揮するだろう。
2005年3月にOASISが、分散したリソースをWebサービスによって管理するための仕様であるWSDM（Web Services Distributed Management）を承認したことにより、徐々にではあるが、仲介機能を採用する製品が増えている。また同年6月には、Intel、Microsoft、Sunの3社が、サービス管理に関するもう1つの仕様であるWS-Managementを標準化団体であるDMTF（Distributed Management Task Force）に提出している。このWS-Managementは、WSDMと一部重複する部分もあるが、アプリケーション・レベルのメッセージングではなく、ネットワーク・ハードウェアの管理を主な対象としている点が異なる。
このようにSOA環境の管理仕様が標準化されようとしているが、現時点では、一元管理を実現するには、Webサービス管理製品を1つのベンダーで統一しなければならない。この分野で先行しているのは、アクショナルやアンバーポイント、ブルー・チタン、SOAソフトウェアといった専業ベンダーで、大手ネットワーク管理製品ベンダーがそれに追随している。BMC Software、CA、HP、IBM、Novellの各社は、いずれもWSDMを支持しており、その進捗状況はまちまちであるが、Webサービスの管理機能を自社製品に取り込もうとしている。また、Cisco Systemsも、Webサービス管理機能を備えたネットワーク機器を近いうちに製品化すると発表している。
H＆Rブロックのトンプソン氏によると、同社はアンバーポイントのWebサービス管理製品を使用しているが、限定した部分にしか導入していないという。「まずは、サービス・レベルを監視することから始めて、次に例外の発生を監視できるようにした。本当は、暗号化／復号、認証、権限付与といった機能を管理できるようにしたいのだが、まだそこまでは達していない」（トンプソン氏）
一方、ハートフォードのモアランド氏は、Webサービス管理製品を導入した理由について、「サービス・レベルが低下したり、サービスに障害が発生したりした場合に通知する機能と、ポリシーを実施する機能が欲しかったから」と説明する。
そのほか、一元的なポリシー管理機能が最も重要だと考える向きもある。ローカルで実行されているWebサービスの状態をチェックすることは比較的容易だが、組織全体にまたがる数千ものWebサービスを再構築するためには、プラットフォームに依存しないポリシーに関する標準仕様が必要になる。この問題を解決する仕様としてはWS-Policyがあるが、製品への実装は進んでいない。
STEP 10
オーケストレーションを考慮する
サービスを自在にまとめ上げて、アプリケーションを構築するオーケストレーション機能は、どのSOAプラットフォームにも用意されているが、残念ながら現時点では、まだまだ満足できるものではない。その理由は、大規模なSOA環境におけるオーケストレーションが非常に困難であるからだ。一方で、小規模なSOA環境では、オーケストレーションがあまり必要とされていないという現実がある。
オーケストレーションが必要かどうかを判断する基準を、Forrester Researchのヘフナー氏は次のように説明する。「何らかのリクエストを受けた際に、複数のアプリケーションにまたがって処理を行う必要がある場合は、オーケストレーションが必要である」（ヘフナー氏）
さらに、同氏は、オーケストレーションを行うためには、ある程度の待ち時間を許容しなければならないと補足する。「基盤となるアプリケーションでどの程度の処理を行うかにもよるが、4分の1秒でオーケストレーションを行うというのはまず無理だろう。場合によっては、5秒でも足りないのかもしれない」（ヘフナー氏）
前出のリンド氏は、オーケストレーションについて、次のように語る。「オーケストレーションは、BPMを体系化する試みで、信じ難いほど複雑な作業である。製造業などの特定業種に適用するのであれば、ある程度シンプルな形にまとめることはできるだろう。しかし、業務全般にわたるサービスの管理となると、各プロセスの関係が複雑であるため極めて難しい」（リンド氏）
リンド氏の意見とは異なり、オーケストレーションと、ワークフロー・モデリングにルーツを持つBPMとを明確に区別するべきだと主張するのは、ヘフナー氏である。「この両者には、元々深いつながりがない。モデリング言語には、このステップをBPEL（注1）に落とし込もうといった判断ができるような、プロセス全体を見渡す手段が提供されていない。なぜそうなっているのか、わたしには理解できないのだが」（ヘフナー氏）
一方、このBPELには、致命的な弱点があると主張するのは、フラッシュラインのスタック氏である。「2004年に業界内でBPELに関する議論が行われていた際に、人間との相互作用に対応しないオーケストレーション・プロトコルに決めたことは間違いだったと思う。その証拠に、小規模な実験以外でBPELを使用している顧客を知らない」と同氏は語る。ちなみに、同社の顧客には、旅行サイトを運用しているセイバー・ホールディングスや住宅ローン会社であるカントリーワイドなど、先進的なWebサービスを展開している企業も含まれている。
ハートフォードのモアランド氏は、IBMとSAPが共同提案しているBPELの拡張仕様であるBPEL4Peopleに可能性を感じているという。「BPEL4Peopleによって、オーケストレーションとBPMワークフローという2つのレイヤは統合されると見ている」（モアランド氏）
H＆Rブロックのトンプソン氏は、プロプライエタリなBPM製品を導入しても、決して不利益にはならないという経験をしている。H＆Rブロックでは、TIBCOのBPM製品を採用したことによって、社内へのSOA導入に弾みがついたのだという。「さまざまなサービスをオーケストレーションさせて1つのビジネス・プロセスを構築し始めるまで、われわれはSOAの効果を全面的に信じていたわけではなかった。ところが、想像以上の成果をもたらした」とトンプソン氏は語る。
注1：BPEL（Business Process Execution Language）は、複数のWebサービスのワークフローを記述するためのXMLベースの記述言語である
最終的なゴールは遠いものの
現時点でもメリットは大きい
SOAを推進しているアーキテクトたちは、SOAのテクノロジーをさらに高いところに引き上げることを目指しており、「自己最適化するIT」という理想が現実になると予言している。これは、具体的には、容易に調整可能なビジネス・ルールに基づいて、アプリケーションとネットワーク・インフラを自動的に監視、および再構築できるということである。
ただし、自己最適化を行う大規模なSOA環境が実現するには、図4に示したような課題をクリアしなければならない。よって、ゴ－ルに到達するのは、何年も先の話になるだろう。
現在、最もSOAの導入に成功している企業であっても、ほとんどオーケストレーションを実現できていない。しかし、それでもSOAは確かなメリットをもたらしている。Forrester Researchのヘフナー氏は、「以前は実現できなかったアプリケーション統合を容易に行う道が開かれてきていることは事実だ」と語る。このことは、アジリティを極限まで高めるというSOAの将来的なゴールと比べると見劣りしてしまうかもしれないが、現場レベルのITスタッフにとっては、極めて大きな変化である。現時点のSOAは、必要なテクノロジーの一部が未成熟であるが、ITのアジリティを引き上げるために必要なフレームワークを提供してくれるのだ。
なお、導入したSOAが効果的に働いているか否かは、BAMによって知ることができる。BAMはSOAのメッセージ・ストリームを監視し、各サービスや再構築されたアプリケーションがどの程度のビジネス価値を生み出しているかをユーザーが判断できるように視覚化してくれるのだ。
実は長い目で見ると、ホワイトボードを使用したミーティングを熱心に行った企業は、現時点で可能なかぎり高いレベルのオーケストレーションを実現している企業よりも、将来のSOAに向けてより効果的な準備を行っていると言えるかもしれない。ハートフォードのベン・モアランド氏は、「組織という観点から見た場合の最大の課題は、従来とは異なる役割と責任が従業員に求められることを理解させることだ。SOAの世界では、共同責任の重要性が増すことになる。なぜなら、自分たちのビジネス領域に集中しながら、自分たちのコントロールがまったく及ばないかもしれない領域のサービスやインフラを利用することになるのだ」と語る。
（月刊Computerworld 2006年4月号に掲載）
提供：Computerworld.jp
