|
|
WebOTX Manual V10.1 (第7版) 目次を表示 |
|
|
|
WebOTX Manual V10.1 (第7版) 目次を表示 |
ここでは、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 の名前サーバに登録したり、他社製の名前サーバへオブジェ クトの登録、参照をしたりすることができます。
セキュリティを実現するサービスとして、次の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 の各バージョンの主な追加機能と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 Application Server Enterprise に添付) を使用
*2: Open COBOL Factory 21(別途購入要)を使用
*3: HolonEnterprise (別途購入要)を使用