[プロダクトレビュー]
CORBA基盤のeプラットフォーム
iPortal Application Server 1.3
伊笹 広（いざさひろし）
日本アイオナテクノロジーズ株式会社
テクニカル・セールス・マネージャ
2001/3/16
| アイオナの放つアプリケーション・サーバ「iPortal
Application Server」は、このマーケットでは後発になる比較的新しい製品だ。日本市場ではこれからの製品だが、CORBA
ORBの世界ではVisiBrokerと並んでシェアの高いOrbixベースであるだけに注目を集める。ここでは、この最新バージョンの新機能と特長について日本アイオナテクノロジーズ
テクニカル・セールス・マネージャ伊笹 広氏に紹介していただく。（編集局） (編集注：iPortal Application Serverは、アイオナ社の製品統合によりOrbix E2Aに統合されました。現在Orbix E2Aのレビュー記事を準備中です。Orbix E2Aの製品情報については、アプリケーション・サーバセンターを参照ください） |
| 1.トータルシステムの中のアプリケーション・サーバ |
IONA Technologies（以下IONA）のJ2EEアプリケーションサーバであるiPortal Application Serverについての説明をする前に、一般的な話ですが、J2EEが現在置かれている立場について、ちょっと考えてみたいと思います。
J2EEのアプリケーションサーバは、ご存じのようにほとんどのケースでWebサーバの後方で用いられ、eコマースやポータルサイトの中の複雑な処理を分担しています。ここでアプリケーションサーバの果たしている役割は、よく見ると以下の2つに大きく分類されます。
(A） 既存の受発注システムなどを、Webを通じて外部に公開するための仲介
(B) まったく新しいサービスを提供するときの開発環境
実際は（A）、（B）両方の役割を同時に果たすケースがかなり多いわけですが、（A）の部分では、実はアプリケーションサーバのほかに、既存のシステムをアプリケーションサーバから呼び出せるようにするためのゲートウェイ製品を導入しているケースがかなり多いと思います。J2EEで最初に注力されていたのは（B）の機能、すなわち新しいWebアプリケーションの開発環境という側面でした。最近になって（A）を実現するための機能、例えばJ2EEコネクタなどの技術が発表されています。ただし、アプリケーションサーバからほかのシステムへアクセスするための技術にはすでにさまざまなものが存在し、純粋にJ2EEの世界だけを見ていればよいわけではありません。例えば、俗にいわれるEAI（Enterprise Application Integration）製品といわれているもののほとんどでは、アプリケーションサーバとの連携が考慮されています。標準技術でいえばCORBAという実績のあるものが存在しますし、さらに最近注目されているWebサービスでは、W3Cで標準化されたSOAPというXMLベースの手続き呼び出しスキーマが使われ、これによってアプリケーションサーバとの連携を行うことができるようになるでしょう。
私たちIONAが考えるのは、アプリケーションサーバとほかのシステムの連携については、さまざまな技術が今後も存在し続けるが、それらは時間がたつにつれて標準準拠の技術になっていくだろうということです。J2EE完全準拠、DBコネクションプーリングなどは当たり前の最近のアプリケーションサーバですが、なぜか他システムとの連携についてはアドホックな技術で対応したり、製品をまったく別のものに変えたりしなければならないものが多いようです。
アプリケーションサーバは、今後も（技術に通じたエンジニアさえ確保できれば）便利で信頼性の高いビジネスロジック実行環境としての地位を保っていくことは間違いないと思いますが、それと並行して種々の標準的なシステム接続技術をサポートできなければならない、と考えています。
| IONA のミドルウェア基本技術 ： ART |
iPortal Application Server （以下iPAS）は、上で述べたシステム連携の標準技術を幅広くサポートし、もちろん便利で信頼性の高いロジック実行環境として機能します。その基礎となっているのは、IONAが開発した基本技術：Adaptive Runtime Technology（以下 ART）と呼ばれるものです。
ARTとは、さまざまなカテゴリのミドルウェアを、共通の実装をベースに柔軟な仕組みで構築する技術です。皆さんはミドルウェアといえば、アプリケーションサーバやCORBA製品、TPモニタなどを思い浮かべるでしょう。これらミドルウェアにはもちろん固有の機能がありますが、製品の実装を見ると非常に多くのオーバーラップした部分があります。例えばほぼすべての製品は多数のオペレーションを並行に実行するためのマルチスレッドを生成・プールし、管理するメカニズムを持っています。また、コネクション（主にTCP）を管理するサブシステムも皆が備えています。
ARTではこのようなミドルウェアを実現する普遍的な機能セットを整理し、それぞれを小さなモジュールとして作成しました。私たちはこれを「プラグイン」と呼んでいます。これらプラグインを組み合わせることで、さまざまなミドルウェアを構築することができます（図1）。さらに、プラグインはミドルウェアの起動時に動的にロードされる仕組みになっています。ロードしたプラグインの組み合わせによって、起動したミドルウェアがCORBA製品になったり、アプリケーションサーバになったりします。
 |
| 図1 ARTの概念図 |
このようなプラグイン・アーキテクチャ＝ARTにより、以下のような重要なメリットが得られます。
(1） 新しいプロトコル（例えばSOAPなど）、より強力なセキュリティメカニズムなどを、プラグインとして用意することで、迅速にミドルウェアの機能に取り込むことができる
（2） プラグインがほかの機能と連携するためのインターフェイスはしっかりと固定されている。従って、プラグインを交換したときにユーザー・アプリケーションの変更は不要
（３） プラグイン部分のインターフェイスを公開することによって、開発者が独自のプラグイン（例えば、独自の認証機構など）を作成して組み込むことができる
（４） 製品の修正や機能追加がプラグイン単位となり、ほかへの影響を最小限にとどめることができるので、結果的に製品の品質が向上する
ARTでは個々のプラグインの実装はJ2EE、CORBA、Webサービスといった種々の技術で共有されます。結果として各機能の成熟度が高まり、また将来の技術トレンドにも無理なく再利用されることになります。ここで、各技術に別の実装を提供するベンダとは品質とスピードにおいて違いが出てきます。
| ARTに基づくiPASの特長 |
ARTに基づくJ2EE 環境であるiPASは（図2）、上記のメリットをフルに生かした、非常に拡張性の高いアプリケーションサーバ製品であり、開発者・管理者の方々にさまざまなオプションを提供します。細かい機能の解説の前に、以下でiPASの幾つかの大まかな特長について紹介します。
 |
| 図2 iPortal Application Serverの構成。本体であるWeb ContainerとEJB ContainerはそれぞれARTのプラグインアーキテクチャの上に構成されており、IIOPで接続されている |
■幅広い標準技術によるシステム連携の実現――CORBAとWebサービス
先ほど紹介したARTでは、CORBA IIOPプラグインを提供していますが、これはそのままiPASのデフォルトプラグインとして統合されています。これにより、アプリケーションサーバのバックエンドに存在するCORBA準拠のシステムとのシームレスな連携を実現します。さらに、次の重要なプラグインとしてSOAPプラグインが提供されます。これをiPASで用いることにより、EJBコンテナがWebサービスとして動作できることになります。
■CORBA 2.3.1の実現する高いスケーラビリティ
iPASにおけるEJBライフサイクルの管理メカニズムは、IONAのCORBA 2.3.1準拠ミドルウェアであるOrbix 2000と共通のものをARTにより組み込んでいます。CORBA
2.3.1にはPOAという、オブジェクトの特定や生成・消滅などのライフサイクルを効率的に管理する仕組みがあります。これにより数百万単位のオブジェクトを、コンテナ中で必要なときに生成、削除することが可能となります。
■Orbixで実証済みの技術基盤
EJBのトランザクションインターフェイスでJTAの下位サービスを実現するJTSは、CORBAのOTS（Object Transaction
Service）をモデルとしています。またJNDIの実装として、CORBAのCosNamingに基づくサービスプロバイダが将来は必須サポートになりつつあります。このようにEJB仕様にCORBAの技術が採用される流れの中で、IONAでは長年にわたるCORBA製品の実適用経験をiPASに生かしています。従ってAPIの新しさに比して実装の成熟度は高く、基幹システムに適用できる高信頼性、高可用性を実現します。
■IONAの他製品との組み合わせによるCOM、ホストとの連携
上記で登場したOrbix 2000では、Microsoft COM技術との連携を実現するCOMetコンポーネントを提供しています。またIONAでは、メインフレームのアプリケーションをCORBAで通信可能にするiPortal
OS/390 Serverという製品も提供しています。このような製品との組み合わせにより、EJB〜COM〜メインフレームという異種プラットフォームの混在環境を、CORBAという標準の通信バスにより統合することが可能となります。
■シームレスな製品構成
iPASには、2つのEditionが存在します。異種分散トランザクション機能をフルに実装するEnterprise Edition（EE）と、単一リソース向けに最適化された軽量JTA
プラグインを持つStandard Edition（SE）です。限定されたeコマース向けにはまずSEを導入し、その後既存システムを含めた拡張を行う際にEEに移行するといったシナリオが考えられますが、両EditionでトランザクションAPIやコンフィグレーション方法は統一されていますので、プログラムや設定の変更は不要です。当たり前のことのように思われるかもしれませんが、案外このようなスムーズな移行をサポートする製品は少ないようです。
iPAS
1.3の詳細な機能 |
|
||||||
|
||||||||||||||||||||||||
- 実運用の障害対応時間比較に見る、ログ管理基盤の効果 （2017/5/9）
ログ基盤の構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。今回は、実案件を事例とし、ログ管理基盤の有用性を、障害対応時間比較も交えて紹介 - Chatwork、LINE、Netflixが進めるリアクティブシステムとは何か （2017/4/27）
「リアクティブ」に関連する幾つかの用語について解説し、リアクティブシステムを実現するためのライブラリを紹介します - Fluentd＋Elasticsearch＋Kibanaで作るログ基盤の概要と構築方法 （2017/4/6）
ログ基盤を実現するFluentd＋Elasticsearch＋Kibanaについて、構築方法や利用方法、実際の案件で使ったときの事例などを紹介する連載。初回は、ログ基盤の構築、利用方法について - プログラミングとビルド、Androidアプリ開発、Javaの基礎知識 （2017/4/3）
初心者が、Java言語を使ったAndroidのスマホアプリ開発を通じてプログラミングとは何かを学ぶ連載。初回は、プログラミングとビルド、Androidアプリ開発、Javaに関する基礎知識を解説する。
 |
|
|
|
|
