静かに進行する新しいSOAプログラミング標準「SCA」

 「SOAのプログラミング・モデルはSCA」──違いを見つけるのがまるで視力検査のようですが,ともあれ新標準SCA(Service Component Architecture)のVersion 1.0が2007年3月21日に発表されました。

 発表したのは,OSOA(Open Service Oriented Architecture)です。OSOAは,標準化団体ではなく,複数のソフトウエア・ベンダーによるコラボレーション・チームです。

 それほど話題にならなかったこともあり,おそらく多くの読者の方々は,この発表をご存じないかもしれません。非常に静かな船出となったSCA V1.0ですが,発表したOSOAのメンバーを見ると,この新標準が意外に幅広く展開されつつあることがわかります。

 このSCAは,どのような標準で,どのような変化をもたらすのか。本連載で,SCAの全体像を解説していきます。

サービス指向という考え方

 業務アプリケーションは,複数のサービスによって構成される──これがService Oriented(サービス指向)の基本的な立場です。サービスって何? どうやって定義するの? という話題は他の方の記事に譲るとしても,SCAに関係する基本的な部分だけは押さえておきたいと思います。

 サービス指向の解説で必ず触れられる要素としては,以下のものがあると思います。

  • 疎結合
  • 再利用性
  • 標準

 SOAの説明では,言葉は違ってもたいていこれらの要素が入っています。この三つの要素をよく見てみると相互に関連していることがわかります。つまり「スタンダード(標準)」を使用して「疎結合」された「再利用可能」なサービスによって実現されるのがSOAということもできます。

 これは,SOAの大きな目的が“変化に強いIT”ということにあり,それが現在のビジネスの要請になっているからです。言い換えれば,これらの条件を満たしているサービスは,“変化に強い”のです。

 この三つの要素は,SCAの成り立ちにも深い関係があるため,少し細かく見ていきます。

実は奥が深い疎結合

 関係が“疎”であることが,疎結合ということです。関係が“密”であるとお互いに整合性を取る必要が出てくるため,何かを変えることが難しくなります。すなわち,変化に弱くなってしまいます。この密になってしまう関係の要因にはどんなものがあるのでしょう?

図1-1●システムやサービスの関係を密にしてしまう要因は多岐にわたる
図1-1●システムやサービスの関係を密にしてしまう要因は多岐にわたる

 図1-1のように関係を密にしてしまう要因は多岐にわたります。これらから完全に解放されることは現実には難しいと思います。できるだけ関係を薄めつつ,どうしても必要な部分には後から変えられるような工夫をするといったアプローチが現実的です。

再利用性の定義とは

 サービス指向における“再利用性”とは何でしょうか? 基本は,過去に作ったものを後から利用できることです。この利用の形態は,様々なものが考えられます。

 一つは,既存のサービスを一つの機能ブロックとして他のサービスが利用するというものです。ここでのサービスは,どこかですでに稼働していて,それを新しいサービスの利用者(クライアント)が使いに行くというイメージです。これは,とてもSOA的なモデルということができるかもしれません。この場合のサービスは,クライアントから見ると外部サービスということができます。

 もう一つは,いわゆるコードの再利用です。あるサービスを形作っているコンポーネント,もしくはそのサービス自身を,あらたにサービス構築の定義の一部として利用する方法です。

 これら二つの再利用の方法は,それぞれ独立しているというよりは,渾然一体となって新しいサービスを構成していくと考えたほうが現実的です。

SOAのスタンダード(標準)とは

 一般的にSOAの概要の説明では,「SOAは,原則であり…」というくだりがあり,特定のテクノロジで論ずるものではないということが語られます。現在は「これを使えばSOA」というスタンダードは存在せず,開発者が選択したテクノロジによって先に述べたような要件を満たすシステムを構築していくことになります。

 ただし,SOAの概念と親和性の高い技術は存在しており,ご存じのようにWebサービスはその筆頭に挙げられます。Webサービスは,SOAPに始まり,セキュリティやQoSなど,非常に広範な仕様を持っており,SOAと非常に密接な関係を持っています。Webサービスは,言語に依存しないXMLベースのテクノロジであり,.NET,C++,Javaなどで利用可能です。その点でもSOAとの親和性が高いと言えます。

 また,実装のテクノロジとして,J2EEもSOAと関係が深いものです。J2EEは,Javaの特性に由来する幅広いプラットフォームをサポートしているという特徴もあります。現在,J2EEは,Webサービスを内部に取り込む拡張を積極的に行っており,Webサービスの構築・実行環境としての機能を持っています。

 Webサービス,あるいはJ2EEといった標準プロトコル,標準技術をベースに考えることは,作成物の再利用性を考えても必要です。それは,Proprietary(独自実装)との疎結合を達成するために必要であるとも言えます。

何かが足りない

 これまで述べた通り,SOAを実現する技術として,言語に依存しないWebサービスのテクノロジや,プラットフォーム中立のJ2EEなどが利用可能です。SOAベースのシステムを作る材料はすでに整っているようにも見えます。新たなプログラミング・モデルが必要なのか,と思う方もいるでしょう。

 ここでSOAの要件に立ち返って考えて見るといくつかの疑問がわいてきます。

 先ほど,サービス指向の考え方として,複数のサービスの組み合わせよって業務アプリケーションは構成されると述べました。では,それぞれのサービスは標準に従って作られていたとしても,全体としての作成物は何に従って作れば良いのでしょうか?

 また,それぞれのサービスで使用するテクノロジは別々の実装方法を要求していますが,それでは結局のところテクノロジに密に結合しているのではないのか? その状況での成果物は後からの変更要求に耐えられるのか?──など,実際の構築を思い浮かべると全体として何かが足りない気がしてくるはずです。つまり,個々のテクノロジの組み合わせだけでは,SOAの全体的な要件との間にギャップが存在しているのです。

ギャップを埋めるのがSCAの役割

 SOAをさらに形あるものにするためには,既存の標準やテクノロジと,SOA全体の要件とのギャップを埋めていく必要があります。そこで世に出てきたのがSCA(Service Component Architecture)です。

 SCAは,先に述べた疑問に対して巧妙な方法で答えを準備しています。SCAは,できるだけ既存の標準技術を利用し,そこに足りないものを埋めていくというアプローチを採用しています。

図1-2●SCAのアセンブリ・モデル
図1-2●SCAのアセンブリ・モデル

 図1-2は,SCAのアセンブリ・モデルを表しています。これがSCAの基本構造です。非常に単純なモデルのようですが,よく考えられたモデルであり,すべてがこれで表現されます。このパーツの手(左右にある矢型のもの)をつないだり,内部で利用したりすることにより複雑なサービスを組み上げる方法を提供しています。

 次回以降,このモデルによってSCAが何を実現しているかについて説明します。

澤出 達郎(さわいで たつろう)
 日本アイ・ビー・エム ソフトウェア事業 ICP コンサルティング I/Tスペシャリスト