[特別企画] 次世代コミュニケーションサービスを担うJAIN（後編)

JAIN SLEEの役割を理解する

高山義泉
2004/2/7

INDEX

JAIN SLEEの策定基準は？ ＪＡＩＮ SLEEの機能 サービス提供の実際 JAINの今後

　前編「マルチメディアを操るためのＪａｖａ API登場」では、次世代コミュニケーションサービスを意識して策定されたJAINの中でも、「SIP」と「SLEE」について、それぞれの概要を説明しました。

　今回は、JAIN SLEEの機能に焦点を置き、JAIN SLEEがどのようなサービスの提供を実現するのかを明らかにします。

JAIN SLEEの策定基準は？

　　テレコミュニケーションで要求されるアプリケーションとJ2EE（エンタープライズ）アプリケーションの違いをまとめたのが以下の表です。このようにテレコミュニケーションの分野では、エンタープライズのアプリケーションに比べ、より細かなリクエストを頻繁かつ安全に処理しなければなりません。

	テレコミュニケーション	エンタープライズ
アプリケーションの呼び出し（イベント）	非同期＊１	同期
イベントの特性	細かなイベント処理が頻繁に行われる	テレコミュニケーションに比べると、大きなイベント処理であり、それほど頻繁ではない
実処理の特性	軽い細かな処理	重いデータアクセスを行う処理
	短永続性を要求	長永続性を要求
データソース	ロケーション、コンテキスト情報などのメモリ	バックエンドシステム、データベース
トランザクション	軽いトランザクション	データベースのトランザクション
	高速かつ頻繁に処理できるためのトランザクション処理
実行負荷	実計算処理に負荷	データベースアクセスに負荷

＊1：非同期はテレコミュニケーションのサービスを実現するためのアプリケーションに必要になったモデル。非同期のメリットは後述

　テレコミュニケーション分野のアプリケーションに求められる要求をさらに詳しく見ると、以下のように整理できます。

高いパフォーマンス	1つのイベント処理に100ms以下の応答時間を実現できる
	1秒間に数百〜数千のイベント処理を行える
高い可用性	24時間365日ユーザーにサービスを提供し続けられる
高い拡張性	予想し得ないユーザーの増加にも柔軟に対応できる
高い移植性	ネットワークインフラに依存しないサービスロジックを提供できる

JAIN SLEEの機能

　ここまで解説した理由からJAIN SLEEは、J2EEの利点をそのまま引継ぎ、全く違ったアプリケーションサーバおよびアプリケーションデザインとして仕様が策定されました。その内容は以下のように整理できます。（1）（2）のアプリケーションモデルはJ2EEから、JAIN SLEEに特化した機能としては（3）〜（6）の機能が提供されています。

（1）イベントモデル （2）コンポーネントモデル （3）マネージメント機能 （4）リソース機能 （5）ファシリティ機能 （6）プロファイル機能

　以下に、（1）〜（6）の機能について解説しましょう。

（1）イベントモデル

　JAIN SLEE内での処理はすべてアクティビティコンテキスト（図1の「AC」）と呼ばれる仲介役を介したイベントモデルを採用しています。ネットワークリソース（ネットワーク上に存在する端末やWebアプリケーションなど）やほかのSBB（次項で解説：各サービスロジック）など処理を要求するイベントプロデューサは、アクティビティコンテキストへ必要なデータとともにイベント（処理要求）を送信します。一方、処理を実際に行うイベントコンシューマ（図1の「SBB」）はアクティビティコンテキストへアタッチすることによってイベントを受け付けます。このようにイベントプロデューサはイベントコンシューマの存在を知りませんしコンシューマも同様にイベントプロデューサと直接やりとりをしません。イベントをどのコンシューマに送信すればよいかなどのイベントルーティングはすべてアクティビティコンテキストが制御を行います。

図1　ＪＡＩＮ SLEEはイベントモデルで動作している

　このアーキテクチャはJMSのpub／subモデルと同様だと考えてもよいでしょう。JAIN SLEEはイベントプロデューサとイベントコンシューマ間の関係を保つようアクティビティコンテキストを定義します。このようにイベントモデルで採用することで、以下のメリットを実現しています。

（1）SBB開発者は、ネットワークリソースやほかのSBBのインターフェイスを把握する必要は無く、アクティビティコンテキストとやりとりを行うインターフェイスについてのみ知っているだけでよい。そのため開発効率が高く、また拡張性に優れている （2）一貫したイベント配信モデルを定義しているため、開発者はそれを習得するだけでよい （3）アプリケーションコードにルーティングロジックを記述する必要がないため、移植性の高いアプリケーションを構築できる （4）イベントプロデューサとイベントコンシューマの直接参照を制限することで、dangling／invalid referenceの可能性をなくしアプリケーションの安定稼働性を高めることができる （5）プロデューサとコンシューマを分離することによりプロデューサで発生したエラーがコンシューマに影響を与えることがないため、可用性を高めることができる （6）このように疎結合は行っているもののプロデューサとコンシューマの関係はコンテナが管理しており、必要のなくなったコンシューマのガーベジコレクション機能などは提供する

（2）コンポーネントモデル

　前述したようにJAIN SLEEではイベントモデルを採用しており、コンポーネントはそれに合わせたモデルを採用しています。つまり、JAIN SLEEのコンポーネントはイベントドリブンアプリケーションに合わせたコンポーネントということです。各コンポーネントは、お互いのコンポーネントを直接参照したり、ネットワークリソースと直接対話をすることはありません。SLEEのコンポーネントはSBB（Service Building Block）と呼ばれ、SLEEコンテナ上に存在します。SBBではサービスロジックのみ記述するだけで、そのほかテレコミュニケーションアプリケーションで共通に必要となる以下の機能については、JAIN SLEEのコンテナが提供することになります。これら機能をSLEEで使用する場合には、アプリケーションのデプロイメントディスクリプタに記述するだけでよいのです。

1.リソース、ライフサイクル管理 2.セキュリティ 3.永続性 4.トランザクション 5.コンカレンシー

（3）マネージメント機能

　JAIN SLEEでは、Java Management Extensions（JMX）によって定義されたManaged Beans（MBean's）を使用し管理インターフェイスを定義しています。Mbean'sで管理インターフェイスを定義することによってJavaプラットフォームのための標準的な管理インターフェイスを構築することができ、この管理インターフェイスを用いて、JAIN SLEEのサービスの起動や停止、インストール、アンインストール、後述するファシリティの設定などを行うことができます。

（4）リソース機能

　JAIN SLEEのアプリケーションは、多くの場合ネットワークリソースと連携します。しかし、JAIN SLEEは、テレコミュニケーションアプリケーションを実行するための実行環境であり、開発環境であるため、ネットワークリソースと連携するための実装は用意していません。テレコミュニケーションの分野には、前編で解説したSIPをはじめ多くのプロトコルやさまざまなリソースが存在しますが、JAIN SLEEでは、それらプロトコル、リソースに対してのアダプタ実装は用意していません。これは、JAIN SLEEアプリケーションに要求された可搬性を高めるためです。そのため実際にサービスを行うためには、JAIN SLEEコンテナにリソースアダプタ（図2の「RA」）を組み込み外部リソースと連携することになります。しかしリソースベンダーが勝手にリソースアダプタを作ってしまったのでは、結局JAIN SLEE内でそれと連携するための独自APIが存在してしまうことになり可搬性が低下します。それを防ぐためにJAIN SLEEは、外部リソースと連携するために必要なリソースアダプタを構築するためのJavaインターフェイスを提供します。

図2　外部のリソースとはリソースアダプタ（ＲＡ）を用いて接続する

　リソースアダプタアーキテクチャは、JAIN SLEEの仕様の中でいまだ完全に標準化されていませんが、その構築方法は、JAIN SLEE仕様書の付録で論じられています。

（5）プロファイル機能

　JAIN SLEE実装では、アプリケーションから頻繁にアクセスされるデータ（電話網加入者のプロファイルデータなど）を、メモリデータなどに保持されます。JAIN SLEEでは、それらデータのスキーマを定義しており、またデータの追加、削除、修正をするためのインターフェイスを用意しています。このように定義することで、JAIN SLEEアプリケーションで頻繁に使用されるプロファイルデータ構造を一般化でき、またインターフェイスを用意することで容易にかつ可搬性のあるアプリケーションを構築することができます。

（6）ファシリティ機能

　JAIN SLEEでは、テレコムアプリケーションで要求される次のような機能のための実装サービスを提供しています。

Timer Facility	アプリケーションに対してのタイマー機能を提供。定期的に実行する必要がある場合や開始時間を指定する場合などに使用
Alarm Facility	JAIN SLEEコンテナおよびRAで不正を検知した場合に、それを管理アプリケーションに知らせるために使用
Trace Facility	管理アプリケーションによって使用されるトレースメッセージを生成するために使用
Usage Facility	コンテナ内のリソース使用状況を管理するために使用
Profile Facility	プロファイルを操作するために使用

　JAIN SLEEで提供される実行環境を図示すると図3のようになります。

図3　JAIN SLEEで提供される実行環境

サービス提供の実際

　ここまでの解説でJAIN SLEEの概要は理解いただけたと思います。では、サービスを実施する環境はどのようなものになるでしょう。下に通信プロトコルとして、先に紹介したSIPを用いた環境の例を挙げます。

図4　JAIN SLEEはクラスタ化されるのが標準的な実装形態。ＳＩＰとはＲＡ（リソースアダプタ）で通信する

　前述したとおりJAIN SLEEは、ネットワークリソースには一切関与しません。そのためSIPと通信するにはJAIN SLEEのコンテナにSIPリソースアダプタ（図4の「RA」)を組み込んで使用することになります。また、実サービスを考えたうえでは、高可用性を実現するために図のようにJAIN SLEEアプリケーションサーバインスタンスをクラスタ化し、それらの間でのトランザクション管理やデータレプリケーションも必要になるでしょう。加えて、アプリケーションサーバだけでなく、リソースアダプタにも高いパフォーマンスと可用性が要求されます。このようにJAIN SLEEの実装では、JAIN SLEE仕様に加えさまざまなサービスが要求されるのが実際です。

　このように要求は非常にシビアなものですが、すでに、それを完全にカバーした製品もリリースされており、例えばJAIN SLEEのスペックリードであるOpen Cloudは、JAIN SLEEアプリケーションサーバとしてOpen Cloud Rhinoを、また各種リソースアダプタも提供しています。

JAINの今後

　図5は、さまざまなプロトコルスタックからの要求受付をJAIN SLEEで実装し、必要があれば、そこからWebサービスで連携してさまざまなサービスを利用するモデルを表しています。

図5　JAINベースのサービスをWebサービスによる連携で利用するモデル

　JAINのテクノロジは数多くありますが、その中でも本稿では特に注目のJAIN SLEE、JAIN SIPについて紹介しました。前編の冒頭で述べたようにJAINは次世代コミュニケーションサービスを構築するためのテクノロジです。JAIN SLEEはテレコミュニケーションで必要なアプリケーションの実行基盤であり、JAIN SIPは、アプリケーションに依存しないセッション確立プロトコルであるSIPを操作するAPIです。これらを中心にJAINのさまざまなテクノロジを用い、テレコミュニケーションアプリケーションとインターネット網上で提供されているWebアプリケーションを連動することで、いままでにはない価値のあるサービス（＝次世代コミュニケーションサービス）を構築することができるでしょう。

　JAINに関する最新の情報は、「ビジネスインテグレーション―JAINの紹介」で常に参照することができます。今月に開催されるJava Technology Conference 2004でもJAINの詳細を解説するセッションが開催される模様です。JAINは今後ますます注目されるJavaの新しいテクノロジーと言えるでしょう。

INDEX
特別企画：次世代コミュニケーションサービスを担うJAIN
	前編　マルチメディアを操るためのJava API登場
	後編　JAIN SLEEの役割を理解する

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）