レベル: 初級 Greg Flurry, Senior Technical Staff Member, IBM Software Group
2008年 10月 08日 
柔軟でさまざまな状況に対応できるエンタープライズを実現する手段として、SOA がますます使われるようになってきています。SOA の初期導入で成功を収めたアーキテクトや開発者達は、今度はすべてのビジネスや IT システムに共通する事項に焦点を当てています。どのシステムにも当てはまるそうした共通事項の 1 つが「変更」です。この記事では、SOA において変更を行う際の課題と、そうした課題に対応するためのモデルについて説明します。
IBM WebSphere Developer Technical Journal より.
変更の扱い
SOA (Service Oriented Architecture) は、多種多様なエンタープライズにおける、ビジネスの柔軟性およびさまざまな状況への対応能力に対する要求に適切に対応しています。しかし SOA の場合も他のシステムと同様、ビジネス上、あるいは技術上の理由により変更が生じた際には、必ずそうした変更に対応しなければなりません。実際、SOA はビジネスのアジリティーを高めるものであり、アジリティーとはつまり変更を意味するため、SOA はむしろ変更を推奨していると言うこともできます。そうは言っても、SOA でも変更には苦痛を伴う場合があります。SOA の導入によってビジネスはさまざま状況への対応能力が高まり、変更にも適応できるようになったので、今度は SOA はスマートな方法で変更に対処できるようにする必要があると言うこともできます。
システムでの変更のレベルには、さまざまな粒度があります。SOA はサービスを対象とするものであるため、SOA での変更を検証するためにはサービスに焦点を当てることが最も自然です。そして変更が行われた場合、通常はその変更結果を変更対象の新しいバージョンと考えます。そこでこの記事では、SOA のコンテキストでのサービスのバージョン管理について説明します。
SOA では、サービス・コンシューマーとサービス・プロバイダーがやり取りをすることで、何らかのビジネス・タスクを遂行します。そのため SOA での変更はサービスに影響します。また、多くのサービス・コンシューマーが (理想的な SOA では特に) 1 つのサービス・プロバイダーを利用していますが、サービスのバージョン管理に関する考え方や想定は、サービス・コンシューマーとサービス・プロバイダーでは異なると考えるのが妥当です。例えば、サービス・プロバイダーは通常、変更を最小限にとどめようとします。もちろんサービス・コンシューマーからの変更要求やサービス・プロバイダー内部からの変更要求には、妥当な速さで対応します。その一方、サービス・コンシューマーが通常望んでいるのは、何も変更がないことや、変更があっても自分とは関係がないこと、そしておそらくは変更の頻度が非常に低いことです。
このように、SOA での変更に対する考え方の違いによって、サービスをバージョン管理する上で以下の課題が生じます。
- サービス・プロバイダーからの変更の提供を容易にする
- 変更によるサービス・コンシューマーの混乱を最小限に抑える
では、こうした課題を分析するための概念を導入するモデルと、そうした課題に対処するための手法を見て行きましょう。
サービス仕様
サービス・プロバイダーとサービス・コンシューマーの双方との間には、ビジネスおよび技術上の関係があるため、サービス仕様はサービスのバージョン管理モデルの要となります (図 1)。サービス仕様とは、サービスによって実現される、外部から見た機能的及び非機能的特性を簡潔にまとめたもので、サービス・コンシューマーとサービス・プロバイダーとの間での関心の分離を保つために外部特性のみを定義しています。
図 1. サービス仕様
ビジネスのレベルでは、サービス・コンシューマーとサービス・プロバイダーは、サービスでの対話動作によってどのような機能的振る舞いが実現されるかを、このサービス仕様を通じて理解します。技術のレベルでは、サービス・コンシューマーとサービス・プロバイダーは、サービス・コンシューマーのインスタンスとサービス・プロバイダーのインスタンスとの対話動作を、このサービス仕様を通じて理解します。つまりサービス仕様は、サービスでの対話動作における「何を (what)」と「どのように (how)」を記述します。
図 1 は、サービス仕様がモデルの中でバージョン管理されるエンティティーであることを示しており、従ってサービス仕様は ID を持ちます (図の中では省略形で「Nx.y」と表現されています)。ID は、あるドメインの中にある 1 つのサービス仕様に対して一意に決められ、{名前、バージョン} という形式のタプルになっています。この名前は、その名前に対応するサービスを外部から見た大雑把な機能的及び非機能的特性を表現し、さまざまなサービスを区別するものですが、同じサービスの異なるバージョンは区別しません (例えば {“CreditScore”, ?} と {“Customer”, ?} など)。バージョンは同じサービスの異なるバージョンを区別するものです (例えば {“CreditScore, 1.2} と {“CreditScore”, 1.3} など)。
サービス仕様のバージョンは論理的に <major.minor> という形式の数字であり、OSGI による後方互換性に基づいています。バージョンは、最初のサービス仕様に対する <1.0> で始まります。後方互換性のある変更の場合は <minor> 番号がインクリメントされます。後方互換性のない変更の場合は <major> 番号がインクリメントされ、<minor> 番号は 0 にリセットされます。
サービス仕様におけるバージョン変更
サービス仕様の変更は、進化型か革新型です。進化型の変更では、それまでのサービス仕様を明らかに継承していますが、革新型の変更では継承していません。進化型の変更では、ビジネスの価値は (進化してはいるものの) 基本的に変更前と同じであるため、新しいバージョンのサービスということになります。つまりサービスの捉え方として、そのサービスのライフタイム全体にわたって進化してきたサービス仕様の連続体と見なすことができます (図 2)。
図 2. 進化型の変更
革新型の変更では、変更の結果として新しいサービスが作成されます (図 3)。サービス・プロバイダーは、その変更が進化型なのか革新型なのかを、サービス・コンシューマーへの影響とサービス・プロバイダーが最終的に受ける影響とを考慮して決定する必要があります。「古い」サービスのライフタイムを継続するか終了するかは、そのエンタープライズにおける必要性に依存します。この記事では、バージョンが新しくなる進化型の変更について説明します。
図 3. 革新型の変更
サービス仕様の詳細
図 4 は、より詳細にサービス仕様を表現しています。
図 4. サービス仕様の詳細
サービス仕様は次の 4 つの主要部分から構成されています。
- BS (Behavior specification: 動作仕様) は、そのサービス (特にそのサービスのオペレーション) のビジネス上の意味合いを、そのサービスのオペレーションで要求され、生成されるビジネス・データの観点から記述します。
- IfS (Interface specification: インターフェース仕様) はサービスのオペレーションに関するビジネスの構文を、そのオペレーションで使用される抽象データ型の観点に厳密に絞って記述します。
- IaS (Interaction specification: 対話動作仕様) は、サービス・コンシューマーがサービスと対話動作する際に満足する必要のある、ビジネス以外の、あるいはインフラに関する、ポリシーやプロトコル、メカニズム、制約を記述します。
- OS (Operation specification: オペレーション仕様) は、サービスが明示する必要があってもサービス・コンシューマーがサービスと対話動作する上では必要のない、ビジネス機能以外の特徴 (パフォーマンスや容量など) を記述します。
IaS と OS はオペレーションのサービス品質を定義するものと考えることができます。
サービス仕様は一体のものとして扱われ、個々の部分自体はバージョン管理の対象となるエンティティーではありません。また、サービス仕様に含まれない特性を元に変更を行うことはできません。
サービス記述
サービス仕様では、サービスの対話動作における「何を」と「どのように」を定義することはできますが、実際にサービスの対話動作を実現するためにはサービス仕様単独では十分ではありません。特に、サービス・プロバイダーの特定のインスタンスの場所を示す情報がありません。サービス記述 (Service description) と呼ばれるエンティティー (図 5) は、あるバージョンのサービスのインスタンスとの対話動作に必要なすべての情報を含んでいます。サービス記述は、外部から見た関係する機能的及び非機能的特性 (「何を」と「どのように」) を定義するサービス仕様と、サービス・インスタンスのアドレス (Service instance address) (「どこで」) と (を含むか参照すること) で構成されます。
図 5. サービス記述
サービス記述そのものは、サービス仕様と同じ形式の一意に決まる ID を持ちます。実際、サービス記述の ID はサービス仕様の ID を反映していますが、バージョンにはサービス仕様のバージョンに加えて <micro> が追加され、「メンテナンス変更」に対応できるようになっています。<micro> がインクリメントされるのは、ある特定のバージョンのサービス仕様に関して、外からは見えない動作に影響する内部的な変更が行われた場合です。そうした例としては、さまざまな構成ファイルや構成ルール、さらにはサービス・インスタンスの実装や構成に対するバグ修正まで含まれます。サービス記述には、同じサービス仕様を実現するためのサービス・インスタンス同士を区別する、さまざまな形式のタグを含めることができます。
サービス記述は通常、サービス・レジストリーに (メタデータとして) 公開されます。一般的には、関連するサービス仕様も (メタデータとして) 公開されます。
サービス・バージョン
前のセクションでは、多くのサービス・インスタンスが同じバージョンのサービス仕様を実装する場合があることを説明しましたが、この場合、バージョン管理モデルの中にはサービス・バージョン (Service version) という別のエンティティーが必要になります (図 6)。
図 6. サービス・バージョン
サービス・バージョンは、あるサービスの同じバージョンのサービス仕様を実装する、すべてのサービス・インスタンスを集約します。サービス・バージョンは、1 つのバージョンのサービス仕様と 1 つ以上のサービス記述 (を含むか参照すること) で構成されます。
サービス・バージョン自体はサービス仕様の ID と同じ、一意に決まる ID を持ちます。しかしサービス・バージョン自体はモデルの中でバージョン管理されるエンティティーではなく、ある特定のサービス・バージョンのすべてのインスタンスを表現するにすぎません。
サービス・バージョンも他のエンティティーと同様、通常はサービス・レジストリーの中に (メタデータとして) 公開されます。
サービス
バージョン管理モデルの中の最後のエンティティーがサービスです (図 7)。先ほどのセクションで、サービスがサービス仕様とそうしたサービス仕様の実装の連続体と見なせることを説明しました。
図 7. サービス
サービスは、そのサービスが作成された時から最新バージョンまで、すべてのサービス・バージョンを集約し、その結果としてサービス・バージョンの連続体が作成されます。またサービスは間接的に、あるサービス仕様のすべてのバージョンを実装する、すべてのサービス・インスタンスも集約します。サービスは、1 つ以上のサービス・バージョン (を含むか参照すること) で構成され、それぞれに対応するサービス仕様とサービス記述が特定されます。
サービスは ID を持ちますが、その ID はサービス仕様の場合と同様、単にサービスの名前にすぎません。サービス自体はモデルの中でバージョン管理されるエンティティーではありません。
他のエンティティーと同様、サービスも通常はサービス・レジストリーの中に (メタデータとして) 公開されます。
図 8 はこのモデルの要約を示しています。
図 8. このモデルの要約
サービスはいくつかのサービス・バージョンで構成されます。各サービス・バージョンは、外部から見たそのサービス・バージョンの機能的及び非機能的特性をサービス仕様の中で定義しています。どのサービス仕様も、そうしたサービス仕様を具体的に表す多くのサービス・インスタンスを持つことができます。各サービス・インスタンスはサービス記述によって定義され、それぞれのサービス記述は対応するサービス・バージョンによって識別されます。
まとめ
この記事で紹介したモデルによって、SOA における変更がサービスをとおして実際にどのように表されるのか、その変更の表記方法、変更の分類方法、変更の表現方法を判断することができ、従って変更の影響を理解することができます。このモデルはサービス・レジストリーの中に表現されるため、ガバナンス・プロセスを実行することによって変更の管理や関係者への変更の通知、さらには ESB の中でのメディエーション実行まで行うことができ、変更の影響を最小限にとどめるのに役立ちます。
参考文献
著者について  | 
| | Greg Flurry は、IBM SOA Advanced Technology グループのシニア・テクニカル・スタッフです。その任務には、顧客との連携によるサービス指向ソリューションの構築、そして IBM サービス指向製品の拡張が含まれます。 |
記事の評価
| 
