"YUKATA"から始まるコミュニケーション（Agile2008 ライトニングトークより）
私は「浴衣」を着てパーティーに参加したことで、たくさん声を掛けていただけました。 そこで感じたことは、このカンファレンスが人との繋がりを生み出し、また言葉の壁を越えて積極的に交流する場所であることです。民族衣装はそれらを助けてくれるものでした。きっとこの交流が、新たなムーブメントをアジア圏の仲間たちにも与えてくれると確信しています。
News
消費者とサービス提供者を直接やりとりさせてはいけない
作者 Mark Little, 翻訳者 編集部 投稿日 2008年3月11日 午後12時34分
過去数年間に指摘した(source)人が何人か(参考記事・英語)いるが、誰かがWebサービスを開発しているからといって、その人がSOAの原則に従っているとは限らない(参考記事・英語)。同じことがRESTにも当てはまる。HTTPとHTMLを使っているからといって、RESTの仲間入りをしたとは限らず、RESTの仲間入りをしたからといってHTTPとHTMLを使っているとも限らない(source)。しかしながら、Ron Schmelzer氏は最近の記事(source)の中で、以下を理由に「統合中心の技術者」に堂々と非難を向けている。SOAはかく機能すべき、という自身の誤解と誤認がおそらく原因となって、SOA成功の足を引っ張っていること。彼の視点では、問題はつまるところ、コミュニケーションと、開発者が従来の統合プロジェクトに従事する典型的なやり方に帰着する。それは次のようなやり方である。
...1つのシステムからデータやアプリケーション機能性をどのように手に入れようか、どうやって別のシステムに入れようか、1つの場所から別の場所へその情報や機能性を移動するために使うメカニズム、そしてその後は、あるフォーマットやプロトコル、コンテキスト、プロセス、ポリシーから別のフォーマットやプロトコル、コンテキスト、プロセス、ポリシーに変換途上にある間、それをどう扱うかについて、開発者は考えをめぐらせるのです。
そのため、Ron Schmelzer氏によれば、統合中心の開発者がサービスベースの環境内で探している（期待している）のは、データ転送と変換の方法であり、多数のベンダーが喜んで既存の統合ソリューションで手助けしてくれるが、そのソリューションはRPCよりもSOA的でないこと(source)を意味する。これがなぜ悪いアプローチかというと、その理由は多数あるが、コミュニケーションの側面が重大と彼は主張する。
こうなるともちろん、状況に変化があっても、ほかのどこかで何かを破壊しないことを保証しなければならないという、いつもの難題が持ち上がる。複雑な大規模システムでは、変化する可能性のある変数の数（ロケーションとサービス可用性、サービス実装とコントラクトのバージョニング、ビジネスプロセスとポリシーの変更など）が非常に多いので、慎重さを欠いた変化が起これば、どこかで何かが壊れる可能性が高くなる。なぜでしょう？最初に申し上げますが、SOAの主な概念は、継続的な異種環境内で、機能の消費者と機能の提供者を疎結合する構造上のモデル、規範、抽象概念を構築することにより、頻繁かつ予測不可能な変化に対処したいということです。つまり、どのように使われるかを知らずに、どうにかして機能を開発しなければならないことを意味します。
しかし、サービスがただのAPIと考えているなら、サービス提供者を直接サービス消費者と接続しようとすると、大混乱が生じます。提供者が移動したらどうなるのでしょう。サービスコントラクトが変わったらどうなるのでしょう。提供者が利用不可能になったらどうなるのでしょう。今度は新しいコミュニケーションメカニズムが必要となったり、あるいはデータスキーマを変更したりしたらどうなるのでしょう。ソフトウェアに間接指定のレベルをもう1つ追加して変化を隔離するアプローチは、ここでも機能する。サービス消費者とサービス提供者の間に何かしら置くことにより、問題を改善できる。ところが、これを実施する現在のアプローチも間違っているとRon Schmelzer氏は考えており、開発者は解決にあたって技術だけに頼るべきではない。この業界の多数の事柄同様に、派生して起こる影響のすべてを考慮せずに、問題の解決を急ぐのが最悪の行為である。特に今回のケースでは、システムのアーキテクチャがソリューションの鍵であり、必ずしもベンダーの製品ではない。
機能性を消費もしくは構成するサービス消費者を構築したいとしましょう。しかし、その機能性の在りかはもとより、その機能性とのコミュニケーション方法さえ分からないのです。この特定の難題に対処する方法は少なくとも3つあります。まず、あなたがちゃんと理解できる言語で、すでに居場所が判明しているプロキシ（あるいはブローカーか仲介者）と会話が可能であり、消費者の代理を務めるこのプロキシに要求を送ることができます。この方法は明らかに、プロキシに変更はないと仮定している！
サービス消費者はプロキシと最終受信者のみを知っていればよいため、「サービス消費者は変更を知っている必要がある」という問題を、このアプローチは単純化します。技術的見方をすると、WS-Addressingの使用によりこのアプローチは単純化します。本質的には、サービス消費者は提供者のWSアドレスを知っていればよく、そのアドレスをサービスプロキシに渡して、リゾルブとデリバーしてもらいます。残念ながら、SOAに関する限り、WS-Addressingが常にきっちり正常動作するとは限らない(PDF・英語)ことをRon Schmelzer氏は忘れている 。しかしながら...
このアプローチにおける問題は、サービスプロキシがメッセージをデリバーする方法を見つける必要性がまだ残っているということで、プロキシがブラックボックスの中に全ルールをしまいこんでいれば、EAI 2.0様式のESBソリューションと同じ問題を抱えていることになります。ここでレジストリが介入するのです。サービスプロキシは固有のルールを格納すべきではなく、むしろ、レコード中央システムからルーティングやロケーション、ポリシーに基づいた拘束ルールのすべてを入手すべきです。SOAでは、これはレジストリの役割にあたります。さて、レジストリが問題の軽減に役立っても、消費者とプロキシを接続する問題がまだ残っている。何も考えずにプロキシに間接指定のレベルをもう１つ追加するだけでは、問題を別の場所に押しやるだけで、解決になるわけではない。
そして、WS-Addressingもここで役立つ。Ron Schmelzer氏は最後に、このシナリオにおけるESB有用性の疑問に答えている。この難題に対する答えは、レジストリベースの「遅延バインディング」の利用です。今回のシナリオでは、サービス消費者はレジストリにピングして、おそらくはサービス消費者の現在位置と、サービス消費者が通信可能なプロトコルに基づいて、プロキシの在りかを突き止めます。サービス消費者のメタデータをレジストリで見つけたら、サービス消費者をサービス提供者に直接結合できると考えるでしょうが、それは間違いです。サービス提供者が代替プロトコルを使っていたり、サービス消費者からコンタクト不可能な場所に位置していたりすると、通信上の不具合が持ち上がるのが問題なのです。ですから、レジストリでメタデータが見つかる場合でさえ、サービス消費者と提供者間の直接通信はしたくないのです。
ESBは必要でしょうか。必ずしも必要ではありません。とにかく１つを買っておけば、気分的に楽になるでしょうか。おそらくそうでしょう。当然ながら、こうしたプロキシとは何でしょうか。ESBのベンダーとしてもちろん、このコンフィギュレーションではベンダー製品がプロキシとして使用可能ということを、あなたに信じてもらいたいのですし、それはまったくの真実です。確かにプロキシとして使えます。ESBが優良プロキシになれないことが論点ではないのです。もちろん、優良プロキシになり得ますし、その点は特に指摘しておきます。けれども、ESBを使わずとも、あるいは既存のインフラを使うことで切り抜けることが可能で、それでも万事うまくいくのです。原文はこちらです：http://www.infoq.com/news/2008/03/consumer-provider
No comments
返信