|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
|
|
|
WebOTX Manual V11.1 (第6版) 目次を表示 |
ここでは、CORBA 、及びアプリケーションから利用できる部品であるサービスについて説明します。
はじめに、CORBAについて説明します。
Object Management Group (OMG)は米国の民間の標準化団体です。会員の提案にもとづいた仕様策定 を行っています。会員には、内外の主要なコンピュータメーカ、ソフトベンダやそれらのユーザ企業、他の 標準化組織などが参加しています。
Common Object Request Broker Architecture (CORBA)はOMG が規定した分散オブジェクトに関する標 準仕様です。分散オブジェクトの開発時の仕様と実行時の仕様に分けられます。開発時の仕様には、記 述するプログラミング言語に独立したInterface Definition Language (IDL)言語によるオブジェクトの外部 仕様の表現方式と各種プログラミング言語からの利用方法を規定する言語マッピングがあります。実行 時の仕様には、分散環境下に存在するオブジェクト間の通信プロトコルであるGeneral Inter-ORB Protocol/ Internet Inter-ORB Protocol (GIOP/ IIOP)などがあります。
CORBA を利用すると、オブジェクト指向言語であるJava やC++では通信に関連するプログラミングを意 識せずに、Java やC++のオブジェクトを呼び出す感覚で分散環境下での通信プログラムを記述すること ができます。引数や戻り値には整数や文字列などの基本型のほかに、構造体や配列などの複雑な型を 利用できますので、通信電文の設計やバイトオーダ(メモリ上でのデータの格納順序)の変換などに時間 を割く必要がありません。呼び出されるオブジェクトの記述言語と呼び出されるオブジェクトの記述言語 は異なってもかまいません。クライアントをJava で記述し、サーバ側ではJava はもちろんのこと、C++や COBOL などで記述することもできます。CORBA での通信は関数呼び出しと同様の動作となる要求応答 型(リクエストレスポンス型)です。一方、ファイル転送や画像配信などのデータ送信方向が片道であるス トリーム型通信には適していません。
WebOTX はCORBA仕様に基づいた分散オブジェクト技術をサポートしています。CORBA で開発した アプリケーション(オブジェクト)は部品として再利用が容易です。また各種既存システムと連携するため のコネクタを提供しているため、既存のシステムをオブジェクト部品としてラッピングして再利用すること も可能です。これにより、既存資産を生かした速やかなシステム構築を実現したり、システムの保守性を 確保したりすることができます。これらオブジェクト指向による部品化技術とWindows やUNIX、Linux な どの多様なプラットフォームへの対応により、急激なIT 技術の変化にも柔軟に対応することができま す。
WebOTX はCORBA 2.3/3.0(一部)仕様に対応しており、CORBA 2.0 以降仕様の他社製品に対する 実証された相互接続性がありますので、マルチベンダ環境のシステムの統合も容易に実現できます。 また、さまざまな言語でアプリケーションを作成することが可能なため、業務への適性とアプリケーション 開発者の得手・不得手に対し、最適なものを選択することができます。
CORBA を利用したアプリケーションの開発は通常次の手順で行われます。
IDL コンパイラはIDL 定義ファイルから、クライアントおよびサーバで使用するスタブと呼ばれるプログラ ムと、サーバで使用するスケルトンというプログラムを生成します。クライアントではクライアントでの処理 を記述したプログラムとスタブをコンパイルして使用します。また、サーバでは、サーバの処理を記述し たプログラムとスタブおよびスケルトンをコンパイルして使用します。
CORBA ではサーバオブジェクトの識別情報はInteroperable Object Reference (IOR)で表現されます。 IOR 中にはサーバオブジェクトのIP アドレスあるいはホスト名とTCP ポート番号が含まれています。 CORBA の実装内部ではこれらの情報を使ってサーバオブジェクトとのTCP コネクションを確立して通信 を行います。主な通信は、処理要求であるリクエストメッセージと処理結果を返すレスポンスメッセージで 行われます。
言語マッピングを使用するアプリケーションプログラムからは、関数呼び出しの延長として通信が行われ ますので、通信の詳細について意識する必要はありません。
WebOTX Object Broker は異なるORB 間の接続のためのCORBA 標準プロトコルGeneral Inter-ORB Protocol/ Internet Inter-ORB Protocol (GIOP/ IIOP)を内部プロトコルとしても使用しています。このた め、マルチベンダのシステムでも通信性能を損なうことがありません。現在GIOP/ IIOP には、1.0、1.1、 1.2 の3つのマイナーバージョンがありますが、GIOP/ IIOP はバージョン混在を前提に設計されています ので、これらのバージョンのいずれかをサポートしていればWebOTX Object Broker と通信することがで きます。ただし、バージョン混在時は低いバージョンで通信されますので、一部機能が制限されることが あります。
GIOP には、バイトオーダ(整数型、浮動小数点型などのメモリ上の格納順序)を変換する機能があります が、これについては、CORBA を使用することにより自動的に処理され、アプリケーションはこのことにつ いて意識せずにプログラムを記述することができます。
文字コードの変換をする機能です。string 型およびwstring 型に適用されます。クライアントで SJIS、サーバでEUC など異なる文字コードを使用しているときに、変換をCORBA に任せることができます。 文字コードの指定方法は、 [ リファレンス > 設定 > CORBA通信基盤(Object Broker) > Object Broker設定項目・設定方法 ] をごらんください。
WebOTX のORB はCORBA が規定するInternet Inter-ORB Protocol (IIOP)を使用します。WebOTX で はIIOP 1.2/1.1/1.0 をサポートしているのでIIOP に準拠する他のORB 製品と容易に通信ができます。ま たIIOP over SSL をサポートしているのでIIOP の通信をセキュアに行うこともできます。 WebOTX は Java,C++ともCORBA 2.3/3.0(一部)仕様の言語マッピングに準拠した開発環境を提供します。通信に関 する部分はORB で管理されるので、アプリケーション開発者は通信部分をプログラミングする必要があ りません。またObject Adapter にはPortable Object Adapter (POA)を使用しているので他のORB 製品 からの移植もスムーズに行うことができます。
名前サービスは、ネットワーク上に分散するオブジェクトリファレンスを一箇所に登録して、階層的な名前 を付けて管理するためのCORBA のサービスで、OMG が公布する「Naming Service Specification 1.1 (formal/2001-02-65)」を実装しています。
CORBA では通信相手であるオブジェクトを識別するためにオブジェクトリファレンスを使用します。 クライアントは通信をする前に通信相手のオブジェクトリファレンスを入手しなければなりません。 オブジェクトリファレンスを受け渡す方法にはいくつかありますが、もっとも一般的な方法は名前サービスを 使用することです。オブジェクトリファレンスとその名前をあらかじめ名前サービスに登録しておき、クライ アントは名前をもとにオブジェクトリファレンスを入手します。
WebOTX では名前サービスを実現するサーバプロセスを提供します。このプロセスを名前サーバと呼びます。 名前サーバではファイルシステムのように階層化してオブジェクトリファレンスを管理します。 名前コンテキストはファイルシステムのディレクトリに相当するもので、このコンテキストが集まり木構造を 作ります。名前コンテキストのうち、ファイルシステムのルートディレクトリに相当するものを特にルートコ ンテキストと呼び、ファイルシステムと同様に名前コンテキストの下に名前コンテキストを置くことができます。
WebOTX の名前サービスはCORBA 2.4 で規定されているインタオペラブル名前サービスに対応していま す。そのため他社製ORB 製品をWebOTX の名前サーバに登録したり、他社製の名前サーバへオブジェ クトの登録、参照をしたりすることができます。
インタフェースリポジトリは厳密にはCORBA Service ではありませんが、CORBA アプリケーションが他のサー ビス同様に利用できるためここにあげています。CORBA 2.3 仕様を実装しています。実行時にオブジェクトのイ ンタフェース情報を取得するために使用します。
スタブやスケルトンを使用する通常のアプリケーションでは必要ありません。主にDII やDSI などの利用時に使 用します。データの登録はIDL コンパイラが生成するファイルを用いて行います。
セキュリティを実現するサービスとして、次のIIOP over SSL、CSIv2 が提供されています。
Security Service 1.2 仕様にしたがっています。IIOP 通信で使用する通常のTCP/IP ソケットの代わりにSSL を 使用する通信方式です。通信データがSSL により保護されます。IIOP over SSL で通信を行うためには、SSL で使用する「証明書」が必要です。
セキュリティ認証情報をIIOP プロトコルで伝播するためにCORBA 2.6 で規定された仕様です。
Transaction サービスはCORBA 共通サービスの1つであるTransaction Service(OTS) 1.4 仕様に準拠してお り、WebOTX のアプリケーションに対してトランザクションの原子性、一貫性、独立性、永続性を提供します。こ れにより、アプリケーションは分散されたデータベースなどの複数のリソースに対する更新を安全に行うことが できます。またJTA の章でも記載したとおり、WebOTX が提供するTransaction サービスではJava EE 仕様の JTA インタフェースとOTS との連携を規定するJTS にも対応しており、Transaction サービスでJTA、および OTS を利用したトランザクションの管理を一手に行なっています。
また、ACOS とオープンサーバのリアルタイム連携を実現するためのランタイムライブラリ「ACOS Access Toolkit」が提供するJDBC ドライバと連携することで、本来は2フェーズコミットメントをサポートしていない ACOS 上のトランザクションをWebOTX が管理する2フェーズコミットメントトランザクションに参加させることが できるように強化を図っています。 これによってACOS 上のデータベースと、オープンサーバ上のデータベース(Oracle など)の同時 更新が可能になります。昨今のレガシーマイグレーション需要の増加に伴い、従来の業務系システムの 一部をオープン化し、メインフレームとオープンシステム間でアプリケーション連携を実現する事例が増 えています。例えば、従来のデータはメインフレーム上で管理、新規に追加された部分のデータ管理は オープンサーバ上で、という要件には適しています。 概要については、後述する [ ACOS 上トランザクションの2フェーズコミットメ ント参加 ]、詳細については [ 構築・運用 > ドメインの拡張機能 > Transactionサービス] をご参照ください。
WebOTX Transaction Service では従来のRecovery Server によるトランザクションに加え、Recovery Coordination Server を導入して、トランザクションを高速に管理する機能を提供しています。従来のRecovery Server はCORBA Transaction Service の仕様に準拠しており、高い相互接続性があります。しかし、トランザク ションの開始・終了時にアプリケーションとRecovery Server との間でCORBA Transaction Service が規定する 通信が必要でした。Recovery Coordination Server では、トランザクションの開始や終了処理をアプリケーショ ンプロセス内で実行し、大幅な性能の改善を図りました。ただし、CORBA Transaction Service 仕様を一部拡張 しているため、相互接続性はありません。
V7.1 以降では、従来別プロセスとして動作させていたRecovery Coordination Server をドメイン管理プロセス内 で動作させるようにしました。これにより、メモリ使用量の削減やドメイン起動時間の短縮が図られています。 WebOTX 上で動作するアプリケーションは堅牢なプロセスになるため、サーバトランザクションを実行する際に Recovery Coordination Server を使用するのが最も適した形になります。
フラットトランザクションは、ネットワーク全体で単一のトランザクションとしてリソースのコミット、ロールバックを 行う単純な形態です。そのため、あるアプリケーションで障害が発生した場合はトランザクション全体がロール バックしてしまいますが、トランザクションの一貫性(consistency)を保つという点ではこの形態を使用するのが 一般的です。
ネスティッドトランザクションは、全体のトランザクションを多段のサブトランザクションにツリー上に分割して実 行する形態です。サブトランザクション内のリソースに障害があってロールバックされても、全体のトランザクシ ョンには影響を与えないようにすることができます。一方、サブトランザクションのコミットはトップレベルのトラン ザクションがコミットされるまで実行されません。
Transaction サービスの提供するネスティッドトランザクションはCORBA トランザクションサービスに完全に準拠 していますが、仕様自身に相互接続性がありません。したがってWebOTX のTransaction サービスと、それ以 外のCORBA トランザクションサービスとの間でサブトランザクションを実行できるという保証はありませんので 注意してください。
ネスティッドトランザクションはリカバリサーバのみのサポートです。RCS はサポートしておりません。
Transactionサービスが提供するトランザクションサービスでは、トランザクションの管理のためにトランザクショ ンコンテキストを使います。
トランザクションコンテキストは、トランザクションに参加しているアプリケーションやリソース、トランザクションの 状態といったトランザクションに関する情報をもっています。Transaction サービスあるいはアプリケーションプ ログラムは、トランザクションコンテキスト内の情報を変更/参照することにより、トランザクションの制御を行い ます。例えば、アプリケーションをトランザクションに参加させるには、アプリケーションをトランザクションコンテ キストに関連付けることで実現します。
アプリケーションがトランザクションコンテキストを管理する方法として次の方法があります。
間接的なコンテキスト管理とは、アプリケーションとトランザクションコンテキストの関連付けをTransaction サー ビスが自動的に管理します。アプリケーションはTransaction サービスが提供するインタフェースを使用するだ けでトランザクションの制御を行うことができます。
トランザクションコンテキストを伝達することで、クライアントアプリケーションが呼び出したサーバオブジェクト を、クライアントが開始したトランザクションに参加させることができます。サーバオブジェクトは、伝達されたト ランザクションコンテキストを使ってトランザクションに参加し、トランザクションの制御を行うことができるように なります。このトランザクションコンテキストの伝達を伝播といいます。伝播には次の2種類があります。
暗黙的な伝播は、Transactionサービスが伝播を行います。間接的なコンテキスト管理によりアプリケーション のスレッドにトランザクションコンテキストが関連付けられているときにサーバオブジェクトが呼び出されるとトラ ンザクションサービスは暗黙の伝播を行います。アプリケーションは伝播のために特別な処理を行う必要はあ りません。伝播が行われるかどうかは、サーバオブジェクトのOTSPolicyによって決まります。
明示的な伝播は、アプリケーションが伝播を行います。アプリケーションがサーバオブジェクトのオペレーション を呼び出す時、引数にトランザクションコンテキストを指定することで行います。
WebOTX では、CORBA Transaction Service の最新仕様(OTS)である1.4 に対応しています。OTS 1.2/1.3 と同 様にOTSPolicy を設定することにより、トランザクションとして動作させることができます。なおOTS 1.2 からトラ ンザクションの伝播はサーバアプリケーションが登録されたPOA のPolicy によって設定されます。OTSPolicy はREQUIRES、FORBIDS、ADAPTS の3種類があります。
オブジェクトは必ずトランザクション内で動作する必要があることを示します。そのため、REQUIRES が設定されたオブジェクトを呼び出すクライアントはトランザクションを開始しておかなければなりま せん。トランザクションを開始していない状態で呼び出すとCORBA::TRANSACTION_REQUIRED 例 外が発生します。
オブジェクトは必ずトランザクション外で動作する必要があることを示します。クライアントでトランザ クションが開始されている場合、サーバアプリケーションを呼び出すかどうかはNonTxTargetPolicy によって決定します。WebOTX Transaction Service はNonTxTargetPolicy の既定値をPERMIT とし ているため、トランザクションコンテキストを伝播させずにサーバアプリケーションの呼び出しを行い ます。NonTxTargetPolicy をPREVENT に設定した場合、トランザクションが開始されていると CORBA::INVALID_TRANSACTION 例外が発生します。
オブジェクトはトランザクション内でもトランザクション外でも動作できることを示します。クライアント でトランザクションが開始されていればトランザクションコンテキストを伝播し、トランザクションが開 始されていなければトランザクションコンテキストを伝播せずにサーバアプリケーションを呼び出しま す。OTS 1.1 のCosTransactions::TransactionalObject を呼び出す場合はOTSPolicy がADAPTS で あるものとみなして動作します。
ルートPOA や明示的にOTSPolicy を設定しない子POA のOTSPolicy はFORBIDS として動作します。OTS 1.2 ではサーバアプリケーションはCosTransactions::TransactionalObject を継承していてもトランザクションとして は動作しませんが、オブジェクトマネージャへの登録時にADAPTS を設定することでOTS 1.1 のアプリケーショ ンをそのまま動作させることができます。クライアントアプリケーションはOTSPolicy が設定されていないサー バアプリケーションを呼び出す場合CosTransactions::TransactionalObject を継承しているかチェックを行い伝 播するため、OTS 1.1 に対する互換性は保証されます。
Transaction サービスでは、トランザクションを終了する場合、次の2種類のコミットメント制御を使用します。
トランザクションに参加しているリソースが1つの場合は、そのリソースに対して即座にコミットを要 求します。
トランザクションに参加しているリソースが複数の場合は、リソース全体のコミットを実施します。この 際にトランザクションの終了処理は次の2つのフェーズに分けて行います。
トランザクションに参加している全リソースに対してプリペアを要求します。リソース側ではこれを要 求されると、アクセスしたデータを更新可能であり、トランザクションをコミットできるかどうかを通知し ます。リソースのうちのいずれかがコミット不可能であると通知してきた場合、自動的にトランザクショ ンはロールバックします。
第1フェーズの結果に基づいて、トランザクションのコミットあるいはロールバックを全リソースに対し て要求します。
トランザクションに参加したリソースが単一か複数かを判断してWebOTX が自動的に必要となるコミットメント制 御を行いますので利用者は意識する必要がありません。
Transaction サービスは、X/Open 分散トランザクション処理にしたがってデータベースをサポートします。 X/Open 分散トランザクション処理では、トランザクションサービスを提供する部分をトランザクションマネージ ャ、データベースなど永続的なリソースを提供する部分をリソースマネージャと呼びます。トランザクションマネ ージャとリソースマネージャとのインタフェースはXA インタフェースと呼ばれるインタフェースが使われます。
Transaction サービスは、トランザクションマネージャとして以下のXA インタフェースをサポートするデータベー スなどと協調してトランザクションとして動作します。
Transaction サービスは、X/Open 分散トランザクション処理にしたがって次の2つのトランザクションをサポート します。
トランザクションサービスの制御の元にあるトランザクションで、ネットワーク上全体としてコミットまた はロールバックされます。
トランザクションサービスでの制御とは独立に、コミット、ロールバックを行うトランザクションです。ロ ーカルトランザクションを完了させるためには、SQLのCOMMIT文またはROLLBACK文を使用する 必要があります。
グローバルトランザクション内でローカルトランザクションを行うと、ネスティッドトランザクションのように一部分 だけ全体のトランザクションの結果に独立したデータの更新ができます。ネスティッドトランザクションと異なる のは、コミット制御も独立に行うことができる点です。
XAインタフェースにおいて基本となる概念にトランザクションブランチがあります。トランザクションブランチと は、各スレッドおよびリソースマネージャ上に生成されるリカバリの最小単位です。例えば、1つのトランザクシ ョン内で複数のアプリケーションスレッドが連携して動作する場合、スレッドごとにトランザクションブランチが生 成されます。トランザクションブランチは、アプリケーションがトランザクション処理を実行する前にそのスレッド 上で開始され、アプリケーションがトランザクション処理を終了後にそのスレッド上で終了します。トランザクショ ンブランチを開始・終了することで、トランザクションマネージャはリソースマネージャに対してリカバリの対象と なるトランザクション処理の範囲を示します。
Transaction サービスは、サーバオブジェクトの呼び出しと戻りで、自動的にトランザクションブランチの開始お よび終了を行います。また、トランザクションの開始、終了時にも自動的にトランザクションブランチの開始およ び終了を行います。
トランザクションブランチを識別するためにトランザクション識別子が使われます。
トランザクション識別子は、OTS(JTS)とXA インタフェースでは形式が異なりますが、基本的にはフォーマット識 別子、グローバルトランザクション識別子、ブランチ識別子の3つからなります。フォーマット識別子はトランザ クションサービス/トランザクションマネージャを識別するコードです。グローバルトランザクション識別子はグロ ーバルトランザクションを識別するバイト列です。ブランチ識別子はトランザクションブランチを識別するバイト 列です。
密結合とは、1つのグローバルトランザクション内の複数のトランザクションブランチがデータベースの同一エン トリを更新することを認めるものです。
逆に、同一エントリの更新を認めない動作を疎結合と呼びます。提供される結合度についてはデータベースに 依存します。
最も強力な密結合は、トランザクションブランチが別のプロセスや別のマシンの場合でも、同一エントリの更新 を認めます。密結合はトランザクション識別子のブランチ識別子を同一にしてデータベースにアクセスすること で実現します。
Transaction サービスでは、同一のグローバルトランザクション内で同一のオブジェクトに対する複数のメソッド 呼び出しは密結合として動作させます。異なるオブジェクトや異なるプロセス、マシンへの呼び出しは疎結合と して動作させます。分散トランザクションで複数のマシン、複数のプロセスで同一のデータベースエントリを更 新することは、データベース破壊などの危険な状況を起こしやすいので、これを避けるためにこのような制御を 採用しています。
トランザクションマネージャは、一般に、アプリケーションが接続しているデータベースすべてに対してトランザ クションブランチを開始します。
これを静的登録と呼びます。この場合、トランザクションマネージャは、どのデータベースへのアクセスが行わ れるかを判断できないため、実際にはアクセスされないデータベースが存在しても、すべてのデータベースでト ランザクションブランチを開始してしまいます。この場合無駄なトランザクションブランチも開始することになりま す。
そこでリソースマネージャがアプリケーションからデータベースにアクセスがあった場合にのみ、トランザクショ ンブランチを開始する方法があります。これを動的登録と呼びます。動的登録が行われると、本当に必要なデ ータベースに対してのみトランザクションブランチが開始され、コミットプロトコルに参加するようになるので、無 駄がなくなります。
Transaction サービスは、静的登録、動的登録どちらにも対応していますので、データベース側が動的登録を サポートしていれば、効率のよいトランザクションを実行することができます。
Transaction サービスは、データベースをデータベース識別名により一意に識別しています。C++で使用するデ ータベース識別名は、データベースの種類を示すリソースタイプとオープン文字列、クローズ文字列を代表す る名前です。また、Java で使用するデータベース識別名は、接続文字列やユーザ名といったJDBC データソー スのプロパティ情報に対応してデータベースに接続する際のコネクション情報に対応する名前です。
Transaction サービスでは、ACOS Access Toolkit(AAT)が提供するJDBC ドライバと連携することで、本来は2 フェーズコミットメントをサポートしていないACOS 上のトランザクションをWebOTX が管理する2フェーズコミッ トメントトランザクションに参加させることができます。
それを実現するために、Transactionサービスでは、ACOS上のデータベースを管理するために使用する「1フェ ーズコミット対応リソース」を実装しており、ここからAAT提供のJDBCドライバを経由してデータベースの更新 処理を行います。
Transaction サービスでは、同一グローバルトランザクションへの、1つの1フェーズコミット対応リソースと、任 意の数の2フェーズコミット対応リソース(従来からTransaction サービスが提供するデータベースアクセス用の リソース)の登録ができるようになっています。
つまりこれによってACOS 上のデータベースと、オープンサーバ上のデータベース(Oracle など)の同時更新が 可能になります。
なお、本来であれば1フェーズコミットメントでの動作を前提としているものを2フェーズコミットメントトランザク ションに参加させているため、いくつかの制限、および運用操作上の注意事項を設けています。それらの詳細 については、 [ 構築・運用 > ドメインの拡張機能 > Transactionサービス] をご参照ください。
Transaction サービスでは、アプリケーションがネットワーク上のどこにあるかを意識する必要はありません。ネ ットワーク上の最適な位置にアプリケーションを再配置することができます。従って、Transaction サービスを使 うと、1台のサーバで集中して処理を行う集中型のシステムや複数サーバ・クライアントが協調して処理を行う 分散型のシステムなど、さまざまな業務形態に合わせたシステムを構築することができます。
Transaction サービスを使ったトランザクションシステムの構成は基本的に、「サーバトランザクションモデル」 「クライアントトランザクションモデル」、およびこれらを組み合わせた「複合形態モデル」に分けられます。
「CORBA Service (98-12-09)」にしたがっています。イベントサービスは、イベントチャネルオブジェクトを媒介と して、any 型のデータを1イベントとする非同期通信を提供します。データの供給側(サプライア)、データの消費 側(コンシューマ)とも、プル型とプッシュ型のデータ交換が可能です。プッシュ型では、供給者がクライアントと なり、消費側オブジェクトを呼び出します。プル型では、消費者がクライアントとなり、供給側オブジェクトを呼び 出します。なお、イベントチャネルを介して通信しますので、供給者、消費者でプッシュ型、プル型を混在させて 使用することができます。
Persistent State Service (PSS) は CORBA サーバアプリケーション開発者のためのサービスです。アプ リケーションを構成する Servant から Datastore domain (データベースなど)にアクセスするために利用 するインタフェースinternal interface を提供します。
WebOTX ではPersistent State Service 2.0 仕様に準拠したデータベースを利用するサーバアプリケーシ ョンの開発環境を提供します。
WebOTX が提供するCORBA 実行環境であるWebOTX Object Broker が提供する機能について説明し ます。
Portable Object Adapter (POA)は、CORBA 2.2 で追加された標準的なオブジェクトアダプタであり、サー バアプリケーションのポータビリティを実現します。
POA の主な機能は、CORBA オブジェクトとサーバントのライフサイクルを管理し、クライアントからのオブ ジェクトに対する呼び出しを適切なサーバントにディスパッチすることです。サーバントとは、CORBA オブ ジェクトを実装したC++やJava などの言語上のオブジェクトのことです。
それまでのBOA と大きく異なる点は、複数のCORBA オブジェクトをひとつのサーバントに対応付けるこ とができることです。例えば、データベースの個々のデータに対応する膨大な数のCORBA オブジェクト をひとつのサーバントで処理させることが可能になります。
要求をシングルスレッドで処理させるか、ORB に依存したマルチスレッドで処理させるかを設定します。
ORB_CTRL_MODEL の場合にWebOTX Object Broker が提供するマルチスレッドについて説明します。
C++版: 次の3つのスレッド処理を選択できます。
選択は、プログラムで設定するか、レジストリやファイルまたは環境変数で行う方法があります。
Java 版: 次の2つのスレッド処理を選択できます。
選択は、プログラムで設定するかプロパティやファイルで行う方法があります。
これらの設定方法の詳細については、
[ 構築・運用 >
設定 >
Object Broker >
Object Broker設定項目・設定方法 ]、
または、
[ アプリケーション開発 >
CORBA アプリケーション >
プログラミング・開発ガイド >
Object Broker ]
をごらんください。
CORBA オブジェクトを一時オブジェクトとして作成するか、永続オブジェクトとして作成するかを設定 します。
PERSISTENT の場合、CORBA オブジェクトを作成して、その後サーバプロセスを停止・再起動して も、クライアントは同じリファレンスで引き続き同じオブジェクトにアクセスすることができます。
CORBA オブジェクトのオブジェクトID をアプリケーションで割り当てるか、ORB で自動的に割り当て るかを設定します。
オブジェクトID をデータベースアクセスのキーとして使用する場合など大量のオブジェクトに1つの サーバントを割り当てるときには、USER_ID を使用します。
CORBA オブジェクトとサーバントの対応付けを1対1とするか、多対1とするかを設定します。
MULTIPLE_ID を設定する典型的なケースは、後述するデフォルトサーバントを使用する場合です。
Active Object Map (AOM) を使用するか否かを設定します。AOM とは、CORBA オブジェクトとサー バントの対応付けを管理する対応表です。
NON_RETAIN を選択するには、後述するサーバントマネージャを作成して、アプリケーション自ら対 応付けを行うか、デフォルトサーバントを使用することになります。このほかにも、RETAIN を選択し てサーバントマネージャかデフォルトサーバントを実装することもできます。
クライアントからの要求をどのサーバントにディスパッチするかを設定します。
USE_DEFAULT_SERVANT でもUSE_SERVANT_MANAGER の場合でも、ServantRetainPolicy に RETAIN が設定されているときには、まずAOM でサーバントを検索し、見つからない場合にだけデ ィスパッチします。
暗黙的な活性化を行うか否かを設定します。
NO_IMPLICIT_ACTIVATION を選択する場合、POA::activate_object() や POA::activate_object_with_id()により明示的に活性化しなければなりません。
IMPLICIT_ACTIVATION を選択する場合、まだ活性化されていないサーバントでも、 POA::servant_to_reference()やPOA::servant_to_id()の呼び出しのタイミングで 暗黙的に活性化され、オブジェクトリファレンスやオブジェクトID が返されます。
ORB はすべて既定値のPOA ポリシーをもつrootPOA を提供しています。RootPOA は、 ORB::resolve_initial_references("RootPOA")オペレーションで取得できます。
アプリケーションが独自のPOA ポリシーを持ったPOA を必要とする場合には、rootPOA を基点として階層 的に自由に生成(POA::create_POA)することができます。
図中にあるPOA マネージャ、サーバントマネージャ、アダプタアクティベータ、そしてデフォルトサーバント について簡単に説明します。
POA マネージャは、POA に対するクライアントからの要求の流れを制御する管理オブジェクトで す。4つの状態があり、POA マネージャに対するオペレーション、
により状態が遷移します。
デフォルトのPOA マネージャはrootPOA にあらかじめ関連付けられており、独自のPOA を生成 する際にPOA::create_POA()の引数にそのPOA マネージャを引き継ぐか、引き継がずに新 たなPOA マネージャを関連づけるかを選択することができます。POA マネージャを分けることに より、いくつかのPOA をグループ化して制御することができます。
サーバントマネージャとは、アプリケーション側でCORBA オブジェクトとサーバントの対応付けを 行うもので、サーバントアクティベータとサーバントロケータの2種類があります。 サーバントアクティベータを使用するには、以下の2つのポリシーが必須となります。
クライアントから要求を受けると、まずAOM を検索し、見つからない場合にのみサーバントアクテ ィベータを呼び出します。サーバントアクティベータが対応するサーバントをPOA に返すと、AOM に登録されて以降の同じオブジェクトに対する要求のディスパッチはAOM の情報で解決されま す。サーバントアクティベータは、ServantActivator インタフェースで定義されている incarnate()とetherealize()を実装しなければなりません。
一方、サーバントロケータを使用するには、以下の2つのポリシーが必須となります。
AOM を使用しないため、クライアントからの要求ごとに呼び出され、サーバントをPOA に返しま す。サーバントロケータは、ServantLocator インタフェースで定義されているpreinvoke() とpostinvoke()を実装しなければなりません。
サーバントアクティベータもサーバントロケータも、登録はPOA::set_servant_manager() で行います。
デフォルトサーバントとは、あるPOA のすべてのCORBA オブジェクトに対する要求をひとつのサ ーバントで処理する場合に使用します。この場合、以下の2つのポリシーが必須となります。
ServantRetentionPolicy を変えることによって、全ての要求をデフォルトサーバントで処理する か、AOM にない場合にだけデフォルトサーバントで処理するかを選択できます。デフォルトサー バントの実装の中でCORBA オブジェクトに依存した処理を行うためには、呼び出しの延長で POACurrent オブジェクトをORB::resolve_initial_references("POACurrent")を 使用して取得します。そして、PortableServer::Current::get_object_id()で対応 するオブジェクトID を取得します。デフォルトサーバントの登録は、 Portable::POA::set_servant()で行います。
最後にCOBRA オブジェクトの数に応じたサーバタイプについて説明します。
オブジェクトの数が多く、実際にはそのうちの少数しか利用されないケースでは、全てのオブジェ クトをあらかじめ活性化しておくよりも、必要時に活性化を行いAOM に登録するという、AOM と サーバントアクティベータ併用のパターンが適しています。
ただし、このパターンでは、一度活性化されたオブジェクトはAOM に登録されるため、利用される オブジェクトが多くなると最終的にAOM だけを使用するパターンと同様にメモリの問題が懸念さ れます。このような場合には、サーバントロケータを使用して、対応付けをアプリケーション側で 完全に制御し、オブジェクトをキャッシュして管理するような仕組みを実装します。
デフォルトサーバントを使用すると全てのオブジェクトをひとつのサーバントで対応するためオブ ジェクトの数に依存せずにスケーラブルに対応できます。これは、データベースのキーをオブジェ クトID に対応づけるようなシステムに最適です。
WebOTX Object Broker は、POA ポリシーの組み合わせで実現できるいろいろなサンプルプログラ ムが用意しています。内容については、サンプル集をごらんください。
動的起動インタフェースDII は、IDL コンパイラが生成するスタブ・スケルトンを使用せずに、実行時に動 的に要求を組み立ててオブジェクトを呼び出す機能です。
CORBA 2.4 で追加された仕様についてはサポートしていません。
一般的には、次のようなケースで利用します。
DII では、クライアントは次のような手順でサーバ呼び出しを行います。
不特定のオブジェクトを扱うような場合には、インタフェース情報をインタフェースリポジトリに登録してお き、そこから取得した情報をRequest オブジェクトの作成に使用します。
要求の発行には、4つの方法があります。
サーバに要求を送信して応答を待ち合わせます。
サーバに要求を送信するだけで応答を待ち合わせません。
要求の送信と応答の受信を非同期に行います。
oneway もしくは遅延同期オペレーションによる複数の要求を同時に送信します。
Request やNVList の生成および発行方法については、[ アプリケーション開発 > CORBA アプリケーション ]をご覧ください。
動的スケルトンインタフェースDSI は、IDL コンパイラが生成するスケルトンを使用せずにサーバ処理を 実装し、クライアントからの要求を動的に処理する機能です。とくにインタフェースに依存しないサーバ処 理を実装する場合に必要となります。
DSI では、サーバは次のような手順でクライアントからの要求処理を行います。
ServerRequest やNVList の生成および発行方法については、[ アプリケーション開発 > CORBA アプリケーション ]をご覧ください。
DII のRequest オブジェクトとDSI のServerRequest オブジェクトは、共にオペレーションの引数情 報を保持するために同じNVList オブジェクトを使用しています。このため、クライアントからの要求を DSI で受け取り、その引数をそのままDII でサーバに要求を発行するようなゲートウェイプログラムの実 装にも利用することができます。後述するDynamicAny やインタフェースリポジトリを使用して、特定のイ ンタフェースに依存しない処理を実装することもできます。
DynamicAny は、実行時にIDL コンパイラが生成するコードを使用せずに動的にany 型を扱う機能です。
CORBA 2.2 で最初に追加されましたが、CORBA 2.3 で大きく仕様が変更されています。WebOTX Object Broker Java(TM)は、CORBA 2.3 の仕様をサポートしています。
DynamicAny を使用することにより、次のことが可能になります。
例として、次のようなIDL 型を動的に扱う場合について説明します。
// IDL
struct MyStruct {
long member1;
boolean member2;
}
このような構造体(MyStruct)を動的に生成してany に格納するには、次のような手順で行います。
ORB::resolve_initial_references("DynAnyFactory")
ORB::create_struct_tc()
DynAnyFactory::create_dyn_any()
DynStruct::insert_long() // member1 の設定 DynStruct::next() // 次のメンバへの位置付け DynStruct::insert_boolean() // member2 の設定
DynStruct::to_any()
逆にany に格納されたMyStruct からmember2 の値を取り出すには、次のような手順で行います。
ORB::resolve_initial_references("DynAnyFactory")
DynAnyFactory::create_dyn_any()
DynStruct::next() // 次のメンバへの位置付け DynStruct::get_boolean() // member2 の取得
以上のように、IDL コンパイラが出力する支援コード(Java マッピングの場合はHelper やHolder を指す) を使用する必要がありません。
Interceptor は、CORBA 2.3 で追加されたクライアントとCORBA オブジェクトとの間の呼び出しルートにお いて割り込み処理を実現する機能です。リクエストレベルとメッセージレベルの割り込み処理を実装して リクエストの引数を変更したり、メッセージを変更したりすることができます。CORBA サービス(例えばセ キュリティのアクセス制御)をプラグイン的に実装するような用途としても考えられています。ただし、この 仕様にはあいまいな部分(例えば、native 型で宣言されながら各言語マッピングにはそれが定義され ていない）が存在します。また、既にCORBA 2.5 で全く新しい仕様に変わることが分かっています。
WebOTX Object Broker の将来のバージョンではこの新しい仕様をサポートする予定ですが、従来から 提供しているWebOTX Object Broker 独自のフック機能が現バージョンでは利用できます。
フック機能は、Interceptor と同様のリクエストレベルとメッセージレベルに加えて、応答送信完了時に呼 び出されるフックやクライアントとサーバ間のコネクション切断時に呼び出される、サーバ側のフックを登 録できます。
Objects by Value は、CORBA 2.3 で追加されたオブジェクトの値渡しを実現する機能です。
Value は、interface とstruct 定義の中間に位置し、オペレーションやメンバを定義することができ ます。valuetype というIDL キーワードを使用して定義します。
// IDL
valuetype Names {
public Names next;
private string name;
private string kind;
public Names oya;
void print();
};
interface と異なるのは、interface の場合はそのオブジェクトリファレンスが渡される(参照渡し)の に対し、valuetype の場合にはそのコピーが渡される(値渡し)ことになります。そのため、オブジェクト に対するオペレーションはローカルな呼び出しとなり、メンバの値変更も、ローカルなオブジェクトに閉じ た変更となります。
struct と異なるのは、継承・再帰定義が可能であることと、共有とnull の概念をサポートしている点で す。これにより、送信元の再帰的なリストや木構造をそのままのイメージで送信先に渡すことが可能にな ります。
一般的に、値渡しには通信コストがかかります。Value オブジェクトのメンバ情報をシリアライズして転送 するためです。しかし、以降のオブジェクトへの呼び出しは全てローカルなものになるため、逆に通信コ ストはかかりません。その反面、値渡しされたValue オブジェクトに対してのアクセスとなるため、サーバ 側での更新が反映されないことになります。Value オブジェクトは、このような特性をよく理解して利用す ることが必要です。
Value Box は、メンバを一つだけ持つValue のことです。
// IDL valuetype Name string;
とくに有効なstring とwstring については、標準で次の定義をサポートしています。
// IDL
module CORBA {
valuetype StringValue string;
valuetype WStringValue wstring;
}
あるオペレーションの引数に、メンバにstring 型のデータをもつstruct が多数リンクされており、か つそのデータが全て同じ文字情報を持っているような場合、通常その個数分シリアライズされて送信さ れ、送信先では異なるstring 型のデータとして復元されてしまいます。しかし、string 型の代わりに Value Box であるStringValue 型を使用すると同じ文字情報は最初のものだけがシリアライズされ、 残りはすべてそこを参照する形でシリアライズされます。送信先においても、ただひとつの文字情報が復 元されます。このように、共有の概念をプリミティブな型においても取り入れることが可能になります。
Abstract Interface は、あるオペレーションの引数にオブジェクトを指定する場合に、Value として渡すか、 interface のオブジェクトリファレンスとして渡すかを、IDL 定義時ではなく、実際の呼び出しの時点で決定 する仕組みを提供します。
abstract interface というIDL キーワードを使用して定義します。
// IDL
abstract interface Print {
void print_op();
};
例えば、次のようなケースで利用することができます。
RMI over IIOP は、CORBA 2.3 で追加された、Java 特有の機能です。
Java では分散オブジェクトプログラミングを可能にするRemote Method Invocation (RMI)が標準でサポー トされていますが、CORBA で作成されたプログラムと通信することができません。RMI over IIOP は、 RMI で作成されたプログラムのインタフェースを変更することなく、CORBA の標準プロトコルであるIIOP を使って実行する機能です。これにより、RMI と CORBA の相互運用性を実現できます。
WebOTX Object Broker Java(TM)は、EJB の実行基盤としてサポートしています。
WebOTX Object Broker でのCORBA アプリケーションの起動方法には、クライアントの呼び出しによりサ ーバプロセスが自動的に起動される「自動起動」とクライアントの呼び出しを実行するまえにあらかじめ サーバプロセスを立ち上げておく「手動起動」とがあります。自動起動は次のoadj (Java) およびoad (C++)により行われます。
oad は呼び出しが発生した時点で該当するサーバプロセスが立ち上がっていない(応答が極端に低下し た場合も含みます)ときに、サーバプロセスを自動的に立ち上げます。このとき、立ち上げを許可するファ イル名をexeallow ファイルにあらかじめ記述しておく必要があります。このほか、特定のファイルの実行 を不可能にする設定ファイルや、特定ホストからの要求のみ自動起動を可能にする設定などがありま す。詳しくは、 [ 構築・運用 > 設定 > Object Broker > Object Broker C++における環境設定 ]をごらんください。
oadj による自動起動を行うためには、instimpl コマンドでサーバプロセスを起動するためのコマンドイメー ジを登録しておく必要があります。自動起動を行う場合のオブジェクトリファレンスは、POA の LifespanPolicy をPERSISTENT に設定して作成します。
詳しくは、 [ 構築・運用 > ドメインの拡張機能 > Object Broker > Object Brokerの運用操作 ]、 または、 [ アプリケーション開発 > CORBA アプリケーション > プログラミング・開発ガイド > Object Broker ] をごらんください。
CORBA の各バージョンの主な追加機能とWebOTX Object Broker での対応状況は次の表のとおりです。
| CORBAバージョン | 機能 | WebOTX Object Broker | |
|---|---|---|---|
| Java | C++ | ||
| CORBA 2.0 | GIOP/IIOP 1.0 | ○ | ○ |
| インタフェースリポジトリ | ○ | ○ | |
| DII | ○ | ○ | |
| CDR | ○ | ○ | |
| CORBA 2.2 | GIOP/IIOP 1.1 | ○ | ○ |
| POA | ○ | ○ | |
| コードセット | ○ | ○ | |
| DSI | ○ | ○ | |
| DynamicAny | ○ | × | |
| longlong型 | ○ | ○ | |
| long double型 | - | ○ | |
| fixed型 | ○ | ○ | |
| CORBA 2.3 | GIOP/IIOP 1.2 | ○ | ○ |
| Objects by Value | ○ | ○ | |
| RMI over IIOP | ○ | - | |
| CORBA 2.5 | Portable Interceptors | ○ | ○ |
| CORBA 2.6 | IIOP over SSL | ○ | ○ |
| CSIv2 | ○ | ○ | |
また、開発言語と作成するアプリケーションの対応状況は次の表のとおりです。
| 言語 | クライアントアプリケーション | サーバアプリケーション |
|---|---|---|
| Java | ○ | ○ |
| C++ | ○ | ○ |
| Visual Basic(*1) | ○ | - |
| COBOL(*2) | - | ○ |
| Holon(*3) | ○ | ○ |
*1: CORBA ゲートウェイ、EJB ゲートウェイ(WebOTX Client、WebOTX Download Contents、WebOTX Application Server Standard + Extended Option に添付) を使用
*2: Open COBOL Factory 21(別途購入要)を使用
*3: HolonEnterprise (別途購入要)を使用