• Java実行環境(Java runtime environment)
この層は、下位のネイティブな実行環境を隠蔽することで、上位レイヤのアプリケーショ ンプログラムのコードがポータブルであることを保証する。
この層の機能は、Javaの仕様、例えば、J2SE(Java 2 Platform StandardEdition)や J2EE(Java 2 Platform Enterprise)などのように、標準化されている。J2SEはJavaの 実行環境(runtime environments)を規定し、J2SEはEJB(Enterprise Java Beans)の環 境を規定するものである。
アプリケーションに対しさまざまなAPI(Application Programming Interface)やライブ ラリを提供するのもこのレイヤである。データベース、トランザクション、メッセージ 通信等の機能がこのレイヤに含まれる。
J2EEにおいては、ほとんど全ての機能がJavaで記述されている。
• 汎用ミドルウェア(General purpose middleware)
このレイヤは、プロトコル処理機能、および、システム管理機能を含む。
例えば、VoIPのシグナリング制御のためのプロトコルである、H.323 [45] SIP [44] MEGACO(H.248) [45]などは、このレイヤに実装されている。
同様に、既存電話網内のシグナリング機能としてISUP、運用、保守、メンテナンス (OA&M)機能としてCORBAやSNMP、データベース管理機能としてSQLなどが含ま れる。
このレイヤにおいては、プログラミング言語としてC++(Cを含む)やJavaなどが使わ れることが多い。C++は高性能を必要とする領域に適用される。一方、Javaは、頻繁に 修正されたり、機能追加の多い箇所に適用される。
• アプリケーションサービスレイヤ(Application service layer)
このレイヤでは、基本呼処理、ナンバーポータビリティ、電話会議、インスタントメッ セージング(IM)、課金などのようなアプリケーションサービスが提供される。サービス 開発の迅速性を重視して、プログラムは、Javaにて記述されることが多い。
5.3 リアルタイム性に関する要件
5.3.1 通信ノードに対するリアルタイム性の要件
リアルタイム処理は、タスクのデッドラインについての制約の違いにより2種類に分類される [56, 57]。
• ハードリアルタイム[58]: デッドラインを越えた場合にタスクやシステムの価値が0になる。
例: 飛行機、発電所
"! #$ &% #
' )(*+,-%
.#0/#1,&%
23*4% 55( %,
67+,8 9 *%: # %;<%=&$ $ < %: +
>?(@"A9B * +C 5 /
'D E$ (,9#&+F5(*FGH'?I
図 26: リアルタイム処理の種別
• ソフトリアルタイム[59]: デッドラインを越えるとタスクの価値が徐々に下がる。例: ビデオ ストリーミング、家電製品のUI
一つのシステムにハードリアルタイム処理とソフトリアルタイム処理が混在することもしばしば ある。大抵のリアルタイムシステムは、ハードリアルタイム処理を行ないながらソフトリアルタイ ム処理をこなしている。システムとして見た場合、ハードリアルタイムとソフトリアルタイムの境 界は明確に分かれるものではない(図 26)。
交換機のような通信システムにおいては、短期的にデッドラインを越える遅延の発生は許容され るが、その状態が長期的に続くことは応答性を著しく低下させることになりシステムとして成り立 たなくなることから許容されない。人によっては、このような領域のリアルタイムシステムを特に ファームリアルタイムとして、ハードリアルタイムとソフトリアルタイムの中間に分類することも ある。
5.3. リアルタイム性に関する要件 57
5.3.2 リアルタイムJava
リアルタイム分野へ適用するためのJavaの仕様としては、Javaリアルタイム仕様(RTSJ)が存 在する。[60, 61] RTSJにリアルタイム処理のために追加された仕様としては、
• リアルタイムスレッド制御
• 非同期転送制御
• タイマ
• 非ヒープメモリ
がある。RTSJは仕様のみであり、その実装は開発者に任されている。実際の実装に当たっては、
下記のようなJVM特有の機能についての対応が必要となる。
• GC
• メソッドの動的バインディング
• 動的クラスロード
• 実行時コンパイラ(JIT/HotSpot)
RTSJ準拠のJVMの実装技術については本論文の主題ではない。
5.3.3 サービス中断のないプログラム修正の要求
Javaにおけるオンラインでのプログラム部分入れ換え(Javaオンラインプラグイン)に関する要 求条件は以下のとおりである。
(1) 入れ換えるプログラムはJava言語で記述できること。
(2) オンラインで行なわれているサービスは中断されてはならない。
言い替えると、修正されるプログラムは、事前にアンロードされてはならない。
(3) 処理性能低下という影響を与えてはならない。
(4) プラグイン処理は、アドレス関連の例外や、無限ループのような、システムの重大な問題を引 き起こしてはならない。
(5) 修正後に異常が発生した場合、システムは元(プラグイン前)の状態に普及する必要がある。オ ペレータは修正の状況を監視し、コントロールできなければいけない。
(6) できる限り多くの問題事象のバグ修正に利用できること。
Javaの特性を考慮してこれらの要求を考察してみる。
まず、最も大きな違いは、JITコンパイルを伴った中間コード(バイトコード)による実行にある。
システムが、VoIP呼処理での使用に耐えるような十分なパフォーマンスを狙うのであれば、種々 の改善が必須である。JITコンパイラは重要な役割を果たしている。JITコンパイラは、頻繁にア クセスされるメソッドを、ネイティブコード(機械語)にコンパイルすることにより、処理の重いバ イトコードの逐次実行(interpretation)を避けるものである。実質的には、メインルートにおける全 てのJavaメソッドは、ネイティブコードに変換される。さらに、JITコンパイラは、頻繁に使用さ れるメソッドを、サブルーチン呼出形式ではなく、インラインに展開する。インライン展開された メソッドに修正の必要がある時、修正済みのコードをいかにリンクするかは、Javaオンラインプラ グイン機構として解決しなければならない課題である。