SOAへの移行により、ソフトウェア開発のライフサイクルには新たな課題が山積されます。組織がこうした課題に対応するためにサービス指向開発能力を増強した場合に限って、対処が可能です。
この論文では、組織のサービス開発能力改善を目指した実用的な提案をします。SOAがソフトウェア開発のライフサイクルにもたらす課題をまとめた後に、消費者主導契約がどのようにしてサービス指向開発のライフサイクルを強化できるかを説明しますが、消費者主導契約は「サービスのためのストーリ」と、サービスの開発ストリーム間で交換する単体テストという形式をとります。
SOAの開発諸問題
サービス指向化では、新しいアーキテクチャの単なる導入ではまったく不十分です。組織はアーキテクチャのさらなるサービス指向化を図ろうとアーキテクチャを修正しても、それに釣り合うように開発テクニックを変えないので、SOAイニシアチブが完全な失敗となるのです。
サービスの創設、構築、運用にまつわる問題には以下のようなものがあります。:
- 創設段階中、サービス機能性は複数のコンテキストでの再利用を受けつけるように、仕様を定めねばなりません。特定の1コンテキストのみで再利用できるだけの粗さの粒度でも、かなりの追加労力をかけなければ複数のコンテキストで再利用できないほどの粒度でもいけません。
- サービス構築時には、提供者と消費者が必ずお互い独立して進化できるようにしなくてはなりません。1つのサービス機能性に対して全関係者が同時に変化しなくてはならないなら、サービスは真に疎結合とは言えません。
- サービス運用時には、サービス間の関係を把握する必要があります。目的は、問題を診断し、サービス可用性における変化の影響を、たいていは多少の距離をおいたところから査定し、新規の、もしくは変更が加えられたビジネス要件に応じて、進化する個々のサービスを計画することです。
全資産的な観点からすれば、各サービス特有の開発ライフサイクルは同位サービスのライフサイクルと一致させなくてはなりませんが、全関係者を、完全統制の、まるで氷河の進行のように遅い、つまるところ実行不可能なタイムラインに理不尽にも縛りつけるようなことはあってはなりません。
SOAがソフトウェア開発ライフサイクルにもたらす難題は、サービス資産のサービスが互いに連携しているという特質から生じます。貴重なビジネス利益を実現するのはもはや、単一トラックのタイムラインを持ち、所有権や予算、運用の境界がばらばらの隔離されたアプリケーションではありません。むしろ、サービス間の相互作用によって実現されるのであり、各サービスにはかなり明確なサービス開発ライフサイクルがあります。ところが、この複数のライフサイクルを、ちょっとした手間で一致させられるものではありません。それどころか、これからご覧いただくように、共有の成果をもたらすコミットメントを示す協同アクティビティやアーチファクト一式を識別しなければならなくなります。こうしたアクティビティやアーチファクトは -- ほんの短い時間であっても -- ストリームを同調させるための基礎を時々提供しているのです。
アジャイルな方法を使えば、頻繁なリリースを通じて価値の高いビジネス利益を早期かつ頻繁にもたらすことができますが、組織がこのアジャイルな方法でSOAを実装しようとすれば、開発問題はなおさら緊急性を増します。アジャイルなソフトウェアデリバリは、その名称にもかかわらず、SOAに関連した組織的なアジリティの利益に対して有害であると考える人が大勢います。頻繁なリリースというアジャイルの慣行は見送られることが多く、その理由は、サービス間に多数の結びつきが存在する環境にサービスの新バージョンを配置することには、運用上のリスクが伴うからです。また、アジャイルではひとつのビジネス利益の実現に関与する全関係者に、緊密かつタイムリーな協力を奨励しますが、サービスが複数あり、ライフサイクルも異なれば、こうした協力の調整が難しくなることもあります。
連携したエクスペクテーション(期待)
伝統的なストーブパイプ開発(訳注:将来の接続性や他のシステムとの統合を考慮せずに、当面の問題を解決するためにシステムを設計・作成すること)では、ビジネス所有権や予算、営業の境界までを、同位デリバリストリームの範囲内とします。サービス指向開発が伝統的なストーブパイプ開発と異なる点は、外部の依存性と責務を強調し、開発ライフサイクルの各段階に組み入れることです。これはSOAガバナンスの領域になります。つまり、デリバリの相互関係を管理し、サービス資産や、その資産によってサポートされているビジネス活動、プロセス、成果が共通して対応しているものを中心に、ストリームを調整することです。SOAガバナンスは洞察とフィードバックに依存しています。サービスインベントリの現状に対する洞察と、進化するサービス提供者ならびに消費者の影響に関するフィードバックです。連携したエクスペクテーションと責務をアーチファクトとして把握することにより、洞察を高め、フィードバックを増大させることができます。こうしたアーチファクトは、特定のサービス開発ストリーム内の段階を越えて移行可能であり、また、異なる開発ストリームとの間で交換もできます。
エクスペクテーションと責務を把握し、交換する実用的な方法として、consumer-driven contracts(消費者主導契約)(リンク)と呼ばれるものの利用が挙げられます。消費者主導契約は、提供者契約、消費者契約、消費者主導契約それ自体で形成される、緊密に結びついたサービス契約トリオの一部を成すものであり、エクスペクテーションと責務という観点からサービス提供者と消費者間の関係を記述します。:
- 提供者契約 - 提供者契約は私たちが最も馴染みのある種類のサービス契約です。WSDLやXMLスキーマ、WS-ポリシーを考えてみてください。提供者契約はその名が暗示するように、提供者中心になっています。提供者は、提供できるものについて指令を発し、各消費者は、この「ひとつですべてに対応する」提供物に自分自身をバインドします。消費者は提供者契約を採用することにより、自分自身を提供者の機能性に連結しますが、消費者がこの機能性を実際に必要としている程度とは無関係に、機能性全体との連結になります。
- 消費者契約 - 消費者契約は提供者契約とは反対に、個々の消費者の必要性をより正確に記述したものです。消費者契約は、特定の相互作用という環境においてその消費者が必要とする、提供者機能性の特定の要素を表します。消費者契約は既存の提供者契約に注釈をつけるために使ったり、まだ明示されていない提供者契約を捜し出す手助けとして使ったりできます。
- 消費者主導契約 - 消費者主導契約は、サービス提供者の現在の全消費者に対する責務を表したものです。各消費者が提供者に固有のエクスペクテーションを伝えると、消費者主導契約が作成されます。供給者側に生まれた責務により消費者主導契約が確立します。提供者は既存の責務を全うし続けている限り、消費者主導契約の採用の一環として、自由にサービス提供物を発展、刷新させられます。
サービス指向開発のライフサイクル
消費者主導契約はどのようにして、サービス指向開発のライフサイクルに再配置されるのでしょうか。消費者主導契約はどのようにして、連携したサービス資産がもたらす難題の処理に役立つのでしょうか。
創始
サービス開発の第1段階では、消費者主導契約はサービスのユーザストーリに酷似しています。サービスが有用になるのは、サービスが消費される場合に限るため、有用性を明示する最良の方法は、消費者がそのサービスに何を期待するかを説明することです。ユーザストーリは、役割や特徴、利益の観点から優先度の高いビジネス成果を説明することにより、サービス機能性の重要要素のデリバリ計画に役立ちます(Dan NorthによるWhat‘s in a story〔ストーリの中身〕(リンク)とMike CohnによるUser Stories Applied〔ユーザストーリの適用〕(リンク)をご覧ください)。ユーザストーリとして実装された消費者主導契約は、サービス消費者の役割、消費者が実現を求めている成果もしくは利益、その成果を達成するためにサービス提供者に求められる機能や行動を説明します。
ビジネス的に有意義なサービス行動を明示するこのアプローチは、明らかにアウトサイド・インであり、ビジネスや組織、技術の境界を横断し、他のワークストリームや開発ライフサイクルから依存性、エクスペクテーション、責務をとらえています。実際面ではビヘイビア駆動開発(BDD)(リンク) に類似しており、ビヘイビア駆動開発の場合も、ビジネスの目標、その目標に付随する利益、目標をかなえるために異なるアクターによる提示が必要なアクティビティとビヘイビアのアウトサイド・イン的な見方を重要視します。全体的なビジネス成果に寄与するビヘイビアと相互作用を識別することにより、消費者主導契約はBDDの類例のように、サービスがビジネスに有意義な価値をもたらすに「ちょうど十分」なほどの機能性を指定します。
外部に存在する相互作用やビヘイビアで重要なことは、ビジネス活動によってはその進行や終了に、こうした相互作用やビヘイビアの発現が必須であるため、ビジネス的に意味のある要素に相当するということです。システムに本来備わっている価値は、ビジネスイベント、文書の交換、関係者間の対話といった、サービス同士が接触する場所で表面化します。消費者主導契約は、1つのビジネスグループ、機能、能力が自らの仕事をするために他者に期待することを捕捉します。こうした契約を総合すると、ビジネス成果に最も寄与する、ビジネス活動に関する高レベルの見方を提供します。
消費者主導契約は、SOAでしばしば尋ねられる難しい問いの1つに答えます。具体的に言うと、「伝統的なストーブパイプ式のやり方を使えば目先のビジネスニーズに応えられるし、おそらく、ストーブパイプ式の方が簡単にできるのに、なぜ、アクティビティやプロセスをサービス可能にするのか」という問いです。ファクタリングがうまくできているサービス資産では、同位サービス間で相互作用することにより、実に興味深く、かつ有用な成果が実現されていますが、このようなサービス資産では、個々のサービスを、個別のビジネス目標や個別のビジネス利益一式に、いつも簡単に結びつけられるというわけではありません。ストーブパイプのアプリケーションは具体的な利益や成果と直接結びつけて考えられることが多いのに対し、多数のサービスは「プロセスのあいまいさ」が原因で、ビジネスにもたらす価値との間に隔たりが生じます。サービスが支援する特定の利益と成果を認識するためには、サービスをその合作的なコンテキストで理解する必要があります。ここで消費者主導契約が役に立ちます。サービス共同体の合作的なエクスペクテーションを象徴する消費者主導契約は、よりアクセスしやすい一対の関係を介して、直接的にはアクセスできない共同体の価値を効率的に調停します。
構築
構築段階中、消費者主導ストーリを実行可能なエクスペクテーションに変えられます。消費者主導ストーリは受容可能な成果を記述しているため、ストーリを承認基準に変換でき、そして最終的にはプログラマチック・アサーションやテストに変換できます。開発プロセスに消費者主導契約を取り入れる最も混乱の少ない方法は、提供者チームが消費者主導ストーリをプログラマチック契約に変換することです。これにより、サービスの開発ライフサイクル段階間のアーチファクトを移行する方法は確かに提供されますが、サービス資産の連携した特質を正当に扱っているかというと、実はそうではありません。はるかに望ましい方法は、消費者アプリケーションやサービスの提供を担当するチームが自ら消費者テストを書き、サービス提供者にそのテストを渡すことです。各消費者はサービス提供者に、消費者契約のテストベース版を渡します。提供者が受け取った契約一式が、その提供者の消費者主導契約を構成することになります。消費者はその結果、提供者が同一のエクスペクテーション一式を対象に開発しているという保証を手に入れながら、自身の契約を展開できます。こうすることで、両者の開発ストリームの中へと契約を焼き固めることができるのです。
サービス資産の適切に連携されている特質を維持するためには、消費者のエクスペクテーションと契約は「消費者の所有物である」ということを認識する必要があります。消費者のエクスペクテーションから消費者の所有権を外してしまうと、SOAの組織的かつ構造的特徴による連携力が減少してしまいます。消費者契約の所有権を消費者開発ストリームに割り当てることにより、提供者の消費者主導契約が、提供者が解釈する消費者のエクスペクテーションではなく、消費者のアーチファクトに直接由来することが確実になります。このようにしてテストを交換すれば、開発プロセスと構築プロセスをリンクでき、提供者?消費者間のドリフトのリスクを低減できます。
時折、異なる消費者が要求する契約同士がコンフリクトを起こします。消費者契約を明示すれば、このようなコンフリクトの早期識別に役立ちます。コンフリクトの重大性が比較的低い場合は、関係各チームとともに、全関係者にとって最良の方法を話し合うことができます -- おそらく、いずれかの消費者に対してルールを緩める方法をとることになるでしょう。コンフリクトが深刻な場合は、設計再考の必要があるという暗示かもしれず、オペレーションやメッセージの抽出を目的に、より焦点を狭めた懸案事項をターゲットにします。ある程度は判断の問題になります。消費者主導契約に従えば、プロセスのあいまいな、再利用可能なビヘイビアの最小セットを作り出せますが、ビジネス的に有意義な成果を確実にもたらすようにし、関心事を効果的に分離させる必要があります。
最も単純な消費者契約は、サービス提供者と消費者間で交換するメッセージのアサーションです。XMLベースのメッセージで消費者が自らのエクスペクテーションを表現するのに利用する言語には、XPathやSchematron(リンク)などがありますが、両言語とも、異種技術の環境下でうまく機能します。消費者はXMLスキーマやRELAX NG(リンク)も使えますが、この2つの妥当性確認はどちらかといえば妥協を許さないため、XMLスキーマやRELAX NGで書かれた消費者契約には、消費者にとって現時点では重要でない提供者契約の要素を説明するための拡張ポイントを提供しなくてはならず、多少、趣旨からそれてしまいます。
消費者契約は、サービスによって露出される種類の提供者契約に直接の影響を与えます。サービスが送受するメッセージの構造をXMLスキーマで記述する場合、発行するスキーマはその消費者のエクスペクテーションを満たさなくてはなりません。新サービスの場合、提供者と消費者両陣営の開発チームが、消費者のアサーションと、そのアサーションをかなえる提供者スキーマを共同設計することになるかもしれません。既存サービスでは、スキーマのコピーにカスタムのアサーションをアノテートすることを消費者が選択するかもしれません。提供者にしてみれば、消費者主導契約により、開発の方向が明確になります。他の単体テスト同様、開発者はテストのエクスペクテーションをかなえるようサービスビヘイビアを作成しながら、開発活動の原動力とする目的で消費者テストを使うことができます。継続的な統合環境にテストを加えることも、各ビルドでのサービス機能性を対象にアサートすることも可能です。消費者が契約を生のXPathやSchematronの表現形式で提供する場合、提供者は、自身が作り出すメッセージに対する基礎テストを、JUnit、NUnit、XMLUnitなどのテスト用フレームワークを使って実行できます。
実世界のメッセージが1人以上の消費者のエクスペクテーションを満たせない場合、早期にフィードバックを提供するために、提供者はランタイムアクティビティに消費者主導契約を組み入れることさえ可能です。すべての消費者契約に対する厳格な適合が絶対不可欠なら、提供者は送信パイプラインで消費者のエクスペクテーションをアサートすることにより、送信メッセージの妥当性確認を行わなければならない可能性もあります。アサートする契約のサイズや数にもよりますが、この妥当性確認によってレイテンシとスループットが影響を受ける可能性があります。これに代わる方法として、提供者はWire Tap(リンク)やその他の追加サブスクリプションを送信メッセージへ実装し、送信パイプライン外で提供者の責務をアサートすることができます。
消費者サイドでは、消費者契約により非常に特殊な開発プラクティスが促進されます。提供者に消費者主導契約(それ以上でもそれ以下でもなく、この契約だけ)を固守する義務があるなら、消費者も消費者側の契約を必ず守らなければなりません。消費者は提供者契約全体をインポートするのではなく、消費者が提供者に必要と伝えたものだけを消費するべきです。そうすれば、消費者には関係のない提供者契約の要素が変更になっても、消費者は自らを保護できます。絶対に必要なものに限った消費は、消費者サイドでスキーマの妥当性確認を行わないことを意味します。その代わりに、渡されたエクスペクテーションを提供者が守り、そのエクスペクテーションに沿って十分正当なメッセージを送っているとみなすのです。消費者サイドのデシリアライゼーション・メカニズムが追加、欠落、アウトオブオーダーの各フィールドを許容できる程度に応じて、受信メッセージを強く型付けされた表現にデシリアライズすることも避けたいと、消費者は希望するかもしれません。代わりに、関心のあるメッセージを部分的にXPath化することを選択するのです。この戦略はしばしばWS-DuckTyping(WS-ダック・タイピング)(リンク)と呼ばれます。
テストに基づいた消費者契約は、ベンダーパッケージやCOTSアプリケーションの評価にも役立ちます。消費者主導のアプローチをとり、参加が予定されるコラボレーションや、システムの他の部分によって寄せられるエクスペクテーションという観点から、パッケージの必要条件を記述します。消費者のエクスペクテーションを目録化することにより、外部に置いたコラボレーション点から見て、パッケージ実装がどのように見えるべきかを明示します。こうしたエクスペクテーションを消費者主導契約として、おそらくは自動化テスト一式というかたちでインスタンス化することにより、そのアプリケーションが資産の「善良な市民」となる可能性が高いかどうかを決定できます。
運用
サービス開発チーム間で交換したテストにより、サービス資産内における重要度の高い外部コラボレーション点が識別されます。こうしたテストやテストが示す相互関係により、サービス運用担当者は、有用かつ実行可能なドキュメンテーションを手に入れます。消費者主導契約はサービス依存者、その依存性の性質を識別し、サービス資産の日々のビヘイビアに対する運用者の見識を高めます。
共有テストとして実装された消費者主導契約一式は、サービス資産内の関係をより透過的にする以外にも、進化するサービスの効果に関して一層のフィードバックを提供します。消費者主導契約は、アサートされたビヘイビアの基礎で構成され、サービス契約への変更の結果起こりうる影響を、このビヘイビアを対象として査定することができます。消費者テストは、サービス開発ストリーム全体におよぶ回帰テスト一式の基礎を形成し、提供者は既存の責務を全うし続ける限り、この回帰テストに従って進化できます。
消費者主導契約がサービス資産に対する変更計画に利用される限りにおいては、デリバリ組織のバージョンニング戦略に寄与します。バージョンニング・サービスでは下位互換性、上位互換性の原則が最優先事項であることに変わりはありませんが、消費者主導契約は、残存責務と関係に基づいて互換性問題をコンテキスト化するのに役立ちます。必須要素の変更を契約破りの変更と常にみなす必要はありません。それよりも、なんらかのバージョニングを必要とする変更が、消費者契約を破る変更と同一視される可能性があります。既存の消費者がメッセージの必須要素を使っていない場合は、その要素の変更や削除を、もはや契約破りの変更とみなす必要はありません。
まとめ
SOA導入により、サービス資産が有する連携した特質の結果、開発ライフサイクルに新たな課題がもたらされます。サービス開発の成否は、複数の開発ストリームを洞察する力とフィードバック収集にかかっています。中には、消費者主導契約を使って取り組める目標もあります。消費者主導契約は、「サービス向けのストーリ」や開発ストリーム間で交換するテストの形で使用し、開発ライフサイクル内のアクティビティをリンクしたり、開発ストリーム間でアクティビティを調整したりします。消費者主導契約はサービス指向システムの開発とテストを支援し、サービスライフサイクルに関与する全関係者間の協力を奨励します。
消費者主導契約に関するさらに詳しい解説は、The ThoughtWorks Anthology(リンク)ならびに著者のブログ(リンク)で探すことができます。
著者について
Ian Robinson氏(リンク)はThoughtWorksの首席コンサルタントを務め、サービス指向システムおよび分散型システムの設計とデリバリを専門にしています。マイクロソフトの技術を使った統合パターンの実装に関して、マイクロソフト社向けに手引き書を作成し、また、ビジネス指向開発の方法論や分散型システム設計に関する論文を発表しています。最近ではThe ThoughtWorks Anthology(リンク)(Pragmatic Programmers、2008年)を出版しています。現在は、Webフレンドリーな企業統合に関する本を共作中です。
原文はこちらです:http://www.infoq.com/articles/consumer-driven-contracts
(このArticleは2008年7月27日に原文が掲載されました)