The Death Of SOA(参考記事)およびThe Wake For SOA(リンク)の余波で、SOAを存続させるのは何かに関する議論が続いている。Phillip Calcado氏は、極めて基本的な質問をしている。サービスとは何か?
SOAおよびサービスの定義はたくさんあり、このトピックでこれまで読んだ中で、完全に同意したものは何もなかったと思う。SOAができる前の時代、分散コンポーネントの複数のフレーバーに取り組んできた。SOAを定義するために人びとが使っているものと、Component-Based Designですでに利用可能になっているリソースとの間に大きな違いを見出すことができない。
Phillip氏の考えでは、SOAは「ア－キテクチャでのノイズを低減」し、「ビジネスの一部」であるコンポーネントを使用している。それにより、 SOAがDomain-Driven Architectureだと氏は考える。これに関して氏の考えを強固にするのに役立つ、これまで関与したビジネス上の取り組みについてPhillip氏は説明している。これには、現在配置されているものが他のビジネスアプリケーションの陰になっており、他のアプリケーションに対して第一級オブジェクトと して公開されていないため、新たな請求システムを購入する必要があったと考えているクライアントが関わった。
この場合、アーキテクチャがビジネスを熟考しなかった。値が張る製品のベンダーであるなら、何をどのように公開するかに関する制約が確かにある。そうではあるが、問題の技術的な側面のみに集中すると、ビジネスピープルに戦略を考える際に請求機能を使える何かとして考えさせる場合、それを第一級オブジェクト をするべきである。
その議論で、氏は以下のように主張している。
SOAの背後にあるテクノロジーは、良き古いComponent-Based Designで使われたテクノロジーとほとんど同じである。Servicesを使用して、こんにちわれわれがおこなうことの多くは、コンポーネントテクノロジーで完了する。主な違いは物の見方であり、しばしばコンポーネントは技術者によって作成され、使用される。サービスは、ユーザベースが幅広い。
これは、同様の質問をしたときにJack van Hoof氏が言わなければならなかったこと(リンク)と一致する。
ソフトウェアコンポーネントがサービスで、CBD(Component Based Development)はService Oriented Architectureであるのか?まったくそうとは言えない。反対である。すなわち、SOAのServiceは(SOAが現在理解されているように) ソフトウェアコンポーネントであるが、ビジネス機能の制約が厳しいコンポーネントである。SOAは、コンポーネントベースアーキテクチャのインスタンスである。そういうわけで、いつもSOAの構築はCBDとかかわりがある。しかし、CBDは、われわれがSOAを理解しているように、SOAの構築とつねに関 係があるわけではない。
しかし、Phillip氏はさらに一歩先を行き、アーキテクチャはデベロッパや利害関係者(デベロッパは利害関係者ではないのか?)が理解することができる言語である必要があると考えている。
ちょうど設計レベルであるように、システムのアーキテクチャのために、ユビキタス言語を取得するには、多少の作業が必要である。それにもかかわらず、アー キテクチャレベルでDomain-Driven Design原理に基づき作業するのがおそらく簡単だと言っても差し支えない。アーキテクチャのコンポーネント(実体がよりある)はたいていのクラスやオ ブジェクトについてはあてはまらない、ビジネスに直接影響を与えるからである。
ここでDomain Driven Design(リンク)が役立つ。「サービスはユーザが理解する概念の実装であるべきだ」。そしてPhillip氏はEメールの例を挙げて、意味することを例証する が、その中心となる概念はアプリケーションのサービスは、デベロッパが考えることや、低レベルシステムが提供することよりもむしろ、エンドーユーザが期待 することと一致する必要があるということである。
重要なのは、サービスを定義することである。サービスは、自分の作業についてのユーザの考え方の一部である。サービスの定義時に、APIユーザが使用中の 言語を十分に理解している場合に限り、システムの開通という目標を達成することができる。たとえ、サービスについての考え方(ユーザインターフェイスがど う見えるかによって)とそれの実装方法間で必要とされる変換の量など、詳細なマニュアルを提供してもである。
OASIS SOA Reference Model(PDF)スタンダードに対するサービスの構成要素についてまとめることにする。そうすることで、Phillip氏やJack氏が述べた内容に大いに同調する。
名詞である「サービス」は辞書では「他の人に対するサービス(機能)のパフォーマンス」であると定義されている。しかしながら、その用語が一般的に理解されているように、以下のような考えも併せ持つ。こうした概念は、ある機能とその機能を実現する能力の間の違いを強調する。必要性も機能もどちらもSOAとは無関係に存在するが、SOAではサービスはメカニズムであり、それによって必要性や機能が一緒になる。
- 他のものに対し、作業を実行する能力
- 他のものに対し、提供される作業の詳説
- 他のものに対し、作業を実行するという提案
Phillip氏の投稿記事のコメントのセクションには、氏が説明していることは正しいかどうかについて、意見の相違が見られる。そのうちの1つは、以下のとおりである。
ここで説明していることがSOAの正しい定義であるとは思わない。なぜなら誰もが独自の真理を持っており、1つの正しい真理などないからである。しかし、この投稿記事には、これまで見てきた中でもSOAのもっとも役立つ定義の1つがある。
他はそうかどうかはよく分からない。
SOAに関する考えはいたるところにあるが、個人的にビジネスにフォーカスしたSOA(おそらくSteve Jones氏のスタイル)について話したり、ドメインモデルについて深く掘り下げたい。そうする中で、直接的にDDDから考えを引き出し(UL)、他の考 えを使ってわれわれのサービス(コンテキストマップ/バウンドコンテキスト)を形成/記述するかもしれない。しかし、近いうちにSOAに関する同様の本を 誰かが書いてくれることを期待している。
それでもはっきりしていることは、サービスの構成要素が何であるのかが不明である限りは、どうしてSOAが提供されるなど期待することができるか?もしくは、おそらくこれは孤立した症例であり、他の誰もが本当にサービスの構成要素を理解しているのか?