第2回　SCAは何も変えない？

　前回は，SCAが必要とされる背景についてお話しました。今回は，SCAが何を解決するのについて説明します。

サービス実装とテクノロジへの依存

　SCAの詳細に入る前に，サービスとテクノロジの依存についてもう少し考えてみたいと思います。

　あるWSDLで表現されているサービスあり，それを利用する必要があったとします。Javaの開発者であれば「JAX-RPCのクライアント・プログラムを書いて…それを呼び出すビジネス・ロジックを作ればいいな…」と考えます。現在は，WSDLさえあれば，呼び出しクラスを自動生成してくれるIDE（統合開発環境）があったり，JAX-RPCの機能をさらに拡張するJAX-WSが準備されていたりしますので，クライアントの開発自身は比較的容易です。

　ただし，厳密に言うとここで作られた成果物は，当然のことながらJAX-*と深く結びついているとも言えるわけです。これはサービス提供側の実装についても同じことです。例えば，提供側は，JAX-RPCでのサービス・エンドポイントを実装していくことになります。サービス・エンドポイントは，その機能をinterfaceで表現することになっており，抽象性の高い優れた仕組みですが，やはりJava言語におけるJAX-RPCの仕様と深く結びついたコードということが言えます。

　利用側，提供側が，それぞれ利用したテクノロジへの依存性を持つことになります。では，SCAではどういう方法を取るのでしょうか？ その方法を見ていきましょう。

SCAおけるサービスの呼び出し

　SCAでは，外部のサービスを“Reference（参照）”することによって利用します。サービスの利用者は，何らかの方法でSCAが参照しているこのサービスを利用することになります。その方法は，実はJAX-RPCかもしれません。

　実際にどうやって参照するかは，SCAのRuntime（実行環境）が決めることです。JAX-RPCで参照しているのならば，「何も変わらないじゃない！」と思われるかもしれませんが，実際に開発するプログラムにはJAX-*に関連するコードは含まれません。どのようなプロトコルで参照するかは，Referenceに対するBinding定義で決まります。

　SCAが存在することでSOAの理想である“疎結合”に少し近づいていることがわかります。SCAによって参照されたものは，Component（ここではサービスの実装のインスタンスと考えてください）からはローカルに存在しているようにとり扱うことができます（図2-1）。

図2-1●実装から独立して外部を参照

SCAおけるサービスの実装

　外部のサービスをReference（参照）を使って利用する一方で，自身がサービスを実装することが必要な場合もあります。SCAにおけるサービスの実装は，Componentによって行います（図2-2）。このComponentは，Implementation（実装）をインスタンス化するための定義になっています。

図2-2●SCAにおける実装“Component”

　Implementationは，複数の言語を対象としています。例えばJavaの場合は，実装の作業として必要なものは，ほぼビジネス・ロジックの作成だけです。外部へのサービスとしての公開インタフェースは，通常のJava Interfaceによって決定します。これはInterfaceを定義してある普通のJavaプログラムの作成とほとんど違いはありません。いわゆるPOJOです（リスト1）。

/* Java によるサービス・コンポーネントの実装例 */
/* 　　　　　　Abcサービスの実装コード     　　*/

package abc;

import org.osoa.sca.annotations.Service;
import org.osoa.sca.annotations.Reference;
import org.osoa.sca.annotations.Property;

@Service(AbcService.class)
public class AbcServiceImpl implements AbcService {

    @Reference
    protected PriceService priceService;
	
    @Property
    protected float discountRate;

    public int getDiscountPrice(int price) {
        return priceService.getDiscountPrice(price,discountRate);
    }
}

　明らかな違いがあるとすれば，SCA用のアノテーションが追加されているくらいです。あとは必要な定義を外部にXMLで記述するだけです。使用する実装言語によって必要な定義ファイルが少し異なりますが，基本的なアーキテクチャは同じSCAです。言語による違いは，言語がIntrospection（内省）に対応しているかどうかといった違いに依存します。もちろん，言語がIntrospectionに対応していなくても，XML定義を書けば大丈夫な仕様になっています。

SCAにおけるサービスの公開

　定義されたサービスを公開するのは，Serviceによって行います。Serviceによってどのような方法で，Binding（プロトコル）で外部に公開するかを決めることができます。つまり，実装とは独立して公開の方法を定義できます（図2-3）。

図2-3●実装から独立してサービスを公開

　実装側はこの公開の仕組みを意識する必要はありません。公開は，WebサービスやJMSと言った既存の仕組みをSCA Runtime（実行環境）が利用して行います。どのようなプロトコルで公開するかは，Serviceに対するBinding定義で決まります。

SCAは何も変えない？

　SCA自身は，新しい通信プロトコルを定義しているわけではありませんし，新しいWebサービス標準を作っているのでもありません。既存の優れたテクノロジはSCA Runtime（実行環境）がそのまま利用しています。サービスの実装のコーディングに関しても，ビジネス・ロジックの実装については，ほとんど何も変えません。

　ただし，今まで既存のテクノロジを利用するするために必要であったBoilerplate（定型句）が不要になりますので，そこは“変える”ことになるのですが，これはむしろ良い変化であると思います。例えば，何かを実行する前にObjectをlookupしてくるという部分は，誰もがやりたくてやっている部分ではなかったはずです。そのような部分は無くなります。

　第1回と第2回では，主にSCAの必要とする背景とその提供する機能の特徴を述べてきました。SCAは，サービスを入れるための万能な入れ物と言えるかもしれません。次回は，少し踏み込んでSCA V1.0の技術仕様について具体的に解説します。