次の各項では、Oracle Tuxedoのプログラミング環境の概要を示します。
Oracle Tuxedoシステムは、メッセージベースの通信および(必要に応じて)分散トランザクション処理を使用して、アプリケーションを複数のプラットフォーム、データベースおよびオペレーティング・システムに分散する
ミドルウェア製品です。
ミドルウェアをクライアント/サーバー・アプリケーションとともに使用することにより、複数のサーバー間で処理を分散したり、分散トランザクションを管理したり、複数のデータベース・プラットフォームを統合することができます。ミドルウェア・システムは、オンライン・トランザクション処理(OLTP)システムと呼ばれることもあります。
Oracle Tuxedoシステムは、AT&T、UNIX System Laboratories (USL)、Novell、Oracle Systemsなどのテクノロジ企業のグループが20年以上の年月をかけて開発した完成度の高い製品です。これは、開発プラットフォームであると同時に実行プラットフォームでもあります。Oracle Tuxedoシステムは、オペレーティング・システムの拡張要素として機能します。
Oracle Tuxedoシステムには、次のような特徴があります。
|
•
|
異種のクライアント/サーバー環境において分散オンライン・トランザクション・アプリケーションの作成および集中管理を行うための業界標準。 |
|
•
|
アプリケーション開発者にとっての使いやすさ。サーバーの場所、ルーティングまたは使用プラットフォームのすべての詳細を把握する必要がありません。Oracle Tuxedoアプリケーションでは、プログラムのこれらの局面は透過的です。 |
|
•
|
信頼性が高く、パフォーマンスに優れ、管理しやすい分散システムを作成、管理および保守するための基盤。 |
Oracle Tuxedoシステムには、ATMIアプリケーションのアーキテクチャに関する局面に対応する多数の機能が用意されています。
|
•
|
分散サービス: 異なるハードウェア・プラットフォーム上に存在するアプリケーション・サービスやシステム・サービスに透過的にアクセスできます。
|
|
•
|
高速なコネクションレス型通信: クライアントはサーバーではなく掲示板に接続されるため、システムのパフォーマンスが向上します。
|
|
•
|
サーバーの透過性: 掲示板のサービス・ディレクトリによってサービス名がサーバーにマッピングされるため、クライアントがサーバーIDを認識する必要はありません。
|
|
•
|
スケーラビリティ: サービスおよびサーバーのレプリケートおよび配布が簡単なので、アプリケーション設計者はシステム・ロード需要の変化に対応して素早くOracle Tuxedoアプリケーションをスケーリングできます。設計者は、Oracle Tuxedoシステムで新規サーバーの自動生成やサーバーの自動停止が行われるように、プログラムでしきい値を設定できます。
|
Oracle Tuxedoシステムには、ATMIアプリケーションの管理に関する局面に対応する多数の機能が用意されています。
|
•
|
パスワード・セキュリティおよびアクセス制御セキュリティ: パスワード・セキュリティにより、アプリケーション設計者は、初期化の際にパスワードを要求すること(認証)によってアクセスを制御できます。認可は、特定のアプリケーション・サービスへのアクセスを制限する手段であり、明示的な権限を付与され認証済のIDを持つクライアントのみがサービスにアクセスできるため、さらなる制御が可能になります。
|
|
•
|
アプリケーション固有イベントおよびシステム・イベントの通知: Oracle Tuxedoシステムでは、サーバーの予期しない停止やネットワーク障害などのアプリケーション・イベントおよびシステム・イベントに関する詳細が提供されます。クライアントまたはサーバーによってイベントがポストされると、Oracle Tuxedoのパブリッシュ・アンド・サブスクライブ・コンポーネントがそのイベントのすべてのサブスクライバをルックアップし、各サブスクリプションで指定されている適切なアクションを実行します。
|
|
•
|
管理情報ベース(MIB): 管理者が独自のプログラムによってアプリケーションのモニター、構成およびチューニングを行うことができる管理用インタフェース。これは、フィールド操作言語(FML)属性のセットとして定義されている実装に依存しない管理データベースであり、管理者による情報の問合せまたは変更を可能にします。
|
|
•
|
Webベースの管理: World Wide Webを介してOracle Tuxedoアプリケーションの構成と制御を行うために使用可能なグラフィカル・ユーザー・インタフェース。
|
Oracle Tuxedoシステムには、ATMIアプリケーションのプログラミングに関する局面に対応する多数の機能が用意されています。
|
•
|
通信手法: Oracle Tuxedoシステムのアプリケーション・プログラミング・インタフェース(API)は、X/OpenのXATMIインタフェースのスーパーセットであり、Application-to-Transaction Monitor Interface (ATMI)と呼ばれます。Oracle Tuxedo ATMIには、分散アプリケーションを作成するための通信手法が豊富に用意されています。
|
|
•
|
分散トランザクション処理(DTP): 分散アプリケーション全体で行われる作業をアトミックに完了できます。これは、どのOLTPシステムにも備わっている基本的な特性です。
|
|
•
|
型付きバッファ: 異種プラットフォーム間でアプリケーション・データを透過的に処理できます。
|
|
•
|
X/Open XA準拠: Oracle Tuxedoシステムは、(リソース・マネージャと呼ばれる)トランザクション・データベース・システムに対するX/Openインタフェース標準に準拠しています。このため、アプリケーション設計者はデータの整合性を維持しながら、1つのアプリケーション内で複数のデータベースを混在させ、一致させることができます。
|
|
•
|
X/Open TX準拠: Oracle Tuxedoシステムは、トランザクション・デマーケーションに対するX/Openインタフェース標準に準拠しています。また、Oracle Tuxedoにはトランザクション・デマーケーション用の独自のATMIインタフェースも用意されています。
|
クライアント/サーバー・アーキテクチャにおいては、クライアント(サービスを必要とするユーザーを表すプログラム)とサーバー(サービスを提供するプログラム)はそれぞれ別個の論理オブジェクトであり、ネットワーク上で通信を行い連携してタスクを実行します。クライアントはサービスをリクエストし、そのリクエストに対する応答を受け取ります。サーバーはリクエストを受け取って処理し、必要なレスポンスを送り返します。
クライアント/サーバー・アーキテクチャには、次のような特徴があります。
|
•
|
非対称のプロトコル: クライアントとサーバーの間には、多対1の関係があります。クライアントは常にサービスをリクエストすることによってダイアログを開始します。サーバーは受動的にクライアントからのリクエストを待機します。
|
|
•
|
サービスのカプセル化: サーバーはスペシャリストとして、サービスをリクエストするメッセージを受け取り、そのジョブの実行方法を決定します。サーバーのアップグレードは、サーバーとクライアントの両方で使用されるパブリッシュ済のメッセージ・インタフェースが変更されていないかぎり、クライアントに影響を与えることなく行えます。
|
|
•
|
整合性: サーバーのコードおよびデータは集中管理されるため、メンテナンスのコストが抑えられ、共有データの整合性が保護されます。また同時に、クライアントの個別性と独立性を維持できます。
|
|
•
|
場所の透過性: サーバーは、クライアントと同じマシンまたはネットワーク上の別のマシン上に存在できるプロセスです。通常、クライアント/サーバー・ソフトウェアは、サービス・リクエストをリダイレクトすることによって、サーバーの場所をクライアントから隠蔽します。クライアントがサーバーの場所を認識しなくてもよいようにする必要があります。
|
|
•
|
ネームスペースの透過性: クライアントは、同じ命名規則(およびネームスペース)を使用してネットワーク上のすべてのサーバーを検出できる必要があります。
|
|
•
|
メッセージベースの交換:クライアントとサーバーは、メッセージを使用してサービス・リクエストと応答を交換できる、疎結合のプロセスです。
|
|
•
|
モジュール方式の拡張可能な設計: クライアント/サーバー・アプリケーションはモジュール方式で設計されており、フォルトトレラントにすることができます。フォルトトレラントなシステムにおいては、障害が発生してもアプリケーション全部が停止することはありません。フォルトトレラントなクライアント/サーバー・アプリケーションでは、1つ以上のサーバーに障害が発生しても、障害の発生したサーバーで提供されていたサービスが他のアクティブなサーバー上で使用可能になっているかぎり、システム全体が停止することはありません。モジュール方式のもう1つのメリットは、クライアント/サーバー・アプリケーションが、1つ以上のサービスやサーバーを追加または停止することによって、システム・ロードの増加または減少に自動的に対処できるということです。
|
|
•
|
プラットフォームからの独立性: 理想的なクライアント・サーバー・ソフトウェアがハードウェアやオペレーティング・システムのプラットフォームに依存していないため、クライアントおよびサーバーで異なるプラットフォームを使用できます。異なるオペレーティング・システムを使用する異なるハードウェア上にクライアントおよびサーバーをデプロイできるため、それぞれで実行される処理のタイプを最適化できます。
|
|
•
|
再利用可能なコード: サービス・プログラムを複数のサーバー上で使用できます。
|
|
•
|
スケーラビリティ: クライアント/サーバー・システムは水平または垂直にスケーリングできます。水平スケーリングとは、パフォーマンスにほとんど影響を与えずにクライアント・ワークステーションを追加または削除することです。垂直スケーリングとは、より大型で高速なサーバー・マシンに移行したり、サーバー・マシンを追加することです。
|
|
•
|
クライアント/サーバー機能の分離: クライアント/サーバーとは、同じマシンまたは別のマシン上で実行されるプロセス間の関係です。サーバー・プロセスはサービスのプロバイダです。クライアントはサービスのコンシューマです。クライアント/サーバーでは、機能が明確に区別されます。
|
|
•
|
共有リソース: 1つのサーバーが多数のクライアントに対してサービスを同時に提供し、クライアントから共有リソースへのアクセスを制限できます。
|
2層および3層のクライアント/サーバー・アーキテクチャの違い
すべてのクライアント/サーバー・アプリケーションには、次の3つの機能単位が含まれています。
|
•
|
プレゼンテーション・ロジックまたはユーザー・インタフェース(例: ATMマシン) |
|
•
|
ビジネス・ロジック(例: 顧客が口座残高をリクエストするためのソフトウェア) |
これらの機能単位は、クライアント・プログラムか、アプリケーション内の1つ以上のサーバー・プログラムの一部になります。数多くの可能なバリエーションからどれを選択するかは、アプリケーションを分割する方法や、各層間の通信に使用するミドルウェアによって異なります(次の図を参照)。
2層クライアント/サーバー・アプリケーションにおいては、ビジネス・ロジックはクライアント上のユーザー・インタフェースに埋め込まれているか、サーバー上のデータベース内にストアド・プロシージャの形式で埋め込まれています。また、ビジネス・ロジックをクライアントとサーバーの間で分割することもできます。ストアド・プロシージャを含むファイル・サーバーやデータベース・サーバーは、2層アーキテクチャの例です。
3層クライアント/サーバー・アプリケーションでは、ビジネス・ロジックはデータやユーザー・インタフェースから切り離された中間層に存在します。このように、プロセスをユーザー・インタフェースやデータベースと切り離して管理およびデプロイすることができます。また、3層システムでは、複数のソースからのデータを統合できます。
ニーズに応じたクライアント/サーバーの各種のアーキテクチャ
クライアント/サーバー・アーキテクチャは、次の各状況のニーズに対応できます。
|
•
|
小型の店舗およびラップトップ: クライアント、ミドルウェア・ソフトウェア、およびほとんどのビジネス・サービスが、同じマシン上で動作します。このアプローチは、歯科医院、在宅業務、ラップトップ・コンピュータを多用する出張者などの小規模なビジネスに対して使用することをお薦めします。 |
|
•
|
小規模のビジネスおよび社内の部署: LANベースの単一サーバー・アプリケーションが必要です。このタイプのアプリケーションのユーザーには、複数の医師を擁する病院、複数の部署がある企業、複数の支店を持つ銀行など、小規模のビジネスが該当します。このタイプのアプリケーションでは、複数のクライアントが1つのローカル・サーバーと通信します。セキュリティはマシン・レベルで実装され、障害は容易に検出されるため、管理は単純です。 |
|
•
|
大企業: 様々な機能を提供する複数のサーバーが必要です。高いスケーラビリティを持つ企業ネットワーク、イントラネットおよびインターネットに複数のサーバーを配置できます。サーバーは、機能、リソースまたはデータベースごとにパーティション化でき、またフォルト・トレランスやパフォーマンスを高めるためにレプリケートすることもできます。このモデルは非常に強力で、柔軟性に富んでいます。このクライアント/サーバー・モデルでは、アプリケーションを適切に構成することが重要です。サーバー間で処理を分割したり、他のサーバーに処理を委任するようにサーバーを設計することが必要な場合もあります。 |
クライアント/サーバー・モデルにおけるOracle Tuxedoシステム
Oracle Tuxedoシステムは、クライアント/サーバー・モデルの中間に位置します。Oracle Tuxedoアプリケーションにおいては、クライアントがログインしてサービスをリクエストし、アプリケーションによりそのサービスが提供されます。Oracle Tuxedoシステムは、透過的な掲示板を介してこれらのサービスを提供します。掲示板には、
グローバルなディレクトリ通知サービスがあります。
たとえば、次のサンプル銀行取引アプリケーションでは、掲示板によって預入れ、引出しおよび照会のサービスが通知されています。次にOracle Tuxedoシステムにより、適切な支店または地方の事務所で、リクエストされたサービスを提供できるサーバーが検出されます。
サンプル銀行取引アプリケーションでは、Oracle Tuxedoアプリケーションの主要なビルディング・ブロックが示されています。
|
•
|
クライアント: ユーザーからの入力を収集し、Oracle Tuxedoシステムからサーバーにリクエストを送信して、サーバー応答をユーザーに送信するプログラム。
|
|
•
|
サーバー: アプリケーションを定義するサービスのセット内にビジネス・ロジックをカプセル化するプログラム。
|
|
•
|
ミドルウェア: クライアントとサーバーの間の対話をサポートするために必要なすべての分散ソフトウェアが含まれます。これは、クライアントがサーバーからサービスを取得できるようにする媒体となります。ミドルウェアには、(1)クライアントがリクエストの発行とレスポンスの受信に使用し、サーバーがレスポンスの発行に使用するAPI関数と、(2)クライアント・リクエストとサーバー・レスポンスをネットワーク経由で送信するために使用されるメッセージング・パラダイムが含まれます。ミドルウェアには、クライアントのユーザー・インタフェース、アプリケーション・ロジック、またはサーバーにより提供されるサービスは含まれません。
|
Oracle Tuxedoのサンプル銀行取引アプリケーションにおいては、クライアント(現金自動預け支払い機)がリクエストを発行し、(支店および出張所の)サーバーがサービスおよびレスポンスを提供します。たとえば、顧客は現金自動預け支払い機を使用して、当座預金口座の利用可能金額を調べることができます。現金自動預け支払い機(クライアント)はサーバーをコールして残高を取得します。サーバーはリクエストを受け取って残高を取得し、その情報を現金自動預け支払い機に送信します。
クライアントとは、ユーザーからリクエストを収集し、そのリクエストを実行できるサーバーに渡すプログラムです。クライアントは、アプリケーションのフロントエンドの一部としてPCまたはワークステーションに配置できます。また、クライアントをATMマシンなどの通信装置を読み取るソフトウェアの中に埋め込むと、このような通信装置からデータを収集してフォーマットした後、Oracle Tuxedoサーバーによって処理することができます。
プログラムがクライアントになるためには、アプリケーション・トランザクション・モニター・インタフェース(ATMI)と呼ばれるOracle Tuxedoの関数およびプロシージャのライブラリを起動できることが必要です。ATMIは、複数の言語バインディングでサポートされています。
クライアントは、ATMIクライアント初期化ルーチンをコールすることによってOracle Tuxedoアプリケーションに参加します。アプリケーションに参加したクライアントは、トランザクション境界を定義したり、アプリケーション内の他のプログラムと通信するためのATMI関数をコールできるようになります。クライアントは、ATMI終了関数を発行することによってアプリケーションから分離します。クライアントは、必要なときにのみアプリケーションに参加し、適切なタスクが完了した時点でアプリケーションから分離することにより、他のクライアントおよびサーバーが使用できるようにOracle Tuxedoシステムのリソースを解放します。
分散アプリケーションを構築するときは、処理対象の情報をどのようにして収集して提供するかを決定する必要があります。ATMI関数をコールする場所やタイミングは、ビジネス・ロジックおよびビジネス・ルールに基づいて自由に制御できます。プログラムは、あるOracle Tuxedoアプリケーションに参加し、いくつかのタスクを実行してそのアプリケーションから分離した後、別のOracle Tuxedoアプリケーションに参加して別のタスクを実行することができます。マルチコンテキスト・アプリケーションを使用している場合、クライアントはどのアプリケーションからも分離せずに、複数のアプリケーションでタスクを実行できます。
Oracle Tuxedoサーバーは、一連のサービスを監督するプロセスで、サービスをリクエストするクライアントに対して自動的にディスパッチします。また、サービスはビジネスに必要な特定のタスクを実行するサーバー・プログラム内の機能です。たとえば、とある銀行には預金を受け入れるサービスと口座残高を報告するサービスがあるとします。この銀行のサーバーは、両方のサービスに対するクライアントからのリクエストを受信します。サーバーは、各リクエストを適切なサービスにディスパッチする責任を負います。
サービス関数は、SQLなどのデータベース・インタフェースへのコールを介してビジネス・ロジックを実装し、場合によってはATMIへのコールを介して他のサービス、キューおよびその他のリソースにアクセスします。これらのサービスが配置されているサーバーは、クライアントに応答するか、クライアント・リクエストを新しいサービスに送信します。
Oracle Tuxedoシステムによって提供されるアプリケーション処理サービス
Oracle Tuxedoシステムに用意されているサービスを使用すると、アプリケーション開発者は次の機能をアプリケーションに実装できます。
Oracle Tuxedoシステムによって提供される管理サービス
Oracle Tuxedoシステムには、アプリケーション管理者が次の管理タスクを実行するためのサービスが用意されています。
