「戦略的な意思決定」がSOA導入を成功に導く

実装技術／製品の選定は全体像を明確にした後に

（2007年02月23日）

　一般に、SOAの導入プロセスが進行するにつれて、アクセス制御と認可機能をアーキテクチャに取り込むことが難しくなる。セキュリティ制御の変更はプロセスとデータ・フローに大きく影響するため、セキュリティ機能に変更を加えるのであれば、アーキテクチャの根本的な修正が必要だ。

　そうした理由から、セキュリティ機能については外部セットとして構築するほうが有利だと、USiのラルフ氏はアドバイスする。同社では、すべてのサービスをセキュリティに対応させるため、セキュリティ検証とアクセス制御、さらにはエラー・リポーティングやデータ予測などの機能を含むWSDL（Web Services Description Language）テンプレートをID管理システムに組み込んでいる。

　レンタカー事業を展開するエービス・バジェットでも、「Omega」と呼ぶ初期のSOAプラットフォームのほうにセキュリティ機能をビルトインした。「認証機能は問題ないものの、認可機能については、サービスでハンドルするか、それともセキュリティ・サイドで実装するか、まだ検討中だ」と、担当者のツラトー氏は語る。すべてのサービスとアプリケーションに共通のセキュリティ機能を提供するというのが、SOAを導入するうえでの同社の方針だ。ツラトー氏によると、LDAPを使ってOmegaプラットフォームのセキュリティ機能を強化する予定だという。

　LDAPはID管理のキー・テクノロジーの1つであり、LDAP検索のクエリを含むすべてのサービスを開発することをツラトー氏は思い描いている。ただし、実行ごとのダイレクトなLDAP検索をなくす必要があることから、ビジネス・プロセスを特定する段階でLDAP検索を行い、ID情報をそれ以降のサービスに受け渡すようにすると同氏は説明する。

　このアプローチが抱えるリスクは、認証された属性さえ入手すれば簡単に正規ユーザーになりすますことができる点だ。そのためツラトー氏は、属性がいつどこで、また正しいプロセスで認証されたかどうかをトレースできる署名として実装することを検討している。

　オンライン・オークション大手のイーベイも、エービス・バジェットに似たセキュリティ・アプローチを採用している。すなわち、他のサービスから必要に応じてセキュリティ機能をコールするのである。同社の場合、プロジェクトごとに並列的なセキュリティ機能を用意するのではなく、それぞれのアプリケーション・ドメインに既存のサービスとアプリケーションを適用している。

　柔軟性を持たないセキュリティ制御は相応のリスクを伴う。ADPのボンギオーノ氏は、「当社では現在、セキュリティ・モデルを標準化する作業を進めているが、標準化によって過度な負担がかかるようであれば例外も許容するようにしている」と話す。

サービスのテストとデバッグ

　SOAやESBの導入に関連して、もう1つ正当に評価されていないものがある。サービスのテストとデバッグだ。「適切にセッティングされたSOAは、とりわけ実装にかかる時間の短縮化に貢献する。ただし、そのためには徹底したテストが不可欠だ」とADPのボンギオーノ氏は語る。

　厳密に定義されたサービス・インタフェースを適用していれば、サービス間の統合についてテストしたり、デバッグしたりするのは簡単だ。しかし、多対多というようなサービス間の関係や、ハードウェアやソフトウェアの多様性が時としてテストを困難なものにする。したがって、サービスのテストにあたって必要とされるのは、テストの対象領域を意味のあるスケールまで可能なかぎり広げることである。

　イーベイでは、自動回帰テストをサポートする独自の品質検査ツールを開発し、SOA固有の実行シナリオをテストする際に使っている。また、マーキュリー・インタラクティブが販売しているツールも併せて利用しているという（ADPでもマーキュリーの自動回帰テスト・ツールを利用している）。さらに、アパッチ・ソフトウェア・ファウンデーションが提供しているSOAPサーバ「Apache Axis」のサービス検査ツールを現在評価中だ。

　一方、金融機関向けのディザスタ・リカバリ・サービスを提供しているサンガードは、サービス間のあらゆる相互関係とサービスの要求仕様について完璧を期すため、すべてのサービスに関するテスト・ケースを最優先でそろえることに努めている。同社のテクニカル・アーキテクト、ニルス・ウィンクラー氏によると、そうしたテスト・ケースからユニット・テストを構築し、自動回帰テストを実施するという。

　もう1つ、サービスのテストとデバッグに関して忘れてはならないことがある。サービスのバージョン管理だ。当然のことだが、サービスの数が増加すれば、おのずと複数のバージョンをサポートしなければならなくなる。一度にすべてのサービスをアップデートするのは現実的ではないからだ。

　レジストリやリポジトリを使えば、サービスのバージョン情報を標準的な属性の一部として記録することができる。「この方法は有効だ。他のサービスもその情報に依存することができる」とボンギオーノ氏は言う。

　サービスのバージョンを管理するうえで最もすぐれた方法は、最初から管理スキームを念頭に置いてサービスを設計することだろう。ハートフォードのモアランド氏も、それを実践している1人だ。同氏は、すべてのサービスをいずれリプレースすることを前提に、サービスに関する設定や利用期間などの情報を管理するよう心がけている。移行期間中に異なるバージョンのサービスを実行する場合は、可能なかぎり、新しいサービスではなく古いサービスにデータをマッピングする移行支援サービスを利用するという。

　もちろん、どれだけテストに力を注いでも、すべてのエラーをキャッチすることは到底不可能だ。とりわけ、サービスのロジカル・エラーを検出するのはたやすいことではない。この種のエラーをサービスの実行時に特定するためには、呼び出したサービスからのメッセージを確認し、ビジネス・プロセスの仕様に沿ってフォーマットやポリシー、その他の属性におけるミスマッチをチェックする必要がある。

前のページへ < ｜1｜2｜3｜ > 次のページへ