EIP / Conclusion

EIP

Conclusion †

同じパターンについて異なる実装をしても、相互運用が可能だと言ってデザインパターンを拡張するのが標準的な考え方だ（？）。Ｗｅｂサービスの標準を通じてメッセージングパターンを拡張しようとする試みは数多く行われている。これらの標準の多くは、ビジネスプロセスコンポーネントと呼ばれるワークフローコンポーネントの組み立てと振る舞いに焦点を合わせている。BPEL、WSCI、WS-*仕様といった標準は、本書に書かれているような多くの問題に取り組んでいて、それぞれのパターン言語でいくつかのパターンを実装している。

それでも、次々に現れる標準の話は、しばし衝突し、混乱を招くことがある。重要な場所（？）で使う準備がすべて整っているわけではないのだろう。パターンを適用するときには、アプリケーション開発者は標準のせいで身動きがとれなくなってしまってはいけない。目の前の個別のユースケースに集中し続けなければならないのだ。特定の標準が、ある問題にどのようにアプローチしているかに目を向け、意義があると思ったり、実装に役立つと思ったら、そのパターンの戦略的、イデオム的実装を採用しよう。そのアプローチがいくつかのベンダーの製品で標準化されているかどうかということは気にする必要がない。開発者も標準化組織にフィードバックをもたらすことができる。それは、課題であることも、批判であることも、あるいは、その標準が極めて有用で、アカデミックであったりベンダー固有のものではないという保証であることもある。標準が成熟するにつれて、アーキテクトはその利用がエンタープライズインテグレーションソリューションに拡張するにあたって、より広範に、リスクを少なく、コストも低く、より洗練された形で行えると考えるようになるのだ。