真のSOAへの冒険

作者 Alex Maclinovsky , 翻訳者 松本 清一 投稿日 2009年1月15日

セクション

エンタープライズ・アーキテクチャ

トピック

WSDL ,

Webサービス ,

SOA ,

ガバナンス ,

Architecture ,

エンタープライズアーキテクチャ ,

Systinet

共有 |

私が12才のときに初めてJ.-H. Rosny Aine氏のQuest for Fireを見つけてから、冒険ジャンルに魅了され続けています。私にとって、冒険の特質は、捉えどころのないゴールを追求して、長くて危険な旅行に乗り出して、最終的には、いつもどおりに初めに発見したものより価値があって重要で、すごいものを見つける多彩な人物の一団に関する物語です。素晴らしいオズの魔法使いからロードオブザリングまで、私はそれらの話に夢中にならざるをえませんでした。

私は、冒険をSOAに関する私の考えの進化に対する完全なメタファとして用い、ガバナンスに関する私の考えと業界で浸透しているそれとが何故違っているのかについて、若干の光を投じようと思います。2004年の秋、私はEAIとSOAプラットフォームの主要ベンダーで働いていました。当時、SOAは熱く、マーケティングでも製品はSOAでした。言うまでもなく、競合相手もそれらの販売についてはまったく同じことを言っていました。しかし、私たちが自身の領域をエンタープライズでの実現に広げれば広げるにつれ、マーケティングメッセージのすべてが正確というわけではないということが明らかになってきました。あなたが弊社製品を得て、私たちの方法論を採用し、ガイドラインやベストプラクティスに従ってそれらを実行した場合（私たちのプロフェッショナルサービスを利用したとしても）、最終結果はSOAではないでしょう。少なくとも、SOAではない方法となるでしょう。それが作られることで、特定の目的に機能し、役に立つでしょう。しかし、それは数年早く想定されたので、SOAの当初の目的を果たすことはほとんどないでしょう。そして、それは用途が広く、大きな粒度、疎結合、動的に検索可能、容易に組み立て可能、楽に再利用できるサービスといったことを含んだ約束で、ビジネスとITの両方にアピールできるような SOAの考えになっていて、すべてのCIOの戦略プラン、RFI/RFP、製品機能リストについて、必要なものを順々につくりました。これは、私たちの製品の批評ではありません。私たちは、当時、他の人と同じようにそれをSOAと呼ぶ権利がありました。問題は、SOAの定義自身にあります。その考えが一般的になると、それを「完了した」と宣言しようと急ぐことがありました。そうするために、ベンダーとIT組織は、一様に、彼らのソリューションがサポートしているものをベースとした定義を微妙に変えました。結果として、すべての人がSOAを得たものの、ほとんどの人がそこからメリットを得られませんでした。

こうした背景に対して、私のチームでは経験に基づいた質問を求めました。ＳＯＡが持つべきすべての不足点に関して誰も言うことができないであろうプラットフォームを構築するために何をしますか？私たちの答えは、40ページのホワイトペーパーにまとめられました。それには、企業クラスのＳＯＡサービスの核となる特性とインフラをサポートしていると思われる内容を記述することによって私たちの考えを明示しています。:

1. モジュールのデコンポーザビリティ、コンポーザビリティ、モジュールの理解しやすさ、モジュールの連続性、モジュールの保護を含む、サービスの自己の閉じ込めとモジュラリティ;
2. サービス、コンシューマ、インフラ、ツールとレガシーの世界の間のインターオペラビリティ
3. コンシューマとプロバイダ間の疎結合
4. サービスに関するオーケストレーションとコンポーザビリティのサポート
5. サービスの見つけやすさとコンシューマとプロバイダ間の動的バインディング
6. サービス、コンシューマ、基盤コンポーネントのロケーションの透過性
7. 認証、権限、インテグリティ、機密性、アカウンタビリティ、同一性、ポリシーといったセキュリティの側面のいくつか、あるいはそのすべてを解決することによる、ＳＯＡエコシステム（サービス、コンシューマ、エージェント、コンポジットアプリケーション、インフラを含む）のいたるところにある信頼ある設計による幅広いセキュリティ
8. 要求に応じてリソースを取り出して公開するだけでなく、検知、予知、不要なものや想定外の動作や状態の軽減を含めた、持続可能性や自己回復のサポート
9. サービスの実装やコンシューマの複数バージョンの共存について、透過的に分かりやすくすることで、SOAエコシステムの時間的進化をサポートしているサービスのバージョニング
10. サービスコンシューマとプロバイダ間の関係を明確に定義・維持し、潜在的に危険な共通の前提についてのあいまいさをなくすためのサービスの契約
11. 活気があり、用途の広いＳＯＡのエコシステムを維持するのに必要な、多くのトランスポート、プロトコルをサポートしている柔軟な呼び出しメカニズムと、同期のオプションをもったネットワークの解決可能なサービスインターフェース
12. 多くのサービスの利用シナリオをサポートするために、容易に洗練することのできる大きな粒度のサービス
13. サービス利用の計測（リアルタイムと履歴の両方）
14. サービスとそれらの実装に関する監視、管理、制御
15. 相互関係と根本原因解決法をサポートしている例外と警告のハンドリング
16. サービスのインターフェースと実装の完全な分離を確かなものとしている効果的なサービスの仮想化
17. パフォーマンス、信頼性、可用性、標準度、アクセシビリティ、整合性、セキュリティ、などを含んだ、公開され、検証可能で、実施可能なサービスの品質（QOS）

この一覧は、私たちにＳＯＡ製品と実装に関する成熟度と完全性を評価するためのきちんとした基準も与えています。私たちの主要製品に適用してみると、どういった人がコードを所有したいかによって、それは40±5%となりました。そうして、再考することなく、私たちは「残りの60%」を構築しようとしました。そして、2005年の秋にリリース1.0までの間、そう呼ばれていました。

そういったものを作り始めるにつれ、私たちはいくつかの指標を見逃していたことに気づきました。しかし、19の核となるＳＯＡの指標は、17のものと同じくらいの素晴らしい響きを持っていなかったので、私たちはそれらを外見ベースのＳＯＡ基盤の考えの上に最初に遭遇するものとして、「17+」と呼ぶことにしました。その前提には、何故私たちが、エンタープライズのためのコンピュータプラットフォームとして適切なものにするであろうＳＯＡサービスの特徴のすべてをあげることができなかったかという根本的な理由がありました。その理由は、これらの指標が実際のビジネスをベースとして規定され、時とともに業界、場所、クライアントからクライアントへ、そして最も重要なのは、時間がたつにつれ変化する運命にある別の要求をベースにしているところにありました。市場が必要としていたことは、自由裁量に近いサービス指標のセットを実現・支援するためのプラットフォームであり、ユーザーが思いつきでサービスの追加・変更・削除をすることができることでした。より適切に言えば、現在のビジネスにとって重要なことをベースとしていたことです。

この非常に基本的な考えは、私たちのまさに最初のクライアントとの出会いで有効となりました。そのクライアントは国防軍で、まさに軍部基準の非常にこだわりのあるもので、セキュリティ要件の長いリストが出来上がりましたが、そのほとんどが私たちが直接サポート可能なものか、彼ら独自のセキュリティ基盤に任せることのできるものでした。しかし、私を驚かせる一つの要求がありました。それは、クライアントが、合法的で、きちんと認証され、正当に許可を得ているが十分な確認をしていないのユーザーによって、知らないところで、不十分に書かれたサービスを機密情報が明らかになる可能性を防ぎたいというものでした。私の最初の反応は、有能な開発者を雇い、完璧なＱＡをし、そして、なんとかなります！でした。そのとき私が実感したのは、クライアントの視点では、予見できない漏えいの脅威に対処するのは、業界の他の人たちも注意を払う責任があると考えるであろうすべての他のサービスの指標と同じくらい重要なことなのです。次に、私たちは、クライアントへ行く途中でサービスのレスポンスをチェックする検閲の観点について設計しました。メッセージや個々の断片の分類レベルを決定し、認証の間利用可能となっているプロフィールからクリアランスレベルでそれを比較し、必要な修正措置をとり、部分的な難読化から完全な傍受にわたりました。

リリース1.0の一方で、マーケティングは名前を必要としました。奇妙な理由のために、彼らは「残りの60%」のまわりでキャンペーンを始めるのに熱心でありませんでした。SOAiやSOAf (それぞれ、基盤[Infrastructure]の i と基礎[Foundation]の f を表しています)をいじった後で、おそらく当時のキャッチフレーズであったことから、ある人がガバナンスを持ち出しました。私は、当時、その言葉をよく知らなかったので、ちょっとググってみましたが、私が開発した技術と関係があることとはどうしても理解できませんでした。私の主たる関心事には、明確な定義と不明確なそれがなかったということです。

その分野の大部分のベンダーは、SOAガバナンスを単純に「私たちができること」として定義しました。Systinetは、WSDLのための記録システムであるという考えを押していて、分類法、公開ワークフロー、サブクリプション/ノーティフィケーションのメカニズムに関連したものをサポートしていました。 AmberPointは、それをautodiscoveryに依存した「良くないサービス」、軽量なセキュリティや監視、エンドツーエンドの故障解析であると見ていました。アプライアンスベンダーは、ガバナンスをWebサービスセキュリティが彼らが持っているすべてのメディエーション機能を加えるものとして見ていました。専門家は、下記のOASISのSOA参照モデルのように、謎めいてはっきりしない定義となっていました。それは、Pythia（ピュティア）を誇り高くするでしょう。

SOAガバナンス：構造化された関係、手順、方針を通じた、予測可能な前提条件と期待されるものと一致した管理結果の方法や規律が、組織や異なる所有者ドメインの統制下であるかもしれない分散された機能の利用に適用されること

それにいくらかの検討を加えた後に、私はこれらすべての背後に基礎をなす象が必要である（※１）(リンク)と実感し、それを定義しようと試みました。本稿の残りで、結果として起こるSOAの特徴を定義するものとしてSOAガバナンスの考えについて説明しようと思います。

（※１）問題をきちんと把握する必要があるという意味（Blind men and an elephant の寓話の象を引き合いにしています）

SOA全体の問題領域が、あいまいな専門用語に苦しめられているので、私たちはいくつかの重要な定義を明らかにすることから始めることにします。まずはじめに、私たちは統制するとは何かから始める必要があります。その答えは一目瞭然のように思われます。そう、サービス！です。しかし、この用語は、非常に多くの異なることを表現するのに使用されていて、そのほとんどがSOAとは関係のないものです。私は、あることを明らかにするのに、通常、資格があるかによってそれをおこないます。

エンタープライズサービスは、機能でない、ポリシー駆動な特性(セキュリティ、業界/顧客が定義したサービスポリシー、管理、モニタリング、ライフサイクル管理)の拡張可能なセットと結合し、自己の閉じ込められたコンポーネントを配布するビジネス機能です。そして、それは、明確に、標準化され、公開されたインターフェースによるリクエストに対処します。

エンタープライズサービスを説明するもう一つのものは、次の通りです。名称がCEOやビジネスオーナーの人たちに知られているサービス。後者はそれが何をしたかに関心があります。この定義によれば、invoiceCustomer(顧客請求)、dischargePatient(患者の退院)、 launchICBM(ICBN発射)は、エンタープライズサービスとしての資格がありますが、invokeBAPI(BAPI呼び出し)、 saveLogRecord(ログレコードの保存)は、明らかにその資格がありません。この定義に照らして、SOA自身は、次のように説明することができます。

エンタープライズサービスのエコシステムに向かって、エンタープライズITの進化を与えて手助けをするためのアーキテクチャスタイル

そして、最終的にはSOAガバナンスは、単純に次のようになります。

今日のビジネスに重要な機能でないサービスの特性という点で、エンタープライズサービスのライフサイクルを促進し、企業方針のためのコンプライアンスを生成、伝達、実行、管理するための手段を提供するプロセス、慣習、ツールの組合せ。

これらの定義によると、SOAガバナンスは、SOA参加者の制御の分野を超えた信頼できる再利用を許可することによって、エンタープライズサービスをデジタルなアーティファクトから真のビジネス資産に変えることです。この要約をよりやさしいものとするために、仮定に基づいた例を説明させてください。

多国籍企業Hot Dog, Incを想像してください。その会社は2つのビジネス単位(部門)を持っています(ロールパン調査部門とソーセージ開発部門)。それらには、別々の管理、P&L責任、ＩＴ部門と予算がありますが、同じ企業体の中で機能します。

あるとき、ロールパン研究のリーダーは、自身のコアビジネス機能を実行する想定の新しいアプリケーションを実装することを決定します。彼らがそうすることで、100万ドルの費用がかかりますが、善良な企業市民となり、彼らは新しく開発した機能を再利用可能な形式としてパッケージ化するために、さらに$50kを費やします。そして、企業全体の利益のためにそれを公開します。

次の年、ソーセージ開発の管理者は、自身のコアビジネスを実行するための新しいアプリケーションを構築する必要があるということを実感します。そして、たまたま、このアプリケーションには、開発、パッケージ化、デプロイされ、6か月早くロールパン調査部門の好意により彼らが利用できるようになった機能がまさに必要でした。[SOAのテキストにあるビジネスケースのように聞こえますね?] ソーセージ開発のITは、今、それらのサービスを再利用するか、新たに100万ドルを投じてスクラッチから機能を(再)開発するかのいずれかを選択します。私は、基礎をなす技術がCORBAや統制されていない(上記の定義を参照)SOAであるならば、ソーセージ開発の管理に対する責任を伴う唯一の行動方針は、彼らのドメイン制御の範囲内で要求された機能を実装するために、あえて資金を投じることです。理由は、次のとおりです。元のサービスは実装され、ロールパン調査部門によってホストされているので、機能的な観点で100%一致しているとしても、ソーセージ開発部門には以下の要素を知る術がありません。そして、それらのすべてが、ソーセージ開発部門のビジネスコンテキストの中でサービスの使いやすさを決定するのに不可欠なものなのです。

• 期待される可用性、信頼性、MTBFと修復までの時間はどれくらいか？
• どのようなセキュリティおよびアカウンタビリティのメカニズムが、実施されているか？
• これらのサービス実装が監査され、関連する規則の順守に含まれているか? （USAのSOX、ヨーロッパのプライバシー、医療のHIPAA など)
• どのくらいのパフォーマンスレベルがサポートされているか? どのくらいの負荷レベルが許容可能か??
• それらは一定か、あるいは、時間、日、週、季節などで異なるのか?
• サービス利用はどのように計測されて計上されるのか?

仮にソーセージ開発部門の管理者が、ロールパン調査部門内の中の対をなすものからこの情報のすべてを調査したとしても、重要な問題が一つ残ります。それは、私たちがこれらすべてが来週(来月、来年)に変更の予定がないということをどうやって知りますか?

思考プロセスが完了し、上記のSOAガバナンスの考えが具体化したとき、いくつかの事項が明らかになります（少なくとも私たちに）。

1. アインシュタインの相対性理論が、ニュートンの古典力学を後の人が適用できなかった領域に拡張した手法と同様に、SOAガバナンスに関する統合された考えを否定するものではないですが、そのかわりに、上記で述べた断片化した定義やアプローチを構築します。SOAガバナンスに関する私の記事、「SOAガバナンス - 考え方」に詳細を記載しています(リンク)。
2. 適切に実行されたこの考えは、先に記述したエンタープライズSOAの17+の核となる指標の全てに適合可能なソリューションを生み出すでしょう。
3. そのようなソリューションは、不完全なSOAプラットホームと今日の実行例をとって、それらを独自の考えを実現した真のサービス指向アーキテクチャに変える可能性があり、期待されたメリットのすべてを生み出す可能性があります。

結局、このガバナンスプラットフォームの構築は、私たちが考えたより簡単なことがわかりました。そして、ここまで冒険形式で説明したように、私たちは多くの予測できない有益な発見をしました。例えば、委任されたガバナンス、時間分析のガバナンス、使われなくなったものにやさしいガバナンス、統一されたガバナンス情報モデル、それらすべてが今後の記事の素晴らしいトピックとなるでしょう。

原文はこちらです：http://www.infoq.com/articles/quest-for-true-soa
（このArticleは2008年9月10日に原文が掲載されました）