ここでは、WebOTX V5.1のリリースで新しく追加された機能や変更点を説明します。
WebOTX V5.1より製品全般における機能強化項目について説明します。
WebOTX V5.1より全製品で
Java 2 Platform, Enterprise Edition(J2EE) v1.3に対応しました。
Standard-J Edition以上でJ2EEサーバを提供します。主な特徴は次のとおりです
-
J2EE 1.3仕様に対応
J2EE 1.3仕様の主要なサーバ側テクノロジー、EJBコンテナとWebコンテナ、
JMSサーバを単一JVMで起動します。あるいは、それら3つを異なるJVMで動作させることも可能です。
-
Webブラウザによる簡易モニタの提供
サポートするJ2EE APIと実装
J2EEサーバは、次の各仕様バージョンのAPIや実装を提供します。
| API |
備考 |
| JDBC 2.0標準拡張 |
DBベンダが提供するJDBCドライバと共に機能します。 |
| JTA 1.0.1 |
WebOTX Transaction Serviceが下層でトランザクション・サービスを提供します。 |
| JNDI 1.2.2 |
WebOTX JNDIサービスとObject Brokerがネーミング・サービスを提供します。 |
Servlet 2.3
JSP 1.2 |
WebOTX Webコンテナ、v4.0.6がエンジンとして動作します。 |
| EJB 2.0 |
WebOTX EJBコンテナが実装しています。 |
| RMI/IIOP 1.0 |
Object Brokerが通信部分を提供します。 |
| JMS 1.0.2 |
WebOTX JMSサーバがメッセージング・サービスを提供しています。 |
| JCA 1.0 |
J2EEサーバはリソースアダプタの実行環境を含みます。 |
JavaMail 1.2
JAF 1.0.1
JAXP 1.1.3
JAAS 1.0 |
Sun Microsystemsが提供するリファレンス実装をバンドルしています。 |
WebOTX V4.2以前はWeb/Standard-J EditionのみLinuxに対応していましたが、V5.1よりWebOTX 全製品で以下のLinux OSに対応しました。
ObjectBrokerにおいて新しく追加された機能を以下に示します。
- JSSEサポート
Java 2 Platform, Standard Edition(J2SE)で提供されるJava Secure Socket Extension(JSSE)を使用してSecure Sockets Layer(SSL)での通信が行えます。
- CSIv2サポート
セキュリティ属性をクライアント、サーバ間のリクエスト/リプライメッセージ中のサービスコンテキストに設定して送受信する Common Security Interoperability Version 2(CSIv2) 機能をサポートします。
- Portable Interceptors サポート
ORB の処理中に利用者が定義した割り込み処理を実行するPortable Interceptors 機能をサポートしました。
Webコンテナに新しく追加された機能を以下に示します。
- セション情報の共有機能
負荷分散装置を用いたWebサーバのクラスタ環境で、Webコンテナ上で動作するWebアプリケーションのセション情報の共有機能を提供します。これにより、Webアプリケーションの作成者は、クラスタ化を意識することなくWebアプリケーションの開発ができます。
- ファイル転送機能ライブラリ
WebアプリケーションとWebブラウザ間でファイル転送を行うためのライブラリを提供します。ファイル転送のためのエンコードやデータの解析をライブラリとして提供しているので、ファイル転送機能をより簡単に作成することができます。
- 性能向上
Webコンテナの処理を全体的に改善しV4.2のWebコンテナに比べて120~140%の性能改善を行いました。
Webサービスにおいて新しく追加された機能を以下に示します。
- CORBAプロバイダの提供
ユーザがコーディングレスで、バックエンドのCORBAサーバを呼び出し可能とするCORBAプロバイダを提供します。これによりWebサービスのビジネスロジックをCORBAで作成して利用することが可能となります。
EJBコンテナはEJB 2.0仕様をサポートし、次の新機能を実装します。
- メッセージ・ドリブンBean
WebOTXのJ2EEシステムは、Java Message Service (JMS) と統合され、非同期機能によるシステムの合理化が実現しました。
EJBとJMSとの統合によって、メッセージ・ドリブンBeanは、アプリケーション・クライアントのユーザ・インタフェースが介在しなくてもJMSメッセージを受信し、その情報に従って動作できます。
- コンテナ管理による永続性 (CMP) 2.0
EJB 2.0ではアプリケーション開発の簡略化と迅速化のため、CMP機能が強化されました。
EJB 1.1では、データモデリング機能と、CMP Beanからデータベース・スキーマへのマッピングの定義に使用されるメカニズムの点で、機能に制約がありすぎました。 EJB 2.0では、より複雑なデータベース・スキーマではなく、抽象スキーマに基づいて、移植可能なクエリ言語を初めて採用しています。これによって、データベースやベンダに依存しない方法で、実行時にEntity Beanを多様な検索条件に基づいて検索できます。
- ローカル・インタフェース
ローカル・インタフェースは、呼び出し元が同一コンテナ内にある場合、呼び出しを合理化できます。したがって、この機能は、同じ場所に配置しようとしているアプリケーションのパフォーマンスを向上させます。
- EJBコンテナ間の相互運用性
EJB 2.0仕様では、アプリケーションにサーバ間の相互運用性を持たせることで、異機種システム混在環境の有効化のレベルアップを図っています。これによって、各種ベンダの EJB 2.0サーバで動作するEJBアプリケーションを、RMI/IIOPプロトコルを使用して自由に相互運用できます。
| 3.7. Java Message Service(JMS) |
J2EE1.3で追加されたJava(TM) Message Service(JMS) v1.0.2に準拠したメッセージングサービスを新規にサポートしました。JMSとは、複数のオブジェクト間においてイベント通知を実現するサービスであり、キューやトピックと呼ばれる宛先を介して非同期に通信を行うことができます。
また、EJB2.0で導入されたイベント受信処理を行うメッセージドリブンBeanはJMSと連携しています。
なおJMSは以下のEditionにてサポートされます。
- Standard-J Edition
- Standard Edition
- Enterprise Edition
| 3.8. Standard/Enterprise Edition 実行環境 |
Standard/Enterprise Edition実行環境において新しく追加された機能を以下に示します。
以下にそれぞれの機能について説明します。
- 名前サーバに登録するオブジェクトリファレンスの永続化
WebOTX V4.2以前はオブジェクトリファレンスをアプリケーション起動時に名前サーバに登録して、終了時に削除を行っていましたが、この方式に加えアプリケーションの起動とは独立して永続的に名前サーバに登録する方式を提供します。
この方式の利点を次に示します。
- WebOTX初期化処理における負荷の低減
アプリケーション起動時に名前サーバにオブジェクトリファレンスを登録する方式ではWebOTXシステム起動時に、複数のアプリケーションが同時に起動され、そのアプリケーションで登録されているオブジェクト全てが名前サーバに登録されます。アプリケーションの数とオブジェクトの数に依存しますが、大量の登録要求が同時に名前サーバに対して行われます。名前サーバに登録するオブジェクトリファレンスの永続化することにより、この処理が行われなくなり、システム起動時の負荷を低減することができます。システム起動が完了するまでの時間も短縮されます。
- オブジェクトリファレンスを任意の名称で名前サーバに登録
WebOTX V4.2以前はオブジェクトリファレンスを名前サーバに登録するときの名前はWebOTXで規定した次に示すネーミングルールに従って登録していました。
/mudulename_interfacename
/NEC/WebOTX/WO_Default/mudulename/interfacename/1
/NEC/WebOTX/nameinggroup /mudulename/interfacename/1
modulename:IDLで定義したモジュール名
interfacename:IDLで定義したインタフェース名
naminggroup:名前サービス登録グループ名
また、登録する名前サーバについてはWebOTXシステム単位で「名前サーバホスト名」で指定するサーバに限定されていました。
WebOTX V5.1よりインタフェース単位で登録するオブジェクトリファレンスに対して任意の名前を設定することが可能になります。
この方式の利点を次に示します。
- インタオペラビリティの向上
自由な名前でオブジェクトリファレンスを登録が可能となるため、CORBAアプリケーションとしての自由度が高まります。マルチベンダ環境(複数ベンダのORBを利用した環境)での利用が容易になりました。インタオペラブル名前サービスをサポートしているORB製品との相互接続性が向上します。
- 複数の名前サーバへの登録
corbaname形式のURLで名前を指定するので、複数の名前サーバへの登録が可能となります。これにより名前サーバを分散して利用することが可能となります。
- オブジェクトリファレンスに複数のサーバ情報を定義
WebOTX V4.2以前はWebOTX Standard/Enterpriseをマルチサーバ構成で負荷分散を行う場合、名前サーバによるラウンドロビン負荷分散で実装を行っていました。名前サーバによるラウンドロビン負荷分散には次に示す問題点がありました。
-
名前サーバにオブジェクト取得要求を行った契機で接続先サーバが決定されるためオペレーション呼び出し単位で負荷分散が行われず、オペレーション要求が各サーバへ均等に分散されない場合がある。
-
接続先のサーバが異常終了した場合、そのオブジェクトは使うことができなくなる。よって処理を再開するためには名前サービスより再度オブジェクト取得を行う必要がある。
WebOTX V5.1より、オブジェクトリファレンスにそのオブジェクトが利用できるマルチサーバのリストを埋め込むことが可能となりました。これによりオペレーション単位で接続先サーバが振り分けられ、リスト中のあるサーバが異常終了した場合でも、オブジェクトリファレンスの再取得を行うことなく、オペレーション要求を行うことができます。このとき異常終了したサーバを除いた振り分けが行われます。
- 同一インタフェースを持つ複数のコンポーネントの登録
WebOTX V4.2以前はコンポーネントが使用するインタフェースはWebOTXシステムで一意である必要がありました。この制限により、同一のインタフェースからなる異なるコンポーネント(インタフェースが同じで、ロジックが異なるコンポーネント)を同一WebOTXシステムに登録し動作させることはできませんでした。WebOTX V5.1より、同一のインタフェースからなる異なるコンポーネントをそれぞれ異なるプロセスグループに登録し動作させることが可能になりました。
この方式の利点を次に示します。
-
複数の版のアプリケーションを同一のシステム上で動作させることが可能になります。例えばテスト用と本番用のアプリケーションを同一のシステム上で動作させることが可能となります。テスト用と本番用のオブジェクトに対して異なる名前を設定し、クライアントからのテスト用もしくは本番用の名前を指定することでそれぞれにアクセスすることが可能になります。
- ステートレス/ステートフルオブジェクトの混在
WebOTX V4.2以前はステートレス/ステートフル属性はプロセスグループのプロパティで設定していました。よって、ステートレスとステートフル属性のオブジェクトを同一コンポーネントの中に定義することができませんでした。WebOTX V5.1ではインタフェース単位でステートレスとステートフル属性を設定できるようになりました、これによりステートレスとステートフル属性のオブジェクトが同一プロセスグループ内で混在することが可能になりました。
J2EE展開ツールはJ2EE 1.2のテクノロジー、EJB 1.1/サーブレット 2.2/JSP 1.1コンポーネントの後方互換を維持しながら、新しいJ2EE 1.3仕様に含まれるコンポーネントを扱えます。
| 3.10. Transaction Service |
Transaction Serviceにおいて新しく追加された機能を以下に示します。
- OTS1.3の準拠
OTSの最新の仕様OTS 1.3に対応しました。OTS1.2と同様にOTSPolicyを設定することにより、トランザクションとして動作させることができます。
- C++版 RCSのサポート
従来のRecoveryServerの性能改善版であるRCS(Recovery Coordinator Server)のC++のアプリケーションに対応しました。従来のRecovery Serverの約2倍のトランザクションの処理を行なうことができます。
- Proxy RCSのサポート
従来のRecovery Serverに変えてリッチクライアントでのトランザクションを管理するためのProxy RCSを追加しました。クライアントトランザクションを他のRCSと同様に管理することができます。
| 3.11. Notification Service |
Notification Serviceにおいて新しく追加された機能を以下に示します。
- イベント通知性能の向上
単位時間あたりのイベント通知件数を、全体的に改善しR4.2と比較して約2倍に向上しました。またデータベース更新時の、Commitのチェックポイント制御を実装しました。これによりCommit処理の回数を減らすことが可能になります。
WebAP JSPにおいて新しく追加された機能を以下に示します。
- サポートWebサーバ、Webコンテナの拡張
「WebOTX WebAP JSP実行環境」と連携して動作可能なWebサーバとして、以下をサポートしました。
- Sun ONE Web Server 6.0
「WebOTX WebAP JSP実行環境」と連携して動作可能なServletコンテナとして、以下をサポートしました。
- JRun 4.0
- Sun ONE Web Server 6.0の内蔵しているコンテナ
- モアレッシモ連携
モバイル端末向けWebシステム構築基盤製品「モアレッシモ」と連携して、「WebOTX WebAP JSP開発環境」で生成したWebアプリケーションをモバイル端末から実行できるようになりました。
- 環境設定機能の強化
WebAP JSP実行環境を、環境設定時に指定した任意のディレクトリで動作させることができるようになりました。これにより、１つのマシンにWebAP JSP実行環境の動作環境を複数作成することができます。
- MFDL移行機能の強化
MFDLの文字色指定を有効にしました。プレーンテキストの文字色はMFDLで指定した色で表示できるようになりました。
COM/CORBA ゲートウェイにおいて新しく追加された機能を以下に示します。
- struct対応強化
IDL定義において、struct中にstruct/array/sequenceが現われるような複雑なstructに対応できるようになりました。本機能強化によりVISコネクタなどのサーバアプリケーションをVisualBasicから容易に利用することが可能となります。
画面テンプレートにおいて新しく追加された機能を以下に示します。
- サポートWebサーバの拡張
動作可能なWebサーバとして、以下をサポートしました。
・Sun ONE Web Server 6.0
・WebOTX Webサーバ
UDDIレジストリにおいて新しく追加された機能を以下に示します。
- 性能向上
JDBCデータソースを利用することにより、V1.1のUDDIレジストリと比較して約+50%の性能改善を行いました。
- コード変換機能
VISコネクタ 実行環境が提供するコード変換機能が、G1文字コード変換にも対応しました。
OLF/TPアダプタは、開放型OLF/TPプロトコルを利用して、ACOS-4 VIS II、TPBASEなどのEIS（Enterprise Information System）と通信するためのアダプタです。JCA（J2EE Connector Architecture）Ver.1.0に準拠しています。APコンポーネントはOLF/TPアダプタの提供するJCA準拠のインターフェースを使用してEISと通信することができます。
- OLF/TPアダプタの機能
OLF/TPアダプタの主な機能を次に示します。
- JCA準拠のAPI
JCAで規約されているバックエンドサーバアクセス用の標準インターフェースであるCCI(Common Client Interface)をサポートしています。ここでいうバックエンドサーバとは、ACOS-4 VIS II、TPBASEなどのEISを指します。 さらに、APコンポーネントとOLF/TPアダプタ間のデータ形式についてはJCAの規約にあるRecordインターフェースのIndexedRecord、MappedRecordをサポートしています。
- 通信プロトコル
開放型OLF/TPプロトコル、OLF/TP-UWプロトコルをサポートするACOS-4 VIS II、TPBASEとの通信ができます。
- 非管理環境
JCA準拠のAPサーバを利用しない環境でも、OLF/TPアダプタを利用することができます。OLF/TPアダプタではDefaultConnectionManagerにより管理環境と同レベルのプール管理機能を提供します。
- 非同期受信機能
OLF/TPアダプタでは、非同期受信機能をサポートしています。これは、バックエンドサーバから送信される非同期電文をＡＰコンポーネントに通知するインターフェースです。非同期受信についてはJCA1.0規格では未定義のため、独自実装でサポートしています。非同期通信機能を利用するには、APコンポーネントはMessage-Driven Beanとしてください。APコンポーネントへの通知はJava Message Service(JMS)のインターフェースを利用して通知します。
- コード変換
以下のコード種別の相互変換に対応しています。
- unicode−JIPS(E)
- unicode−JIS(JIPS(J))
- unicode−シフトJIS
- unicode−EUC
また、辞書機能により任意のコードをバックエンドサーバの任意のコードにマッピングさせて変換を行うことが可能です。辞書変換機能を使用することで外字や、禁則文字などはシステムごとに独自の変換ができます。
- データ変換
バイナリ形式データ変換としてエンディアン変換機能(BIGエンディアン/ LITTLEエンディアン)を提供しています。また、バックエンドサーバ上のCOBOLのTPPでよく使われるパックやアンパック形式と数値文字列間の変換機能も提供しています。
- ジェネレータ
バックエンドサーバ上のTPPでよく使われるCOBOLのコピー原文ファイルを読み込み、その電文情報から電文フォーマットクラスとレコードマッピングクラスを生成します。このクラスはコンパイル後リソースアダプタと一緒にパッケージングされてデプロイされ、RecordオブジェクトがAPコンポーネントと送受信データの入出力を行う際にコード変換/データ変換を行うために使用されます。
