サービス管理者

http://martinfowler.com/bliki/ServiceCustodian.html

SOAの幸せでできた、素敵な世界を想像してみましょう。その世界では、お互いに効果的なコラボレーションを可能にするサービスを提供するたくさんの小さなアプリケーションに、企業のコンピュータ計算のニーズが分割されています。ある晴れた朝に、コンシューマーサービスは、サプライヤーサービスからのいくつかの情報を必要とします。予想外の事態は、サプライヤーサービスがこの情報を得るために必要なデータと処理するロジックを持つけれど、それはまだサービスインターフェイスを通してその情報を明かしていないということです。サプライヤーは、将来性のあるサービスを持っていますが、それは実際にはまだそこにありません。

理想の世界では、コンシューマーサービスの開発者はただ、サプライヤーサービスに将来性のあるサービスを開発するように頼みます。そして、そのすべては飛びっきり素晴らしいものです。しかし、人生は理想どおりにはいきません。ここで立ち止まらせる点は、サプライヤーサービスの開発者には他にやることがあるということです。それは普通、コンシューマーサービスチームを助け出すことよりも、彼らの顧客やマネジメントにとって重要なことです。

最近私は、同僚のエリック=ドーネンバーグと話をしていて、この問題を扱うためにクライアントが使うのを見た手法について、私に教えてくれました。彼らは、オープンソース戦略計画書からの1枚を手に取り、彼らの全てのサービスを内部のオープンソースシステムに作り変えました。これで、コンシューマーサービス開発者自身が、サービスを書くことを可能にしたのです。

これを読んでいる多くの方は、このことがもたらす混沌とした未来像に呆れた目で見ていることは確かだと思っていますが、それと同時に、オープンソースプロジェクトは、誰にでも編集することが許されるわけではありません。このクライアントは、オープンソーススタイルの制御機構を使います。具体的に言うと、それぞれのサービスは、2人の管理者がいます。彼らの責任は、サービスを正常に保つことです。通常の物事の道理では、コンシューマー開発者は、実際にはサプライヤーのソースツリーを直接変えるようなことをしません。その代わり、彼らはパッチをカストーディアンに送ります。ちょうどオープンソース保守者にように、カストーディアンは、パッチを受け取って、それがコミットして良いものなのかどうかレビューします。もしそうでなければ、コンシューマー開発者との会話がなされます。

エリックが彼のオープンソースの仕事から良く知っているように、パッチのレビューというのは、自分自身で変更を行うよりも、ちっとも努力が要らないです。カストーディアンの手法は、サプライヤー開発者の作業を待つことを必要とするコンシューマー開発者の問題を全体的には消し去りませんが、この困難を削減することが色々と行えます。再びオープンソースモデルに従うと、カストーディアンが落ち着いたころには、コンシューマー開発者がコミッターになる可能性があります。 これは、コミットはカストーディアンによってレビューされうることをまだ意味していますが、カストーディアンがボトルネックになることは回避されます。

これに関連したことといえば、サービスレジストリに対するこれらの手法です。私たちは、サービスレジストリの可能性を提供するために販売されているたくさんの面白い製品を見てきました。それは、人々がサービスを検索できて、それをどのように使ったらよいか分かるようなものです。このクライアントは、それらを放棄して、その代わりに、HumaneRegistryを使ったのです。