|
これまでの連載で，SCAが必要とされる背景やその仕様について説明してきました。今回は，SCAの存在によって何が変わるのかについて，もう一度考えてみたいと思います。
もしSCAが無かったら
SCAが仮に存在していないとしても，“絶対にこれができない”ということは無いかもしれません。現在の多くのサービスは，実際にその“無い”状況で動いているとも言えます。ただ，現在のサービスについて「そのサービスをどうやって作ったのか」「どう動いているのか」「再利用はできるのか」といった観点で考えていくと，SCAの価値が浮かび上がってきます。
もし，あるサービスがHTTP/SOAPを使用するWebサービスならば，おそらくそのサービスは最初からHTTP/SOAPを使用するWebサービスとして作成され，また，それを利用するサービスもHTTP/SOAPを意識して作られています。ところが，現実にその作成物を再利用することを考えると，すべての場合にSOAP/HTTPで呼び出すことが適しているわけではありません。別のものと別の方法で組み合わせて使用するという可能性もあります。
つまり，この“何か”を意識して実装されているということが，その後のサービスの再利用のシナリオの中で障害となり得るのです。これは，サービスの本質であるビジネス・ロジックとその提供形態が密に結びついているからです。このような依存性をできるだけ減らしていくことが，サービスの再利用性を高めるための解になります。
それを提供するのがSCAです。SCAは，ビジネス・ロジックとその提供/利用形態を分離します。もしSCAが無ければ，多くのサービスの再利用性は，ある環境に縛られた限定的なものになってしまいます。では，SCAが“ある”とは具体的にはどういうことなのでしょうか？
SCAのある世界「Domain」
“SCAのある世界”というのは抽象的な表現ですが，SCA 1.0では具体的にSCAの影響の及ぶ範囲が定義されています。それは「Domain」と呼ばれています。SCAに基づいて作られた成果物は，このDomainの中に置かれることになります。
Domainの中に置かれるものは，Compositeで表現されたComponent，Service，Reference，Wire（コンポーネント間の参照関係を表現できるCompositeの要素。参照を明示的に表現したい場合に使用）などになります。これらのものを含むSCA成果物は，“Contribution”と呼ばれ，必要なものがパッケージされたZIP形式やJ2EE EARなどが想定されています。Wiring（コンポーネント間に参照関係を持たせること。コンポジット図においてコンポーネント間を結線すること）ができるのも，SCA間のPolicy Frameworkに従って定義される各種の要件の有効範囲も，このDomainの中になります（図1）。
|
|
| 図1●SCAのDomainのイメージ |
このDomainは，一つの筐体に存在するだけでなく，複数のマシン（ノード）にまたがって存在することができると定義されています。例えば，全社の業務が一つのDomainということも仕様的には可能ですし，ある会計業務のような特定の業務が一つのDomainを形成するということもできます。複数のノードの場合は，複数のSCAのRuntimeがネットワーク上で相互接続されていることになります。SCAが提供できる機能とは，Runtimeが相互接続されたDomainがもたらすものです。このDomainの中に，ビジネス・ロジックが再利用しやすい形で存在できるわけです。
広がるSCAの世界
Domainを支えているのがSCAのRuntimeです。SCAのRuntimeは，Componentの定義に基づき，ビジネス・ロジックをインスタンス化して動かします。
Runtimeは，必要に応じて拡張することができます。例えば，Apache TuscanyのJava用のRuntimeでは，すでにJava言語だけではなく，JavaScriptやRubyなどのスクリプト言語をサポートできるように拡張されています。このスクリプト・サポートの拡張に伴ってTuscanyは，Bindingも拡張しており，JSON-RPCやRSS/ATOM Feedもサポートしています。このスクリプトへの拡張は，SCAの今までと違った領域での使われ方を予感させます。
また，Tuscanyには，「Native」と呼ばれるRuntimeもあり，そこでは実装としてC++を中心にRuby，Python，PHPなどが開発されています。ほかの新しい言語のサポートに関しては，まだ仕様の段階で，Runtimeでのサポート形態は不明です。ただし，OSOAからCOBOLのサポートに関してはDraftが公開されました。
もし，COBOLプログラムをSCAで実行できる環境が整えば，その資産の豊富さからSCAのカバーできる領域が大きく広がります。このようにRuntimeが拡張，発展していくことにより，Domainの提供できる“SCAの世界”が徐々に広がりつつあります（図2）。
|
|
| 図2●Runtime機能の拡張 |
連載のおわりに
SCA仕様には，セキュリティなどの非機能要件をサポートするPolicy Frameworkをはじめ，本連載で取り上げていない部分がまだたくさんあります。それらに関しては，ぜひ一度，OSOAサイトの仕様のページをご参照ください。頻繁に更新されていますので，きっと新しい発見があると思います。
仕様書以外のお薦めの資料もいくつかご紹介しておきます。OSOAサイトのリソースのページを見ると，SCA関連の情報がきれいに整理されています。簡単な技術資料からPowerPointのプレゼンテーション・スライドまで，様々なものがリンクされています。
その中でも最近追加された「Introducing SCA（a White Paper by David Chappell）」というDavid Chappell氏のホワイト・ペーパーは読み物としても面白く，内容も非常に参考になります。また，プレゼンテーション・スライドですが，2007年6月に北京と東京で開催されたSCAセミナーの資料「SCA Tutorial Part 1- Given in Beijing & Tokyo」は，仕様の開発者達が話した資料だけに説得力があり，各種のSCA Runtimeについても触れられていて興味深いものです。
以上，7回にわたって連載してきました「SCA V1.0入門」も今回で最終回です。この連載によって，少しでもSCAについてご興味を持っていただけたら幸いです。ここまでお読みいただきました読者の皆様に感謝いたします。
