「お互いにサービスを提供し、効果的な協力を可能にする、多くの小さいアプリケーションへと企業のコンピュータニーズが分割されている、SOAの世界を思 い描いてみる。ある晴れた朝、カスタマーサービスがサプライヤーサービスからの情報を必要としている」。Martin Fowler氏は複数のビジネスユニットのSOAインフラが直面する問題の舞台を設定している。
理想的な世界では、カスタマーサービスのデベロッパは、サプライヤーサービスに見込みのあるサービスを提供するように依頼する。しかし、人生とは理想通りにはいかない。サプライヤーサービスのデベロッパが他にすることがあり、それはたいていカスタマーサービスチームを支援することよりもカスタマーや管理に とってより重要な意味を持つことである。
Martin氏は、同僚のErik Dornenburg氏によって採用された、その問題に対する現実世界でのソリューションの例を示している。
オープンソースのプレイブックからリーフを取り出して、すべてのサービスを内部のオープンソースシステムにした。これによって、カスタマーサービスのデベロッパはサービス自体を記述することができる。
誰でもサービスの拡張が可能で「パッチ」をサブミットすることができることを提示している。パッチはその後Service Custodianによってレビューされ、「採用される」。Service Custodianのロールをオープンソースメンテナーになぞらえて「Custodianでは、アプローチはサプライヤーデベロッパに仕える必要があるカ スタマーデベロッパの問題を完全には取り除かず、その難しさを低減する」。Custodianにとって、サービス拡張を開発するより「パッチ」を適用するほうが容易であり、カスタマーサービスデベロッパがやがてCustodianの信頼を得ると、プロセスは適切に拡大縮小することを提案している。
Service Custodianの責務は、このアプローチが成功するためには不可欠である。Martin氏がほのめかしているソリューションは、Jim Webber氏のGeurilla SOA(SOAへの草の根の取り組み)(参考記事・英語)に例えることができる。SOA InsightsのポッドキャストでTony Baer氏は、そのようなアプローチの潜在的なリスクについて警鐘を鳴らしている(リンク)。
新しい要求に応えるのに十分なくらい、プロジェクトが大きくなったらどうなるか?作業をより迅速に終わらせるので、ゼロから新しいサービスを作成する。それはまさにスパゲッティコードが作成される状況である- 作成がさらに迅速化する一方で、そんな無価値なものを維持したくはない。
サービスの再利用は、それぞれの機能チームによって制度化され、統治されるべきか?または企業内での草の根のオープンソース運動であり、機能チームの Service Custodian(リンク)によって管理されるべきか?Martin Fowlers氏によるオリジナルの記事(リンク)を忘れずにチェックし、自分の経験を皆で共有したい。
原文はこちらです：http://www.infoq.com/news/2008/11/service-custodian