サービスカストディアン

効率的なコラボレーションを可能にするために、多数の小型アプリケーションに分散された企業のコンピューティングニーズが他のアプリケーションにサービスを提供する、SOA の幸せな夢の世界を想像してみましょう。ある日、コンシューマーサービスがサプライヤーサービスにある情報を必要としました。奇妙なことに、サプライヤーサービスにはこの情報を取得するための必要なデータと処理ロジックがあっても、まだサービスインターフェイスを介してこの情報を公開していません。サプライヤーにはサービスの可能性はあるのですが、まだ実際には存在していません。

理想的な世界では、コンシューマーサービスの開発者はサプライヤーサービスに、可能性のあるサービスの開発を依頼するだけでうまくいきます。しかし、人生は理想にはほど遠く、ここでの問題点は、サプライヤーサービスの開発者にはやらなければならないことが他にもあることで、通常はコンシューマーサービスチームのサポートよりも、顧客や経営にとってより重要なことです。

最近、同僚のエリック・デルネンバーグと話したところ、彼はこの問題に対処するためにクライアントが使用したアプローチについて話してくれました。オープンソースのプレイブックからヒントを得て、すべてのサービスを内部オープンソースシステムにしました。これにより、コンシューマーサービスの開発者は自分でサービスを書くことができます。

このことがもたらす混乱の想像について多くの読者が呆れていると確信していますが、オープンソースプロジェクトでは誰でも何でも編集できるわけではありません。このクライアントはオープンソーススタイルの制御メカニズムを使用しています。特に、各サービスには管理者が 2 人います。サービスを健全に保つ責任を負う担当者です。通常の場合、コンシューマーの開発者は実際にサプライヤーのソースツリーに変更を直接コミットすることはなく、代わりにパッチを管理者に送信します。オープンソースのメンテナーと同様に、管理者はパッチを受け取って、コミットするのに十分かどうかを確認します。そうではない場合は、コンシューマー開発者との対話が発生します。

エリックは自身のオープンソース作業からよくわかっているように、パッチの確認は自分で変更を加えるよりもはるかに労力がかかりません。したがって、管理者のアプローチでは、コンシューマー開発者はサプライヤー開発者に頼る必要があるという問題が完全に解消されるわけではありませんが、困難さは大幅に軽減されます。そして、オープンソースのモデルと同様に、管理者が満足したら、コンシューマー開発者はコミッターになることができます。つまり、コミットは依然として管理者によって確認されますが、管理者がボトルネックになることはなくなります。

これと関連して、サービスレジストリに対する彼らアプローチがあります。人々がサービスを検索し、それらを使用する方法を確認できるように、サービスレジストリ機能を提供するために多数の優れた製品が販売されているのを目にしました。このクライアントはそれらを使用せず、代わりにHumaneRegistryを使用しました。

2012 年 5 月 24 日に再掲載