Tuscanyとは何か
既にSOAの概念をご存じの方にとっては、「Tuscanyの出現」の「SCAの魅力」で挙げたものがTuscanyであると言った方が分かりやすいかもしれません。また、「SCA誕生」で述べたSCAの根本にある考え方を実装したものがTuscanyであると言えます。
Tuscany誕生
SCA1.0がOASISより公開された2007年に、TuscanyはApacheの中でIncubatorとして扱われていましたが、今では正式なプロジェクトになっています。執筆時点（2009年8月初旬）では2.0 Milestone 3です。当連載ではEclipseを使って説明する予定で、Eclipse3.5（Galileo）のSCA Toolsプロジェクトが1.4をサポートしていることもあり、Tuscany 1.4または1.5を使用します。SOAが非常に簡単だと思えるようになったのはEclipseが強力にSCAをサポートしているためでもあると考えています。優れたツールがない開発ほど疲れるものはありません。2.0がstable版になったときには、何が変わったのか紹介できればと考えています。
Tuscanyを構成するもの
Tuscanyは非常にシンプルな構成になっています。
- コンポーネント
- サービス
- リファレンス
- プロパティ
- コンポジット
- ドメイン
詳しくは仕様書に任せて、とりあえずこの6つさえ押さえておけば設計・開発が可能です。
1）コンポーネント
コンポーネントは乱暴な言い方をすれば実装と言えます。Javaのコードであったり、Rubyのコードであったりします。また、BPELなども言語として位置づけられています。機能を外部に公開していない実装をコンポーネントと言います。
この後紹介する、サービス、リファレンス、プロパティもコンポーネントモデルではコンポーネントの一部とされ区別されていませんが、コンポジットモデルでは区別されます。コンポーネントをより柔軟に組み合わせるには、サービス、リファレンス、プロパティをコンポジットの要素とすることで可能となるからです。
2）サービス
サービスはコンポジットの外部または同じコンポジット内の他のコンポーネントにビジネスロジックを公開するものです。実態はSCA JavaではJavaのインターフェースです。インターフェースにアノテーションを付け加えるだけです。また、サービスはプロトコルとは完全に分離されています。コンポジットの外部にビジネスロジックを公開しているサービスは、プロトコルに何が使われて外部とやり取りしているのかさえ意識する必要がありません。つまり、サービスの実装コードに（つまりコンポーネントに）外部とやりとりするためのコードは一切不要です。
3）リファレンス
上記で説明しましたが、コンポーネントが、他のコンポジットまたは他のコンポーネントのサービスを消費（参照）する場合に使用します。実態は、コンポーネント内の単なる変数です。アノテーションで変数がリファレンスであることをコンテナに伝えると、コンポジットを定義するファイル（コンポジットファイルと呼ばれる）に指定された実装がランタイムに変数に注入されます。
4）プロパティ
プロパティもリファレンス同様、ランタイムに変数に注入される値を指します。
5）コンポジット
コンポジットはまさしく、コンポーネントの合成物です。既に触れたコンポーネント、サービス、リファレンス、プロパティで構成されます。コンポジット自体も他のコンポジットと連携できるため、サービスの粒度を粗くしたいという要求を容易に実現しています。コンポーネントはコンポジットに組み込むだけでなく、取り外すことも可能で、コンポジットの構成を簡単に変更できます。
Eclipse（Galileo）のSCA Toolsを使ったコンポジット図は当連載の後の回で説明するので、ここでは簡単に紹介します。角の丸い大きな四角形の「SampleComposite」と書かれているのがコンポジットです。コンポジットの左側にある、大きな矢印のような形をしたものがサービスです。サービスから線で結ばれた角の丸い四角形がコンポーネントです。コンポーネントの左側にも小さい矢印のような形のものがありますが、これもサービスです。大きな方のサービスが実際にはJavaのインターフェースなどを使って記述された「本物の」サービスです。コンポーネントから右側へ線が延び、サービスとは色が違う大きな矢印がリファレンスです。実際のコンポジット図には赤い楕円形はなく、サービス、コンポーネント、リファレンス、プロパティがどれであるか分かるように筆者が付け加えました。コンポジット図を描くことにより、コンポジットの構成を表す「コンポジットファイル」（XMLファイル）が自動的に作成されるため、視覚的に設計できます。
6）ドメイン
ドメインの概念をつかむのは意外と難しいと思います。コンポジットをまとめる役割をしているようにも思えます。こういう時は素直にSCAの仕様書「SCA Service Component Architecture Assembly Model Specification」から一文紹介するのが1番です。2774行目から原文と私の拙い訳で理解していただければと思います。
原文
An SCA Domain typically represents an area of business functionality controlled by a single organization.
筆者訳
SCAドメインは1つの組織で管理されるビジネス機能の領域を主として表現します。
要は財務部、人事部、購買部など機能的に強い結びつきのある部門内の、関連性の強いビジネスロジックをコンポジットとして定義し、その部門の機能を網羅するようコンポジットをすべて集めたものがドメインである、ということだと思います。1つのマシン内だけでなく、複数のマシンにまたがるコンポジットの集合と考えた方がより理解しやすいかもしれません。
Tuscanyの特徴
Tuscanyの特徴と言っても、新たな発明がどんどん出てきたというわけではありません。技術が「先に存在したものの上にさらに新たなもの・新しい方法を積み上げていくもの」であるとすれば、特徴を挙げただけではその有難みは伝わりづらいかもしれません。しかしあえて特徴を挙げるとすれば、「SCAの魅力」と重複しますが、次のものが挙げられます。
- 言語中立
- プロトコル中立
- サービスのネストが容易
すべて何気ないように書いていますが、その実現の仕方が非常にエレガントであると筆者は感じています。JBIを紹介したのもその比較を交えつつ説明する方が分かりやすいと考えたからです。
言語中立
言語中立と言っても、実際何か細工がいるのではと考えている方も多いと思います。当連載の後の回で詳しく説明しますが、ここでは簡単に説明します。まず他の言語で実装します。次にその実装に対応するJavaのインターフェースを定義します。その後、そのインターフェースを実装したクラスに、フィールド変数として、依存性注入したい実装の変数を定義します。また、その変数のsetterメソッドを作成し、このメソッドに@Referenceアノテーションを付けることでコンテナは依存性注入を行い、他の言語の実装が実行されます。このような方法で言語中立が実現しています。執筆時点で使える言語は限られていますが、皆さんが使用される時には、サポートされている言語を確認してください。
プロトコル中立
JBIのプロトコル中立ではJBIのプレイヤーとしてSE、BC、NMRを挙げ、メッセージをどのように交換しているかを説明しました。では、SCAもプレイヤーを挙げてよ、と思った方も多いかもしれません。JBIでプレイヤーを紹介したのは、そのプレイヤーの実装内部にJBIがプロトコル中立を実現させるためのコードを書く必要があったからです。SCAはプロトコルに関連するコードをコンポーネントに加える必要がありません。つまり、ビジネスロジックとプロトコルが完全に分離されているのです。このような意味でJBIとSCAのプロトコル中立の意味が違うということを言ってきたわけです。SCAのこのようなプロトコル中立のおかげで、サービスに複数のプロトコルを簡単に結びつけることができるようになりました。非常にシンプルかつ強力な仕組みが提供されています。
言語中立とは言いましたが、SCA準拠のTuscanyでサービスを記述するのは、今のところJavaのインターフェースを利用するのが楽です。このインターフェースには一切、プロトコルに関連するコードを加える必要がないということです。上述のとおり、サービスはコンポジットファイルの中でプロトコルと結び付けられます。コンポジットファイルはXMLファイルであり、service要素の子要素としてbinding要素があり、この設定によりサービスが使用するプロトコルがランタイムに決定するのです。
サービスのネストが容易
サービスの粒度をいかにそろえるかということが非常に神経質に語られた時期があります。コンポジットの説明でも触れましたが、コンポジットは誤解を恐れずに言うとコンポーネントの集まりであり、コンポジットはコンポーネントであるとも言えます。コンポーネントのうち他のコンポジットやコンポーネントにビジネスロジックを公開するものがサービスです。コンポジットは必ず1つ以上のサービスを公開しており、コンポジットはリファレンスを通して、他のコンポジットを参照できます。コンポジットもサービスであることから、コンポジットをネストすることにより、サービスの粒度を粗くすることは簡単に行えるのです。確かに、サービスやコンポジットの作成ルールを決めるのは非常に大切なことなので、SOAガバナンスを否定するつもりは毛頭ありません。ここではサービスの粒度に過敏になりすぎるとシステムの構築は前に進みにくくなるということを指摘したいだけです。
コンポーネントやコンポジットを眺めるとそれはあたかもフラクタルのようです。コンポーネントだと思ってよく眺めていると、それはコンポジットであったりというように。この仕組みこそ、サービスの粒度を過度に意識することなく設計・開発できる可能性を与えてくれたと言えるでしょう。
次回は、Tuscanyの環境設定について説明します。
