Comments
Description
Transcript
BEA Tuxedo システム入門
BEA Tuxedo BEA Tuxedo システム入門 BEA Tuxedo リリース 7.1J 7.1 版 2000 年 9 月 Copyright Copyright © 2000 BEA Systems, Inc. All Rights Reserved. Restricted Rights Legend This software and documentation is subject to and made available only pursuant to the terms of the BEA Systems License Agreement and may be used or copied only in accordance with the terms of that agreement. It is against the law to copy the software except as specifically allowed in the agreement. This document may not, in whole or in part, be copied photocopied, reproduced, translated, or reduced to any electronic medium or machine readable form without prior consent, in writing, from BEA Systems, Inc. Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the BEA Systems License Agreement and in subparagraph (c)(1) of the Commercial Computer Software-Restricted Rights Clause at FAR 52.227-19; subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013, subparagraph (d) of the Commercial Computer Software--Licensing clause at NASA FAR supplement 16-52.227-86; o their equivalent. Information in this document is subject to change without notice and does not represent a commitment on the part of BEA Systems. THE SOFTWARE AND DOCUMENTATION ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. FURTHER, BEA Systems DOES NOT WARRANT, GUARANTEE, OR MAKE ANY REPRESENTATIONS REGARDING THE USE, OR THE RESULTS OF THE USE, OF THE SOFTWARE OR WRITTEN MATERIAL IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. Trademarks or Service Marks BEA, ObjectBroker, TOP END, and Tuxedo are registered trademarks of BEA Systems, Inc. BEA Builder, BEA Connect, BEA Manager, BEA MessageQ, BEA Jolt, M3, eSolutions, eLink, WebLogic, and WebLogic Enterprise are trademarks of BEA Systems, Inc. All other company names may be trademarks of the respective companies with which they are associated. BEA Tuxedo システム ステム入門 Document Edition Date Software Version 7.1J 2000 年 9 月 BEA Tuxedo リリース 7.1J 目次 第 1 章 BEA Tuxedo システムの基本概念 参考文献 .........................................................................1-1 BEA Tuxedo システムとは ..................................................1-2 BEA Tuxedo システムの機能 .........................................1-3 クライアント / サーバ・モデルの分析 .................................1-6 クライアント / サーバ・アーキテクチャの特徴 .............1-6 2 層および 3 層のクライアント / サーバ・アーキテクチャの違い ...............................1-8 ニーズに応じたクライアント / サーバの各種の アーキテクチャ .........................................................1-9 クライアント / サーバ・モデルにおける BEA Tuxedo システム ..................................................1-10 BEA Tuxedo 環境におけるクライアント、 サーバ、サービス .........................................................1-12 BEA Tuxedo のクライアントとは ................................1-12 BEA Tuxedo サーバとは ..............................................1-13 BEA Tuxedo サービスとは ...........................................1-14 BEA Tuxedo システムによって提供されるサービス .........1-14 管理サービス ................................................................1-14 アプリケーション処理サービス ...................................1-15 BEA 製品ファミリ .............................................................1-15 第 2 章 BEA Tuxedo システムのアーキテクチャ BEA Tuxedo システムの基本アーキテクチャ .....................2-1 ATMI ..................................................................................... 2-4 BEA Tuxedo のメッセージング・パラダイム ...................2-10 会話型通信 ......................................................................... 2-11 EventBroker ....................................................................... 2-13 通知されるイベントのタイプ ............................................2-14 イベントの通知 ..................................................................2-14 待ち行列ベースの通信 .......................................................2-15 アプリケーション待ち行列 ..........................................2-16 要求 / 応答型通信 ...............................................................2-17 同期メッセージング .....................................................2-17 BEA Tuxedo システム入門 v 目次 非同期メッセージング .................................................2-18 任意通知型通信 ..................................................................2-19 サービス要求の入れ子と転送 ............................................2-20 入れ子になった要求 .....................................................2-20 転送された要求 ............................................................2-22 BEA Tuxedo システムのメッセージ処理 ...........................2-24 サービス要求処理の利点 ..............................................2-26 型付きバッファ ..................................................................2-27 バッファ・タイプの特徴 ..............................................2-28 MIB ..................................................................................... 2-32 MIB ユーザのタイプ ...........................................................2-33 MIB のクラス、属性、状態 ................................................2-34 BEA Tuxedo アプリケーション処理サービス ...................2-34 データ圧縮 ......................................................................... 2-35 データ依存型ルーティング ................................................2-35 データ依存型ルーティング ..........................................2-36 水平分離型データベースでのデータ依存型 ルーティングの例 ...................................................2-37 規則対応型サーバでのデータ依存型 ルーティングの例 ...................................................2-38 分散アプリケーションでのデータ依存型 ルーティングの例 ...................................................2-40 データの符号化と復号化 ...................................................2-42 データの暗号化 ..................................................................2-42 データ・マーシャリング ...................................................2-43 ロード・バランシング .......................................................2-45 ロード・ファクタの割り当て .......................................2-45 メッセージの優先順位付け ................................................2-46 ネーミング ......................................................................... 2-48 ネーミング・サービス .................................................2-48 サービスの宣言 ............................................................2-49 イベントのネーミング .................................................2-50 BEA Tuxedo の管理サービス .............................................2-50 第 3 章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 BEA Tuxedo システムの基本インフラストラクチャ ...........3-1 vi BEA Tuxedo システム入門 管理に対する視点 : 管理ツール ...........................................3-2 使用可能な BEA Tuxedo システムの MIB .....................3-3 BEA Administration Console ................................................3-4 ブラウザの要件 ..............................................................3-4 BEA Administration Console の利点 ....................................3-5 BEA Administration Console のメイン・メニュー ...............3-6 コンフィギュレーション・ツール .................................3-7 ツリー ............................................................................. 3-8 パワー・バー ..................................................................3-9 MIB を使用した操作の管理 ................................................3-10 MIB ユーザのタイプ ...........................................................3-11 MIB のクラス、属性、状態 ................................................3-12 コマンド行ユーティリティ ................................................3-12 コマンド行ユーティリティを使用した アプリケーションのコンフィギュレーション .............3-13 コマンド行ユーティリティを使用した アプリケーションの操作 ..............................................3-14 EventBroker を使用したシステム・イベントの管理 .........3-15 イベント ............................................................................. 3-16 イベントのサブスクライブ ................................................3-16 イベントのタイプ ..............................................................3-18 システム・イベントとアプリケーション固有の イベントの相違点 ...................................................3-18 BEA Tuxedo の管理サービス .............................................3-19 アプリケーション待ち行列管理 .........................................3-20 qmadmin を使用したアプリケーション 待ち行列の管理 .......................................................3-20 tmconfig を使用したコンフィギュレーションの変更 ..3-21 コンフィギュレーションの管理 .........................................3-22 コンフィギュレーション・ファイルの作成 .......................3-22 コンフィギュレーションの永続的な変更 ..........................3-24 コンフィギュレーションの動的な管理 ..............................3-25 tmadmin(1) を使用した動的操作の実行 .............................3-26 よく使用される tmadmin コマンド ..............................3-27 tmadmin コマンドの出力例 ..........................................3-28 分散アプリケーションの集中管理 .....................................3-29 セキュリティの管理 ...........................................................3-31 BEA Tuxedo システム入門 vii 目次 セキュリティ・オプションの選択 .....................................3-32 セキュリティの設定 ...........................................................3-33 アプリケーションの起動とシャットダウン .......................3-34 トランザクションの管理 ...................................................3-35 トランザクション・マネージャ・サーバ (TMS) による操作の調整 ...................................................3-36 トランザクション・ログ (TLOG) による パーティシパントのトラッキング ..........................3-37 ワークステーションの管理 ................................................3-38 開発の視点 : ATMI の使用 ..................................................3-39 ランタイム・システムの視点 : 各種コンフィギュレーションにおけるツールの使用 ...3-45 ランタイム・システムの機能 .......................................3-45 シングル・マシン・コンフィギュレーション ...................3-47 マルチ・マシン ( 分散 ) コンフィギュレーション .............3-49 マルチ・ドメイン・コンフィギュレーション ...................3-53 マルチ・ドメイン・コンフィギュレーションの特徴 ........3-58 BEA Tuxedo BRIDGE ........................................................3-58 掲示板と BBL の役割 .........................................................3-60 クライアントとサーバ .......................................................3-61 DBBL .................................................................................. 3-62 Domains 管理ツール ..........................................................3-62 IPC メッセージ待ち行列 ....................................................3-65 単一サーバ、単一待ち行列 (SSSQ) の使用 .................3-66 複数サーバ、単一待ち行列 (MSSQ) のセットの使用 ..3-66 ワークステーション・ハンドラと ワークステーション・リスナ .......................................3-68 ワークステーション・クライアントの アプリケーションへの接続 .....................................3-70 ユーザ・ログ (ULOG) ........................................................3-71 ULOG の作成 ...............................................................3-71 ULOG メッセージの例 .................................................3-71 ULOG の存在する場所 .................................................3-73 viii BEA Tuxedo システム入門 第 4 章 BEA Tuxedo 製品ファミリとエンタープライズ・ システムの統合 BEA Tuxedo 製品の統合 ......................................................4-1 BEA 製品スイート ..........................................................4-2 メインフレーム・コネクティビティ : BEA eLink ................4-4 BEA eLink 製品スイートのコンポーネント .........................4-4 BEA eLink for Mainframe - TCP/IP for MVS (for IMS and CICS) ...................................................4-4 BEA eLink for Mainframe - SNA .....................................4-5 BEA eLink for Mainframe - OSI TP ................................4-6 インターネット・アクセス : BEA Jolt .................................4-7 BEA Jolt のコンポーネント ..................................................4-8 アプリケーションの開発と管理 : BEA Manager ...............4-10 BEA Manager のコンポーネント .................................4-11 BEA Tuxedo 製品のコンポーネント ..................................4-11 オンライン・トランザクション処理 : BEA Tuxedo コア・システム .......................................4-12 スケーラビリティの実現 : BEA Tuxedo Domains .............4-15 BEA Tuxedo Domains の機能 ......................................4-17 ドメイン ............................................................................. 4-18 Domains ゲートウェイ ......................................................4-18 ドメイン・ゲートウェイの種類 .........................................4-19 BEA Tuxedo Domains のコンポーネント ..........................4-21 メッセージとサービス要求の格納 : BEA Tuxedo /Q .........4-22 メッセージ待ち行列サーバ ..........................................4-23 メッセージの格納と転送 ..............................................4-25 BEA Tuxedo /Q の機能 .................................................4-27 ワークステーション・コネクティビティ : BEA Tuxedo Workstation .............................................4-28 Workstation コンポーネント ..............................................4-29 WebLogic Enterprise を使用したクライアント / サーバ・アーキテクチャの開発 ...................................4-30 Java ベースの分散アプリケーションの開発と管理 : BEA WebLogic Server ..................................................4-32 WebLogic Server のインプリメンテーション ..............4-33 BEA WebLogic Server の利点 ......................................4-34 BEA Tuxedo システム入門 ix 目次 x BEA Tuxedo システム入門 第1章 BEA Tuxedo システムの基本概念 BEA Tuxedo システムとは クライアント / サーバ・モデルの分析 クライアント / サーバ・モデルにおける BEA Tuxedo システム BEA Tuxedo 環境におけるクライアント、サーバ、サービス BEA Tuxedo システムによって提供されるサービス BEA 製品ファミリ 参考文献 BEA Tuxedo システムに関しては、さまざまな書籍やドキュメント が出版されています。次の書籍、ホワイト・ペーパー、およびプ レゼンテーションには、クライアント / サーバ・アーキテクチャ、 分散ビジネス・アプリケーションの構築と管理、BEA Tuxedo シス テムを使用したエンタープライズ・アプリケーションの構築と管 理などに関する情報が記載されています。 J. M. Andrade、T. Carges、T. Dwyer、S. Felts 共著『Tuxedo シス テ ム – 分 散 ビ ジ ネ ス ア プ リ ケ ー シ ョ ン の 構 築 と 管 理』 Addison-Wesley Publishers Japan, Ltd. 渡辺榮一 監訳、漆原茂 / 佐々木政和 訳 1998 年 6 月 30 日 J. Edwards、DeVoe 共著 『3 層 C/S コンピューティング ケース スタディ』( 株式会社 翔泳社、笠野英松 監修、有限会社シンク ス 訳、1998 年 3 月 30 日 J. Edwards、Harkey、R. Orfali 共著 『The Essential Client/Server Survival Guide』New York、John Wiley & Sons, Inc.、1997 年 5 月 C. Hall 著『Building Client/Server Applications Using Tuxedo Designing and Building Cost-Effective, High Performance Client/Server Applications Using Tuxedo』 Wiley Computer Publishing BEA Tuxedo システム入門 1-1 第1章 BEA Tuxedo システムの基本概念 R. Lee 発表『BEA Tuxedo Essentials』1999 年 2 月、ルイジアナ 州ニューオーリンズにおける BEA User’s Conference でのプレ ゼンテーション R. MacBlane 発表『Managing your BEA Tuxedo Applications Even Over the Internet』1997 年 5 月、カリフォルニア州サンノゼにお ける BEA User’s Conference でのプレゼンテーション R. MacBlane 発表『Tuxedo’s Management Information Base 』1996 年 2 月、カリフォルニア州サンフランシスコにおける BEA User’s Conference でのプレゼンテーション 『BEA Tuxedo: The Programming Model』( ホワイト・ペーパー ) 『BEA Tuxedo and the Component Software Model』( ホワイト・ ペーパー ) 『Inter-Application Transaction Processing with BEA Tuxedo Domains』( ホワイト・ペーパー ) 『Reliable Queuing Using BEA Tuxedo』( ホワイト・ペーパー ) BEATuxedo システムとは BEA Tuxedo システムは、メッセージ・ベースの通信、および必要 に応じて分散トランザクション処理を行って、複数のプラット フォーム、データベース、およびオペレーティング・システムに わたってアプリケーションを分散するミドルウェア製品です。 クライアント / サーバ・アプリケーションでは、ミドルウェアを使 用して、複数のサーバ間で処理を分散したり、分散トランザクショ ンを管理したり、複数のデータベース・プラットフォームを統合 することができます。ミドルウェア・システムは、「オンライン・ トランザクション処理」システム、 「OLTP」システムと呼ばれる こともあります。 1-2 BEA Tuxedo システム入門 BEA Tuxedo システムとは BEA Tuxedo システムは、AT&T、UNIX System Laboratories (USL)、 Novell、および BEA 社などのテクノロジ企業のグループが 15 年以 上の年月をかけて開発した完成度の高い製品です。このシステム は、開発プラットフォームであると同時に、実行プラットフォー ムでもあります。BEA Tuxedo システムは、オペレーティング・シ ステムの拡張として機能します。 BEA Tuxedo システムでは、以下が実現されています。 異種クライアント / サーバ環境における分散オンライン・トラ ンザクション・アプリケーションの作成と集中管理のための業 界標準。 アプリケーション開発者にとって使いやすいシステム。開発者 は、使用するサーバのロケーション、ルーティング、プラット フォームなどの詳細を完全に把握する必要はありません。BEA Tuxedo アプリケーションでは、プログラムのこのような要素 が透過的に扱われています。 信頼性が高く、パフォーマンスに優れ、管理しやすい分散シス テムを作成して管理し、維持するための基盤。 BEA Tuxedo システムの機能 BEA Tuxedo システムには、アプリケーションの管理者、構築担当 者、およびプログラマのニーズに応える多くの機能が提供されて います。 管理に関する機能 パスワード・セキュリティおよびアクセス制御セキュリティ − パスワード・セキュリティにより、アプリケーション設計者は、 初期化の際にパスワードを要求すること ( 認証 ) によってアク セスを制御できます。アクセスは、権限によってさらに制御で きます。これは、特定のアプリケーション・サービスへのアク セスを制限する手段で、明示的な許可を与えられ、認証を受け たクライアントだけがサービスにアクセスできます。 BEA Tuxedo システム入門 1-3 第1章 BEA Tuxedo システムの基本概念 システム・イベントの通知 − BEA Tuxedo システムでは、サー バの停止やネットワーク障害などのシステム・イベントに関す る詳細が提供されます。クライアントまたはサーバによってイ ベントがポストされると、EventBroker がそのイベントのすべ てのサブスクライバを確認し、各サブスクリプションの指定に 従って適切な処理を行います。 MIB ( 管理情報ベース ) − 独自のプログラムによってアプリ ケーションの監視、コンフィギュレーション、チューニングを 行うことができる管理用のインターフェイスです。これは、 FML 属性として定義され、インプリメンテーションに依存しな い管理データベースです。情報を照会したり、変更することが できます。 Web ベースの管理 − World Wide Web を通して BEA Tuxedo ア プリケーションのコンフィギュレーションと制御を行うグラ フィカル・ユーザ・インターフェイスです。 アーキテクチャに関する機能 分散サービス − 異なるハードウェア・プラットフォーム上に 存在するアプリケーション・サービスやシステム・サービスに 対して、透過的にアクセスすることができます。 高速なコネクションレス型通信 − クライアントがサーバでは なく掲示板に接続するので、システムのパフォーマンスが向上 します。 スケーラビリティ − サービスおよびサーバを簡単に複製した り分散できるので、要求されるシステム・ロードの変化にすば やく対応してアプリケーションの規模を調整できます。プログ ラムでしきい値を設定すると、BEA Tuxedo システムで自動的 にサーバを新しく作成したり、シャットダウンすることができ ます。 サーバの透過性 − 掲示板上のサービス・ディレクトリによっ てサービス名がサーバにマップされるので、クライアントが サーバを識別する必要はありません。 1-4 BEA Tuxedo システム入門 BEA Tuxedo システムとは プログラミングに関する機能 通信方法 − Tuxedo システムのアプリケーション・プログラミ ング・インターフェイス (API) は、X/Open の XATMI インター フェイスのスーパーセットであり、アプリケーション・トラン ザクション・モニタ・インターフェイス (ATMI) と呼ばれます。 BEA Tuxedo の ATMI には、分散アプリケーションを作成する ための通信方法が豊富に提供されています。 分散トランザクション処理 (DTP) − 分散アプリケーション全 体で行われている作業をアトミックに完了することができま す。これは、どの OLTP システムにおいても重要な特徴の 1 つ です。 型付きバッファ − 異種プラットフォーム間でアプリケーショ ン・データを透過的に処理することができます。 X/Open TX 準拠 − BEA Tuxedo システムは、トランザクション の境界判定に関する X/Open インターフェイス標準に準拠して います。 X/Open XA 準拠 − BEA Tuxedo システムは、トランザクショ ン・データベース・システム ( リソース・マネージャ ) に関す る X/Open インターフェイス標準に準拠しています。そのため、 データの整合性を維持しながら、1 つのアプリケーション内で 複数のデータベースを混在させ、そのデータベースに合致させ ることができます。 関連項目 第 1 章の 14 ページ 「BEA Tuxedo システムによって提供され るサービス」 第 1 章の 15 ページ 「BEA 製品ファミリ」 BEA Tuxedo システム入門 1-5 第1章 BEA Tuxedo システムの基本概念 クライアント / サーバ・モデルの分析 クライアント / サーバ・アーキテクチャでは、クライアント ( サー ビスを必要とするユーザを表すプログラム ) とサーバ ( サービスを 提供するプログラム ) は、それぞれ別個の論理オブジェクトであ り、ネットワーク上で通信して共同で処理を行います。クライア ントは、サービスを要求し、その要求に対する応答を受け取りま す。サーバは、要求を受け取って処理し、要求された応答を送り 返します。 クライアント / サーバ・アーキテクチャの特徴 非対称のプロトコル − クライアントとサーバには、多対 1 の 関係があります。クライアントは、常にサービスを要求するこ とによって会話を開始します。サーバは、受動的にクライアン トからの要求を待ちます。 サービスのカプセル化 − サーバは、サービスを要求するメッ セージを受け取り、それをどのように処理するかを決定しま す。サーバとクライアントによって使用されるメッセージ・イ ンターフェイスが変更されない限り、クライアントに影響を与 えずにサーバをアップグレードできます。 整合性 − サーバのコードとデータを集中管理することによ り、メンテナンスのコストを抑えることができ、共有データの 整合性が保護されます。同時に、クライアントの個別性と独立 性を維持できます。 位置透過性 − サーバは、クライアントと同じマシン、または ネットワーク上のほかのマシンに存在するプロセスです。通 常、クライアント / サーバ・ソフトウェアでは、サービス要求 をリダイレクトすることによって、サーバのロケーションがク ライアントに隠ぺいされます。プログラムは、クライアント、 サーバ、またはその両方になることができます。 メッセージ・ベースの交換 − クライアントとサーバは、メッ セージを使用して、サービス要求と応答を交換できる疎結合の プロセスです。 1-6 BEA Tuxedo システム入門 クライアント / サーバ・モデルの分析 モジュール方式の拡張可能な設計 − クライアント / サーバ・ア プリケーションはモジュール方式で設計されており、フォルト トレラントにすることができます。フォルトトレラントなシス テムでは、障害が発生してもアプリケーション全体がシャット ダウンすることはありません。フォルトトレラントなクライア ント / サーバ・アプリケーションでは、異常終了したサーバ上 で提供されていたサービスがほかのアクティブなサーバ上で 利用できる限り、1 つ以上のサーバが異常終了しても、システ ム全体が停止することはありません。モジュール方式のもう 1 つの利点として、クライアント / サーバ・アプリケーションが、 1 つ以上のサービスまたはサーバを追加したりシャットダウ ンすることによって、システム・ロードの増加や減少に自動的 に対応できます。 プラットフォームからの独立性 − 理想的なクライアント / サーバ・ソフトウェアは、ハードウェアやオペレーティング・ システムのプラットフォームに依存しないので、クライアント とサーバで異なるプラットフォームを使用できます。クライア ントとサーバは、それぞれが実行する作業のタイプを最適化し て、異なるオペレーティング・システムを使用する異なるハー ドウェア上で実行できます。 再利用可能なコード − サービス・プログラムを複数のサーバ 上で使用できます。 スケーラビリティ − クライアント / サーバ・システムは、水平 方向または垂直方向に規模を調整できます。水平方向の調整と は、クライアント・ワークステーションの追加または削除を意 味します。パフォーマンスにはわずかにしか影響しません。垂 直方向の調整とは、より大型で高速のサーバ・マシンへの移 行、またはサーバ・マシンの追加を意味します。 クライアント/サーバ機能の分離 − クライアント/サーバとは、 同じマシンまたは別のマシン上で実行されるプロセス間の関 係です。サーバ・プロセスは、サービスの供給者です。クライ アントは、サービスの要求者です。クライアント / サーバでは、 両者の機能がはっきりと区別されます。 共有リソース − 1 つのサーバが多くのクライアントに対して サービスを同時に提供し、共有リソースに対するアクセスを制 御できます。 BEA Tuxedo システム入門 1-7 第1章 BEA Tuxedo システムの基本概念 2 層および 3 層のクライアント / サーバ・アーキテクチャの違い すべてのクライアント / サーバ・アプリケーションには、次の 3 つ の機能単位が含まれています。 プレゼンテーション・ロジックまたはユーザ・インターフェイ ス ( たとえば、ATM マシン ) ビジネス・ロジック ( たとえば、顧客が口座残高を照会するた めのソフトウェア ) データ ( たとえば、顧客の口座レコード ) これらの機能単位は、クライアントと 1 つ以上のサーバのいずれ かに存在します。数多くの種類のアーキテクチャからどれを選択 するかは、アプリケーションをどのように分割するか、そして階 層間の通信にどのようなミドルウェアを使用するかによって決ま ります。 2 層クライアント / サーバ・アプリケーションでは、ビジネス・ロ ジックがクライアント上のユーザ・インターフェイス内に埋め込 まれているか、またはサーバ上のデータベース内にストアド・プ ロシージャとして格納されています。または、ビジネス・ロジッ クがクライアントとサーバ間で分割されている場合もあります。 ストアド・プロシージャを含むファイル・サーバやデータベース・ サーバは、2 層アーキテクチャの一例です。 3 層クライアント / サーバ・アプリケーションでは、ビジネス・ロ ジックがデータやユーザ・インターフェイスから切り離された中 間層に存在します。このような方法で、プロセスをユーザ・イン ターフェイスやデータベースと切り離して管理し、実行すること ができます。また、3 層システムでは、複数のソースからのデータ を統合することもできます。 1-8 BEA Tuxedo システム入門 クライアント / サーバ・モデルの分析 図 1-1 2 層および 3 層のクライアント / サーバ・モデル ニーズに応じたクライアント / サーバの各種のアーキテクチャ クライアント / サーバ・アーキテクチャは、以下の各状況における ニーズに対応できます。 小規模な事業およびラップトップ − クライアント、ミドル ウェア・ソフトウェア、および大部分のビジネス・サービスが 同じマシン上で動作します。この方法は、歯科医院、在宅業 務、ラップトップ・コンピュータを多用する出張者などの小規 模な事業に使用することをお勧めします。 BEA Tuxedo システム入門 1-9 第1章 BEA Tuxedo システムの基本概念 中小企業および社内の部署 − LAN ベースの単一サーバ・アプ リケーションを必要とします。このタイプのアプリケーション のユーザには、複数の医師を擁する病院、複数の部署がある企 業、複数の支店を持つ銀行など、中小規模のビジネスが該当し ます。このタイプのアプリケーションでは、複数のクライアン トが 1 つのローカル・サーバと通信します。管理業務は単純で す。セキュリティはマシン・レベルでインプリメントされ、障 害は簡単に検出できます。 大企業 − さまざまな機能を提供する複数のサーバを必要とし ます。インターネット、イントラネット、および社内ネット ワーク上に複数のサーバが存在し、そのすべてが高いスケーラ ビリティを持ちます。サーバは、機能、リソース、またはデー タベースごとに分割したり、また障害耐久性やパフォーマンス の向上のために複製することもできます。これは、強力かつ柔 軟性の高いモデルです。このクライアント / サーバ・モデルで は、アプリケーションがうまく構築されているかどうかが重要 です。作業をサーバ間で分担したり、あるサーバの作業をほか のサーバに委譲する場合もあります。 クライアント / サーバ・モデルにおける BEA Tuxedo シ ステム BEA Tuxedo システムは、クライアント / サーバ・モデルの中央に 配置されます。BEA Tuxedo アプリケーションでは、クライアント がログインし、アプリケーションによって提供されるサービスを 要求します。BEA Tuxedo システムでは、透過的な掲示板を通して これらのサービスが提供されます。掲示板には、サービスを宣言 するディレクトリが定義されています。たとえば、銀行業務アプ リケーションの場合、掲示板には預け入れ、引き出し、残高照会 などのサービスが宣言されます。この後、BEA Tuxedo システム が、要求されたサービスを提供できるサーバ ( たとえば、該当す る支店など ) を見つけます。 1-10 BEA Tuxedo システム入門 クライアント / サーバ・モデルにおける BEA Tuxedo システム 図 1-2 銀行業務のサンプル・アプリケーションにおけるクライアントと サーバ この図には、BEA Tuxedo アプリケーションを構成する基本単位が 示されています。 クライアント − ユーザからの入力を収集し、BEA Tuxedo シス テムを通して要求をサーバに送信した後、サーバからの応答を 収集してユーザに配信するプログラム。 サーバ − アプリケーションを定義する一連のサービスに、ビ ジネス・ロジックがカプセル化されたプログラム。 ミドルウェア − クライアントとサーバ間のやり取りをサポー トするために必要なあらゆる分散ソフトウェア。これは、クラ イアントがサーバからサービスを取得するための手段です。ミ ドルウェアには、クライアント ( 要求の発行と応答の受信 ) お よびサーバ ( 応答の発行 ) によって使用される API 関数と、ク ライアントの要求とサーバの応答をネットワーク上で転送す るためのメッセージング・パラダイムから構成されます。ミド ルウェアには、クライアント上のユーザ・インターフェイス、 アプリケーション・ロジック、サーバによって提供されるサー ビスは含まれません。 BEA Tuxedo システム入門 1-11 第1章 BEA Tuxedo システムの基本概念 この銀行業務のサンプル・アプリケーションでは、クライアント ( 現 金自動預け払い機および銀行窓口 ) が要求を行い、( 支店の ) サーバ がサービスと応答を提供します。たとえば、ある顧客が、現金自 預け払い機を使って自分の当座預金の残高を調べるとします。現 自動預け払い機 ( クライアント ) は、残高を取得するためにサーバを 呼び出します。サーバは要求を受信し、残高を取得し、その情報 現金自動預け払い機に送信します。 関連項目 第 1 章の 6 ページ 「クライアント / サーバ・モデルの分析」 第 1 章の 12 ページ 「BEA Tuxedo 環境におけるクライアント、 サーバ、サービス」 BEA Tuxedo 環境におけるクライアント、サーバ、サー ビス ここでは、BEA Tuxedo 環境におけるクライアント、サーバ、およ びサービスについて説明します。 BEA Tuxedo のクライアントとは クライアントとは、ユーザからの要求を収集し、その要求を処理 できるサーバに渡すプログラムです。アプリケーションのフロン ト・エンドの一部として、PC またはワークステーション上に置く ことができます。また、ATM マシンなどの通信装置を読み取るソ フトウェアの中に埋め込むこともできます。このような通信装置 からデータが収集され、BEA Tuxedo サーバによって処理される前 にフォーマット処理されます。 プログラムがクライアントになるには、アプリケーション・トラ ンザクション・モニタ・インターフェイス (ATMI) と呼ばれる BEA Tuxedo の関数およびプロシージャのライブラリを呼び出せること が必要です。ATMI は、いくつかの言語バインディングでサポー トされています。 1-12 BEA Tuxedo システム入門 BEA Tuxedo 環境におけるクライアント、サーバ、サービス クライアントは、ATMI のクライアント初期化ルーチンを呼び出 すことによって、BEA Tuxedo アプリケーションに参加します。ア プリケーションに一度参加すると、クライアントはトランザク ション境界を定義したり、アプリケーションのほかのプログラム と通信するための ATMI 関数を呼び出すことができるようになり ます。クライアントは、ATMI 終了関数を呼び出すことによって、 BEA Tuxedo アプリケーションから分離します。必要な場合だけア プリケーションに参加し、必要なタスクが完了したら分離するよ うにすると、ほかのクライアントやサーバが使用できるように BEA Tuxedo システムのリソースを解放できます。 分散アプリケーションを構築する場合、ビジネスに関して、処理 対象の情報がどのように集められて提供されるかを決定する必要 があります。ATMI 関数を呼び出す場所やタイミングは、ビジネ ス・ロジックやビジネス・ルールに従って自由に決めることがで きます。ある BEA Tuxedo アプリケーションに参加し、いくつか のタスクを実行してこのアプリケーションから分離した後、別の BEA Tuxedo アプリケーションに参加して別のタスクを実行する ことができます。マルチコンテキスト・アプリケーションを使用 している場合は、どのアプリケーションからも分離せずに、複数 のアプリケーションでタスクを実行することができます。 BEA Tuxedo サーバとは BEA Tuxedo サーバとは、一連のサービスを監視し、それらを要求 したクライアントに対して自動的にディスパッチするプロセスで す。それに対して、サービスとは、ビジネスに必要な特定のタス クを実行するサーバ・プログラム内の関数です。たとえば、銀行 には、預け入れを受け取るサービスと、口座残高を報告するサー ビスが用意されています。あるサーバが、この両方のサービスを クライアントから受け取ったとします。それぞれの要求を該当す るサービスにディスパッチするのは、サーバの役目です。 BEA Tuxedo システム入門 1-13 第1章 BEA Tuxedo システムの基本概念 サービス関数は、SQL などのデータベース・インターフェイスへ の呼び出しを通じて、ビジネス・ロジックをインプリメントしま す。また、ATMI への呼び出しによって、ほかのサービスや問い 合わせ、別のリソースにアクセスする場合もあります。これらの サービスが存在するサーバでは、クライアントに応答するか、ま たはクライアントの要求を別のサービスに転送します。 BEA Tuxedo サービスとは サービスとは、タスクを実行するアプリケーション・コードのモ ジュールです。サービスは、コンパイルされてリンクされ、実行 可能形式のサーバを生成します。 BEATuxedo システムによって提供されるサービス BEA Tuxedo システムでは、アプリケーションの効率化と管理に役 立つ数多くのサービスが提供されています。 管理サービス BEA Tuxedo システムでは、以下の管理タスクを行うためのサービ スが提供されています。 アプリケーション待ち行列管理 中央集中型のアプリケーション・コンフィギュレーション 分散アプリケーション管理 アプリケーションの動的な再コンフィギュレーション イベント管理 セキュリティ管理 アプリケーションの起動とシャットダウン トランザクション管理 ワークステーション管理 1-14 BEA Tuxedo システム入門 BEA 製品ファミリ アプリケーション処理サービス BEA Tuxedo システムでは、以下の機能をアプリケーションにイン プリメントするためのサービスが提供されています。 データ圧縮 データ依存型ルーティング データ符号化 データ暗号化 データ・マーシャリング ロード・バランシング メッセージの優先順位付け サービスおよびイベントのネーミング BEA 製品ファミリ BEA 社では、以下のような製品ファミリが提供されています。 製品 機能 BEA eLink BEA Tuxedo 分散アプリケーションをエンタープライ ズ・アプリケーションにシームレスに統合するコネ クティビティ製品スイート。 BEA Jolt Java における BEA Tuxedo クライアント API。 BEA Manager BEA Tuxedo または WebLogic Server アプリケーショ ン用の管理ツール・パッケージ。 BEA Tuxedo システム入門 1-15 第1章 BEA Tuxedo システムの基本概念 製品 BEA Tuxedo システムの 4 つのコンポーネント BEA Tuxedo コア・ システム Domains /Q Workstation 機能 BEA Tuxedo コア製品 − 優れたパフォーマンスと 高い信頼性を持つミッション・クリティカルなア プリケーションの構築を可能にします。異機種の 分散環境において、スケーラブルな 3 層クライア ント / サーバ・アプリケーションを構築するため のフレームワークを提供します。 Domains − BEA Tuxedo クライアント / サーバ・モ デ ル を 拡 張 し て、別 々 に 管 理 さ れ て い る BEA Tuxedo アプリケーション間にトランザクション の情報交換機能を提供します。 /Q − 要求に対して、信頼性の高い待ち行列処理を 行います。 Workstation − 各種のオペレーティング・システム に対する完全なクライアント・サポートを提供し、 アプリケーションが BEA Tuxedo の完全なインプ リメンテーションを必要としないリモート・クラ イアントを使用できるようにします。 BEA WebLogic Enterprise 業界で主力のアプリケーション・サーバ製品ファミ リ。ミッション・クリティカルなアプリケーション に依存する企業や組織に、BEA Tuxedo システムの強 力さ、堅牢さ、定評のある信頼性と共に、Common Object Request Broker Architecture (CORBA) 準拠およ び Enterprise Java Beans (EJB) プログラミング・モデル の利点をもたらします。 BEA WebLogic Server Java アプリケーション・サーバ。大規模な分散型の Web アプリケーション、ネットワーク・アプリケー ション、およびデータベース・アプリケーションの 開発、統合、運用、および管理を行います。 1-16 BEA Tuxedo システム入門 第2章 BEA Tuxedo システムのアーキテクチャ BEA Tuxedo システムの基本アーキテクチャ BEA Tuxedo のメッセージング・パラダイム BEA Tuxedo システムのメッセージ処理 BEA Tuxedo アプリケーション処理サービス BEA Tuxedo の管理サービス BEATuxedo システムの基本アーキテクチャ 次の図は、BEA Tuxedo システムを構成する基本的な要素を示して います。BEA Tuxedo は、システムへの外部インターフェイス、 ATMI 層、MIB、BEA Tuxedo システムの各サービス、および標準 に準拠したリソース・マネージャとのインターフェイスから構成 されます。 図 2-1 BEA Tuxedo システムの基本アーキテクチャ BEA Tuxedo システム入門 2-1 第2章 BEA Tuxedo システムのアーキテクチャ この図で示してあるように、BEA Tuxedo システムは次の要素から 構成されています。 構成要素 説明 外部インターフェイ ス層 この層は、ユーザとシステム間のインターフェイスから 構成されています。SNMP (Simple Network Management Protocol) エージェントなどのアプリケーション開発 ツール、および BEA Administration Consol などの管理 ツ ー ル の 両 方 が 含 ま れ て い ま す。BEA Administration Console や SNMP エージェントは、標準の管理コンソー ルとやり取りできます。そのため、ユーザは BEA Tuxedo システムとネットワークのコンフィギュレーションを 1 つのコンソールから管理できます。また、アプリケー ションのアーキテクチャの設計者や開発者は、独自の管 理ツールまたはアプリケーション固有のツールや特定 分野のツールを MIB の最上位に構築できます。 アプリケーション・ト ランザクション・モニ タ・インターフェイス (ATMI: Application to Transaction Monitor Interface) ア プリ ケ ーシ ョン と BEA Tuxedo シ ステ ム間 の イン ターフェイス。ATMI と BEA Tuxedo システムには、ト ランザクションを行う X/Open DTP モデルがインプリ メントされています。ATMI では、抽象的な環境とし て位置透過性がサポートされ、インプリメンテーショ ンの詳細が隠蔽されます。そのため、プログラマはア プリケーション・コードを変更せずに、複数のプラッ ト フォ ー ムに BEA Tuxedo ア プリ ケ ーシ ョン を コン フィギュレーションして運用できます。 メッセージング・パラ ダイム クライアントとサーバ間のメッセージ転送を行う各種 モデル。たとえば、要求 / 応答モード、会話モード、イ ベント、任意通知型通知などがあります。 2-2 BEA Tuxedo システム入門 BEA Tuxedo システムの基本アーキテクチャ 構成要素 説明 管理情報ベース (MIB) BEA Tuxedo システムのプログラミングと管理を行う ためのインターフェイス。MIB での操作によって、監 視、コンフィギュレーション、チューニングなど、す べての管理タスクを行うことができます。MIB では、 一度に 1 つのタスクを 1 つのオブジェクトに対して実 行したり、ツール・キットを作成してタスクやオブジェ クトをバッチ処理することができます。利用可能な MIB については、第 3 章の 3 ページ 「使用可能な BEA Tuxedo システムの MIB」を参照してください。 BEA Tuxedo サービス ( 管理サービスおよび アプリケーション処 理サービス ) BEA Tuxedo システムのインフラストラクチャによっ て提供されるアプリケーションの開発と管理のための サービスや機能。開発者が利用できるアプリケーショ ン処理サービスには、データ圧縮、データ依存型ルー ティング、データ符号化、ロード・バランシング、ト ランザクション管理などがあります。管理サービスに は、中央集中型のアプリケーション・コンフィギュレー ション、分散アプリケーション管理、ドメインの分割、 動的な再コンフィギュレーション、イベントおよび障 害の管理、IPC メッセージ待ち行列、Workstation 管理 などがあります。管理サービスについては、第 3 章の 1 ページ 「BEA Tuxedo システム・インフラストラク チャに対する 3 つの視点」を参照してください。 リソース・マネージャ データが格納されたソフトウェア製品。データは、こ こからアプリケーション・ベースの照会によって取得 されます。リソース・マネージャ (RM) は、BEA Tuxedo システムとやり取りを行い、XA 標準インターフェイス をインプリメントしています。リソース・マネージャ の代表的な例はデータベースです。リソース・マネー ジャによって、トランザクション機能とアクションの 永続性が可能になります。これらは、グローバル・ト ランザクション内でアクセスして制御できます。 関連項目 第 2 章の 50 ページ 「BEA Tuxedo の管理サービス」 BEA Tuxedo システム入門 2-3 第2章 BEA Tuxedo システムのアーキテクチャ 第 2 章の 34 ページ 「BEA Tuxedo アプリケーション処理サー ビス」 ATMI BEA Tuxedo API である ATMI は、通信、トランザクション、およ びデータ・バッファ管理を行うためのインターフェイスで、BEA Tuxedo システムでサポートされているすべての環境で動作しま す。ATMI によって、アプリケーション・プログラムと BEA Tuxedo システムとが接続されます。ATMI は、広範囲にわたる各種機能 に対する 1 つの単純なインターフェースです。ATMI には、トラ ンザクション処理として X/Open DTP モデルがインプリメントさ れています。 図 2-2 ATMI の使用 2-4 BEA Tuxedo システム入門 ATMI ATMI ライブラリには、BEA Tuxedo アプリケーションでグローバ ル・トランザクションを定義して制御するための各種の関数が含 まれています。グローバル・トランザクションを使用すると、分 散アプリケーションにおいて、複数のプログラムとリソース・マ ネージャにかかわる排他的な操作単位を管理できます。1 つのトラ ンザクションでのすべての操作は、1 つの論理単位として扱われま す。そのため、タスクを正常に完了できないプログラムが 1 つで もあると、そのトランザクションではプログラムによってどの操 作も実行されません。ほとんどの ATMI 関数では、各種の通信方 法がサポートされています。これらの関数は、プログラム間でデー タを送受信できるようにして、分散プログラムを互いに結び付け ます。すべての ATMI 関数は、型付きバッファでデータを送受信 します。次の表は、ATMI 関数 (C および COBOL のバインディン グ対応 ) と、それらの関数によって行われる処理を示しています。 関数は、タスクごとに分類されています。 表 2-1 ATMI 関数の使用 タスク C 関数 COBOL 関数 処理内容 クライアン ト・メンバー シップ tpchkauth(3c) TPCHKAUTH(3cbl) 認証が必要かどう かを確認します。 tpinit(3c) TPINITIALIZE(3cbl) クライアントをア プリケーションに 参加させます。 tpterm(3c) TPTERM(3cbl) クライアントをア プリケーションか ら分離させます。 BEA Tuxedo システム入門 2-5 第2章 BEA Tuxedo システムのアーキテクチャ タスク C 関数 COBOL 関数 処理内容 バッファ管理 tpalloc(3c) N/A メッセージ・バッ ファを作成しま す。 tprealloc(3c) N/A メッセージ・バッ ファのサイズを変 更します。 tpfree(3c) N/A メッセージ・バッ ファを解放しま す。 tptypes(3c) N/A メッセージのタイ プとサブタイプを 取得します。 tpgprio(3c) TPGPRIO(3cbl) 最後の要求の優先 順位を確認しま す。 tpsprio(3c) TPSPRIO(3cbl) 次の要求の優先順 位を設定します。 tpcall(3c) TPCALL(3cbl) サービスの同期要 求/応答を開始しま す。 tpacall(3c) TPACALL(3cbl) 非同期要求 ( ファ ンアウト ) を開始 します。 tpgetrply(3c) TPGETRPLY(3cbl) 非同期応答を受け 取ります。 tpcancel(3c) TPCANCEL(3cbl 非同期要求を取り 消します。 メッセージの 優先順位 要求 / 応答型 通信 2-6 BEA Tuxedo システム入門 ATMI タスク C 関数 COBOL 関数 処理内容 会話型通信 tpconnect(3c) TPCONNECT(3cbl) サービスとの会話 を開始します。 tpdiscon(3c) TPDISCON(3cbl 会話を切断しま す。 tpsend(3c) TPSEND(3cbl) 会話中にメッセー ジを送信します。 tprecv(3c) TPRECV(3cbl) 会話中にメッセー ジを受信します。 tpenqueue(3c) TPENQUEUE(3cbl) メッセージをメッ セージ待ち行列に 登録します。 tpdequeue(3c) TPDEQUEUE(3cbl) メッセージをメッ セージ待ち行列か ら取り出します。 高信頼性待ち 行列 BEA Tuxedo システム入門 2-7 第2章 BEA Tuxedo システムのアーキテクチャ タスク C 関数 COBOL 関数 処理内容 イベント・ベー スの通信 tpnotify(3c) TPNOTIFY(3cbl) 1 つのクライアン トに任意通知型 メッセージを送信 します。 tpbroadcast(3c) TPBROADCAST(3cbl) 複数のクライアン トにメッセージを 送信します。 tpsetunsol(3c) TPSETUNSOL(3cbl) 任意通知型メッ セージをコール バックに設定しま す。 tpchkunsol(3c) TPCHKUNSOL(3cbl) 任意通知型メッ セージの到着を確 認します。 N/A TPGETUNSOL(3cbl) 任意通知型メッ セージを取得しま す。 tppost(3c) TPPOST(3cbl) イ ベ ン ト・メ ッ セージをポストし ます。 tpsubscribe(3c) TPSUBSCRIBE(3cbl) イ ベ ン ト・メ ッ セージをサブスク ライブします。 tpunsubscribe(3c) TPUNSUBSCRIBE(3cbl) イ ベ ン ト・メ ッ セージのサブスク リプションを削除 します。 2-8 BEA Tuxedo システム入門 ATMI タスク C 関数 COBOL 関数 処理内容 トランザク ション管理 tpbegin(3c) TPBEGIN(3cbl) トランザクション を開始します。 tpcommit(3c) TPCOMMIT(3cbl) トランザクション をコミットしま す。 tpabort(3c) TPABORT(3cbl) 現在のトランザク ションをロール バックします。 tpgetlev(3c) TPGETLEV(3cbl) トランザクショ ン・モードである かどうかを確認し ます。 tpsuspend(3c) TPSUSPEND(3cbl) 現在のトランザク ションを中断しま す。 tpresume(3c) TPRESUME(3cbl) トランザクション を再開します。 tpsvrinit(3c) TPSVRINIT(3cbl) サーバを初期化し ます。 tpsvrdone(3c) TPSVRDONE(3cbl) サーバを終了しま す。 tpservice(3c) N/A サービスのエント リ・ポイントのプ ロトタイプです。 N/A TPSVCSTART(3cbl) サービス情報を取 得します。 tpreturn(3c) TPRETURN(3cbl) サービス関数を終 了します。 tpforward(3c) TPFORWAR(3cbl) 要求を転送しま す。 サービスの登 録と応答 BEA Tuxedo システム入門 2-9 第2章 BEA Tuxedo システムのアーキテクチャ タスク C 関数 COBOL 関数 処理内容 動的な宣言 tpadvertise(3c) TPADVERTISE(3cbl) サービス名を宣言 します。 tpunadvertise(3c) TPUNADVERTISE(3cbl) サービス名の宣言 を取り消します。 tpopen(3c) TPOPEN(3cbl) リソース・マネー ジャを開きます。 tpclose(3c) TPCLOSE(3cbl) リソース・マネー ジャを閉じます。 リソース管理 注記 ATMI トランザクション管理に関係する関数の使用は必須で はありません。 関連項目 『BEA Tuxedo アプリケーション実行時の管理』の第 2 章の 32 ページ 「ATMI を使用してシステム・エラーとアプリケーショ ン・エラーを処理する」 BEATuxedo のメッセージング・パラダイム 次の表は、アプリケーション開発者が利用できる BEA Tuxedo の メッセージング・パラダイムを示しています。 表 2-2 BEA Tuxedo のメッセージング・パラダイム BEA Tuxedo のメッセージ ング・パラダイム 説明 会話型通信 クライアントと専用サーバ間で、双方向で複数の やり取りを行うサービス要求モード イベント・ベースの通信 パブリッシュ / サブスクライブ・モード 待ち行列ベースの通信 配達保証モード 2-10 BEA Tuxedo システム入門 会話型通信 BEA Tuxedo のメッセージ ング・パラダイム 説明 要求 / 応答型通信 同期 ( 要求元が応答を受け取るまで処理を行わず に待機する ) または非同期 ( 要求元が応答を待つ 間も処理を継続する ) のサービス要求モード 任意通知型メッセージン 任意のクライアントまたはサーバから任意のク ライアントへの通信で、受信側のクライアントが 要求または予期していないもの 関連項目 第 2 章の 11 ページ 「会話型通信」 第 2 章の 13 ページ 「EventBroker」 第 2 章の 15 ページ 「待ち行列ベースの通信」 第 2 章の 17 ページ 「要求 / 応答型通信」 第 2 章の 19 ページ 「任意通知型通信」 第 2 章の 20 ページ 「サービス要求の入れ子と転送」 会話型通信 会話型通信は、BEA Tuxedo システムのメッセージ交換のパラダイ ムで、人の会話に似た通信がクライアントとサーバ間でインプリ メントされています。この通信方法では、クライアントとサーバ 間に仮想の接続が行われます。人が 2 人で会話するように、ある 結論に達するまで、2 つのエンティティ間で数多くのメッセージが やり取りされます。通信が行われている間、両者によって会話の ポイント ( または状態 ) が「記憶」されます。そのため、一時的な 照会、レポート、ファイル転送などの比較的時間のかかる操作を サポートできます。デフォルトで、会話型サーバを使用できます。 必要に応じて、自動的にサーバを追加することもできます。 BEA Tuxedo システム入門 2-11 第2章 BEA Tuxedo システムのアーキテクチャ BEA Tuxedo システムでは、アプリケーション内で会話を作成する ためのアプリケーション・プログラミング・インターフェイス (API) が提供されています。この API を使用して、クライアントを サーバに接続し、メッセージを送受信し、会話を終了します。 会話は入れ子にすることもできます。ただし、そのためにパフォー マンスが低下する場合があります。会話には、トランザクション またはサービス要求のいずれかが含まれます。会話型サービスに よってサービス呼び出しを行ったり、会話を確立できます。ただ し、これらのサービス呼び出しと会話は転送できません。会話は、 トランザクションのスコープ内に置いて、トランザクションに よって制御されます。 図 2-3 会話型通信 関連項目 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の第 1 章の 11 ページ 「会話型通信」 2-12 BEA Tuxedo システム入門 EventBroker EventBroker BEA Tuxedo EventBroker は、任意の数の供給者が任意の数のサブ スクライバにメッセージをポストできる通信パラダイムを提供し ます。EventBroker を使用するクライアントとサーバのプロセスで は、サブスクリプションに基づいて相互に通信が行われるため、こ のパラダイムはパブリッシュ・アンド・サブスクライブ型の通信 と呼ばれます。EventBroker では、購読料を支払っている購読者だ けに新聞を配達するように、処理が行われます。 図 2-4 イベントのポストとサブスクライブ イベントの発信元 ( クライアントまたはサーバのいずれか ) は、変 更や問題が起こると、EventBroker に通知します。このプロセスは イベントのポストと呼ばれます。通知を受けた EventBroker は、そ のイベントの名前をサブスクライバのリストに定義されたイベン ト名と照合し、合致した場合はそのサブスクライバにイベントを 通知します。 関連項目 第 2 章の 14 ページ 「通知されるイベントのタイプ」 第 2 章の 14 ページ 「イベントの通知」 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 15 ページ 「イベント・ベースの通信」 BEA Tuxedo システム入門 2-13 第2章 BEA Tuxedo システムのアーキテクチャ 通知されるイベントのタイプ BEA Tuxedo システムでは、次のイベントが通知されます。 システム・イベント − サーバの異常終了やネットワーク障害 など、BEA Tuxedo システム・イベントの詳細が通知されます。 クライアントまたはサーバによってイベントがポストされる と、EventBroker は、ポストされたイベントの名前をそのイベ ントのサブスクライバと照合し、合致すると各サブスクリプ ションに対して指定された処理を行います。 ユーザ・イベントまたはアプリケーション定義のイベント − 特定の条件が満たされた場合に、アプリケーション・プログラ ムによってイベントがポストされます。たとえば、銀行取引ア プリケーションの場合、一定額を超える引き出しが行われると イベントがポストされます。 イベントの通知 EventBroker では、パブリッシュ・アンド・サブスクライブ型の通 信が行われます。プロセスは、EventBroker にサブスクリプション を登録し、特定のイベントに関心があることを示します。以降、指 定されたイベントが発生したことが別のプロセスから通知される と、EventBroker はそのイベントをサブスクライブしているすべて のプロセスに通知します。 2-14 BEA Tuxedo システム入門 待ち行列ベースの通信 図 2-5 イベント・ベースのメッセージング EventBroker では、次のメカニズムを使用して、イベントのパブ リッシュ ( 通知の発行 ) が行われます。 ディスク・ベースの待ち行列への登録 非同期のサービス呼び出し ユーザ・ログ・エントリ 任意通知型メッセージ システム・コマンド 待ち行列ベースの通信 BEA Tuxedo システムでは、/Q と呼ばれる待ち行列ベースのアー キテクチャが提供されています。これは、アプリケーションでデー タを継続的に格納する必要がある場合に使用します。/Q コンポー ネントでは、すべてのクライアントまたはサーバがメッセージま たはサービスの要求を待ち行列に格納できます。格納された要求 は、必ずトランザクション・プロトコルを使用して送信されるの で、安全が保証されています。 BEA Tuxedo システム入門 2-15 第2章 BEA Tuxedo システムのアーキテクチャ BEA Tuxedo システムの待ち行列は、後入れ先出し (LIFO) または 先入れ先出し (FIFO)、または時刻や優先順位に基づいて順序付け することができます。待ち行列の集まりは、待ち行列空間と呼ば れる 1 つのエンティティとして管理され、参照されます。 図 2-6 キュー・ベースのメッセージング アプリケーション待ち行列 アプリケーション待ち行列は、時間に依存しない通信を行う場合 に使用します。時間に依存しない通信とは、プログラムが互いに 独立して動作し、互いの通信を同期する必要がない通信方法です。 時間に依存しないプログラムでは、互いにアプリケーション待ち 行列にメッセージを残すことによって同期が行われます。メッ セージを待ち行列から取り出す場合は、先入れ先出し (FIFO)、優 先順位、時刻順など、任意の順序付けスキーマを使用できます。 BEA Tuxedo のクライアント・プログラムとサーバ・プログラムで は、メッセージを待ち行列に登録したり、待ち行列から取り出す ことができます。同じ待ち行列に複数のクライアントやサーバが アクセスできます。 アプリケーション待ち行列を使用するには、アクセスする待ち行 列と、その待ち行列が置かれた待ち行列空間に名前を付ける必要 があります。アプリケーションでは、複数の待ち行列空間を使用 できます。また、各待ち行列空間には、複数のメッセージ待ち行 列を格納できます。 2-16 BEA Tuxedo システム入門 要求 / 応答型通信 アプリケーション待ち行列はディスク上に存在するため、格納し たメッセージはマシンに障害が発生した場合でも利用できます。 どのような場合にアプリケーション待ち行列を使用するかは、業 務 ( たとえば、注文書の入力 ) で時間に依存しない同期をいつ行う かによって決定されます。注文書は、ディスク上の待ち行列に登 録し、品目や出荷場所など特定の注文条件によって、異なる待ち 行列空間に置くことができます。各待ち行列空間に、コストや状 態などの条件を追加することもできます。 関連項目 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の第 1 章の 16 ページ 「待ち行列ベースの通信」 要求 / 応答型通信 BEA Tuxedo システムでは、要求 / 応答型通信のインプリメントに IPC メッセージ待ち行列が使用されます。待ち行列は、コネクショ ンレス型通信の基本要素です。各サーバには、要求待ち行列と呼 ばれるプロセス間通信 (IPC) メッセージ待ち行列が割り当てられ、 各クライアントには応答待ち行列が割り当てられます。そのため、 クライアント・アプリケーションでは、サーバとの継続的な接続 を確立する代わりに、要求をサーバの待ち行列に登録して、サー バにその要求を送信できます。また、アプリケーションの応答待 ち行列からメッセージを取り出して、サーバからのメッセージを 確認して取得できます。 要求 / 応答型モデルは、以下に説明するように、同期と非同期の両 方のサービス要求に使用できます。 同期メッセージング 同期呼び出しでは、クライアントがサーバに要求を送信し、クラ イアントが待機している間にサーバが要求された処理を行いま す。その後、サーバがクライアントに応答を送信し、クライアン トが応答を受信します。 BEA Tuxedo システム入門 2-17 第2章 BEA Tuxedo システムのアーキテクチャ 図 2-7 同期要求 / 応答型通信 非同期メッセージング 非同期呼び出しでは、BEA Tuxedo クライアントは、送信したサー ビス要求の処理が完了するまで待機しません。要求を発行した後 も、別のタスク ( ほかの要求の発行など ) を実行します。最初の要 求への応答が返されると、クライアントはその応答を取得します。 図 2-8 非同期要求 / 応答型通信 2-18 BEA Tuxedo システム入門 任意通知型通信 関連項目 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 7 ページ「要求/応答型モデル (同期呼び出し)」 任意通知型通信 BEA Tuxedo システムでは、任意通知型通知と呼ばれる通信パラダ イムが提供されています。任意通知型通知が発生すると、BEA Tuxedo クライアントは要求していないメッセージを受け取りま す。この機能によって、アプリケーション・クライアントは、ア プリケーション固有のイベントが発生したときに、リアルタイム で明示的に通知を要求しなくても、そのイベントの通知を受け取 ることができます。 任意通知型メッセージは、名前 (tpbroadcast) または以前に処理 されたメッセージと共に受け取った識別子 (tpnotify) としてク ライアント・プロセスに送信されます。tpbroadcast 関数を使用 すると、サービスまたは別のクライアントにメッセージを送信で きます。メッセージは、狭い範囲または広い範囲のターゲットに 対して送信できます。配達保証付きまたは配達保証なしのメッ セージをポイント・ツー・ポイントの通知によって個々のクライ アントに送信したり (tpnotify) 、クライアントのグループに対し て情報を送信する (tpbroadcast) ことができます。たとえば、ク ライアントから照会された口座が解約されていることをサーバか らそのクライアントだけに通知できます。または、あるマシンが メンテナンスのために特定の時刻にシャットダウンされることを そのマシン上のすべてのクライアントに通知することもできま す。 プロセスが特定のイベント ( メンテナンスのためにシャットダウ ンされるマシンなど ) について通知が必要な場合は、自動的に通 知されるように要求をシステムに登録できます。登録されたイベ ントは、発生するたびにクライアントまたはサーバに通知されま す。イベントのこのような自動通信は、任意通知型通知と呼ばれ ます。 BEA Tuxedo システム入門 2-19 第2章 BEA Tuxedo システムのアーキテクチャ イベントを生成したり、イベントについて任意通知型通知を受信 するクライアントおよびサーバの数に制限はありません。そのた め、このカテゴリの通信は、管理業務が複雑になる場合がありま す。BEA Tuxedo シ ステ ムに は、任意 通知 型通 知を 管理 する EventBroker と呼ばれるツールが用意されています。 図 2-9 任意通知型通知のメッセージング 関連項目 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 13 ページ 「任意通知型通知」 サービス要求の入れ子と転送 入れ子になった要求 BEA Tuxedo システムでは、サービスがクライアントとして動作し て、別のサービスを呼び出すことができます。入れ子のレベルは、 2 レベルに制限されています。これは、3 層クライアント / サーバ・ アーキテクチャ、つまりプレゼンテーション・ロジック層、ビジ ネス・ロジック層、およびデータベース層から構成されるシステ ムで特に有用です。このようなシステムでは、プレゼンテーショ ン層で特定のビジネス関数が要求され、データベースに 1 つ以上 の照会が行われます。入れ子は 2 レベルに制限されているため、パ フォーマンスが低下することはありません。 2-20 BEA Tuxedo システム入門 サービス要求の入れ子と転送 図 2-10 入れ子になったサービス要求 入れ子になった要求の利点 入れ子になった要求を使用すると、各コード部分が限定された処 理だけを行うので、コードが少なくて済み、再利用も可能になり ます。ただし、システムのサービスが複数のサーバに分散してい る場合は、要求を入れ子にするとパフォーマンスが低下する場合 があります。入れ子になった要求が処理されている間、元のサー ビス ( 入れ子になった要求を発行したサービス ) は、応答を待機す る必要があります。つまり、応答を受信するまで、別の要求を処 理することはできません。そのため、このサービスを持つサーバ の要求待ち行列に、メッセージがバックアップされます。 BEA Tuxedo システム入門 2-21 第2章 BEA Tuxedo システムのアーキテクチャ 入れ子になったサービス要求の例 ある顧客が現金自動支払機を使って、普通口座から当座預金に預 金を移すとします。振替に必要な操作は、BEA Tuxedo アプリケー ションによって行われます。まず、顧客に代わって、クライアン トが TRANSFER サービスへの要求を発行します。この要求は、そ のサービスを提供するサーバの待ち行列に置かれます。次に、 TRANSFER サービスが WITHDRAW および DEPOSIT という 2 つの サービスを要求します。この 2 つのサービスは、別のサーバによっ て行 われ ます。WITHDRAW およ び DEPOSIT の 各サ ービ スが TRANSFER サービスに応答を返します。最後に、TRANSFER サービ スがクライアントの応答待ち行列に対して応答を送ります。クラ イアントが待ち行列から応答を取得すると、現金自動支払機の画 面に振替が完了したことを通知するメッセージが表示されます。 転送された要求 入れ子になったサービス要求に代わる方法として、要求の転送が あります。クライアントの要求を処理する代わりに、サービスは その要求を別のサービスに渡します。要求を受け取ったサービス は、要求を処理するか、または別のサービスに渡します。 2-22 BEA Tuxedo システム入門 サービス要求の入れ子と転送 図 2-11 サービス要求の転送 要求を転送できる回数に制限はありません。要求を転送したサー ビスは、その要求を受け取った別のサービスからの応答を待つ必 要がありません。そのため、入れ子になった要求とは異なり、転 送ではサーバがブロックされることはありません。ただし、転送 は X/OPEN のプロトコル X/ATMI でサポートされていないため、 アプリケーションによっては支障が出る場合があります。 関連項目 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 10 ページ 「転送された呼び出し」 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 9 ページ 「入れ子になった呼び出し」 BEA Tuxedo システム入門 2-23 第2章 BEA Tuxedo システムのアーキテクチャ BEATuxedo システムのメッセージ処理 BEA Tuxedo システム内のすべての通信は、メッセージを転送する ことによって行われます。BEA Tuxedo システムでは、オペレー ティング・システムのプロセス間通信 (IPC) メッセージ待ち行列を 使用して、クライアントとサーバ間でサービス要求のメッセージ をやり取りします。システムのメッセージとデータは、バッファ に格納され、クライアントとサーバの待ち行列間でやり取りされ ます。これは、オペレーティング・システムでサポートされたメ モリ・ベースの待ち行列です。BEA Tuxedo システムでは、メッ セージは型付きバッファにパッケージ化されます。このバッファ には、メッセージ・データと、送信されたメッセージ・データの タイプを識別するデータが格納されます。 図 2-12 要求の処理 2-24 BEA Tuxedo システム入門 BEA Tuxedo システムのメッセージ処理 クライアントは、ATMI 関数を使ってサービスを名前で要求しま す。ネーミング機能を使って MIB が照会され、指定されたサービ スが現在利用可能かどうかが確認されます。BEA Tuxedo システム では、特定の条件 ( メッセージの値 ) を満たすメッセージを特定の サーバにマップする自動ルーティング・オプションが使用されて います。これは、データ依存型ルーティングと呼ばれます。メッ セージにデータ依存型ルーティングが使用される場合、ルーティ ング・アルゴリズムではバッファに格納されたデータが使用され ます。このアルゴリズムによって、サービス要求を処理できるサー バのグループが選択されます。一部のサーバに要求が集中し、同 じサービスを宣言するほかのサーバがアイドル状態になることを 避けるために、BEA Tuxedo システムではサービス要求をすべての サーバ間で均等に分散するために MIB を使用しています。これは ロード・バランシングと呼ばれます。 選択されたサーバに対してローカルのサービス要求が用意され、 そのサーバの待ち行列に定義済みの優先順位で登録されます。こ れはサービスの優先順位付けと呼ばれます。サービス要求がサー バ上に置かれると、ランタイム・システムによってメッセージが 優先順位に従って取得されます。メッセージは、適切なサービス にディスパッチされて、処理されます。その後、クライアントの 待ち行列に結果が返されます。 BEA Tuxedo システムで提供されるソフトウェアには、メッセージ 処理の際にアプリケーションが自動的に、そして定期的に使用で きる機能があります。これらの機能には、たとえば、データの符 号化と復号化、データの圧縮と圧縮解除、トランザクション・コ ンテキストの設定、セキュリティに関する処理などがあります。ま た、BEA Tuxedo システムのソフトウェアは、サービス関数をディ スパッチし、それを適切に前処理されたバッファに渡すことに よって、アプリケーションのビジネス・ロジックを呼び出します。 BEA Tuxedo システム入門 2-25 第2章 BEA Tuxedo システムのアーキテクチャ サービス・ルーチンが実行されると、応答 ( 型付きバッファ ) が返 されます。ランタイム・システムは、メッセージを自動的に符号 化することによって、クライアントへの応答を用意します。つま り、バイトの並び順が異なるマシン間で転送できるようにデータ をパッケージ化し、データがネットワークやプラットフォームの 境界を越えて転送できるようにします。その後、メッセージをク ライアントに送信します。このプロセスはデータの符号化と呼ば れます。クライアント上のランタイム・システムは、応答メッセー ジを取得し、必要に応じて復号化した後、FML バッファ ( またはほ かのメッセージ・バッファ・タイプのバッファ ) を送信してアプ リケーション・データをパッケージ化します。必要に応じて、タ イプの検証、符号化、ルーティング、およびロード・バランシン グが行われます。サービス要求は、同期でも非同期でも実行され ます。 リモート要求は、ローカルの BRIDGE を通ってリモート・マシン に到達します。リモート・マシンでは、リモートの BRIDGE がク ライアントとして動作し、クライアントとサーバが同じマシン上 にあるかのように要求が処理されます。BRIDGE は、標準のデータ 符号化 / 復号化を行い、標準のネットワーク転送を使用して通信し ます。クライアントとサーバからは、BRIDGE は通常のローカル・ サーバのように見えます。 サービス要求処理の利点 コネクションレス型の処理 − この処理をクライアント / サー バの直接通信と組み合わせると、接続の確立に関連するオー バーヘッドを減らすことができます。 ネットワーク・トラフィックの削減 − サービス要求はリモー ト・マシン上の複雑なサービスを呼び出し、必要最小限のデー タだけを送信し、最小限の結果を受信します。 関連項目 第 2 章の 10 ページ 「BEA Tuxedo のメッセージング・パラダ イム」 第 2 章の 27 ページ 「型付きバッファ」 2-26 BEA Tuxedo システム入門 型付きバッファ 型付きバッファ すべての ATMI 関数は、型付きバッファを使ってデータを送受信 します。BEA Tuxedo システムでは、異種のマシン間での翻訳と データ変換が可能です。BEA Tuxedo プログラムではバッファが使 用されているので、異なるデータ表現の異種プラットフォーム間 でやり取りされるデータを変換する必要はありません。 バッファとは、データの論理的な入れ物として機能するメモリ領 域です。バッファにメタデータ ( バッファ自体に関する情報 ) が含 まれていない場合、そのバッファは型なしのバッファと呼ばれま す。バッファ内に格納できる情報として、タイプとサブタイプ、ま たはバッファを特徴付ける文字列名などのメタデータが含まれて いる場合、そのバッファは型付きバッファと呼ばれます。 型付きバッファは、BEA Tuxedo システムでサポートされる任意の プロトコルを使用して、どの種類のネットワークからもどの種類 のオペレーティング・システムにも送ることができできます。異 なるデータ表現のプラットフォーム上で使用することもできま す。そのため、型付きバッファを使用すると、異種マシン間での 翻訳とデータ変換のためのタスクが簡略化されます。 BEA Tuxedo システムでは、次の 5 種類の型付きバッファがサポー トされています。 STRING VIEW CARRAY FML XML バ ッ フ ァ・タ イ プ は、コ ン フ ィ ギ ュ レ ー シ ョ ン・フ ァ イ ル の MACHINES セクションに定義されている ENVFILE パラメータで指 定します。コンフィギュレーション・ファイルの SERVERS セク ションの ENVFILE パラメータでバッファ・タイプを指定したり上 書きすると、バッファ・タイプが必要なプロセスでそれらのバッ ファ・タイプを使用できなくなる場合があります。 BEA Tuxedo システム入門 2-27 第2章 BEA Tuxedo システムのアーキテクチャ メッセージ・バッファの各種のタイプの定義については、『BEA Tuxedo のファイル形式とデータ記述方法』の tuxtypes(5) の tm_typesw の説明を参照してください。tm_typesw を変更して、 特定のサーバで特に必要なバッファ・タイプだけを含むようにし ておくと便利です。 バッファ・タイプの特徴 ATMI 通信関数を使用する場合、まずアプリケーションで tpalloc を使用して、バッファのサイズ、タイプ、およびサブタイプ ( 省略 可能 ) を指定し、システムからバッファを取得する必要があります。 BEA Tuxedo システムによってバッファ・タイプが認識されて処理さ れるため、データは BEA Tuxedo システムによってサポートされてい るどの種類のネットワーク、プロトコル、およびオペレーティング・ システム上でも転送できます。次の表は、BEA Tuxedo の環境で使用 できる各バッファ・タイプを示しています。 表 2-3 各バッファ・タイプの特徴 バッファ・ タイプ CARRAY 説明 使用対象 文字配列型は、曖昧に処理される文字の 集まりです。 BEA Tuxedo システム によって解釈されず、 データ依存型ルー ティング、符号化、ま たは復号化を必要と しないデータ 文字にはどのような解釈も行われま せん。 サブタイプは指定されません。 ATMI 関数への入力として使用され る CARRAY メッセージには、アプリ ケーションでバッファ長を指定する 必要があります。 2-28 BEA Tuxedo システム入門 型付きバッファ バッファ・ タイプ FML 説明 使用対象 フィールド操作言語 (FML) は、タグ付き 値を格納するデータ構造です。値には型 が付いていて、複数指定したり長さを変 えることができます。 通信 フィールドの作成、 変更、削除、または アクセス FML バッファは、フィールドの作成、変 更、削除、またはアクセスの操作に使用 される抽象的なデータ型です。プログラ ムでは、識別子を参照することによって、 フィールド化バッファ内のフィールドに アクセスしたり更新します。FML 関数に よ っ て、フ ィ ー ル ド の ロ ケ ー シ ョ ン と データ型が実行時に変換され、操作が実 行されます。 FML へのインターフェイスには、フィー ルド識別子およびフィールド長として 16 ビ ッ ト を 使 用 す る も の (FML16) と、32 ビットを使用するもの (FML32) がありま す。 16 ビットのインターフェイスでは、一 意なフィールドを約 8000 個まで、文 字列や配列を 64,000 バイトまで使用 できます。 32 ビットのインターフェイスでは、一 意なフィールドを数百万個、バッファ 長として 20 億バイトまで使用できま す。 この 2 つのインターフェイスの機能は同 じです。FML の威力は、その柔軟性にあ り ま す。各 メ ッ セ ー ジ に 対 す る ア プ リ ケーションのニーズに応じて、バッファ のサイズを変えることができます。文字 フィールドも長さを変えられるため、不 要な領域がなくなります。 BEA Tuxedo システム入門 2-29 第2章 BEA Tuxedo システムのアーキテクチャ バッファ・ タイプ 説明 使用対象 フィールド化バッファによって、アプリ ケーションはデータから独立できます。 アプリケーションの作成時に、フィール ド化バッファのどこに、どのようにデー タが格納されるのかを知る必要はありま せん。FML によって対応するフィールド にアクセスできるため、単にフィールド 名を指定すれば値が返されます。また、 FML には変換関数もあるため、記憶領域 の種類に関係なく、特定のデータ形式と してフィールドを格納したり、取り出す ことができます。 FML バッファは、1 つのフィールドに複数 の値を格納することもできます。フィー ルド化バッファの可変長の型により、同 一のフィールドがある場合でも格納した り、取り出すことができます。 フィールド化バッファは、メッセージご とに異なるフィールドの集まりをクライ アントとサーバ間でやり取りしたり、ア プリケーション待ち行列にフィールドを 格納する場合に使用すると便利です。特 に ク ラ イ アン ト と サ ーバ 間 の イン タ ー フェイスが変わる可能性がある場合は、 FML を使用することをお勧めします。 STRING NULL 文字で終了する非 NUL 文字の集 まりです。データ型は文字であり、デー タ長はバッファ内の文字数を NUL 文字 まで数えた値です。サブタイプを指定す る必要はありません。 2-30 BEA Tuxedo システム入門 C プログラム 型付きバッファ バッファ・ タイプ VIEW 説明 使用対象 VIEW は単に C 構造体または COBOL レ コードで、それに対応してレコード内で どのフィールドと型がどの順序で現れる かが定義されています。このバッファは、 データ要素の固定的な集まり、または構 造体やレコードに使用します。サブタイ プを使用して、レコード形式名を指定し ます。 VIEW レコードはフラットなデータ構造 です。ほかの構造体に存在する構造体、ま たは構造体やポインタの配列はサポート されていません。長精度型、文字型、10 進数型などのデータ型がサポートされて います。 BEA Tuxedo ア プ リ ケーションで使用さ れる C 構造体および COBOL レコード VIEW は、BEA Tuxedo システムで C 構造 体および COBOL レコードを使用するた めに提供されています。BEA Tuxedo のラ ンタイム・システムでは、実行時に読み 取られる VIEW 記述に基づいて、レコー ド形式が認識されます。VIEW を割り当て る場合、VIEW のバッファ・タイプおよび 名前と合致するサブタイプがアプリケー ションで指定されます。ランタイム・シ ステムでは、次の操作が行われます。 構造体のサイズに基づいて、必要な領 域が決定されます。アプリケーション でバッファ長を指定する必要はあり ません。 要求または応答で送信するデータ量 が計算され、異機種間でメッセージを やり取りする場合に符号化と復号化 が行われます。 BEA Tuxedo システム入門 2-31 第2章 BEA Tuxedo システムのアーキテクチャ バッファ・ タイプ XML 説明 XML バッファを使用すると、BEA Tuxedo ア プ リ ケ ーシ ョ ン 内 およ び ア プリ ケ ー ション間のデータ交換に XML を使用で きるようになります。BEA Tuxedo アプリ ケーションでは、単純な XML バッファを 送受信したり、それらのバッファを適切 なサーバにルーティングできます。解析 など、XML 文書を扱うためのすべてのロ ジックはアプリケーション内に定義され ています。XML 文書は、文書のテキスト を符号化した一連の文字、文書の論理構 造、および構造に関連するメタ情報から 構成されます。 BEA Tuxedo システムの XML パーサは、 文字符号化の自動検出、文字コード変換、 要 素 内 容 お よ び 属 性 値 の 検 出、お よ び データ型の変換を行います。 XML バッファでは、データ依存型ルー ティングがサポートされています。 使用対象 XML 文書および データグラム Web サーバから ユーザのブラウザ へのデータ転送な ど、人とマシンの データ交換 アプリケーション 間、ま た は マ シ ン からマシンへの データ交換 関連項目 『C 言語を使用した BEA Tuxedo アプリケーションのプログラ ミング』の 第 3 章の 32 ページ 「バッファのカスタマイズ」 MIB MIB プ ログ ラミ ング・イ ンタ ーフ ェイ スを 使用 する と、BEA Tuxedo システムの操作を簡単に管理することができます。特に、 独自のプログラムによってアプリケーションの監視、コンフィ ギュレーション、チューニングを行うことができます。MIB は、 次のように定義されます。 FML 属性として定義された、インプリメンテーションに依存し ない管理データベース。 2-32 BEA Tuxedo システム入門 MIB ユーザのタイプ ATMI 関数を使用して、BEA Tuxedo システムへの照会 (get 使 用してシステムから情報を取得すること )、または BEA Tuxedo システムの更新 (set を使用してシステムの情報を変更するこ と ) をいつでも行うことができるプログラミング・インター フ ェ イ ス。こ れ ら の 関 数 に は、tpalloc、tprealloc、 tpgetrply、tpcall、tpacall、tpenqueue、tpdequeue な どがあります。 関連項目 『BEA Tuxedo のファイル形式とデータ記述方法』の MIB(5) 第 2 章の 33 ページ 「MIB ユーザのタイプ」 第 2 章の 34 ページ 「MIB のクラス、属性、状態」 MIB ユーザのタイプ MIB では、システム管理者、システム・オペレータ、それ以外の 3 種類のユーザが定義されています。次の表は、各ユーザを示して います。 ユーザのタイプ 説明 アプリケーション管 理者 アプリケーションの正常な動作を維持するための責任 者。管理者には、すべての管理ツールと MIB のすべて の管理機能を使用する権限が与えられます。管理者は、 稼動中のアプリケーションのコンフィギュレーショ ン、管理、変更を行います。 システム・オペレータ 稼動するアプリケーションの日々の操作を監視し、問 題に対応します。オペレータは、実行中のアプリケー ションに関する統計を監視します。イベントと警告に 対して、サーバの起動やマシンのシャットダウンなど の対処を行う場合もあります。アプリケーションの再 コンフィギュレーション、サーバまたはマシンの追加、 マシンの削除は行いません。 BEA Tuxedo システム入門 2-33 第2章 BEA Tuxedo システムのアーキテクチャ ユーザのタイプ 説明 それ以外のユーザ MIB を読み取る必要はあるが、アプリケーションを変 更する権限を持たない人やプロセス ( カスタム・プロ グラムなど )。 MIB のクラス、属性、状態 クラスとは、BEA Tuxedo アプリケーションを構成するサーバやマ シンなどのエンティティの種類です。属性とは、クラス内のオブ ジェクトの特徴を表すもので、ID、状態、コンフィギュレーショ ン・パラメータ、実行時の統計などがあります。属性には、MIB の操作と応答に共通するもの、および個々のクラスに共通するも のがあります。すべてのクラスには、オブジェクトの状態を示す 状態属性があります。MIB 上でオブジェクトの状態を変更する操 作を呼び出している場合、オブジェクトの状態はユーザへの応答、 または変更後の新しい状態のいずれかになります。 MIB (5) リファレンス・ページに定義されている共通属性は、クラ スに依存しません。これらの属性は、入力操作を制御したり、ユー ザが何をしようとしているのかを MIB に伝達したり、特定のクラ スに依存しない出力バッファの特徴をプログラマに示します。 BEATuxedo アプリケーション処理サービス BEA Tuxedo システムには、次のアプリケーション処理サービスが 提供されています。 データ圧縮 データ依存型ルーティング データ符号化 データ暗号化 データ・マーシャリング ロード・バランシング メッセージの優先順位付け 2-34 BEA Tuxedo システム入門 データ圧縮 サービスおよびイベントのネーミング データ圧縮 データ圧縮とは、ネットワーク上またはリモート・ドメインへの 転送を高速化するために、アプリケーション・バッファを縮小す るプロセスです。アプリケーション・バッファの最大サイズを指 定し、そのサイズ以上のアプリケーション・バッファが自動的に 圧縮されるように設定できます。バッファが送信先に到着すると、 データは圧縮解除されて元のサイズに戻ります。 マシン間でファイルを送付する前にデータ圧縮を行うと、ネット ワークのパフォーマンスが向上します。 圧縮の過程ではデータのスクランブリングも行われるので、セ キュリティも若干強化されます。 注記 データ圧縮は、暗号化でも頻繁に行われます。 図 2-13 データ圧縮 データ依存型ルーティング BEA Tuxedo システムでは、データ依存型ルーティングと呼ばれる 操作を使用して、クライアントが同じサービスへの要求をその サービスの複数のコピーに対して送信できるようにします。サー ビスのどのコピーが最終的に要求を受け入れて処理するのかは、 要求メッセージのデータによって決まります。管理者がアプリ ケーションにデータ依存型ルーティングを設定すると、クライア ントの要求は要求内のデータに基づいて自動的にサーバにルー ティングされます。 BEA Tuxedo システム入門 2-35 第2章 BEA Tuxedo システムのアーキテクチャ 百科事典の第 1 巻に「A」で始まる項目が複数含まれているよう に、アプリケーションに同じサービスのコピーが複数含まれてい る場合、各コピーに対して一意な目的が割り当てられます。その サービスのすべてのコピーのリストと、各コピーの目的に関する 情報の識別文字列は、BEA Tuxedo の掲示板のルーティング・テー ブルに保持されています。システムがクライアントの要求を受信 すると、要求メッセージ内の識別文字列を読み取り、その文字列 を掲示板のルーティング・テーブルで検索します。文字列が合致 すると、クライアントの要求を転送する適切なサーバが識別され ます。 注記 掲示板のルーティング・テーブルは、必要に応じて変更でき ます。 データ依存型ルーティング データ依存型ルーティングは、クライアントが次のものにサービ スを要求した場合に有用です。 水平分離型データベース 規則対応型サーバ 分散アプリケーション 水平分離型データベースとは、セグメントに分割された情報リポ ジトリです。各セグメントには、異なるカテゴリの情報が格納さ れます。これは、各本棚に異なるカテゴリ ( 伝記、フィクション など ) の本が収納されている図書館に似ています。 規則対応型サーバとは、サービス要求をサービス・ルーチンに転 送する前に、サービス要求が特定のアプリケーション固有の条件 を満たしているかどうかを判定するサーバです。ルール・ベース のサーバは、ほとんど同じ複数の要求に対して、ビジネス上の理 由で多少異なる処理を行う場合に使用すると有用です。 2-36 BEA Tuxedo システム入門 データ依存型ルーティング 分散アプリケーションは、ネットワークを通して接続された複数 のマシン上の 1 つ以上のサーバと通信する 1 つ以上のローカルま たはリモートのクライアントから構成されます。 クライアント ( ま たはクライアントとして動作するサーバ ) は、特定のサービスに 対する要求を発行します。要求のアドレスは、その要求を実行で きるサーバを識別するデータ ( 要求と同じバッファで転送される データ ) によって決定されます。要求を実行できるサーバが複数 存在する場合もあります。BEA Tuxedo システムでは、掲示板の ルーティング条件とデータが照合されて、要求を受け取るサーバ が決定されます。 水平分離型データベースでのデータ依存型ルーティングの例 銀行取引アプリケーションで、2 つのクライアントが口座 3 と口座 17 という 2 つの口座の現在の残高を照会する要求を発行したとし ます。アプリケーションでデータ依存型ルーティングが使用され ている場合、BEA Tuxedo システムでは次の処理が行われます。 1. 2 つのサービス要求で指定された口座番号 (3 と 17) を取得しま す。 2. BEA Tuxedo の掲示板のルーティング・テーブルで、どのサー バがどの範囲のデータを処理するのかを確認します。この例で は、口座 1 ∼ 10 に対するすべての要求をサーバ 1 が処理し、 口座 11 ∼ 20 に対するすべての要求をサーバ 2 が処理してい ます。 3. それぞれの要求を該当するサーバに送信します。つまり、口座 3 への要求をサーバ 1 に転送し、口座 17 への要求をサーバ 2 に転送します。 BEA Tuxedo システム入門 2-37 第2章 BEA Tuxedo システムのアーキテクチャ 次の図は、このプロセスを示しています。 図 2-14 水平分離型データベースデータベースでのデータ依存型 ルーティング 規則対応型サーバでのデータ依存型ルーティングの例 次の規則を持つ銀行取引アプリケーションがあるとします。 顧客は、特別なパスワードを入力しなくても、5 万円まで引き 出すことができます。 5 万円を超える額を引き出すには、特別なパスワードを入力す る必要があります。 2 つのクライアントが 1 万円と 8 万円の引き出しを要求したとし ます。引き出しの規則でデータ依存型ルーティングが有効になっ ている場合、BEA Tuxedo では次のような処理が行われます 1. 2 つのサービス要求で指定された引き出し額 (1 万円と 8 万円 ) を取得します。 2-38 BEA Tuxedo システム入門 データ依存型ルーティング 2. BEA Tuxedo の掲示板のルーティング・テーブルで、要求され た額をどのサーバが処理するのかを確認します。この例では、 5 万円までのすべての引き出し要求をサーバ 1 が処理し、5 万 円を超えるすべての引き出し要求をサーバ 2 が処理していま す。 3. それぞれの要求を該当するサーバに送信します。つまり、1 万 円の要求をサーバ 1 に転送し、8 万円の要求をサーバ 2 に転送 します。 次の図は、このプロセスを示しています。 図 2-15 規則対応型サーバでのデータ依存型ルーティング BEA Tuxedo システム入門 2-39 第2章 BEA Tuxedo システムのアーキテクチャ 分散アプリケーションでのデータ依存型ルーティングの例 次の図は、クライアントの要求がサーバにルーティングされる方法を 示しています。この例では、bankapp という銀行取引アプリケーショ ンでデータ依存型ルーティングが使用されています。bankapp には、 3 つのサーバ・グループ (BANK1、BANK2、BANK3) と 2 つのルーティ ング条件 (Account ID と Branch ID ) があります。WITHDRAW、 DEPOSIT、 および INQUIRY の 3 つのサービスは、 Account_ID フィー ルドを使用してルーティングされます。サービス OPEN および CLOSE は、Branch_ID フィールドを使用してルーティングされます。 2-40 BEA Tuxedo システム入門 データ依存型ルーティング 図 2-16 ルーティング条件を使用した銀行取引のサンプル・アプ リケーション 前の図では、要求は次の表に示すようにルーティングされます。 引き出し、預け入れ、照会、開設 / 閉鎖を行う口座 ルーティング先 支店番号 1 ∼ 4 の口座番号 10000 ∼ 49999 銀行 1 支店番号 5 ∼ 7 の口座番号 50000 ∼ 79999 銀行 2 BEA Tuxedo システム入門 2-41 第2章 BEA Tuxedo システムのアーキテクチャ 引き出し、預け入れ、照会、開設 / 閉鎖を行う口座 ルーティング先 支店番号 8 ∼ 1 の口座番号 80000 ∼ 109999 銀行 3 データの符号化と復号化 符号化と復号化を行うと、データ表現 ( バイトの順序や文字セッ トなど ) が異なるメッセージをマシン間で転送できるようになり ます。BEA Tuxedo システムでは、マシンに依存しない表現にデー タを符号化および復号化して、マシン間でのデータの転送を可能 にしています。デフォルトでは、XDR アルゴリズムが採用されて います。BEA Tuxedo システムの関数をユーザ定義の関数で置き換 えると、このアルゴリズムをカスタマイズできます。符号化およ び復号化は、マシン間でのみ使用されます。また、リモート・マ シンのデータ表現がローカル・マシンのものと異なる場合にのみ 使用されます。符号化と復号化によって、異なるデータ構造を持 つマシンが異機種の BEA Tuxedo システムで動作できるようにな ります。プログラマは、それぞれの環境に適した表現でデータを 管理できます。 BEA Tuxedo システムでは、バッファ・タイプを使用して、メッ セージに含まれるフィールドのタイプが判別されたり、コード ディングに必要なマッピングが行われます。このマッピングは、 X_OCTET や CARRAY などの構造化されていないバッファ・タイプ によって行われるものではありません。そのため、異機種が混在 している環境でも、開発者は X_OCTET および CARRAY 型バッファ を自由に運用できます。 データの暗号化 暗号化とは、メッセージをコード化された形式に変換して、ユー ザが解読できないようにすることです。暗号化されたメッセージ は、送信先に到着すると解読されます。つまり、元の形式に変換 されます。 2-42 BEA Tuxedo システム入門 データ・マーシャリング 図 2-17 データの暗号化 暗号化によってデータ内のビット数が増えることはありません が、メッセージ送信での処理時間は増えます。ただし、暗号化で データが圧縮されるため、ネットワーク上に送信されるデータ量 が減少して、処理時間の増加が相殺される場合もあります。また、 データが圧縮されるときに多少のスクランブリングが行われるの で、セキュリティも若干強化されます。 データ・マーシャリング データ・マーシャリングとは、BEA Tuxedo システムによって提供 される言語ベースの TxRPC (X/Open-TxRPC) を使用して情報を扱 う方法です。TxRPC はリモート・プロシージャ・コール用のプロ トコルで、グローバル・トランザクションがサポートされます。 TxRPC 呼び出しは、ローカル・プロシージャ・コールのように見 えます。しかし、C 言語の関数が呼び出されると、関数に渡され る引数がパッケージ化されてサーバに送られ、そこで呼び出され た関数の処理が行われます。このような引数のパッケージ化を マーシャリングと呼びます。関数の引数は、ネットワークやプラッ トフォームの境界を越えることができるようにマーシャリング、 つまりパッケージ化されます。そして、呼び出されたリモート・ プロシージャに渡される前に、送信先でマーシャリングが解除さ れて、プロシージャで使用できる状態になります。 BEA Tuxedo システム入門 2-43 第2章 BEA Tuxedo システムのアーキテクチャ このプロセスは、クライアント ( 呼び出し元のプログラム ) および サーバ ( リモート・プロシージャ ) に透過的です。マーシャリング とマーシャリング解除のルーチンは、BEA Tuxedo のインターフェ イス定義言語 (IDL) コンパイラによって自動的に生成されます。 IDL コンパイラは RPC の記述を受け取り、クライアント・プログ ラムとサーバ・プログラムに対してスタブと呼ばれるルーチンを 生成します。これらのスタブには、クライアントとサーバがマー シャリングされたデータを交換するための通信ロジック、および マーシャリングとマーシャリング解除のロジックが含まれていま す。 図 2-18 データ・マーシャリング 2-44 BEA Tuxedo システム入門 ロード・バランシング ロード・バランシング ロード・バランシングとは、同じサービスを提供するサーバ間で サービス要求を均等に分散する BEA Tuxedo システムの機能です。 この機能を使用すると、負荷の重いサーバがある一方で、アイド ル状態または使用頻度の低いサーバが生じる状態を防ぐことがで きます。要求をサービス・ルーチンに送信する前に、その要求を 処理できるすべてのサーバがシステムで識別され、コンフィギュ レーション内のすべてのサーバで負荷を均衡化するために最も適 したサーバが選択されます。 ロード・ファクタの割り当て ロードとは、サービスの実行に必要な時間に基づいて、サービス 要求に割り当てられた数値のことです。ロードはサービスに割り 当てられるので、BEA Tuxedo システムで要求間の関係を識別でき るようになります。コンフィギュレーション内の各サーバによっ て実行されている処理量、つまり負荷の合計をトラッキングする ために、管理者はすべてのサービスとサービス要求にロード・ファ クタを割り当てます。ロード・ファクタとは、あるサービスまた は要求を実行するために必要な時間を示す数値です。これらの数 値に基づいて、各サーバに対して統計が生成され、各マシンの掲 示板で維持されます。各掲示板では、各サーバの負荷が累積され ます。そのため、すべてのサーバがビジー状態になった場合に、最 も負荷の低いサーバを選択できます。 システム全体に対して、ロード・バランシング・アルゴリズムを 使用するかどうかを制御できます。たとえば、必要な場合のみ、つ まり複数の待ち行列を使用する複数のサーバによってサービスが 提供される場合のみ、このアルゴリズムを使用するように設定で きます。1 つのサーバだけで提供されるサービス、または MSSQ ( 複数サーバ、単一待ち行列 ) にある複数のサーバによって提供さ れるサービスは、ロード・バランシングを必要としません。これ らのサービスの LDBAL パラメータは、N に設定します。それ以外 の場合は、LDBAL に Y を設定します。 BEA Tuxedo システム入門 2-45 第2章 BEA Tuxedo システムのアーキテクチャ ロード・ファクタの割り当て (UBBCONFIG の SERVICES セクショ ン ) を決定する場合は、アプリケーションを長時間実行し、各サー ビスの実行に要する平均時間を記録します。平均値に近い時間を 要するサービスには、LOAD 値に 50 (LOAD=50) を指定します。平 均値より長い時間がかかるサービスには LOAD>50、短い時間の サービスには LOAD<50 を指定します。 図 2-19 ロード・バランシング メッセージの優先順位付け 優先順位によって、サーバが待ち行列からサービス要求を取り出 す順序が決定されます。優先順位は、クライアントによって個々 のサービスに割り当てられます。1 ∼ 100 までの値が使用され、100 が最も高い優先順位です。 2-46 BEA Tuxedo システム入門 メッセージの優先順位付け すべてのサービスには、優先順位の初期値として 50 が割り当てら れます。サーバの優先順位の初期値は、アプリケーションのコン フィギュレーション時に変更できます。サービスを定義した後、こ れらのサービスに適切な優先順位を割り当てることができます。 たとえば、ビジネス上の優先順位が比較的高いサービスに優先順 位 70 を設定すると、このサービスはこれよりも低い優先順位 50 のサービスよりも先に待ち行列から取り出されます。次の例では、 サーバが A ( 優先順位 50)、B ( 優先順位 50)、および C ( 優先順位 70) というサービスを提供しています。 図 2-20 メッセージの優先順位付け C の優先順位が高いため、サービス C に対する要求は、常に A ま たは B に対する要求よりも先に待ち行列から取り出されます。A および B に対する要求は、同じ優先順位になります。この機能は、 アプリケーションで要求の緊急度や重要度が異なる場合に使用す ると有用です。 「枯渇防止策」は、優先順位の低いメッセージが待ち行列でいつま でも待ち続けるのを防ぐためのメカニズムです。この方法では、優 先順位に関係なく、10 個単位のメッセージの 10 番目にあるものが FIFO ( 先入れ先出し ) の順序で待ち行列から取り出されます。先 頭から 9 番目までのメッセージは、優先順位に従って取り出され ます。 BEA Tuxedo システム入門 2-47 第2章 BEA Tuxedo システムのアーキテクチャ ネーミング BEA Tuxedo システムでは、サービス名、メッセージ待ち行列名、 イベント名の 3 つのネーミング・デバイスが使用されています。名 前には、任意の単語または英数字の文字列を使用できます。ただ し、ピリオド「.」で始まる文字列は使用できません。管理サーバ でも BEA Tuxedo システムの同じインフラストラクチャが使用さ れるため、システム・リソースとアプリケーション・リソースは 明確に区別する必要があります。 ネーミング・サービス サービスに名前を付けると、あるアプリケーション・コンポーネ ントが別のコンポーネントをその名前から見つけられるようにな ります。名前には、単純な単語 (「deposit」など ) や英数字の文字 列 (「deposit2」など」) を使用できます。名前は、アプリケーショ ンの規模、およびアプリケーション・コンポーネント間の全体的 な関係のマッピイングに基づいて選択します。これらのマッピン グまたはサービスは、アプリケーション・コンポーネントを記載 した電話帳のページに似ています。 BEA Tuxedo システムのサーバをアクティブにすると、掲示板 (MIB の動的な部分 ) によって、そのサーバのサービス名が宣伝さ れます。サービス名はサーバの物理アドレスと対応付けられてい るので、要求をサーバにルーティングできます。プログラマがア プリケーションで使用する名前は、完全に位置透過的です。クラ イアント・プログラムがサービスを名前で要求すると、BEA Tuxedo システムは掲示板でその名前のレジストリを調べます。名前のレ ジストリには、文字列の名前 (TICKET など ) をマシン名に変換す るために必要な情報と、そのサービスを宣言しているサーバの物 理アドレスが定義されています。BEA Tuxedo システムでは、これ らを使用して要求を該当するサーバに送信します。 2-48 BEA Tuxedo システム入門 ネーミング 図 2-21 名前によるサービスの検索 サービスの宣言 BEA Tuxedo システムでは、2 種類の管理サーバを使って、掲示板 上の情報をアプリケーション内のすべてのアクティブなマシンに 配布します。 DBBL − 特別掲示板連絡 (DBBL) サーバは、MIB に対するグ ローバルな変更を複製転送し、MIB の静的な部分を保ちます。 DBBL は、アプリケーションにかかわる各種のマシンの状態を 調整します。DBBL は、アプリケーション全体に対して 1 つだ け存在します。対障害性を増やすために、ほかのマシンに移行 することができます。 BBL − 掲示板連絡 (BBL) サーバは、掲示板を管理します。BBL はアプリケーションのアクティブなマシンごとに存在します。 BBL は、ローカルの MIB への変更を調整し、自分と同じマシ ン上にあるアクティブなアプリケーション・プログラムが正常 であるかどうかを検証します。 BEA Tuxedo システム入門 2-49 第2章 BEA Tuxedo システムのアーキテクチャ イベントのネーミング BEA Tuxedo システムでは、パブリッシュ・アンド・サブスクライ ブのメカニズムが提供されています。クライアントおよびサーバ は、特定のイベントが発生したときに警告 ( またはメッセージ ) を 受信するための要求を動的に登録したり削除できます。ほかのク ライアントおよびサーバは、アプリケーションで発生したユーザ 定義のイベントまたはシステム・イベントをポストします。クラ イアントまたはサーバが特定のイベントに関する通知が必要なく なった場合、該当するサブスクリプションを取り消すことができ ます。 関連項目 第 2 章の 13 ページ 「EventBroker」 BEATuxedo の管理サービス BEA Tuxedo システムには、次の管理サービスが必要です。これら は、システム・サーバによって提供されます。 アプリケーション待ち行列管理 中央集中型のアプリケーション・コンフィギュレーション 分散アプリケーション管理 アプリケーションの動的な再コンフィギュレーション イベント管理 セキュリティ管理 アプリケーションの起動とシャットダウン トランザクション管理 Workstation 管理 注記 管理サービスについては、第 3 章の 1 ページ 「BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点」を参 照してください。 2-50 BEA Tuxedo システム入門 第3章 BEA Tuxedo システム・インフラストラク チャに対する 3 つの視点 BEA Tuxedo システムの基本インフラストラクチャ 管理に対する視点 : 管理ツール BEA Tuxedo の管理サービス 開発の視点 : ATMI の使用 ランタイム・システムの視点 : 各種コンフィギュレーションに おけるツールの使用 BEATuxedo システムの基本インフラストラクチャ BEA Tuxedo システムは、アプリケーション・サービス要求の効率 的なルーティング、ディスパッチ、および管理、イベントのポス トと通知、そしてアプリケーション待ち行列のためのインフラス トラクチャを提供します。このインフラストラクチャは、次の 3 つの視点から分析することができます。 管理に対する視点 − アプリケーションを管理するための各種 ツール。 開発に対する (ATMI を使用した ) 視点 − ATMI を使用して実 行できるタスク。クライアントは、ATMI を通してサービスを 要求します。サーバ・プログラムはサービスをグループ化し、 それらのサービスは ATMI によって定義された規則に従って 呼び出されます。アプリケーション設計者は、 BEA Tuxedo ラ ンタイム・システムをアプリケーション・コードにリンクする ことによって、クライアント・プログラムおよびサーバ・プロ グラムを構築します。 BEA Tuxedo ランタイム・システムに対する視点 − シングル・ ドメイン、分散ドメイン、およびマルチ・ドメインの各コン フィギュレーション。 BEA Tuxedo システム入門 3-1 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 管理に対する視点 : 管理ツール BEA Tuxedo システムの MIB には、アプリケーションの操作に必 要なすべての情報が格納されています。MIB はプログラム可能な 設計になっており、カスタムの管理プログラムを作成できます。管 理ツールは MIB の周囲に構築され、MIB に対するさまざまなイン ターフェイスを提供します。このようなツールには、次のものが あります。 BEA Administration Console − アプリケーションの監視や動的 なコンフィギュレーションを行うための Web ベースのツー ル。 BEA Tuxedo 管理サーバ − 分散アプリケーションの管理タス クの大部分を自動化するサーバ。このようなタスクには、サー ビスおよびイベントのネーミング、アプリケーションの起動と シャットダウン、アプリケーションの動的な再コンフィギュ レーションなどがあります。 BEA Tuxedo MIB アプリケーション・プログラミング・インター フェイス − MIB の情報にアクセスしたり、変更を行うための 関数。 コマンド行ユーティリティ − アプリケーションの起動 (tmboot)、 終了 (tmshutdown)、コンフィギュレーション (tmconfig)、管理 (tmadmin) に使用するコマンド。 『BEA Tuxedo コマンド・リファ レンス』を参照してください。 EventBroker − 管理者に障害や例外の発生を通知するメカニズ ム。 3-2 BEA Tuxedo システム入門 管理に対する視点 : 管理ツール 図 3-1 アプリケーションを管理するためのツール 使用可能な BEATuxedo システムの MIB 管理情報ベースは、すべてのアプリケーションに共通するコア MIB と、いくつかのコンポーネント MIB ( オプション ) から構成 されています。コア MIB は TM_MIB と呼ばれ、すべての BEA Tuxedo アプリケーションに必要なアプリケーションの構成要素が 定義されています。また、これらのアプリケーションの構成要素 の管理に使用することもできます。TM_MIB では、BEA Tuxedo シ ステムのアプリケーションがクラス ( サーバ、グループ、マシン、 ドメインなど ) として定義されています。各クラスは、各種の属 性 (ID、状態など ) によって特徴付けられるオブジェクトから構成 されます。 BEA Tuxedo システム入門 3-3 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 各コンポーネント MIB では、BEA Tuxedo システムのサブシステ ムが定義されています。現在、次のコンポーネントを使用できま す。 ACL_MIB − アクセス制御リストの管理に使用されます。 APPQ_MIB − アプリケーションの安定記憶域内の待ち行列を 管理するために使用されます。 EVENT_MIB − イベント通知とサブスクリプション要求デー タベースの制御に使用されます。 WS_MIB − ワークステーション グループとそれらに対応付け られたプロセスを管理するために使用されます。 BEA Administration Console BEA Administration Console は、BEA Tuxedo システム、特に MIB に対するグラフィカル・ユーザ・インターフェイスです。このツー ルに は、World Wide Web を介 して アク セス しま す。BEA Administration Console を使用すると、一般的な管理機能をブラウ ザから利用できるようになります。現在利用できるブラウザがあ れば、誰でも BEA Tuxedo アプリケーションを管理できます。 BEA Administration Console を使用するには、次の手順に従います。 1. ブラウザで、ドメイン内の Console サーバ・コンポーネントが 存在するマシンの URL を指定します。 2. Java アプレットのダウンロードを開始します。アプレットに よって Console がインプリメントされ、サーバとの通信が確立 されます。 ブラウザの要件 BEA Tuxedo システムの各リリースでは、リリースの時点で利用可 能な ブラ ウザ がサ ポー トさ れて いま す。 BEA Administration Console で現在サポートされているブラウザについては、次の BEA 社 Web サイトを参照してください。 3-4 BEA Tuxedo システム入門 BEA Administration Console の利点 関連項目 第 3 章の 5 ページ 「BEA Administration Console の利点」 第 3 章の 6 ページ 「BEA Administration Console のメイン・メ ニュー」 『BEA Tuxedo アプリケーション実行時の管理』の 第 2 章の 2 ページ 「アプリケーションの監視方法」 BEA Administration Console の利点 認証 − BEA Administration Console では、ユーザの認証が必ず 行われます。管理者は、ユーザ名とパスワードを入力するよう に求められます。入力した情報は暗号化形式でブラウザとサー バ間でやり取りされ、サーバでユーザの認証が行われます。 サーバ・セットアップの大部分はインストール時、つまり Console のサーバ・コンポーネントがインストールされ、Web サーバからアクセスできるようになったときに設定されます。 コンテキスト・センシティブ・ヘルプ − Console のすべての画 面およびツールで、コンテキスト・センシティブ・ヘルプを利 用できます。画面上の任意のフィールドや領域に疑問符のアイ コンをドラッグしてクリックすると、そのフィールドや領域に 関する情報が表示されます。 暗号化 − サーバ側とブラウザ間で転送されるデータは、誰も 読むことができないように圧縮 (56 ビットまたは 128 ビット の暗号化 ) されます。この機能により、ストリームの中に不正 な管理プロトコル・メッセージが挿入されることを防ぐことが できます。 ファイアウォールへの対応 − BEA Administration Console サー バがブラウザからの要求を受け取り、データのやり取りを行う ポートは、明確に定義され、設定可能なポートです。つまり、 ファイアウォールを通して許可されるポートとして、このポー トを設定できます。この機能により、必要に応じて、ファイア ウォールを通して Console ベースの管理を行うことができま す。 アイコン − BEA Administration Console で使用されるアイコン は、状態 ( 非アクティブなど )、またはアプリケーション内の 特定のオブジェクト ( マシンやサーバなど ) を示します。 BEA Tuxedo システム入門 3-5 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 Java 対応ブラウザ − Java ブラウザでは、アプレットを実行し て通信を可能にする Java 仮想マシンがサポートされていま す。 クライアント側のインストールの不要 − クライアントのマシ ンへのインストールは必要ありません。ブラウザで、ドメイン 内の Console サーバ・コンポーネントが存在するマシンの URL を指定します。続いて、Java アプレットのダウンロードを開始 します。アプレットによって Console がインプリメントされ、 サーバとの通信が確立されます。 世界中からの安全なアクセス − Java 対応のブラウザがあれ ば、セキュリティ・メカニズムが確立されたものとして、世界 中のどこからでもシステムにアクセスできます。 BEA Administration Console のメイン・メニュー 初めて Web にアクセスし、BEA Administration Console を起動する と、メイン・ウィンドウが表示されます。メイン・ウィンドウは、 主に次の 4 つの要素から構成されます。 メニュー・バー − よく使用されるメニューから構成される バー。 パワー・バー − ヘルプなど、よく使用されるツールへのショー トカットであるボタンから構成されるバー。 ツリー − BEA Tuxedo システムのドメイン内に存在する管理 クラス・オブジェクト ( サーバやクライアントなど ) の階層構 造。 コンフィギュレーション・ツール − タブ付きフォルダ。オブ ジェクトの属性 ( マシンの名前など ) の表示、定義、変更を行 うことができます。 3-6 BEA Tuxedo システム入門 BEA Administration Console のメイン・メニュー 図 3-2 Administration Console のメイン・メニュー 注記 ドメインに接続されていない場合、パワー・バーのボタンと メニュー項目の一部が表示されません。 コンフィギュレーション・ツール コンフィギュレーション・ツールを起動すると、このツール用の 領域である右側の列にタブ付きフォルダが表示されます。この フォルダには、コンフィギュレーションに必要な情報を入力しま す。 BEA Tuxedo システム入門 3-7 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 コンフィギュレーション・ツール領域のタブ付きフォルダは、管 理オブジェクトの属性に関する情報を表示したり入力するための 電子フォームです。オブジェクトの管理クラス ( マシンやサーバ など ) ごとに、フォルダがあります。クラスに対応付けられてい る属性の数は、クラスによって大きく異なります。そのため、選 択したオブジェクトに対するタブ付きフォルダを開くと、どこか ら開いた場合でも 1 ∼ 8 個のフォルダが表示されます。 コンフィギュレーション・ツール領域にデータが入力されると、メ イン・ウィンドウのタブ付きフォルダの下に 4 つのボタンが表示 されます。これらのボタンを使用すると、フォルダで行うコンフィ ギュレーション作業を制御できます。 ツリー BEA Administration Console のメイン・ウィンドウの左側の列に表 示されるツリーは、1 つの BEA Tuxedo システム・ドメインを構成 する管理オブジェクトの階層構造です。オブジェクトの入れ子の レベルと親オブジェクトを示すことによって、オブジェクト間の 関係がグラフィカルに表されます。ツリー全体 ( ドメイン内の設 定可能なあらゆる種類のすべてのオブジェクト ) を表示するか、 ま たはオブジェクトのサブセットを表示することができます。 ドメインを設定してアクティブにすると、ドメイン内の管理クラ ス・オブジェクトを表すラベル付きのアイコンがツリーに表示さ れます。 管理オブジェクト ツリーは、クラスから構成されます。各クラス名の下には、その クラスに含まれるオブジェクトが表示されます。たとえば、ドメ イン内に、SITE1 に存在する romeo と juliet という 2 つのマシンが 含まれているとします。ツリーでは、この 2 つのマシンは、属し ているクラスの名前「Machines」の下に表示されます。つまり、次 のように表示されます。 Machines SITE1/romeo 3-8 BEA Tuxedo システム入門 BEA Administration Console のメイン・メニュー SITE1/juliet ツリー内の各オブジェクトの名前の前にはアイコンが付いていま す。たとえば、各マシンはコンピュータのアイコンで表され、各 クライアントは人の形で表されます。 パワー・バー パワー・バーは、BEA Administration Console のメイン・ウィンド ウの最上部近く ( メニュー・バーのすぐ下 ) に表示されます。パ ワー・バーには、頻繁に行う管理操作のためのツールを呼び出す 12 個のボタンが並んでいます。ボタンには、アイコンと名前が付 いています。次の表は、各ボタンの処理内容を示しています。 ボタン 処理内容 Stop 現在の操作を中断し、管理者に制御を戻します。この後で、 管理者は新しい操作を要求できます。 Refresh 現 在 の ウ ィ ン ド ウ を 再 表 示 し て、テ キ ス ト お よ び グ ラ フィックを正しく表示します。 Search ツリーで、特定のオブジェクト・クラスまたはオブジェク トを検索します。 Activate BEA Tuxedo システムのコンフィギュレーション全体、また は選択された部分を開始します。 Deactivate BEA Tuxedo システムのコンフィギュレーション全体、また は選択された部分を終了します。 Migrate サーバ・グループまたはサーバ・マシンを別の場所に移動 MASTER と BACKUP マシンを入れ替えます。 します。または、 Logfile アクティブ・ドメイン内の特定のマシンから ULOG ファイ ルを表示します。 Event Tool システム・イベントを監視します。 BEA Tuxedo システム入門 3-9 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 ボタン 処理内容 Stats BEA Tuxedo システムのアクティビティをグラフィカルに 表示します。 Options 管理用の BEA Administration Console セッションに関するパ ラメータを指定します。(a) オンライン・マニュアルのロケー ションを指定します。(b) オブジェクトを名前またはクラス でソートします。(c) デフォルトの作業モードを表示専用 モードまたは編集モードに指定します。 CS Help コンテキスト・センシティブ・ヘルプを表示します。BEA Administration Console ウ ィ ン ド ウ の 目 的 の 領 域 の 上 で ク リックします。ヘルプ・ウィンドウが開き、選択したトピッ クに関する説明が表示されます。 Help 「Administration」のトピックの先頭が表示されるので、必要 な情報を選択できます。 MIB を使用した操作の管理 AdminAPI は、BEA Tuxedo 管理情報ベース (MIB) の中のシステム 設定に直接アクセスし、変更するためのアプリケーション・プロ グラミング・インターフェイス (API) です。AdminAPI を使用する と、ログ・ファイルの監視やアプリケーションの動的な再コンフィ ギュレーションなどの管理タスクを自動化し、人が行う作業を減 らすことができます。このような利点は、ミッション・クリティ カルなリアルタイム・アプリケーションで重要です。MIB プログ ラミング・インターフェイスを使用すると、BEA Tuxedo システム における操作を簡単に管理することができます。特に、独自のプ ログラムを使用してアプリケーションの監視、コンフィギュレー ション、チューニングを行うことができます。MIB は、次のよう に定義されます。 FML 属性として定義され、インプリメンテーションに依存しな い管理データベース。 3-10 BEA Tuxedo システム入門 MIB ユーザのタイプ ATMI 関数を使用して、BEA Tuxedo システムへの照会 ( get を使 用してシステムから情報を取得すること ) や、BEA Tuxedo シス テムの更新 (set を使用してシステムの情報を変更すること ) を いつでも行うことができるプログラミング・インターフェイス。 こ れ ら の 関 数 に は、tpalloc、tprealloc、tpgetrply、 tpcall、tpacall、tpenqueue、tpdequeue などがあります。 関連項目 『BEA Tuxedo のファイル形式とデータ記述方法』の MIB(5) 第 3 章の 11 ページ 「MIB ユーザのタイプ」 第 3 章の 12 ページ 「MIB のクラス、属性、状態」 MIB ユーザのタイプ MIB では、システム管理者、システム・オペレータ、その他とい う 3 つのタイプのユーザが定義されています。次の表は、各タイ プについて示しています。 ユーザのタイプ 説明 システム管理者 アプリケーションの正常な実行を維持する責任者。管理者 には、すべての管理ツールと MIB のすべての管理機能を使 用する権限が与えられます。管理者は、実行中のアプリケー ションのコンフィギュレーション、管理、変更を行うこと ができます。 シ ス テ ム・オ ペ レータ 実行中のアプリケーションの日々の操作を監視し、問題に 対応する担当者。オペレータは、実行中のアプリケーショ ンに関する統計を監視します。イベントおよび警告に対応 して、サーバの起動やマシンのシャットダウンなどを行う 場合もあります。オペレータは、アプリケーションの再コ ンフィギュレーション、サーバまたはマシンの追加、マシ ンの削除は行いません。 BEA Tuxedo システム入門 3-11 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 ユーザのタイプ 説明 その他 MIB を読み取る必要はあるが、アプリケーションを変更す る権限を持たない人またはプロセス ( カスタム・プログラム など )。 MIB のクラス、属性、状態 クラスとは、BEA Tuxedo アプリケーションを構成するエンティ ティ ( サーバ、マシンなど ) のタイプです。属性とは、クラス内の オブジェクトの特徴を表すもので、ID、状態、コンフィギュレー ション・パラメータ、実行時の統計などがあります。属性には、 MIB の操作および応答に共通するものや、個々のクラスに共通す るものがあります。すべてのクラスには、オブジェクトの状態を 示す状態属性があります。MIB 上でオブジェクトの状態を変更す る操作を呼び出している場合、オブジェクトの状態はユーザ変更 の状態、または新しく変更された状態のいずれかになります。 MIB(5) リファレンス・ページに定義されている共通の属性は、ク ラスに依存しません。これらの属性は、入力操作を制御したり、 ユーザが何をしようとしているかを MIB に伝達したり、特定のク ラスに依存しない出力バッファの特徴をプログラマに示します。 コマンド行ユーティリティ BEA Tuxedo システムには、システムの各構成要素を管理するため のコマンドが提供されています。これらのコマンドを使用すると、 共通の管理ユーティリティにアクセスできます。管理ユーティリ ティでは、次のタスクを行うことができます。 コマンド行ユーティリティを使用したアプリケーションのコ ンフィギュレーション コマンド行ユーティリティを使用したアプリケーションの操作 コマンド行ユーティリティを使用したアプリケーションの監視 3-12 BEA Tuxedo システム入門 コマンド行ユーティリティを使用したアプリケーションのコンフィギュレーション コマンド行ユーティリティを使用したアプリケーション のコンフィギュレーション vi テキスト・エディタなどのコマンド行ユーティリティを使用し て、アプリケーションをコンフィギュレーションできます。特に、 コマンド行ユーティリティを使用すると、コンフィギュレーショ ン・ファイル UBBCONFIG を記述し、tmloadcf コマンドを実行し てこのファイルをテキスト形式 ( UBBCONFIG) からバイナリ形式 (TUXCONFIG) に変換できます。この後、アプリケーションを起動 します。 サーバやマシンを追加したり、マシンを削除して、コンフィギュ レーションを動的に管理することもできます。ただし、TUXCONFIG ( バイナリ版 ) を更新しても、UBBCONFIG ( テキスト版 ) は更新さ れません。この 2 つのファイルを同期させるには、これらをバッ クアップする必要があります。その場合、tmunloadcf コマンド を実行して、バイナリ・ファイルをテキスト・ファイルに変換し ます。 注記 UBBCONFIG は、アプリケーション管理者によって、アプリ ケーション・ディレクトリ (APPDIR) に生成されて格納され ます。 以下は、アプリケーションのコンフィギュレーションに使用でき るコマンド行ユーティリティです。 tmconfig − BEA Tuxedo アプリケーションの実行中に、コン フィギュレーション・ファイルのパラメータまたは MIB 属性 を更新したり、TUXCONFIG セクションにレコードを追加する ためのコマンド。 tmloadcf − バイナリ形式の TUXCONFIG コンフィギュレー ション・ファイルをロードするためのコマンド。 tmunloadcf − UBBCONFIG と TUXCONFIG を同期させるため に、バイナリ形式のコンフィギュレーション・ファイルをテキ スト形式に変換するコマンド。 BEA Tuxedo システム入門 3-13 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 tpacladd、tpaclcvt、tpacldel、tpaclmod − アプリケー ションのアクセス制御リストを作成して管理するためのコマ ンド。これらのコマンドによって、セキュリティ関連の認証機 能を使用できるようになります。 tpgrpadd、tpgrpdel、tpgrpmod − アクセス制御リストを 使用して、サービス、待ち行列、イベントへのアクセスを認め ることにより、ユーザ・グループを作成して管理するためのコ マンド。 tpusradd、tpusrdel、tpusrmod − 認証のためのユーザ・ データベースを作成および管理するコマンド。 関連項目 『BEA Tuxedo のファイル形式とデータ記述方法』の UBBCONFIG(5) 第 3 章の 22 ページ 「コンフィギュレーション・ファイルの作 成」 第 3 章の 24 ページ 「コンフィギュレーションの永続的な変 更」 コマンド行ユーティリティを使用したアプリケーション の操作 アプリケーションを一度コンフィギュレーションすると、次のコ マンド行ユーティリティを使用してアプリケーションを操作でき るようになります。 tmadmin − 分散アプリケーションのコンフィギュレーショ ン、監視、チューニングを行うためのコマンド。 tmboot − 分散アプリケーション用のアプリケーション・サー バを中央で起動するためのコマンド。 tmshutdown − 分散アプリケーションのアプリケーション・ プログラムを中央でシャットダウンするためのコマンド。 3-14 BEA Tuxedo システム入門 EventBroker を使用したシステム・イベントの管理 EventBroker を使用したシステム・イベントの管理 BEA Tuxedo EventBroker は、次のタスクを実行します。 イベントを監視し、tppost(3c) を通じてポストされたイベン トをサブスクライバに通知します。 イベントをトラッキングし、管理者にアプリケーション内の変 化を継続的に通知します。 システム全体にわたるイベントのサマリを提供して、イベント の監視を強化します。 イベントを使用して、さまざまな通知処理を開始するメカニズ ムを提供します。 EventBroker は、MIB オブジェクトの 100 種類以上の状態の変化を システム・イベントとして認識します。システム・イベントをポ ストすると、イベントが発生した現在の MIB としてのオブジェク ト、および発生したイベントを識別するイベント固有のフィール ドの情報が提供されます。たとえば、マシンが分断された場合、イ ベントは次の情報と共にポストされます。 マシン・クラス・オブジェクトの名前 (T_MACHINE) と、その マシンのすべての属性 イベントをマシンの分断として識別するいくつかのイベント 属性 EventBroker は、システム・イベントをサブスクライブするだけで 使用できます。以降、MIB レコードを要求しなくても、MIB オブ ジェクトを表す FML データ・バッファを受け取ることによって、 MIB でイベントが発生したことが自動的に通知されます。 関連項目 第 3 章の 16 ページ 「イベント」 第 3 章の 16 ページ 「イベントのサブスクライブ」 第 3 章の 18 ページ 「イベントのタイプ」 BEA Tuxedo システム入門 3-15 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 15 ページ 「イベント・ベースの通信」 イベント イベントとは、実行中のアプリケーションにおける状態の変化な どで、オペレータ、管理者、またはソフトウェアによる操作を必 要とするものです。EventBroker では、イベントに次の 3 つの重要 度レベルのいずれかが割り当てられます。 エラー − サーバが停止したり、ネットワーク接続が切断され た場合など。 情報 − コンフィギュレーションの変更が検出されたり、プロ セスの結果として、状態の変化が発生した場合など。 警告 − 認証に失敗したために、クライアントがアプリケー ションへの参加を許可されない場合など。 イベントのサブスクライブ BEA Tuxedo アプリケーションの管理者は、クライアントまたは サーバ・プロセスの代わりに EVENT_MIB(5) を呼び出してサブス クリプションを要求できます。EventBroker を使用してイベントを サブスクライブするには、tpsubscribe を使用します。イベント A、B、C をサブスクライブして、これらのイベントが発生したと きに通知されるようにします。 各サブスクリプションには、次のいずれかの通知方法が指定され ています。 クライアント通知 − EventBroker によってこれらのイベント に対するクライアントの関心がトラッキングされます。クライ アントには任意通知型通知として通知されます。匿名でポスト されるイベントもあります。クライアントは、そのクライアン ト以外がサブスクライブしている場合でも、アプリケーション に参 加し て EventBroker にイ ベン トを ポス トで きま す。 EventBroker は、これらのイベントをサブスクリプションの データベースと照合し、該当するクライアントに任意通知型通 知を送信します。 3-16 BEA Tuxedo システム入門 イベントのサブスクライブ サービス呼び出し − サブスクライバがイベント通知をサービ ス呼び出しに送る場合は、ctl パラメータが有効な TPEVCTL 構造体を指している必要があります。 安定記憶域の待ち行列へのメッセージの登録 − 安定記憶域の 待ち行列へのサブスクリプションでは、eventexpr と filter のほかに、待ち行列空間、待ち行列名、および相関識別子を使 用して合致しているかどうかが判定されます。相関識別子は、 同じイベントの記述とフィルタ規則が定義され、格納先が同じ 待ち行列である複数のサブスクリプションを区別するために 使用されます。 ULOG へのメッセージの挿入 − サブスクライバは、EVENT_MIB の T_EVENT_USERLOG クラスを使用して、システムの USERLOG メッセージを記述できます。イベントが検出されて合致すると、 これらのイベントは USERLOG に書き込まれます。 コマンド行ユーティリティ − EventBroker は、EVENT_MIB の T_EVENT_COMMAND クラスを使用して、イベントのトラッキン グと照合を行います。合致するイベントが見つかると、そのイ ベントのサブスクライブに使用されるコマンドに渡します。 注記 通 知 方 法 は、サ ブ ス ク ラ イ バ の プ ロ セ ス の タ イ プ と tpsubscribe に渡された引数によって決まります。 図 3-3 イベントのサブスクライブ 関連項目 『BEA Tuxedo のファイル形式とデータ記述方法』の EVENT_MIB(5) 『BEA Tuxedo C 言語リファレンス』の tpsubscribe(3c) BEA Tuxedo システム入門 3-17 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 イベントのタイプ BEA Tuxedo システムでは、次の 2 つのイベント・タイプがサポー トされています。 システム・イベント − サーバ停止およびネットワーク障害な ど、BEA Tuxedo システム・イベントについての詳細を提供し ます。クライアントまたはサーバによってイベントがポストさ れると、EventBroker はポストされたイベントの名前をそのイ ベントのサブスクライバのリストと照合し、各サブスクリプ ションに指定された処理を行います。 ユーザ・イベントまたはアプリケーション固有のイベント − 特定の基準が満たされた場合に、アプリケーション・プログラ ムがイベントをポストできるようにします。たとえば、銀行業 務アプリケーションが一定額を超える引き出しに対してポス トするイベントなどです。 システム・イベントとアプリケーション固有のイベントの相 違点 次の表は、システム・イベントとアプリケーション固有のイベン トの相違点を示しています。 表 3-1 システム・イベントとアプリケーション固有のイベントの相違点 分野 相違点 イベント システム・イベントは、BEA Tuxedo システムのコードによって 事前に定義されています。アプリケーションでは、設計者が監視 すべきアプリケーション・イベントを決定します。アプリケー ション・プログラムは、a) 対象となるイベントの発生時にそのイ ベントを検出し、b) 検出されたイベントが tppost を介して EventBroker にポストされるように記述します。 3-18 BEA Tuxedo システム入門 BEA Tuxedo の管理サービス 分野 相違点 イ ベ ン ト・ システム・イベントのリストが EVENTS(5) によってユーザに提 リスト 供されるように、アプリケーション・イベント・サブスクリプ ションのリストが関心のあるユーザに提供されます。システム・ イベント名はドット ( . ) で開始されます。ただし、アプリケー ション固有のイベント名をドット ( . ) で開始することはできま せん。 サブスクリ プション アプリケーション固有のイベント・ブローカでイベントをサブス クライブすることは、BEA Tuxedo システムの EventBroker をサ ブスクライブすることと似ています。イベントをサブスクライブ するには、そのアプリケーションの公開イベント・リストを使用 して tpsubscribe を呼び出します。EVENTS(5) は、イベント によって生成された通知メッセージとイベント名 (tppost が呼 び出されたときに引数として使用される名前 ) をリストします。 サブスクライバは、正規表現のワイルド・カード機能を使用し て、tpsubscribe を 1 回呼び出すだけでイベントのカテゴリ全 体に対応することができます。 BEATuxedo の管理サービス システム・サーバによって、BEA Tuxedo システムに必要な以下の 管理サービスが提供されます。 アプリケーション待ち行列管理 中央集中型のアプリケーション・コンフィギュレーション 分散アプリケーション管理 アプリケーションの動的な再コンフィギュレーション イベント管理 セキュリティ管理 アプリケーションの起動とシャットダウン トランザクション管理 ワークステーション管理 BEA Tuxedo システム入門 3-19 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 アプリケーション待ち行列管理 待ち行列処理を使用すると、1 つ以上の待ち行列にアクセスして通 信を行うアプリケーションをプログラミングできます。待ち行列 は位置透過的であり、プログラミングに関する変更を行わずに、管 理者はあるマシンから別のマシンに待ち行列を移動できます。 MIB は、待ち行列デバイス、待ち行列空間、( アプリケーションに よって必要とされる ) 待ち行列、 および待ち行列空間へのメッセー ジの登録と取り出しを行う BEA Tuxedo システムのサーバから構 成されます。管理者は、BEA Administration Console またはコマン ド行ユーティリティを使用して、MIB に待ち行列空間、待ち行列、 および管理サーバを定義することができます。 qmadmin を使用したアプリケーション待ち行列の管理 コマンド行ユーティリティ qmadmin を使用すると、コンフィギュ レーション内のアプリケーション待ち行列に関するあらゆる管理 機能を実行できます。つまり、待ち行列を格納する汎用デバイス・ リスト (UDL) およびボリューム一覧 (VTOC) の設定、待ち行列デ バイスでの待ち行列空間の定義などを行うことができるようにな ります。また、qmadmin ではファイル・システムの操作が可能で す。いくつかのランタイム監視機能を使用して、待ち行列内のメッ セージ数、メッセージ中のヘッダ数を確認できます。また、待ち 行列または待ち行列内のメッセージの属性を変更したり、待ち行 列内のメッセージを削除したり、デバイスのサイズを変更するこ ともできます。1 つのアプリケーションで、複数のアプリケーショ ン待ち行列デバイスを設定し、複数のマシン上でアプリケーショ ン待ち行列を実行できます。各マシンにはそれぞれ専用の待ち行 列デバイスがあり、qmadmin を実行して、各マシン上の特定のア プリケーション待ち行列デバイスを監視したり管理することがで きます。 3-20 BEA Tuxedo システム入門 アプリケーション待ち行列管理 ユーティ リティ qmadmin 説明 メッセージ待ち行列の作成、検査、および変更を行います。待ち行 列空間のための汎用デバイス・リストが存在する ( または存在する ことになる ) デバイス ( ファイル ) 名は、コマンド行引数として指 定することも、環境変数 QMCONFIG を介して指定することもでき ます。この両方で指定されている場合は、コマンド・オプションが 使用されます。 tmconfig を使用したコンフィギュレーションの変更 tmconfig コマンドを使用すると、アプリケーションの実行中に、 TUXCONFIG ファイルとそれに対応付けられたエンティティの参 照や変更を行ったり、新しいコンポーネント ( マシンやサーバな ど ) を追加することができます。 コン フィ ギュ レー ショ ン・ファ イル (MASTER マ シン 上の TUXCONFIG) を変更すると、tmconfig コマンドは次の処理を行い ます。 アプリケーションで現在起動しているすべてのマシンの TUXCONFIG ファイルを更新します。 新しく起動するマシンに、TUXCONFIG ファイルを自動的に複 製転送します。 BEA Tuxedo システムのクライアントとして起動します。 注記 コンフィギュレーション・パラメータの指定方法、指定可能 な値の範囲、および検証については、 『BEA Tuxedo コマンド・ リファレンス』 、および 『BEA Tuxedo のファイル形式とデー タ記述方法』の tmconfig、wtmconfig(1) 、TM_MIB(5) を 参照してください。 BEA Tuxedo システム入門 3-21 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 コンフィギュレーションの管理 アプリケーションのコンフィギュレーションは、主にコンフィ ギュレーション・ファイル、つまり UBBCONFIG ファイルの作成と 維持によって制御されます。コンフィギュレーションの管理には、 次のタスクがあります。 アプリケーションのニーズに適合したコンフィギュレーショ ン・ファイルの作成 UBBCONFIG ファイルの更新によるコンフィギュレーションへ の永続的な変更 アプリケーション実行中のコンフィギュレーションの変更 コンフィギュレーション・ファイルの作成 ア プ リ ケ ー シ ョ ン の コ ン フ ィ ギ ュ レ ー シ ョ ン・デ ー タ は、 UBBCONFIG で保持されます。これは、MASTER マシン上にある通 常のテキスト・ファイルです。コンフィギュレーション・ファイ ル (UBBCONFIG) は、アプリケーションのリソース、マシン、グ ループ、サーバ、利用可能なサービスのリストなど、アプリケー ションを起動するために必要なあらゆる情報が含まれているリポ ジトリです。UBBCONFIG ファイルは、作成後 TUXCONFIG バイナ リ・ファイルにコンパイルされます。マルチ・ドメインのアプリ ケーションを開発している場合は、アプリケーション内のドメイ ンごとにコンフィギュレーション・ファイルを作成する必要があ ります。アプリケーションは、コンフィギュレーション・ファイ ルがないと実行できません。 UBBCONFIG ファイルは、8 つのセクションから構成されています。 そのうち、RESOURCES、MACHINES、GROUPS、SERVERS、SERVICES の 5 つは、 すべてのコンフィギュレーションに必須です。 RESOURCES と MACHINES は、それぞれ最初と 2 番目のセクションであることが 必要です ( 次の図を参照 )。GROUPS は、SERVERS および SERVICES よりも前に置く必要があります。 3-22 BEA Tuxedo システム入門 コンフィギュレーション・ファイルの作成 図 3-4 UBBCONFIG ファイル RESOURCES (必須) − システム全体に関するパラメータが記述 され、アプリケーション全体のリソースが定義されています。 MACHINES ( 必須 ) − 物理マシンの論理名とタイプが記述され ています。 GROUPS ( 必須 ) − サーバをリソース・マネージャおよびマシン と対応付けします。 SERVERS − アプリケーション内の各サーバを識別します。 SERVICES − 各サービスを識別し、優先順位やロードなどを指 定します。 NETWORK − LAN 環境に関するコンフィギュレーション・デー タが記述されています。 ROUTING − データ依存型ルーティング・テーブルが記述され ています。 NETGROUPS − 1 つのマシンに対して複数の BRIDGE を指定で きるようにします。 BEA Tuxedo システム入門 3-23 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 UBBCONFIG ファイルに必要なセクションは、各コンフィギュレー ションによって異なります。作成した UBBCONFIG ファイルは、 TUXCONFIG と呼ばれるバイナリ・ファイルにコンパイルする必要 があります。TUXCONFIG ファイルを生成するには、tmloadcf(1) コマンドを実行するか、または BEA Administration Console を使用 します。 関連項目 『BEA Tuxedo アプリケーションの設定』の 第 3 章の 2 ページ 「1 台のマシンで構成するアプリケーション用のコンフィギュ レーション・ファイル」 コンフィギュレーションの永続的な変更 コンフィギュレーションに永続的な変更を行うには、テキスト・ エディタで UBBCONFIG ファイルのコンフィギュレーション・パラ メータを更新した後、tmloadcf ユーティリティを使用して、こ のテキスト・ファイルを BEA Tuxedo システムで使用されるバイ ナリ形式の TUXCONFIG ファイルにロードします。アプリケーショ ンが起動すると、tmboot によって TUXCONFIG が共用メモリに ロードされて掲示板が構築されます。変更内容は、必要に応じて リモート・マシンに複製転送されます。 3-24 BEA Tuxedo システム入門 コンフィギュレーションの動的な管理 図 3-5 コンフィギュレーションの管理 コンフィギュレーションの動的な管理 管理者は、BEA Administration Console または BEA Tuxedo システ ムのコマンド行ユーティリティを使用して、システムの実行中に 変化するシステム・ロードに応じてパラメータを調整して、アプ リケーションの動的な再コンフィギュレーションを行うことがで きます。変更された TUXCONFIG ファイルは、システムのすべての マシンに自動的に複製転送されます。ただし、RESOURCES パラ メータの多くは、システムの実行中には変更できません。 BEA Tuxedo システム入門 3-25 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 動的に実行できるタスクには、サーバまたはマシンの追加やマシ ンの削除などがあります。コンフィギュレーション・ファイルの テキスト形式 (UBBCONFIG) とバイナリ形式 TUXCONFIG) を常に一 致させるには、tmunloadcf を使用してこの 2 つのファイルを バックアップし、同期させる必要があります。tmunloadcf は、バ イナリ・ファイルをテキスト形式に変換するコマンドです。 システムの大部分の要素は、動的に変更できます。たとえば、新 しいサーバを作成したり、新しいマシンを追加したり、タイム・ アウトのパラメータを変更することができます。ただし、システ ムの実行中には変更できないものもいくつかあります。 コンフィギュレーション・ファイルのパラメータのうち、掲示 板のサイズと形式に影響するものは変更できません。このよう なパラメータの多くには、「MAX」という接頭辞が付いていま す。たとえば、BEA Tuxedo システムで同時に処理できるトラ ンザクションの最大数を指定する MAXGTT パラメータなどが あります。 特定のアプリケーション内でマシンのプロセッサ名を変更す ることはできません。異なる名前で新しいマシンを追加するこ とはできますが、既存のマシンの名前を変更することはできま せん。 MASTER マシンおよび BACKUP マシン上で実行するために割 り当てられたサーバの実行可能プログラムの値は変更できま せん。 関連項目 第 3 章の 26 ページ 「tmadmin(1) を使用した動的操作の実行」 tmadmin(1) を使用した動的操作の実行 tmadmin(1) コマンドを使用すると、実行中のアプリケーションに 次の操作を行うことができます。 パフォーマンスの監視 (bbstats、bbparms)。これは、グルー プ、サーバ、サービスに関する統計値を調べて行います。 3-26 BEA Tuxedo システム入門 tmadmin(1) を使用した動的操作の実行 ロード値の変更 (changeload)、サービスの中断と再開 (suspend および resume)、サービスの宣伝と宣伝の取消し (advertise お よび unadvertise)、AUTOTRAN のタイム・アウト値の変更 (changetrantime) などを実行するサーバ・パラメータおよび サービス・パラメータの変更。 起動 (boot)、クリーンアップ (pclean)、および移行 (migratemach、migrategroup)。 よく使用される tmadmin コマンド tmadmin には、ランタイム・システムの監視、アプリケーション のチューニング、アプリケーションの動的なコンフィギュレーショ ンなどを行うサブコマンドがあります。次は、最もよく使われる tmadmin のサブコマンドです。tmadmin コマンドの全リストにつ いては、 『BEA Tuxedo コマンド・リファレンス』の tmadmin(1) を 参照してください。 help - サブコマンドのリスト、その省略形、引数、および説明 を出力します。 printserver (psr) − アプリケーションおよび管理サーバに 関する情報を出力します。 printservice (psc) − アプリケーションおよび管理サービ スに関する情報を出力します。 printclient (pclt) − 指定されたクライアント・プロセスに 関する情報を出力します。引数が指定されてなく、デフォルト も定義されていない場合は、すべてのクライアントに関する情 報が出力されます。 BEA Tuxedo システム入門 3-27 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 tmadmin コマンドの出力例 以下は、tmadmin printserver (psr) コマンドの出力の例です。 アプリケーションおよび管理サーバに関する情報が示されます。 図 3-6 tmadmin コマンドの出力例 >psr Prog Name --------BBL AUDITC XFER TMS_SQL ACCT TMS_SQL BAL BTADD BALC TLR TLR TLR TLR TLR TLR TLR TLR TLR TLR > Queue Name ---------83108 auditc 00001.00101 BANKB1_TMS 00001.00102 BANKB1_TMS 00001.00103 00001.00104 00001.00105 tlr1 tlr1 tlr1 tlr1 tlr1 tlr1 tlr1 tlr1 tlr1 tlr1 Grp Name -------SITE1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 BANKB1 ID RqDone Load Done Current Service -- ------ --------- --------------0 1 50 ( IDLE ) 1 0 0 ( IDLE ) 101 1 30 ( TRANSFER ) 30001 0 0 ( IDLE ) 102 0 0 ( IDLE ) 30002 0 0 ( IDLE ) 103 6 7 ( IDLE ) 104 0 0 ( IDLE ) 105 0 0 ( IDLE ) 111 0 0 ( IDLE ) 112 3 110 ( WITHDRAWAL ) 113 0 0 ( IDLE ) 114 0 0 ( IDLE ) 115 0 0 ( IDLE ) 116 9 100 ( IDLE ) 117 20 2048 ( IDLE ) 118 30 600 ( IDLE ) 119 0 0 ( IDLE ) 120 0 0 ( IDLE ) 関連項目 『BEA Tuxedo アプリケーション実行時の管理』の 第 2 章の 15 ページ 「tmadmin セッションのしくみ」 『BEA Tuxedo アプリケーション実行時の管理』の 第 2 章の 11 ページ 「コマンド行ユーティリティを使用してアプリケー ションを監視する」 3-28 BEA Tuxedo システム入門 分散アプリケーションの集中管理 分散アプリケーションの集中管理 大型で複雑な BEA Tuxedo アプリケーションでも、すべてのラン タイム管理機能を 1 つの MASTER マシンから実行できます。その 場合、BEA Tuxedo システムによって提供されるコマンド行ユー ティリティ、BEA Administration Console、または BEA Manager 製 品と併用するサード・パーティ製の管理ツールを使用します。 MASTER マシンから、アプリケーションのコンフィギュレーショ ン、起動およびシャットダウン、ランタイムの管理タスクなどを 実行できます。ほかのすべてのマシンは、MASTER マシンを照会で きます。コンフィギュレーション、障害管理、セキュリティ、監 視、パフォーマンスについても、MASTER マシンから制御できます。 実行中のシステムを変更するには、次の 2 つの方法を使用します。 BEA Administration Console − 管理タスク ( システムの動的な 変更など ) 用のコマンドを実行するためのグラフィカル・ユー ザ・インターフェイス (GUI)。 tmadmin コマンド − 50 個のサブコマンドを実行できるシェ ル・レベルのメタ・コマンド。システムの動的な変更など各種 の管理タスクを実行します。 BEA Administration Console はグラフィカル・ユーザ・インターフェ イス (GUI) を備えているため、tmadmin コマンド・インタプリタ より簡単に使用できます。GUI を使用する場合は、管理タスクを 開始する準備ができたら、画面上で BEA Administration Console を 起動します。BEA Administration Console のグラフィックスとオン ライン・ヘルプを参照すると、どの管理タスクでも実行できるよ うに なり ます。次 の図 は、tmadmin コ マン ドま たは BEA Administration Console を使用して、ランタイム・アプリケーショ ンを制御する方法を示しています。すべての操作は MASTER マシ ンから実行できます。ユーティリティによる操作は、MASTER マシ ンの掲示板に直接作用します。更新内容は、ほかの掲示板に自動 的に伝達されます。 BEA Tuxedo システム入門 3-29 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 図 3-7 分散アプリケーションの集中制御 関連項目 第 3 章の 4 ページ 「BEA Administration Console」 第 3 章の 26 ページ 「tmadmin(1) を使用した動的操作の実行」 3-30 BEA Tuxedo システム入門 セキュリティの管理 セキュリティの管理 アプリケーションには、BEA Tuxedo システムによって提供される 適切なレベルのセキュリティを設定することができます。認証お よび権限のレベルを設定して、アプリケーションへのアクセスを 制限できます。セキュリティには、さまざまなレベルがあります。 安全性が高く、認証が行われない環境もあれば、パスワードやア クセス制御リスト (ACL) によって、サービスの使用、イベントの ポスト、待ち行列へのメッセージの登録や取り出しなどを実行で きるユーザを限定する環境もあります。 ACL を使用すると、アプリケーションへの参加時にユーザの認証 が行われるだけではなく、 アプリケーションのエンティティ ( サー ビスなど ) へのアクセスが試みられた場合にパーミッションが確 認されます。あるリソースに対して ACL が作成されると、そのリ ストに含まれていないユーザはそのリソースへのアクセスを拒否 されます。ACL によって保護されていないリソースは、アプリケー ションへの参加に成功したすべてのクライアントがアクセスでき ます。ACL で MANDATORY_ACL セキュリティ・オプションが指定 されていると、アプリケーションに参加したすべてのクライアン トに対してアクセスが拒否されます。 すべてのサーバ (BEA Tuxedo 管理サーバの AUTHSVR を除く ) が、 共用メモリやメッセージ待ち行列などの共用リソースに対して制 限付きのアクセス権を持つように、アプリケーションを設定でき ます。クライアントがアプリケーションに参加する場合、AUTHSVR によって認証サービスが提供され、そのユーザの MIB における認 証レベルが確認されます。このサービスは、プログラマに透過的 に行われます。 関連項目 第 3 章の 32 ページ 「セキュリティ・オプションの選択」 第 3 章の 33 ページ 「セキュリティの設定」 『BEA Tuxedo のセキュリティ機能』の 第 2 章の 1 ページ 「セ キュリティの管理」 BEA Tuxedo システム入門 3-31 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 『BEA Tuxedo のセキュリティ機能』の 第 3 章の 1 ページ 「セ キュリティのプログラミングとは」 セキュリティ・オプションの選択 以下は、BEA Tuxedo システムによって提供されるセキュリティ・ オプションです。 認証なし − クライアントは、アプリケーションに参加する前 に確認されません。 アプリケーション・パスワード − アプリケーション全体に対 して 1 つのスワードが定義されます。クライアントがアプリ ケーションに参加する場合は、このパスワードを指定する必要 があります。 ユーザ・レベル認証 − アプリケーションに参加するには、アプ リケーション・パスワードのほかに、各クライアントが有効な ユーザ名とアプリケーション固有のデータ ( パスワードなど ) を指定する必要があります。 任意アクセス制御リスト (ACL) − クライアントがアプリケー ション・パスワード、ユーザ名、およびユーザ・パスワードを 指定する必要があります。ユーザ名に対応付けられた ACL が ない場合、パーミッションが与えられます。このオプションに よって、管理者はより高いセキュリティを必要とするリソース に対してだけアクセスを設定することができます。誰でもアク セスできるサービス、待ち行列、イベントには、ACL を設定す る必要はありません。 必須アクセス制御リスト (ACL) − クライアントがアプリケー ション・パスワード、ユーザ名、およびユーザ・パスワードを 指定する必要があります。このレベルは任意 ACL のオプショ ンに似ていますが、ACL をユーザがアクセスできるすべての エンティティ ( サービス、待ち行列、イベントなど ) に対して 設定する必要があります。必須 ACL のオプションが使用され ている場合に、ある特定のエンティティの ACL がないと、そ のエンティティに対するパーミッションは与えられません。 3-32 BEA Tuxedo システム入門 セキュリティの設定 リンク・レベルの暗号化 − BEA Tuxedo システム・セキュリ ティのユーザは、BEA Tuxedo アプリケーションのマシン間を 接続するネットワーク・リンク上を移動するメッセージに対し て、データをプライバシ扱いできます。データは、ネットワー ク・リンクに送信される前に暗号化され、リンクから取り出さ れるときに解読されます。セキュリティのレベルには、0 ビッ ト ( 暗号化なし )、56 ビット ( 国際版 )、128 ビット ( 米国およ びカナダ ) の 3 種類があります。 公開鍵暗号方式 − メッセージ・ベースの暗号化とメッセージ・ ベースのデジタル署名から構成されます。メッセージ・ベース の暗号化は、指定された受信者だけにデータを公開します。 メッセージ・ベースのデジタル署名を使用した場合、送信プロ セスは自身の ID を証明し、その証明書を特定のメッセージ・ バッファにバインドしなければなりません。署名の確認は、任 意のサード・パーティが行います。デジタル署名には、バッ ファの内容全体に対して計算され、暗号化によって安全な チェックサムが含まれているので、検出されずに改ざんを行う ことは不可能です。デジタル署名には、送信元マシンのローカ ル・クロックに基づいた、改ざんに対するスタンプも含まれて います。 監査 − 操作の要求とその結果に関する情報の収集、保存、配 布を行います。 セキュリティの設定 アプリケーションのセキュリティを設定するために必要な管理作 業やプログラミングは、選択したセキュリティ・オプションによっ て異なります。管理に関しては、BEA Administration Console また はコマンド行ユーティリティのいずれかを使用して、MIB のコン フィギュレーションを行う必要があります。 また、独自のセキュリティ・メカニズムを構築することもできま す。その場合、アプリケーションのセキュリティ・レベルをユー ザ・レベルの認証に設定し、BEA Tuxedo MIB で認証を実行するア プリケーション・サービスを指定します。 BEA Tuxedo システム入門 3-33 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 認証と権限付与を行うには、MIB で次のコンフィギュレーション を行う必要があります。 AUTHSVR サーバ 権限を持つユーザの ID とパスワード サービス、待ち行列、イベントに対して使用されるアクセス制 御リスト アプリケーションの起動とシャットダウン アプリケーションを起動するには、 『BEA Tuxedo アプリケーショ ン実行時の管理』に説明されているように、次の作業を行います。 1. 第 1 章の 2 ページ 「環境変数の設定」の説明に従って、環境変 数を設定します。 2. 第 1 章の 4 ページ 「TUXCONFIG ファイルの作成」の説明に 従って、tuxconfig ファイルを作成します。 3. 第 1 章の 5 ページ 「BEA Tuxedo システム・ソフトウェアの複 製転送」の説明に従って、BEA Tuxedo ソフトウェアを複製転 送します。 4. 必要に応じて、第 1 章の 7 ページ 「TLOG デバイスの作成」の 説明に従って、TLOG デバイスを作成します。 5. 第 1 章の 8 ページ「全サイトでの tlisten の起動」の説明に従っ て、すべてのサイト (MP 環境 ) で tlisten を起動します。 6. 第 1 章の 10 ページ 「アプリケーションの起動」の説明に従っ て、アプリケーションを起動します。 アプリケーションをシャットダウンするには、次の作業を行いま す。 第 1 章の 13 ページ「アプリケーションのシャットダウン」の説明 に従って、MASTER マシン上で tmshutdown を実行します。 3-34 BEA Tuxedo システム入門 トランザクションの管理 トランザクションの管理 BEA Tuxedo システムの強力な機能の 1 つに、XA インターフェイ スをサポートするデータベース・アプリケーションのトランザク ションを管理する機能があります。トランザクションを使用する と、分散アプリケーションを簡単に記述できるようになります。ト ランザクションにより、マシン、プログラム、およびネットワー クに関する障害など、分散環境における問題への対応が一層容易 になります。 分散アーキテクチャでは、トランザクションに関与するローカル・ マシンがリモート・マシンと通信できます。このリモート・マシ ンが、さらに別のリモート・マシンと通信する場合もあります。リ モート・マシンによって行われる通信および作業は、トランザク ションの一部であり、整合性を維持する必要があります。分散ト ランザクション処理 (DTP) のトラッキングは、複雑な作業になる 場合があります。これは、任意の時点でトランザクションをロー ルバックする ( 取り消す ) のに十分な情報を保持する必要があるか らです。 図 3-8 トランザクション管理 BEA Tuxedo システム入門 3-35 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 BEA Tuxedo システムでは、トランザクションのパーティシパント をトラッキングするために、トランザクション・ログが作成され ます。アプリケーションの状態をコンピュータのメモリの内容ど おりに保つために、1 つ以上のリソース・マネージャが使用されま す。リソース・マネージャとは、情報およびその情報にアクセス するためのプロセスの集まりで、たとえばデータベース管理シス テムなどがあります。トランザクションによって実行されるすべ ての操作、および影響を受けるすべてのモジュールを調整するた めに、BEA Tuxedo システムではトランザクション・マネージャ (TM) が使用されます。トランザクション・マネージャは、リソー ス・マネージャのアクションを指示します。トランザクション・ マネージャとリソース・マネージャの共同作業により、分散トラ ンザクションの原子性が維持されます。 トランザクション・マネージャ・サーバ (TMS) による操作の 調整 BEA Tuxedo トランザクション・マネージャ (TM) は、システム全 体のリソースに関連するグローバル・トランザクションを調整し ます。個々のリソースは、ローカルのリソース・マネージャ (RM) によって管理されます。トランザクション・マネージャ・サーバ (TMS) は、複数のリソースに関与するトランザクションの開始、コ ミット、およびアボートを行います。このサーバでは、RM への 埋め込み SQL インターフェイスを使用して、サーバ・グループに アクセスされるデータベースの読み取りや更新を行います。TMS および RM は、XA インターフェイスを使用して、グローバル・ト ランザクションにおけるすべてのリソース操作を実行するか、ま たはまったく行いません。 3-36 BEA Tuxedo システム入門 トランザクションの管理 トランザクション・ログ (TLOG) によるパーティシパントのト ラッキング グローバル・トランザクションは、コミット・プロセスにある場 合のみ、トランザクション・ログ (TLOG) に記録されます。2 フェー ズ・コミット・プロトコルの第 1 フェーズの最後に、グローバル・ トランザクションのパーティシパントからの応答が TLOG に記録 されます。TLOG の記録は、コミットすべきグローバル・トランザ クションを示します。ロールバックすべきトランザクションは、 TLOG には記録されません。第 1 フェーズ、つまりプリコミットで は、各リソース・マネージャがトランザクション要求をコミット します。すべてのパーティシパントがコミットすると、そのトラ ンザクションは、トランザクション管理によってコミットされて 完了します。アプリケーションまたはシステムの障害によってこ のいずれかのタスクが失敗すると、両方のタスクが失敗し、実行 された処理が取り消されます。つまり、初期状態に「ロールバッ ク」されます。 グローバル・トランザクションの調節を行う TMS では、TLOG ファ イルが使用されます。各マシンには、専用の TLOG が必要です。 注記 Domains 機能を使用している場合は、Domains ゲートウェイ が Domains グループにおける TMS の機能を果たすことに注 意してください。ただし、Domains では、Domains 固有の情 報のほかに、TLOG と同じような情報が記録された独自のト ランザクション・ログが使用されます。 関連項目 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 18 ページ 「トランザクション」 『BEA Tuxedo アプリケーションの設定』の 第 5 章の 1 ページ 「トランザクション対応のアプリケーションのコンフィギュ レーション」 BEA Tuxedo システム入門 3-37 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 ワークステーションの管理 ワークステーション・クライアントには、要求に関する情報をパッ ケージ化するために十分な BEA Tuxedo システム・ソフトウェア が必要です。このようなソフトウェアがあると、ATMI 関数やネッ トワーク・ソフトウェアを含め、すべての BEA Tuxedo システム・ ソフトウェアがサポートされたシステムに、その情報を送信する ことができます。 管理者は、1 つ以上のワークステーション・リスナ (WSL) を設定 して、ワークステーション・クライアントからの接続要求を受け 取ることができるようにします。各 WSL では、1 つ以上のワーク ステーション・ハンドラ (WSH) を使用して、クライアントの要求 が処理されます。各 WSH では、複数のワークステーションが管理 され、特定のワークステーションとのすべての通信が単一の接続 に多重化されます。 図 3-9 ワークステーション・クライアントの処理 3-38 BEA Tuxedo システム入門 開発の視点 : ATMI の使用 この図に示されているように、1 つのマシンで何千ものワークス テーション・クライアントを処理できます。管理者は、ドメイン 内にいくつかの WSL を定義すると、複数のマシン間でワークス テーションの通信負荷を均一的に分散できます。 プログラミングの観点では、ワークステーション・クライアント の開発では、すべてのクライアント ATMI プログラミング・イン ターフェイスがサポートされます。 開発の視点 : ATMI の使用 BEA Tuxedo の API であるアプリケーション・トランザクション・ モニタ・インターフェイス (ATMI) は、通信、トランザクション、 およびデータ・バッファ管理のためのインターフェイスで、BEA Tuxedo システムによってサポートされるすべての環境で動作しま す。この ATMI によって、アプリケーション・プログラムと BEA Tuxedo システムとのインターフェイスが定義されます。ATMI は、 広範な機能に対応する 1 つの単純なインタフェースです。ATMI に は、トランザクション処理の X/Open DTP モデルがインプリメン トされています。 図 3-10 ATMI の使用 BEA Tuxedo システム入門 3-39 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 ATMI ライブラリには、BEA Tuxedo アプリケーションでグローバ ル・トランザクションを定義し、制御するための各種の関数が含 まれています。グローバル・トランザクションを使用すると、分 散アプリケーションで、複数のプログラムおよびリソース・マネー ジャにわたる排他的な作業単位を管理できます。1 つのトランザク ション内のすべての作業は、1 つの論理単位として処理されます。 そのため、タスクを正常に完了できないプログラムが 1 つでもあ ると、そのトランザクションではどのプログラムでも何も処理は 行われません。ほとんどの ATMI 関数では、異なる通信方法がサ ポートされています。これらの関数は、プログラム間でデータを 交換できるようにして、分散プログラムを互いに結び付けます。す べての ATMI 関数は、型付きバッファでデータを送受信します。 次の表は、実行されるタスクごとに分類した ATMI 関数 (C および COBOL のバインディング対応 ) を示しています。 表 3-2 ATMI 関数の使用 タスク C 言語の関数 クライア tpchkauth(3c) ントのメ ン バ ー tpinit(3c) シップ tpterm(3c) 3-40 BEA Tuxedo システム入門 COBOL 言語の関数 処理内容 TPCHKAUTH(3cbl) 認証が必要かどうかを確 認します。 TPINITIALIZE(3cbl) ク ラ イ ア ン ト を ア プ リ ケーションに参加させま す。 TPTERM(3cbl) クライアントをアプリ ケーションから分離させ ます。 開発の視点 : ATMI の使用 タスク C 言語の関数 COBOL 言語の関数 処理内容 該当せず メッセージ・バッファを 作成します。 tprealloc(3c) 該当せず メッセージ・バッファの サイズを変更します。 tpfree(3c) 該当せず メッセージ・バッファを 解放します。 tptypes(3c) 該当せず メッセージのタイプとサ ブタイプを取得します。 メッセー tpgprio(3c) ジの優先 順位 tpsprio(3c) TPGPRIO(3cbl) 最後の要求の優先順位を 取得します。 TPSPRIO(3cbl) 次の要求の優先順位を設 定します。 要求/応答 tpcall(3c) 型通信 TPCALL(3cbl) サービスへの同期要求 / 応答を開始します。 tpacall(3c) TPACALL(3cbl) 非同期要求 ( ファンアウ ト ) を開始します。 tpgetrply(3c) TPGETRPLY(3cbl) 非同期応答を受け取りま す。 tpcancel(3c) TPCANCEL(3cbl) 非同期要求を取り消しま す。 tpconnect(3c) TPCONNECT(3cbl) サービスとの会話を開始 します。 tpdiscon(3c) TPDISCON(3cbl) 会話を異常終了します。 tpsend(3c) TPSEND(3cbl) 会話中にメッセージを送 信します。 tprecv(3c) TPRECV(3cbl) 会話中にメッセージを受 信します。 バッファ tpalloc(3c) 管理 会話型 通信 BEA Tuxedo システム入門 3-41 第3章 タスク BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 C 言語の関数 COBOL 言語の関数 処理内容 高信頼性 tpenqueue(3c) 待ち行列 TPENQUEUE(3cbl) メッセージをメッセージ 待ち行列に登録します。 tpdequeue(3c) TPDEQUEUE(3cbl) メッセージをメッセージ 待ち行列から取り出しま す。 TPNOTIFY(3cbl) クライアントに任意通知 型メッセージを送信しま す。 tpbroadcast(3c) TPBROADCAST(3cbl) 複数のクライアントに メッセージを送信しま す。 tpsetunsol(3c) TPSETUNSOL(3cbl) 任意通知型メッセージの コールバックを設定しま す。 tpchkunsol(3c) TPCHKUNSOL(3cbl) 任意通知型メッセージの 到着を確認します。 該当せず TPGETUNSOL(3cbl) 任意通知型メッセージを 取得します。 tppost(3c) TPPOST(3cbl) イベント・メッセージを ポストします。 tpsubscribe(3c) TPSUBSCRIBE(3cbl) イベント・メッセージを サブスクライブします。 tpnotify(3c) イベン ト・ベー スの通信 tpunsubscribe(3c) TPUNSUBSCRIBE(3cbl) イベント・メッセージの サブスクリプションを削 除します。 3-42 BEA Tuxedo システム入門 開発の視点 : ATMI の使用 タスク C 言語の関数 COBOL 言語の関数 処理内容 TPBEGIN(3cbl) トランザクションを開始 します。 TPCOMMIT(3cbl) 現在のトランザクション をコミットします。 tpabort(3c) TPABORT(3cbl) 現在のトランザクション をロールバックします。 tpgetlev(3c) TPGETLEV(3cbl) トランザクション・モー ドであるかどうかを確認 します。 tpsuspend(3c) TPSUSPEND(3cbl) 現在のトランザクション を一時停止します。 tpresume(3c) TPRESUME(3cbl) トランザクションを再開 します。 TPSVRINIT(3cbl) サーバを初期化します。 TPSVRDONE(3cbl) サーバを終了します。 tpservice(3c) 該当せず サービス・エントリ・ポ イントのプロトタイプで す。 該当せず TPSVCSTART(3cbl) サービス情報を取得しま す。 tpreturn(3c) TPRETURN(3cbl) サービス関数を終了しま す。 tpforward(3c) TPFORWAR(3cbl) 要求を転送します。 tpadvertise(3c) TPADVERTISE(3cbl) サービス名を宣言しま す。 トランザ tpbegin(3c) クション 管理 tpcommit(3c) サービス tpsvrinit(3c) の登録と tpsvrdone(3c) 応答 動的な 宣言 tpunadvertise(3c) TPUNADVERTISE(3cbl) サービス名の宣言を取り 消します。 BEA Tuxedo システム入門 3-43 第3章 タスク BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 C 言語の関数 リソース tpopen(3c) 管理 tpclose(3c) COBOL 言語の関数 処理内容 TPOPEN(3cbl) リソース・マネージャを オープンします。 TPCLOSE(3cbl) リソース・マネージャを クローズします。 注記 ATMI トランザクション管理関数を使用することは必須では ありません。 関連項目 『BEA Tuxedo アプリケーション実行時の管理』の 第 2 章の 32 ページ 「ATMI を使用してシステム・エラーとアプリケーショ ン・エラーを処理する」 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 2 ページ 「BEA Tuxedo クライアントの作成」 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 4 ページ 「BEA Tuxedo サーバの作成」 『サンプルを使用した BEA Tuxedo アプリケーションの開発方 法』の 第 1 章の 6 ページ 「アプリケーションの型付きバッ ファ」 第 2 章の 10 ページ 「BEA Tuxedo のメッセージング・パラダ イム」 第 2 章の 48 ページ 「ネーミング」 3-44 BEA Tuxedo システム入門 ランタイム・システムの視点 : 各種コンフィギュレーションにおけるツールの使用 ランタイム・システムの視点 : 各種コンフィギュレー ションにおけるツールの使用 BEA Tuxedo システムには、アプリケーション内のプロセスおよび プロセス間に発生する通信の作成、監視、管理を行うためのツー ルが提供されています。さまざまなコンフィギュレーションで、プ ロセスとメッセージングの基本パラダイムを使用できます。各コ ンフィギュレーションは、次のランタイム・カテゴリのいずれか に分類されます。 シングル・マシン・アプリケーション − 1 つ以上のローカル またはリモートのクライアントが、同じマシン上にある 1 つ以 上のサーバと通信します。 複数のマシンにまたがる分散アプリケーション − 1 つ以上の ローカルまたはリモートのクライアントが、同じドメイン内の いくつかのマシン上にある 1 つ以上のサーバと通信します。 マルチ・ドメイン・アプリケーション − 複数のドメインが互 いに通信します。 ランタイム・システムの機能 次の表は、シングル・マシン・アプリケーション、分散アプリケー ション、およびマルチ・ドメイン・アプリケーションで使用でき る BEA Tuxedo システムの機能を示しています。 表 3-3 各タイプのコンフィギュレーションで使用できる機能 使用できる機能 シングル・マシン・ コンフィギュレー ション マルチ・マシン ( 分散 ) コンフィ ギュレーション マルチ・ドメイン・ コンフィギュレ ション ATMI X X X メッセージング・ X パラダイム X X BEA Tuxedo システム入門 3-45 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 使用できる機能 管理用の要素 掲示板 (BB)、 BBL、TLOG、 UBBCONFIG、 ULOG、 TUXCONFIG DBBL ブリッジ シングル・マシン・ コンフィギュレー ション マルチ・マシン ( 分散 ) コンフィ ギュレーション マルチ・ドメイン・ コンフィギュレ ション X X X X X X X Domains プロセ ス: DMADM、GWADM、 GWTDOMAIN (TDomains 用 )、 dmloadcf、 dmunloadcf お よび DMCONFIG、 DMTLOG、 BDMCONFIG X アプリケーショ ン・プロセス : ク ライアント、サー バ、およびサービ ス X X X 待ち行列処理 X X X トランザクショ ン管理 X X X イベント管理 X X セキュリティ管理 X X 3-46 BEA Tuxedo システム入門 X シングル・マシン・コンフィギュレーション シングル・マシン・コンフィギュレーション シングル・マシン・コンフィギュレーションは、単一のマシン上 にある 1 つ以上のサーバと通信する 1 つ以上のローカルまたはリ モートのクライアントから構成されます。このマシン上では、1 つ 以上のビジネス・アプリケーションが実行されています。このタ イプのコンフィギュレーションは、複数のアプリケーションを含 む場合でも、単一のエンティティとして管理されるので、シング ル・ドメインと見なされます。このコンフィギュレーション内の すべてのアプリケーションのすべての管理対象要素 ( サービス、 サーバなど ) は、 1 つの BEA Tuxedo コンフィギュレーション・ファ イルで定義されて制御されます。次の図は、単一のマシン上にイ ンストールされて実行されているシングル・マシン・コンフィギュ レーションの基本要素を示しています。 図 3-11 BEA Tuxedo のシングル・マシン・コンフィギュレーション BEA Tuxedo システム入門 3-47 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 表 3-4 シングル・マシン・コンフィギュレーションの構成要素 シ ン グ ル・マ シ ンの構成要素 説明 掲示板 (BB) システムのコンフィギュレーションと動的な情報を保持す る共用メモリ・セグメント。すべての BEA Tuxedo プロセス から利用できます。 BBL 掲示板に格納されているデータ ( 掲示板に対する変更を含 む )、およびすべてのアプリケーション・プログラムを監視 する BEA Tuxedo の管理プロセス。 クライアント BEA Tuxedo システムを介して定期的にサービスを要求す る実行可能プログラム。通常、クライアント・プログラム はユーザが作成します。 メッセージ待ち 行列 クライアントとサーバ間の通信は、オペレーティング・シ ステムでサポートされ、メモリ・ベースであるメッセージ 待ち行列を介して行われます。 メッセージング・ クライアントとサーバ間のメッセージ転送に関する各種の パラダイム モデル。たとえば、要求 / 応答モード、会話モード、イベン ト、任意通知型通信などがあります。 サーバ BEA Tuxedo システムを介して指定されたサービスを提供 する実行可能プログラム。通常、サーバ・プログラムはユー ザが作成します。 ワークステー ション・ハンドラ (WSH) サーバ上のマルチ・コンテキストのゲートウェイ・プロセ ス。ワークステーション・クライアント ( リモート・サイト 上で実行されているクライアント・プロセス ) からのサービ ス要求を管理します。 ワークステー シ ョ ン・リ ス ナ (WSL) アプリケーション・サイト上で実行されるサーバ・プロセ ス。ワークステーション・クライアント ( リモート・サイト 上で実行されているクライアント・プロセス ) からの接続を 受け付け、配信します。 3-48 BEA Tuxedo システム入門 マルチ・マシン ( 分散 ) コンフィギュレーション シ ン グ ル・マ シ ンの構成要素 ULOG ログ ) 説明 ユーザ・ エラー・メッセージが格納されるファイル。 関連項目 『BEA Tuxedo アプリケーションの設定』の 第 3 章の 2 ページ 「コンフィギュレーション・ファイルの作成方法」 マルチ・マシン ( 分散 ) コンフィギュレーション 分散ドメイン ( またはマルチ・マシン ) のコンフィギュレーション は、複数のマシン上で実行される 1 つ以上のビジネス・アプリケー ションから構成されます。このタイプのコンフィギュレーション は、複数のアプリケーションを含む場合でも、単一のエンティティ として管理されるので、シングル・ドメインと見なされます。つ まり、このコンフィギュレーション内のすべてのマシンのすべて のアプリケーションのすべての管理対象要素 ( サービス、サーバ、 マシンなど ) は、 1 つの BEA Tuxedo コンフィギュレーション・ファ イルで定義されて制御されます。 業務の拡大に伴い、個々の管理とサービスやデータの共有が可能 な機能性をベースに、アプリケーション開発者は新しい部門を組 織化する必要があります。機能性に基づいて定義されるアプリ ケーションは、複数のマシンにわたる場合もあり、またほかのア プリケーションとは独立して管理されます。このように機能的に 独立したアプリケーションをドメインと呼びます。 ドメイン名は、提供される機能を表しています。ドメインに「マー ケティング」や「研究開発」などの名前が付けられていると、必 要なアプリケーションを簡単に見つけることができます。 BEA Tuxedo システム入門 3-49 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 次の図は、複数のマシンに分散したコンフィギュレーションの基 本要素を示しています。 図 3-12 分散アプリケーション 表 3-5 分散コンフィギュレーションを構成する基本要素 マ ル チ・マ シ ン の構成要素 BRIDGE 説明 BEA Tuxedo シ ス テ ム に よ っ て 提 供 さ れ る ド メ イ ン 内 の サーバ。マシン間でサービス要求を送受信し、要求をロー カル・サーバ ( 正確にはローカル・サーバの待ち行列 ) に ルーティングします。 3-50 BEA Tuxedo システム入門 マルチ・マシン ( 分散 ) コンフィギュレーション マ ル チ・マ シ ン の構成要素 説明 掲示板 (BB) システムのコンフィギュレーションと動的な情報を保持す る共用メモリ・セグメント。すべての BEA Tuxedo プロセス から利用できます。 BBL 掲示板に格納されているデータ ( 掲示板に対する変更を含 む )、およびすべてのアプリケーション・プログラムを監視 する BEA Tuxedo の管理プロセス。 クライアント BEA Tuxedo システムを介して定期的にサービスを要求す る実行可能プログラム。通常、クライアント・プログラム はユーザが作成します。 DBBL 各マシン上の BBL サーバが実行されていて、正常に機能し ていることを確認するための専用プロセス。このサーバは、 ドメインの マスタ・マシン上で実行され、すべての管理機 能と直接通信します。 メッセージ待ち 行列 クライアントとサーバ間の通信は、オペレーティング・シ ステムでサポートされ、メモリ・ベースであるメッセージ 待ち行列を介して行われます。 メッセージング・ クライアントとサーバ間のメッセージ転送に関する各種の パラダイム モデル。たとえば、要求 / 応答モード、会話モード、イベン ト、任意通知型通信などがあります。 サーバ BEA Tuxedo システムを介して指定されたサービスを提供 する実行可能プログラム。通常、サーバ・プログラムはユー ザが作成します。 ワークステー ション・ハンドラ (WSH) サーバ上のマルチ・コンテキストのゲートウェイ・プロセ ス。ワークステーション・クライアント ( リモート・サイト 上で実行されているクライアント・プロセス ) からのサービ ス要求を管理します。 BEA Tuxedo システム入門 3-51 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 マ ル チ・マ シ ン の構成要素 ワークステー シ ョ ン・リ ス ナ (WSL) ULOG ログ ) 説明 アプリケーション・サイト上で実行されるサーバ・プロセ ス。ワークステーション・クライアント ( リモート・サイト 上で実行されているクライアント・プロセス ) からの接続を 受け付け、配信します。 ユーザ・ エラー・メッセージが格納されるファイル。 複数のマシン上で実行されるコンフィギュレーションでは、プ ラットフォームの相互運用性とサーバの透過性が必要です。 プラットフォームの相互運用性とは、異なるマシン上で異なる オペレーティング・システムが実行されている場合でも、コー ドのカスタマイズを行わずに、アプリケーションがマシン間で 通信できることを意味します。 サーバの透過性とは、クライアントがサーバのロケーションを 指定しなくてもサーバにアクセスできることを意味します。 サーバのロケーションは掲示板に記録され、必要に応じてアク セスできます。そのため、アプリケーション自体を変更するこ となく、動的にサーバの移動、削除、追加を行うことができま す。 DBBL サーバおよび BRIDGE サーバは、このような分散ドメイン・ コンフィギュレーションの要件を満たしています。 関連項目 『BEA Tuxedo アプリケーションの設定』の 第 3 章の 3 ページ 「複数のマシンで構成 ( 分散 ) するアプリケーション用のコン フィギュレーション・ファイル」 『BEA Tuxedo アプリケーションの設定』の 第 6 章の 1 ページ 「ネットワークへのアプリケーションの分散」 『BEA Tuxedo アプリケーションの設定』の 第 7 章の 1 ページ 「分散アプリケーション用のコンフィギュレーション・ファイ ルの作成」 3-52 BEA Tuxedo システム入門 マルチ・ドメイン・コンフィギュレーション 『BEA Tuxedo アプリケーションの設定』の 第 8 章の 1 ページ 「分散アプリケーションのネットワーク設定」 『BEA Tuxedo アプリケーション実行時の管理』の 第 4 章の 1 ページ 「分散アプリケーションでのネットワーク管理」 マルチ・ドメイン・コンフィギュレーション マルチ・ドメイン・コンフィギュレーションは、互いに通信する 複数のドメインから構成されます。各ドメインは、シングル・マ シン・コンフィギュレーションまたはマルチ・マシン・コンフィ ギュレーションのいずれかです。ドメイン間の通信は、すべての ドメインに送信されるサービス要求と、すべてのドメインから応 答されるサービス要求を処理する高度な非同期マルチタスク・ ゲートウェイによって実現されます。複数の BEA Tuxedo ドメイ ンと接続することにより、あるドメインのクライアントがリモー ト・ドメインに物理的に存在するサービスに透過的にアクセスで きます。各ドメインはサービスとデータを共有していますが、別々 に管理されます。 BEA Tuxedo システムでは、さまざまなネットワーク転送プロトコ ルに対応した各種のゲートウェイが用意されています。以下に、各 タイプの Domains ゲートウェイについて説明します。 BEA Tuxedo Domains (TDomains) ゲートウェイは、複数の BEA Tuxedo アプリケーション間の相互運用を実現します。これは、 TCP/IP などのネットワーク転送プロトコル上を流れる特別に 設計された TP プロトコルを介して行われます。 BEA eLink for Mainframe-OSI TP ゲートウェイは、BEA Tuxedo アプリケーションと OSI TP 標準を使用するほかのトランザク ション処理アプリケーションの相互運用を実現します。OSI TP は、国際標準化機構 (ISO) によって定義された分散トランザク ション処理のためのプロトコルです。 BEA Tuxedo システム入門 3-53 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 BEA eLink for Mainframe-SN ゲートウェイは、BEA Tuxedo ド メイン内のクライアントとサーバ、およびリモート SNA ドメ イン内の MVS/CICS または MVS/IMS 環境のクライアントと サーバの相互運用を実現します。また、ローカルの BEA Tuxedo ドメインを複数の SNA ネットワークに接続します。 BEA eLink for Mainframe-TCP for CICS は、BEA Tuxedo 領域内 のトランザクションに関与しないタスクと CICS アプリケー ション・プログラム間で、一方が提供するサービスにもう一方 がアクセスできるようにするゲートウェイ接続機能です。この プロトコルによって、BEA Tuxedo ドメインが TCP/IP ネット ワーク転送プロトコルを介して CICS 環境と通信できるよう になります。 BEA eLink for Mainframe-TCP for IMS は、IMS システム内のク ライアント / サーバ・トランザクションと BEA Tuxedo ドメイ ン、CICS システム、またはほかの IMS システムとの間に、透 過的な通信を実現するゲートウェイ接続機能です。 TOP END Domain Gateway (TEDG) は、BEA TOP END システム と BEA Tuxedo ドメインの相互運用を実現します。 3-54 BEA Tuxedo システム入門 マルチ・ドメイン・コンフィギュレーション 次の図は、マルチ・ドメイン・コンフィギュレーションの基本要 素を示しています。 図 3-13 マルチ・ドメイン・コンフィギュレーション BEA Tuxedo システム入門 3-55 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 表 3-6 マルチ・ドメイン・コンフィギュレーションの構成要素 マルチ・ドメイン の構成要素 説明 BRIDGE BEA Tuxedo シ ス テ ム に よ っ て 提 供 さ れ る ド メ イ ン 内 の サーバ。マシン間でサービス要求を送受信し、要求をロー カル・サーバ ( 正確にはローカル・サーバの待ち行列 ) に ルーティングします。 掲示板 (BB) システムのコンフィギュレーションと動的な情報を保持す る共用メモリ・セグメント。すべての BEA Tuxedo プロセス から利用できます。 BBL 掲示板に格納されているデータ ( 掲示板に対する変更を含 む )、およびすべてのアプリケーション・プログラムを監視 する BEA Tuxedo の管理プロセス。 クライアント BEA Tuxedo システムを介して定期的にサービスを要求す る実行可能プログラム。通常、クライアント・プログラム はユーザが作成します。 DBBL 各マシン上の BBL サーバが実行されていて、正常に機能し ていることを確認するための専用プロセス。このサーバは、 アプリケーションのマスタ・マシン上で実行され、すべて の管理機能と直接通信します。 3-56 BEA Tuxedo システム入門 マルチ・ドメイン・コンフィギュレーション マルチ・ドメイン の構成要素 Domains ツール : DMADM、GWADM、 GWTDOMAIN、 dmloadcf、 dmunloadcf、 および DMCONFIG 説明 DMADM - Domains 管理サーバ。 GWADM - ゲートウェイ・グループの管理サーバ。 DMADM サーバに登録され、ゲートウェイ・グループに使用され るコンフィギュレーション情報を取得します。 GWTDOMAIN - リモート・ゲートウェイ・プロセスへの接 続を実現するゲートウェイ・プロセス (TDomains 用 )。 dmloadcf - DMCONFIG ファイルをバイナリ形式の BDMCONFIG コンフィギュレーション・ファイルに変換 します。 dmunloadcf - BDMCONFIG コンフィギュレーション・ ファイルをバイナリ表現から ASCII 表現に変換します。 DMCONFIG - Domains コンフィギュレーション・ファイ ル。 メッセージ待ち 行列 クライアントとサーバ間の通信は、オペレーティング・シ ステムでサポートされ、メモリ・ベースであるメッセージ 待ち行列を介して行われます。 メッセージング・ クライアントとサーバ間のメッセージ転送に関する各種の パラダイム モデル。たとえば、要求 / 応答モード、会話モード、イベン ト、任意通知型通信などがあります。 サーバ BEA Tuxedo システムを介して指定されたサービスを提供 する実行可能プログラム。通常、サーバ・プログラムはユー ザが作成します。 ワークステー ション・ハンドラ (WSH) サーバ上のマルチ・コンテキストのゲートウェイ・プロセ ス。ワークステーション・クライアント ( リモート・サイト 上で実行されているクライアント・プロセス ) からのサービ ス要求を管理します。 ワークステー シ ョ ン・リ ス ナ (WSL) アプリケーション・サイト上で実行されるサーバ・プロセ ス。ワークステーション・クライアント ( リモート・サイト 上で実行されているクライアント・プロセス ) からの接続を 受け付け、配信します。 BEA Tuxedo システム入門 3-57 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 マルチ・ドメイン の構成要素 ULOG ログ ) 説明 ユーザ・ エラー・メッセージが格納されるファイル。 関連項目 第 3 章の 47 ページ 「シングル・マシン・コンフィギュレー ション」 第 3 章の 62 ページ 「Domains 管理ツール」 『BEA Tuxedo アプリケーションの設定』の 第 3 章の 3 ページ 「複数のマシンで構成 ( 分散 ) するアプリケーション用のコン フィギュレーション・ファイル」 マルチ・ドメイン・コンフィギュレーションの特徴 複数のドメインを含むコンフィギュレーションでは、プラット フォームの相互運用性とサーバの透過性が必要です。 プラットフォームの相互運用性とは、異なるマシン上で異なる オペレーティング・システムが実行されている場合でも、コー ドのカスタマイズを行わずに、アプリケーションがマシン間で 通信できることを意味します。 サーバの透過性とは、クライアントがサーバのロケーションを 指定しなくてもサーバにアクセスできることを意味します。 サーバのロケーションは掲示板に記録され、必要に応じてアク セスできます。そのため、アプリケーション自体を変更するこ となく、動的にサーバの移動、削除、追加を行うことができま す。 BEATuxedo BRIDGE BEA Tuxedo BRIDGE は、BEA Tuxedo システムによって提供され るサーバの 1 つで、マシン間でサービス要求を送受信したり、ロー カル・サーバの待ち行列に要求をルーティングします。 3-58 BEA Tuxedo システム入門 BEA Tuxedo BRIDGE 各 BRIDGE は、システム内のほかのすべての BRIDGE とのネット ワーク接続を可能にします。ネットワーク接続は必要に応じて確 立され、無期限に維持されます。BRIDGE は、隠れたサーバです。 つまり、明示的なコンフィギュレーション・エントリがなくても、 必要に応じて自動的に起動し、停止します。メッセージは、これ らの永続的なネットワーク接続にわたって非同期に送信されま す。個々のメッセージに対して、ネットワーク接続のオーバーヘッ ドが発生することはありません。 図 3-14 マルチ・マシン ( 分散 ) アプリケーションにおける BRIDGE 関連項目 『BEA Tuxedo アプリケーションの設定』の 第 8 章の 1 ページ 「分散アプリケーションのネットワーク設定」 BEA Tuxedo システム入門 3-59 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 『BEA Tuxedo アプリケーションの設定』の 第 7 章の 1 ページ 「分散アプリケーション用のコンフィギュレーション・ファイ ルの作成」 掲示板と BBL の役割 掲示板 (BB) は、すべてのアプリケーション・コンフィギュレー ションと動的な処理に関する情報が実行時に保持されるメモリ・ セグメントです。BB では、次の機能が提供されます。 サービス要求を特定のサーバに割り当てます。サービスが呼び 出されると、掲示板は要求されたサービスを提供するサーバを 検索します。この情報とデータ依存型ルーティング基準に基づ いて、要求データを有効なサーバの要求待ち行列に挿入しま す。 サーバの待ち行列で待ち状態にある要求の数や、処理済みの要 求の数など、アプリケーションの状態に関する動的な情報を保 持します。 サーバの位置透過性を実現し、運用に依存しないアプリケー ションの開発を可能にします。これにより、開発および運用の コストを最小限に抑えることができます。 サーバ名のエイリアスをサポートし、同じサービスに複数の名 前を割り当てることができるようにします。この機能は、ゲー トウェイなどのインタプリタを構築する場合に役立ちます。 BBL は BEA Tuxedo サーバで、掲示板の状態を定期的に調べて、シ ステムのすべての構成要素の機能を調節します。 3-60 BEA Tuxedo システム入門 クライアントとサーバ 図 3-15 掲示板と BBL クライアントとサーバ クライアント − クライアントとは、ユーザからの要求を収集 し、その要求を処理できるサーバに渡すプログラムです。ユー ザからの入力を収集するアプリケーションのフロント・エンド の一部として、PC またはワークステーション上に置くことが できます。また、ATM マシンなどの通信装置を読み取るソフ トウェアの中に埋め込むこともできます。このような通信装置 からデータが収集され、BEA Tuxedo サーバによって処理され る前にフォーマット処理されます。 サーバ − BEA Tuxedo サーバとは、一連のサービスを監督し、 それらを要求したクライアントに対して自動的にディスパッ チするプロセスです。それに対して、サービスとは、ビジネス に必要な特定のタスクを実行するサーバ・プログラム内の関数 です。たとえば、銀行には、預け入れを受け取るサービスと、 口座残高を報告するサービスが用意されています。あるサーバ が、この両方のサービスをクライアントから受け取ったとしま す。それぞれの要求を該当するサービスにディスパッチするの は、サーバの仕事です。 BEA Tuxedo システム入門 3-61 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 DBBL DBBL は、複数のマシン間でアプリケーションの分散を可能にす るサーバです。各マシン上の BBL サーバが実行されていて、正常 に機能していることを確認します。このサーバは、アプリケーショ ンの MASTER マシン上で実行され、すべての管理機能と直接通信 します。 DBBL を使用すると、コンフィギュレーションとサービスのアド レス指定情報が、コンフィギュレーション内の各マシン上の掲示 板に必ず複製されるようになります。リモート・マシン上のサー バは、ローカル・マシン上の BRIDGE を介してアクセスできます。 ローカル・マシン上のサーバは、直接アクセスできます。すべて のローカル通信は、オペレーティング・システムの高パフォーマ ンスのメッセージ待ち行列を介して行われます。リモート通信は、 2 段階で行われます。まず、サービス要求が ( ローカルの ) BRIDGE を介してリモート・マシンに転送されます。次に、リモート・マ シンに到達した要求が、オペレーティング・システムのメッセー ジを使用して適切なサーバに送られます。 Domains 管理ツール マルチ・ドメイン・コンフィギュレーションを構築するには、既 存の BEA Tuxedo アプリケーションをほかのドメインと統合する 必要があります。ドメイン間の相互運用性を確認し、すべてのド メイン上のサービスへのアクセスを維持し、すべてのドメインか らのサービス要求を受け付ける必要があります。これらの機能は、 すべてのドメインに送信されるサービス要求と、すべてのドメイ ンから応答されるサービス要求を処理する高度な非同期マルチタ スク・ゲートウェイによって実現されます。このゲートウェイを 使用するには、ドメイン・ゲートウェイ・グループとゲートウェ イ・サーバ用のエントリを TUXCONFIG ファイルに追加する必要が あります。次の図は、BEA Tuxedo システムによって提供されるマ ルチ・ドメイン・コンフィギュレーションの設定と管理を行うツー ルを示しています。 3-62 BEA Tuxedo システム入門 Domains 管理ツール 図 3-16 Domains 管理ツール Domains ツール 説明 dmadmin(1) ドメイン・ゲートウェイ・グループのコンフィギュレー ション、監視、およびチューニングを動的に行うコマンド。 このコマンドを使用すると、アプリケーションの実行中に BDMCONFIG ファイルを更新できます。このコマンドは、管 理コマンドを DMADMIN サービスへのサービス要求に変換 す る フ ロ ン ト エ ン ド・プ ロ セ ッ サ と し て 機 能 し ま す。 DMADMIN サービスは、DMADM サーバにより宣言される汎 用管理サービスです。DMADMIN サービスは、BDMCONFIG ファイルの管理するために、DMADM サーバによって提供さ れる妥当性検査、取得、または更新処理を行います。 BEA Tuxedo システム入門 3-63 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 Domains ツール 説明 の コ ン フ ィ ギ ュ レ ー シ ョ ン 情 報 は、す べ て D M C O N F I G ( 5 ) 、 Domains BDMCONFIG BDMCONFIG ファイルと呼ばれるバイナリ・ファイルに格 納されています。テキスト形式の Domains ゲートウェイ・ コンフィギュレーション・ファイル (DMCONFIG) は、テキ スト・エディタを使用して作成したり編集できます。コン パイルされた BDMCONFIG ファイルは、システムの実行中 に更新できます。 dmloadcf と dmunloadcf dmloadcf − DMCONFIG ファイルを読み取り、構文を調 べて、オプションでバイナリ形式の BDMCONFIG コンフィ ギュレーション・ファイルをロードします。 dmunloadcf − BDMCONFIG コンフィギュレーション・ ファイルをバイナリ形式からテキスト形式に変換します。 DMADM(5) 実行時の Domains コンフィギュレーションの管理を可能に する Domains 管理サーバ。DMADM は、ゲートウェイ・グ ループの登録サービスを提供します。このサービスは、 GWADM サ ー バ の 初 期 化 プ ロ シ ー ジ ャ の 一 部 と し て GWADM サーバによって要求されます。登録サービスは、要 求元のゲートウェイ・グループが要求するコンフィギュ レーション情報をダウンロードします。DMADM サーバは、 登録したゲートウェイ・グループのリストを維持し、コン フィギュレーションに行った変更をこれらのゲートウェ イ・グループに伝達します。 GWADM(5) 特定のゲートウェイ・グループの実行時の管理をサポート するゲートウェイ管理サーバ。このサーバは、DMADM サー バに登録され、対応するゲートウェイ・グループで使用さ れるコンフィギュレーション情報を取得します。GWADM は DMADMIN からの要求を受け付け、実行時統計情報を取得 したり、指定されたゲートウェイ・グループの実行時オプ ションを変更します。GWADM は、定期的に "I-am-alive" メッ セージを DMADM サーバに送信します。DMADM から応答が なければ、GWADM は再度登録を行います。このプロセスに よって、常にグループの Domains コンフィギュレーション の最新コピーが GWADM サーバに確保されます。 3-64 BEA Tuxedo システム入門 IPC メッセージ待ち行列 Domains ツール 説明 GWTDOMAIN(5) 接続されているすべてのドメイン内のクライアントおよ びサーバからのメッセージを受信し、転送するゲートウェ イ・プロセス (TDomains 用 )。 BDMCONFIG マルチ・ドメイン・コンフィギュレーション用のバイナリ 形式のコンフィギュレーション・ファイル。 IPC メッセージ待ち行列 BEA Tuxedo システムでは、IPC メッセージ待ち行列を使用して、 特定のマシン上で実行されるプロセス間の通信がサポートされて います。IPC メッセージ待ち行列は一時メモリ領域で、通常はオ ペレーティング・システムによって提供され、クライアントとサー バ間の通信に使用されます。デフォルトでは、各サーバが専用の IPC メッセージ待ち行列を持ち、要求と応答を受け取ります。こ の方法は「単一サーバ、単一待ち行列 (SSSQ)」と呼ばれます。必 要に応じて、デフォルトを変更して、複数のサーバが同じ待ち行 列から読み取るように設定することもできます。この方法は「複 数サーバ、単一待ち行列 (MSSQ)」と呼ばれます。同じアプリケー ションで、SSSQ と MSSQ の両方を使用できます。サーバは、い ずれかのタイプの待ち行列に割り当てることができます。 BEA Tuxedo システム入門 3-65 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 単一サーバ、単一待ち行列 (SSSQ) の使用 SSSQ を理解するために、スーパーマーケットを例に考えてみま す。スーパーマーケットには、複数のレジの列があります。レジ の列はそれぞれ別個の待ち行列に相当します。各レジでは、顧客 が 1 人のレジ係の作業を待ちます。その列の作業の速さは、レジ 係によって異なります。ある顧客に対する作業に遅れが生じると、 その列の後続の顧客にもそれぞれ遅れが発生します。ただし、ほ かの列には何の影響もありません。この方式は、異なる種類のサー ビスを提供する複数のサーバ間でロード・バランシングを行い、作 業量を調整するために使用します。要求が比較的小さい顧客は、通 常の顧客とは別の待ち行列を持つサーバによって処理することが できます。小さい要求のためのサイクルまたはレジスタを確保す ることにより、スループットが向上します。 複数サーバ、単一待ち行列 (MSSQ) のセットの使用 MSSQ では、オペレーティング・システムによって提供される IPC メッセージングを使用して、さらにロード・バランシングが進め られます。1 つの待ち行列には、常に同じサービスを提供する複数 のサーバが対応しています。ある要求がサーバの待ち行列に送信 され、その待ち行列が MSSQ セットの一部である場合、メッセー ジが待ち行列から取り出されて、使用可能な最初のサーバに送ら れます。このようにして、個々の待ち行列のレベルでロード・バ ランシングが行われます。 MSSQ を構成するサーバには、そのサーバ固有の応答待ち行列を 設定する必要があります。このサーバがほかのサーバに対して要 求を行った場合、その応答は要求元のサーバに返されなければな りません。つまり、MSSQ 内のほかのサーバによって待ち行列か ら取り出されないようにする必要があります。 大 半 の ア プ リ ケ ー シ ョ ン で は、「複 数 サ ー バ、単 一 待 ち 行 列 (MSSQ)」は重要な役割を果たします。この方式は、サービスの待 ち時間の合計を最小限に抑える場合に理想的です。MSSQ は、要 求を処理できるサーバがアイドル状態のときに、サービス要求を 待機させないようにする場合に使用します。 3-66 BEA Tuxedo システム入門 IPC メッセージ待ち行列 次の場合には、MSSQ の使用をお勧めします。 サービスの処理時間が最重視される場合 サーバの数が適度 (2 ∼ 12) である場合 各サーバが同じサービスを提供する場合 適度なサイズ ( 待ち行列のサイズの 75% 未満 ) のメッセージが 含まれている場合 待ち行列のロードに基づいて自動的にサーバが増減するよう に、MSSQ を動的にコンフィギュレーションできる場合 注記 障害耐久性から、MSSQ は常に複数のサーバで使用してくだ さい。 MSSQ は、長いメッセージがサービスに渡される場合には適して いません。長いメッセージによって、待ち行列がいっぱいになる ことがあるからです。待ち行列がいっぱいになると、非ブロッキ ング送信が失敗するか、またはブロッキング送信がブロックされ ます。 次の場合には、MSSQ の使用をお勧めしません。 バッファ・サイズが 1 つの待ち行列でいっぱいになる場合。 サーバ数が多すぎる場合。ただし、MSSQ を複数使用して対処 することもできます。 サーバごとにサービスが異なる場合。 例 MSSQ を理解するために、銀行を例に考えてみます。銀行では、同 じサービスを行う複数の窓口が 1 列に並んだ顧客に応対します。 次に空く窓口が、常に列の次の顧客に応対します。この例では、各 窓口がすべての顧客サービスを行うことができなければなりませ ん。BEA Tuxedo 環境の場合、単一の待ち行列を共有するように設 定されたすべてのサーバは、常に同じサービスを提供する必要が あります。MSSQ の利点は、個々の待ち行列のレベルで、ロード・ バランシングのもう 1 つの形式を提供していることです。 BEA Tuxedo システム入門 3-67 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 ワークステーション・ハンドラとワークステーション・ リスナ ワークステーション・コンポーネントは、ワークステーション上 のクライアントでもネイティブの BEA Tuxedo アプリケーション を利用できるようにします。このコンポーネントを使用した場合、 ワークステーションがアプリケーションの管理ドメイン内になく てもかまいません。 次の図は、2 つのワークステーション・クライアント (WSC) が接 続されたアプリケーションを示しています。1 つのクライアント は、UNIX システム・ワークステーション上で実行され、もう 1 つ のクライアントは NT ワークステーション上で実行されています。 どちらの WSC も ワークステーション・ハンドラ (WSH) プロセス を通じてアプリケーションと通信しています。最初に、両者とも ワークステーション・リスナ (WSL) と通信することによって、ア プリケーションに参加します。ワークステーションは、クライア ントが代理のハンドラ・プロセスを通してアプリケーションの サービスにアクセスできる環境を定義します。 3-68 BEA Tuxedo システム入門 ワークステーション・ハンドラとワークステーション・リスナ 図 3-17 BEA Tuxedo アプリケーションとワークステーション・コンポーネント ワークステーション上のプログラミング環境は、マシンのオペ レーティング・システムによって決まります。アプリケーション の管理ドメインへの接続は、ローカル・エリア・ネットワーク (LAN) によって行われます。そのため、アプリケーション・サー ビスを配布するハードウェアおよびソフトウェアのプラット フォームの選択で柔軟性がさらに高まります。 BEA Tuxedo システム入門 3-69 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 ワークステーション・クライアントのアプリケーションへの 接続 ワークステーション・クライアントは、次の手順に従ってアプリ ケーションに接続します。 図 3-18 アプリケーションに接続中の WSC 3-70 BEA Tuxedo システム入門 ユーザ・ログ (ULOG) ユーザ・ログ (ULOG) ユーザ・ログ (ULOG) は、BEA Tuxedo システムによって生成され るすべてのメッセージ、つまりエラー・メッセージ、警告メッセー ジ、情報メッセージ、デバッグ・メッセージが書き込まれるファ イルです。アプリケーションのクライアントおよびサーバも、ユー ザ・ログへの書き込みが可能です。ログは毎日新しく作成されま す。そのため、マシンごとにログが異なる場合もあります。ただ し、リモート・ファイル・システムが使用されている場合、ULOG を複数のマシンで共有できます。 ULOG によって管理者に提供されるシステム・イベントの記録か ら、BEA Tuxedo システムおよびアプリケーションのほとんどの障 害の原因を特定できます。ULOG はテキスト・ファイルなので、任 意のテキスト・エディタで表示できます。ULOG には、tlisten プ ロ セ ス に よ っ て 生 成 さ れ る メ ッ セ ー ジ も 挿 入 さ れ て い ま す。 tlisten プロセスは、ほかのマシンに対するリモート・サービス 接続を提供します。マスタ・マシンを含み、各マシンで tlisten プロセスが実行されていることが必要です。 ULOG の作成 ULOG は、次のいずれかの処理が行われるたびに、BEA Tuxedo シ ステムによって生成されます。 新しいコンフィギュレーション・ファイルのロード アプリケーションの起動 ULOG メッセージの例 次は、ULOG メッセージの例です。 121449.gumby!simpserv.27190.1.0:LIBTUX_CAT:262:std main starting ULOG メッセージは、タグとテキストから構成されています。 タグは、次の要素から構成されます。 時間、分、秒で時刻を表す 6 桁の文字列 (hhmmss)。 BEA Tuxedo システム入門 3-71 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 マシンの名前 (UNIX システムの uname -n コマンドの戻り値 )。 メッセージを記録しているプロセスの名前と識別子。このプロ セス ID には、オプションでトランザクション ID を含めること もできます。また、スレッド ID (1) およびコンテキスト ID (0) も含まれています。 注記 シングル・スレッド・アプリケーションの場合、thread_ID フィールドと context_ID フィールドにプレースホルダが 出力されます。アプリケーションがマルチスレッドであるか どうかは、複数のスレッドを使用するまでわかりません。 テキストは、次の要素から構成されます。 メッセージ・カタログの名前 メッセージ番号 BEA Tuxedo システム・メッセージ タグが示す内容 テキストが示す内容 このメッセージは、午後 12 時 15 分 このメッセージは、 LIBTUX カタ 頃にログに書き込まれました。 ログから送信されました。 エラーが発生したマシンは、gumby メッセージの番号は 262 です。 です。 メ ッ セ ー ジ 自 体 の 内 容 は、std このメッセージは、プロセス ID が main starting です。 27190 である simpserv プロセスに よって記録されました。 スレッド ID は 1 です。 コンテキスト ID は 0 です。 注記 メッセージの詳細を確認するには、カタログの名前と番号を 記録します。この情報を使用して、該当するカタログでメッ セージを参照します。 3-72 BEA Tuxedo システム入門 ユーザ・ログ (ULOG) ULOG の存在する場所 デフォルトでは、ユーザ・ログは ULOG.mmddyy (mmddyy は、月、 日、年で表された日付 ) という名前で $APPDIR ディレクトリに生 成さ れま す。UBBCONFIG ファ イル の MACHINES セク ショ ンで ULOGPFX パラメータを設定すると、このファイルを任意の場所に 置くことができます。 BEA Tuxedo システム入門 3-73 第3章 BEA Tuxedo システム・インフラストラクチャに対する 3 つの視点 3-74 BEA Tuxedo システム入門 第4章 BEA Tuxedo 製品ファミリとエンタープラ イズ・システムの統合 BEA Tuxedo 製品の統合 メインフレーム・コネクティビティ : BEA eLink インターネット・アクセス : BEA Jolt アプリケーションの開発と管理 : BEA Manager オンライン・トランザクション処理 : BEA Tuxedo コア・システ ム スケーラビリティの実現 : BEA Tuxedo Domains メッセージとサービス要求の格納 : BEA Tuxedo /Q ワークステーション・コネクティビティ : BEA Tuxedo Workstation WebLogic Enterprise を使用したクライアント/ サーバ・アーキテ クチャの開発 Java ベースの分散アプリケーションの開発と管理 : BEA WebLogic Server BEATuxedo 製品の統合 BEA 製品ファミリでは、異種ハードウェアおよびソフトウェア環 境でエンド・ツー・エンドの統合を簡単に行うことができ、エン タープライズ規模のトランザクション処理システムを構築できる ようになります。BEA 製品は、分散クライアント / サーバ・コン ピューティングの柔軟性と、堅牢なミッション・クリティカルな アプリケーションの利点を企業にもたらします。すべての主な業 界標準に準拠しているため、開発者はエンタープライズ規模のア プリケーションを 70 以上ものプラットフォームで構築、運用、管 理、接続することができます。また、市場をリードするアプリー ケーション開発ツール、システム管理ソリューション、およびレ ガシー・アプリケーションとの完全な統合が可能です。 BEA Tuxedo システム入門 4-1 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 数あるオープン・ミドルウェア・ベンダの中で、BEA の提供する ソリューションは、業界屈指のトランザクション処理コンポーネ ント、Web アプリケーション・サーバ、メッセージング製品が提 供された唯一の完全でエンド・ツー・エンドのエンタープライズ・ ミドルウェア・ソリューションです。 BEA 製品スイート BEA 製品スイートには、次のコンポーネントが含まれています。 BEA eLink − BEA Tuxedo の分散アプリケーションをメインフ レーム・アプリケーションにシームレスに統合するコネクティ ビティ製品ファミリです。 BEA Jolt − インターネット・アクセスと完全な Java 開発サ ポートを提供します。Jolt は、Java 対応クライアントからの要 求を受け取り、BEA Tuxedo アプリケーションの呼び出しに変 換します。 BEA Manager − 管理のためのツールを提供します。 BEA Tuxedo システムは、次の 4 つのコンポーネントから構成 されます。 BEA Tuxedo コア製品 − 最も運用範囲の広いトランザク ション・ミドルウェアで、高パフォーマンスで高信頼性の ミッション・クリティカルな分散アプリケーションを構築 します。異機種の分散環境で、スケーラブルな 3 層クライ アント / サーバ・アプリケーションを構築する業界屈指の ミドルウェア・フレームワークを提供します。 BEA Tuxedo Workstation − Windows、OS/2、Mac、UNIX な どのプラットフォーム上のクライアントを完全にサポート します。これにより、BEA Tuxedo のフル・インプリメント が必要ではないリモート・クライアントをアプリケーショ ンで使用できるようになります。 BEA Tuxedo Domains − BEA Tuxedo クライアント / サーバ・ モデルを拡張して、ドメイン間にトランザクションの情報 交換機能を提供します。 4-2 BEA Tuxedo システム入門 BEA Tuxedo 製品の統合 BEA Tuxedo /Q − クライアントおよびサーバがメッセー ジやサービス要求を格納して、確実な処理が行われるよう にします。 BEA WebLogic Enterprise − 定評のあるプラットフォーム上 で、コンポーネント・ベースのソリューションを構築、運用、 管理することができます。BEA Tuxedo システムの強力さ、堅 牢さ、実証された信頼性に基づいて、Common Object Request Broker Architecture (CORBA) や Enterprise Java Beans (EJB) など の業界標準を最良の形で統合しています。コンポーネント・ ベースのプログラミング機能を備えたこれらのツールによっ て、実際の環境で運用できる完全なエンタープライズ・ソ リューションを構築できます。 BEA WebLogic Server − 大規模な分散型の Web アプリケー ション、ネットワーク・アプリケーション、およびデータベー ス・アプリケーションを開発、統合、運用、および管理するた めの Java アプリケーション・サーバです。 図 4-1 BEA 製品の統合 BEA Tuxedo システム入門 4-3 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 メインフレーム・コネクティビティ : BEA eLink BEA eLink 製品ファミリは、BEA Tuxedo アプリケーションと、IBM CICS と IMS アプリケーション、OSI トランザクション・モニタ間 で、アプリケーションからアプリケーションへのシームレスなト ランザクションの相互運用性を実現します。 この相互運用性は、エンド・ユーザからもアプリケーション・プ ログラマからも透過的です。インターフェイスの両側で、ネイティ ブの API と TP モニタが使用されます。 関連項目 第 4 章の 4 ページ 「BEA eLink 製品スイートのコンポーネン ト」 BEA eLink 製品スイートのコンポーネント BEA eLink for Mainframe - TCP/IP for MVS (for IMS and CICS) BEA eLink for Mainframe - SNA BEA eLink for Mainframe - OSI TP BEA eLink for Mainframe - TCP/IP for MVS (for IMS and CICS) BEA eLink for Mainframe - TCP/IP ゲートウェイは BEA Tuxedo シス テム上で実行され、IBM システム上の CICS 領域または IMS 下で 利用可能なサービスを宣伝します。 メインフレーム上では、BEA eLink for Mainframe - TCP/IP for CICS ゲートウェイ、または BEA eLink for Mainframe - TCP/IP for IMS ゲートウェイのいずれかが、MVS TCP/IP 通信スタックを使用し て、BEA Tuxedo システムからの要求を読み取り、ローカル・ルー チンに転送します。 バッファのデータ表現の変換とバッファ・レイアウトのマッピン グは、BEA eLink ゲートウェイで設定できます。このゲートウェ イは、単方向でトランザクションに関与しません。 4-4 BEA Tuxedo システム入門 BEA eLink 製品スイートのコンポーネント 図 4-2 BEA eLink for Mainframe - TCP/IP BEA eLink for Mainframe - SNA BEA eLink for Mainframe - SNA では、BEA Tuxedo システム上の ゲートウェイが、ATMI プロトコルを LU6.2/PU2.1 プロトコルに マップします。このマッピングによって、メインフレーム上のルー チンが、CPIC または APPC 関数を使用して、BEA Tuxedo システ ムからデータを受け取ってローカル・ルーチンに転送したり、BEA Tuxedo システム内のサービスを要求できるようになります。 バッファのデータ表現の変換とバッファ・レイアウトのマッピン グは、BEA eLink ゲートウェイで設定できます。BEA eLink for Mainframe - SNA は、双方向で完全にトランザクションに関与しま す。 BEA Tuxedo システム入門 4-5 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 図 4-3 BEA eLink for Mainframe - SNA BEA eLink for Mainframe - OSI TP BEA eLink for Mainframe - OSI TP 製品は、BEA eLink for Mainframe SNA 製品と似ています。 両方ともに BEA Tuxedo Domains アーキテクチャ上に構築され、 ゲートウェイ・プロセスを介して透過的でトランザクションに関 与する双方向のアクセスを提供します。このゲートウェイ・プロ セスによって、XATMI プロトコルと外部の TP システム ( この場 合は OSI TP) のプロトコル間で変換が行われます。 4-6 BEA Tuxedo システム入門 インターネット・アクセス : BEA Jolt 図 4-4 BEA eLink for Mainframe - OSI TP インターネット・アクセス : BEA Jolt BEA Jolt を使用すると、BEA Tuxedo クライアントを Java 言語で作 成し、インターネットやイントラネットを介して利用できるよう になります。この製品は、Jolt クラス・ライブラリと Jolt リポジト リという 2 つの主なコンポーネントから構成されています。この 2 つのコンポーネントは、Java で記述されていない BEA Tuxedo ア プリケーションで使用できます。BEA Jolt を使用すると、クライ アントとサーバ間に、インターネットを介した安全でスケーラブ ルなトランザクションを構築できます。 BEA Tuxedo システム入門 4-7 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 図 4-5 BEA Jolt 関連項目 第 4 章の 8 ページ 「BEA Jolt のコンポーネント」 BEA Jolt のコンポーネント BEA Jolt は、Java クラス・ライブラリ、および Java クライアント と BEA Tuxedo システム間の API から構成されます。BEA Jolt に は、BEA Tuxedo のサービスにアクセスする Java ベースのクライ アント・プログラムを作成したり、企業のファイアウォール内部 のサーバに安全で信頼性の高いアクセスを行うためのいくつかの コンポーネントが提供されています。 Jolt サーバ − 1 つ以上の Jolt サーバが、クライアントからの ネットワーク接続要求を受け付け、Jolt メッセージを変換し、 複数のクライアントを単一のプロセスに多重化し、1 つ以上の BEA Tuxedo サーバ上で実行されている BEA Tuxedo アプリ ケーション間で要求をやり取りします。 4-8 BEA Tuxedo システム入門 BEA Jolt のコンポーネント Jolt クラス・ライブラリ (Java 用 ) − Jolt クラス・ライブラリは、 Jolt API をインプリメントする Java クラス・ファイルから構成 されます。これらのクラスによって、Java のアプリケーション およびアプレットが BEA Tuxedo のサービスを呼び出すこと ができるようになります。Jolt クラス・ライブラリでは、通信 属性、通知、ネットワーク接続、トランザクション、および サービスの管理、取得、呼び出しを行うための関数が提供され ます。 Jolt リポジトリ − Jolt の中央リポジトリには、BEA Tuxedo シ ステム・サービスの定義が格納されています。Jolt は、これら のリポジトリの定義を使用して、実行時に BEA Tuxedo のサー ビスにアクセスします。リポジトリ・エディタを使用すると、 クライアント・アプリケーションとは関係なく、新規および既 存の BEA Tuxedo サービスをテストできます。サービスは、Jolt クライアント・アプリケーションにエクスポートしたり、また は Jolt クライアントから定義を隠すことによってアンエクス ポートできます。 Jolt インターネット・リレー − Jolt インターネット・リレーは、 Jolt クライアントから Jolt サーバ・リスナ (JSL) または Jolt サーバ・ハンドラ (JSH) にメッセージをルーティングするコン ポーネントです。このツールを使用すると、JSH と BEA Tuxedo システムを Web サーバとして同じマシン上で実行する必要が なくなります。Jolt インターネット・リレーは、Jolt リレー (JRLY) と Jolt リレー・アダプタ (JRAD) から構成されます。 BEA Jolt がこれらのコンポーネントに分割されていることによっ て、クライアント / サーバ・アプリケーションのトランザクショ ン・コンポーネントとインターネット・コンポーネントを別々に インプリメントし、大規模なインターネットおよびイントラネッ ト・サービスに必要なセキュリティとスケーラビリティを実現で きます。 BEA Tuxedo システム入門 4-9 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 アプリケーションの開発と管理 : BEA Manager BEA Manager はソフトウェア製品が統合されたシステムであり、 業界標準の SNMP テクノロジを使用して、BEA Tuxedo アプリケー ションの開発、管理、統合、運用を行うための完全な環境を提供 します。 図 4-6 BEA Manager 4-10 BEA Tuxedo システム入門 BEA Tuxedo 製品のコンポーネント BEA Manager のコンポーネント 表 4-1 BEA Manager のコンポーネント . BEA Manager の コンポーネント 説明 BEA Manager Agent Connection BEA Tuxedo 管理情報ベース (TMIB) を標準の SNMP 管理 コンソール (OpenView、NetView、Tivoli、BMC など ) に表 示できるようにします。コンソールを使用すると、エン タープライズ環境の集約として情報を簡単に表示して管 理できます。 BEA Manager Agent Integrator 同じ管理マシン上で複数の SNMP エージェントを実行す ることによって、発生した問題を解決します。あらゆるベ ンダの各種の SNMP エージェントおよびサブエージェン トを同じマシン上で操作できます。これらは、SNMP 管理 コンソール上では 1 つの SNMP エージェントとして扱われ ます。 BEA Manager Agent Development Kit 開 発 者 が 独 自 の SNMP エ ー ジ ェ ン ト を 作 成 し て、BEA Tuxedo ( および Tuxedo 以外の ) アプリケーションやそのほ かの特殊化されたソフトウェアまたはハードウェアを監 視したり制御できます。 BEA Manager Log Central 分散マシンからのログ・メッセージを 1 つのマシンにまと めて、表示、フィルタ処理、管理を行うログ集中管理型シ ステムです。イベントを選択して SNMP 管理コンソールに 送ることもできます。 BEATuxedo 製品のコンポーネント BEA Tuxedo コア製品 BEA Tuxedo Domains BEA Tuxedo /Q BEA Tuxedo Workstation BEA Tuxedo システム入門 4-11 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 オンライン・トランザクション処理 : BEA Tuxedo コア・ システム BEA Tuxedo システムは、ビジネスのニーズに応じて、異種のハー ドウェア・プラットフォーム、データベース、オペレーティング・ システムが混在するアプリケーションを作成するための開発プ ラットフォームです。クライアント / サーバ・アーキテクチャ、要 求 / 応答型および会話型の通信インターフェイス、トランザクショ ン・サポート、および分散アプリケーション管理のための基盤を 提供します。 BEA Tuxedo システムは、スケーラビリティ、高パフォーマンス、 ミッション・クリティカルな信頼性、標準準拠など、ハイエンド のオンライン・トランザクション処理 (OLTP) システムが持つあら ゆる特徴と利点を備えています。 図 4-7 基本的な BEA Tuxedo システムのアーキテクチャ 4-12 BEA Tuxedo システム入門 オンライン・トランザクション処理 : BEA Tuxedo コア・システム この図に示されているように、BEA Tuxedo システムは次の要素か ら構成されます。 構成要素 説明 外部インター フェイス層 この層は、ユーザとシステム間のインターフェイスで構成さ れ ま す。Simple Network Management Protocol (SNMP) エ ー ジ ェ ン ト な ど の ア プ リ ケ ー シ ョ ン 開 発 ツ ー ル と、BEA Administration Console などの管理ツールの両方が含まれて います。BEA Administration Console と SNMP エージェント は、標準の管理コンソールとやり取りすることができます。 そのため、ユーザは BEA Tuxedo システムとネットワークの コンフィギュレーションを 1 つのコンソールから管理でき ます。また、アプリケーションの構築担当者および開発者 は、独自の管理ツールや、アプリケーション固有または市場 固有のツールを MIB の上に構築できます。 MIB ( 管理情報 ベース ) 管理情報ベース (MIB) は、ユーザが BEA Tuxedo システムの プログラミングと管理を簡単に行うことができるようにす るインターフェイスです。MIB の操作によって、監視、コン フィギュレーション、チューニングなど、あらゆる管理タス クを実行できます。MIB では、一度に 1 つのタスクを 1 つの オブジェクトに対して実行したり、ツール・キットを作成し てタスクやオブジェクトをバッチ処理できます。MIB の構成 要素については、第 3 章の 3 ページ「使用可能な BEA Tuxedo システムの MIB」を参照してください。 BEA Tuxedo システム入門 4-13 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 構成要素 説明 A dm inistratio n Console BEA Tuxedo アプリケーションを管理するための Web ベー スのグラフィカル・ユーザ・インターフェイスです。このイ ンターフェイスを使用すると、MIB のデータを入力したり変 更することができます。BEA Administration Console は、これ らのツールを Web ブラウザから利用できるようにします。 BEA Administration Console のサーバ側コンポーネントは、 BEA Tuxedo ドメイン内のいずれかのマシンに存在します。 Console を使用するには、サーバの URL を入力して、一連の Java アプレットをダウンロードする必要があります。この Java アプレットによって Console がインプリメントされま す。現在利用できるブラウザがあれば、誰でも Console を使 用して BEA Tuxedo アプリケーションを管理できます。 ATMI ( ア プ リ ケーション・ト ランザクショ ン・モニタ・イン ターフェイス ) アプリケーション・プログラムと BEA Tuxedo システム間の インターフェイスです。ATMI と BEA Tuxedo システムは、 トランザクション処理の X/Open DTP モデルをインプリメン トします。ATMI は、抽象的な環境として、位置透過性をサ ポートし、インプリメンテーションの詳細を隠ぺいします。 その結果、プログラマは、アプリケーション・コードを変更 しなくても、自由に BEA Tuxedo アプリケーションを設定し たり運用することができます。 BEA Tuxedo サー ビス ( 管理サー ビスおよびアプ リケーション処 理サービス ) BEA Tuxedo システム・インフラストラクチャに共通する サービスや機能で、アプリケーションの開発および管理に使 用します。開発者が利用できるアプリケーション処理サービ スには、トランザクション、メッセージング・パラダイム、 タイプ検証、ロード・バランシング、データ依存型ルーティ ング、サービスの優先順位付け、データ符号化、マーシャリ ング、圧縮、信頼性のある待ち行列処理などがあります。管 理サービスには、分散トランザクション処理、セキュリティ 管理、サービスのネーミング、分散アプリケーション管理、 集中管理型のアプリケーション・コンフィギュレーション、 動的な再コンフィギュレーション、ドメインの分割などがあ ります。 4-14 BEA Tuxedo システム入門 スケーラビリティの実現 : BEA Tuxedo Domains 構成要素 説明 リ ソ ー ス・マ ネージャ データが格納されたソフトウェア製品で、内部データはアプ リケーション・ベースの問い合わせによって取得されます。 リソース・マネージャ (RM) は、BEA Tuxedo システム間で やり取りを行い、XA 標準インターフェイスをインプリメン トします。リソース・マネージャのよく知られた例はデータ ベースです。リソース・マネージャは、トランザクション機 能とアクションの永続性を実現します。これらは、グローバ ル・トランザクション内でアクセスおよび制御できます。 関連項目 第 2 章の 1 ページ 「BEA Tuxedo システムのアーキテクチャ」 スケーラビリティの実現 : BEATuxedo Domains Domains は、BEA Tuxedo システムのクライアント / サーバ・モデ ルを拡張して、TP ドメイン間にトランザクションの情報交換機能 を提供します。この機能により、リモート・ドメイン上のサービ スへのアクセスおよびリモート・ドメインからのサービス要求の 受け付けは、アプリケーション・プログラマとユーザに透過的に 処理されます。したがって、クライアント / サーバ・モデルと ATMI インターフェイスとの互換性が保持されます。Domains では、こ のような機能がリモート・ドメインに対するサービス要求と、リ モート・ドメインからのサービス要求を処理する高度な非同期マ ルチタスク・ゲートウェイによって実現されています。 BEA Tuxedo システム入門 4-15 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 図 4-8 マルチ・ドメイン環境 4-16 BEA Tuxedo システム入門 スケーラビリティの実現 : BEA Tuxedo Domains BEA Tuxedo Domains の機能 BEA Tuxedo Domains には、次の機能があります。 エイリアス機能 − 管理者は、ローカル・アプリケーションに 使用されるサービス名に、リモート・アプリケーションに使用 されるサービス名をマップできます。そのため、異なるネーミ ング方式が使用されているアプリケーションを簡単に統合で きます。 可用性 − 1 つのリモート・ドメインに対して複数のネット ワーク・アドレスを定義できます。管理者は、一連のサービス を実行するバックアップ・ドメインを指定できます。 スケーラビリティとモジュール化の促進 − アプリケーショ ン・プログラマは、モジュラリティ、障害の分離、独立した拡 張を実現するアプリケーションを構築できます。リモート・ア プリケーションと Domains のコンフィギュレーション間のイ ンターフェイス ( つまりサービス ) の記述を追加するだけで、 ほかの TP アプリケーションとの相互運用性を簡単に実現でき ます。 セキュリティ − アクセス制御リスト (ACL) 機能によって、特 定のリモート・ドメインからローカル・サービスへのアクセス が制限されます。また、このセキュリティ機能によって、リ モート・ドメインで利用できるエクスポートされたサービスの 各種のビューを定義することもできます。 透過性と独立性 − サービスの配布は、アプリケーションでは まったく意識されません。クライアント・アプリケーションの プログラマは、サービスに対するインプリメンテーションの変 更、サービスの場所、ネットワーク・アドレスなどを知る必要 はありません。サービスは、クライアントと同じマシン、ロー カル・ドメイン内の別のマシン、またはリモート・ドメインで 利用できます。 関連項目 第 4 章の 18 ページ 「ドメイン」 第 4 章の 18 ページ 「Domains ゲートウェイ」 BEA Tuxedo システム入門 4-17 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 第 4 章の 19 ページ 「ドメイン・ゲートウェイの種類」 第 4 章の 21 ページ 「BEA Tuxedo Domains のコンポーネント」 ドメイン ドメインは、1 つ以上のビジネス・アプリケーションを実行する 1 つの BEA Tuxedo アプリケーションで構成されます。1 つのドメイ ンは、1 つのコンフィギュレーション・ファイルで定義され、単一 のエンティティとして管理されます。 Domains ゲートウェイ Domains ゲートウェイ (GWTDOMAIN) は、BEA Tuxedo システムに よって提供されるサーバの 1 つで、リモート・ドメイン間のアク セスを可能にします。Domains ゲートウェイは、複数サーバ、単 一待ち行列 (MSSQ) のセットとして実行されます。このセットで は、各ゲートウェイが共通の要求待ち行列を使用し、それぞれ専 用の応答待ち行列を持っています。また、Domains には 2 つのゲー トウェイ管理サーバが用意されています。GWADM では、Domains ゲートウェイ・グループを実行時に管理できます。Domains の管 理サーバである DMADM では、Domains コンフィギュレーション情 報を実行時に管理できます。 Domains ゲートウェイでは、次の機能がサポートされています。 管理 − ほかの BEA Tuxedo サーバとまったく同じように、 ゲートウェイを起動したりシャットダウンすることができま す。実行時の管理は、管理サーバの DMADM によって行われま す。アプリケーション管理者は DMADM を使用して、ドメイン・ コンフィギュレーション・ファイルを変更したり、ゲートウェ イ・グループのパフォーマンスを調整できます。 ATMI 会話型モデル − アプリケーション・プログラムは、別の ドメインで動作しているプログラムと会話できます。リモー ト・ドメインは、ローカル・サーバによって提供される会話型 サービスを利用して、会話を行うことができます。 4-18 BEA Tuxedo システム入門 ドメイン・ゲートウェイの種類 ATMI 要求 / 応答型モデル − BEA Tuxedo システムを使用して いるアプリケーション・プログラムは、別のドメインで動作し ているアプリケーションに対してサービスを要求できます。ま た、リモート・アプリケーションは、ローカル・サーバに対し てサービスを要求できます。アプリケーション・プログラムに 変更を加える必要はありません。 マルチ・ドメイン間の対話 − ゲートウェイは、同じタイプの 複数のドメインと通信できます。 マルチ・ネットワークのサポート − ゲートウェイは、イーサ ネットや Novell など各種のネットワークを介して、ほかのド メインと通信できます。ただし、ゲートウェイは、そのリンク 先であるネットワーク・ライブラリの機能に制限を受けます。 つまり、1 つのゲートウェイでは、通常 1 種類のネットワーク がサポートされます。 トランザクション管理 − アプリケーション・プログラムは、 トランザクション内でほかのドメインと情報を交換できます。 ゲートウェイは、ドメイン間で行われるトランザクションのコ ミットまたはロールバックを調整します。 型付きバッファのサポート − ゲートウェイは、アプリケー ションで定義されるすべての型付きバッファに対して、符号化 や復号化の操作を実行できます。 ドメイン・ゲートウェイの種類 ドメイン間の通信は、ゲートウェイと呼ばれる一連のプロセスを 通じて管理されます。BEA Tuxedo システムでは、各種の通信プロ トコルに対応した次のドメイン・ゲートウェイが用意されていま す。 BEA Tuxedo (TDomains) − 複数の BEA Tuxedo アプリケー ション間の相互運用性を実現します。これは、TCP/IP などの ネットワーク転送プロトコル上を流れる特別に設計された TP プロトコルを介して行われます。 BEA Tuxedo システム入門 4-19 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 BEA eLink for Mainframe-OSI TP − BEA Tuxedo アプリケー ションと、OSI TP 標準を使用するほかのトランザクション処 理アプリケーションとの相互運用性を実現します。OSI TP は、 国際標準化機構 (ISO) によって定義された分散トランザク ション処理のためのプロトコルです。 BEA eLink for Mainframe-SN − BEA Tuxedo のクライアント およびサーバと、リモート SNA ドメイン内の MVS/CICS また は MVS/IMS 環境のクライアントおよびサーバとの相互運用 性を実現します。また、1 つのローカル BEA Tuxedo ドメイン から複数の SNA ネットワークに接続します。 BEA eLink for Mainframe-TCP/IP for MVS (for CICS) − BEA Tuxedo 領域内の非トランザクション・タスクと CICS アプリ ケーション・プログラム間で、一方が提供するサービスにもう 一方がアクセスできるようにするゲートウェイ接続機能です。 このゲートウェイによって、BEA Tuxedo ドメインが TCP/IP ネットワーク転送プロトコルを介して CICS 環境と通信でき るようになります。BEA Tuxedo ドメインとは、単一のコンフィ ギュレーション・ファイルに定義された BEA Tuxedo アプリ ケーションです。 BEA eLink for Mainframe-TCP/IP for MVS (for IMS) − IMS シス テム内のクライアント / サーバ・トランザクションと BEA Tuxedo ドメイン、CICS システム、またはほかの IMS システム との間に、透過的な通信を実現するゲートウェイ接続機能で す。 TOP END Domain Gateway (TEDG) − TOP END システムと BEA Tuxedo ドメインとの相互運用性を実現します。TEDG で は、TOP END と BEA Tuxedo システム間で、双方向で完全にト ランザクションに関与するメッセージのやり取りや待ち行列 処理がサポートされています。 4-20 BEA Tuxedo システム入門 BEA Tuxedo Domains のコンポーネント 図 4-9 ドメイン・ゲートウェイの種類 BEATuxedo Domains のコンポーネント BEA Tuxedo Domains には、次のコンポーネントが提供されていま す。 ドメイン・ゲートウェイ − リモート・ドメイン間のアクセス を可能にする BEA Tuxedo システム・プログラム。次の 4 つの ゲートウェイがあります。 TDomains は、複数の BEA Tuxedo アプリケーション間の相 互運用性を実現します。これは、TCP/IP などのネットワー ク転送プロトコル上を流れる特別に設計された TP プロト コルを介して行われます。 BEA eLink for Mainframe-OSI TP は、BEA Tuxedo アプリ ケーションと、OSI TP 標準を使用するほかのトランザク ション処理アプリケーションとの相互運用性を実現しま す。 BEA eLink for Mainframe-SNA は、BEA Tuxedo のクライアント およびサーバと、リモート SNA ドメイン内の MVS/CICS、 MVS/IMS、または AS/400 環境のクライアントおよびサーバと の相互運用性を実現します。また、1 つのローカル BEA Tuxedo SNADOM から複数の SNA ネットワークに接続します。 BEA Tuxedo システム入門 4-21 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 BEA TOP END Domain Gateway (TEDG) は、TOP END シス テムと BEA Tuxedo ドメインとの相互運用性を実現しま す。 ゲートウェイ管理サーバ (GWADM(5)) − 特定のドメイン・ ゲートウェイ・グループを実行時に管理する BEA Tuxedo プロ グラム。 ドメイン管理サーバ (DMADM(5)) − ドメイン・ゲートウェイ・ グループに必要なコンフィギュレーション情報を実行時に管 理する BEA Tuxedo プログラム。 管理インターフェイス − ドメイン・ゲートウェイがほかのド メインとの相互運用性のために必要とする情報のコンフィ ギュレーションと実行時管理を行うインターフェイス。 メッセージとサービス要求の格納 : BEA Tuxedo /Q BEA Tuxedo /Q 拡張機能を使用すると、クライアントとサーバが メッセージやサービス要求を格納して、確実な処理が行われるよ うにします。要求は、トランザクション・プロトコルを通して送 信され、安全に格納されることが保証されます。BEA Tuxedo /Q の 管理機能は、待ち行列の作成と管理、および待ち行列機能を備え たシステム・サーバのコンフィギュレーションに柔軟性をもたら します。 4-22 BEA Tuxedo システム入門 メッセージとサービス要求の格納 : BEA Tuxedo /Q メッセージ待ち行列サーバ メッセージ待ち行列サーバ (TMQUEUE) によって、メッセージの待 ち行列への登録や取り出しを透過的に行うことができます。次の 図は、TMQUEUE の処理を示しています。 図 4-10 TMQUEUE を使用したメッセージの待ち行列処理 BEA Tuxedo システム入門 4-23 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 qmadmin(1) を使用して、1 つの待ち行列 (Queue1) を持つ QUEUE SPACE (1 つの待ち行列マネージャによって管理される待ち行列の セット ) が作成されています。次のフローチャートは、メッセー ジがどのように待ち行列に登録され、取り出されるかを示してい ます。 図 4-11 待ち行列へのメッセージの登録と取り出しのプロセス 4-24 BEA Tuxedo システム入門 メッセージとサービス要求の格納 : BEA Tuxedo /Q メッセージの格納と転送 転送サーバ (TMQFORWARD) は、待ち行列からメッセージを取り出 し、それらの処理を行うサーバに転送します。そのため、待ち行 列に登録されたメッセージを透過的に処理することができます。 つまり、BEA Tuxedo システム・サーバでは、着信したメッセージ が通常の要求 / 応答メッセージとして送られたものか、安定待ち行 列を通して送られたものかを意識しません。サーバによる応答は、 各メッセージに対応付けられた応答待ち行列に自動的に登録され ます。次の図は、TMQFORWARD サーバの処理を示しています。 図 4-12 TMQFORWARD を使用したメッセージの格納と転送 BEA Tuxedo システム入門 4-25 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 qmadmin(1) を使用して、Queue 1、Queue2、Queue3、および REPLYQ という 4 つの待ち行列を持つ QUEUE SPACE が作成されています。 次のフローチャートは、メッセージがどのように格納され、転送 されるかを示しています。 図 4-13 メッセージの格納と転送のプロセス 4-26 BEA Tuxedo システム入門 メッセージとサービス要求の格納 : BEA Tuxedo /Q TMQFORWARD(5) サーバは、待ち行列に入れられたメッセージが サービス呼び出しを必要とする場合にのみ必要です。たとえば、あ るプロセスがメッセージを待ち行列に登録し、別のプロセスがそ れを削除するプロセス間通信で、BEA Tuxedo のクライアントまた は サ ー バ 上 で 待 ち 行 列 が 使 用 さ れ る 場 合 が あ り ま す。 tpdequeue(3c) の呼び出しと応答待ち行列の使用は任意です。 BEA Tuxedo /Q の機能 /Q を使用すると、グローバル・トランザクション内で、アプ リケーションがメッセージを安定記憶域の待ち行列に登録し て、後で処理することができます。 /Q は、BEA Tuxedo アプリケーションの管理者に、待ち行列上 のメッセージを処理するための関数を提供します。ATMI イン ターフェイスには、クライアントとサーバが特定の待ち行列に メッセージを格納するための関数 tpenqueue(3c) と、クライ アントとサーバが特定の待ち行列からメッセージを取得する ための関数 tpdequeue(3c) が含まれています。qmadmin(1) コ マンドは、待ち行列および待ち行列に登録されたメッセージの 管理と制御を行います。 要求は、LIFO、FIFO、または時刻に基づいて待ち行列から取 り出すことができます。LIFO および FIFO の範囲内では、優 先順位に従って要求を取り出すことができます。 待ち行列空間とは、分散環境でデータの整合性を保証する X/Open の XA インターフェイスに準拠したリソース・マネー ジャです。 /Q を使用すると、広域ネットワークなど、マシン、サーバ、リ ソースが利用できない場合、または信頼できない場合がある環 境で BEA Tuxedo システムを使用した場合に、メッセージの処 理に必要なリソースが利用できるようになるまでメッセージ を格納して、継続的な処理を行うことができます。 時間がかかるトランザクションのバッチ処理では、メッセージ が最終的に処理されることが保証されるため、トランザクショ ンの完了を待つ必要はありません。 BEA Tuxedo システム入門 4-27 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 プロセスで次の手順を行うために各手順で待ち行列要求を生 成するワーク・フローに /Q を使用できます。データ依存型ルー ティングや優先順位処理などのメカニズムは、待ち行列ベース の要求および応答に対して、そのままの状態で保持されます。 /Q を BEA Tuxedo Workstation と組み合わせると、待ち行列への メッセージの登録や取り出しをワークステーション・クライア ントから行うことができます。この組み合わせのインターフェ イスには、C および COBOL プログラミング言語のものが用意 されています。 ワークステーション・コネクティビティ : BEA Tuxedo Workstation BEA Tuxedo システムの Workstation コンポーネントを使用すると、 アプリケーション・クライアントを BEA Tuxedo ドメインに含ま れないリモート・サイトに置くことができます。このようなリモー ト・サイトでは、管理サーバ、アプリケーション・サーバ、また は掲示板はサポートされていません。クライアントとアプリケー ション間の通信はすべてネットワークを介して行われます。次の 図は、ワークステーション環境を示しています。 図 4-14 Workstation を使用したクライアントの接続 4-28 BEA Tuxedo システム入門 Workstation コンポーネント ワークステーションは、実行時に BEA Tuxedo システムの利点を デスクトップに拡張し、BEA Tuxedo アプリケーションのプログラ ミングと管理をデスクトップから行うことができるようにしま す。実行時の利点としては、より動的な接続性、管理オーバヘッ ドの低減、クライアントをサーバ・システムから離すことによる セキュリティの向上、CPU サイクルとプロセス・コンテキスト・ スイッチの低減によるサーバ使用率の向上、ディスク容量の縮小 などがあります。 関連項目 第 4 章の 29 ページ 「Workstation コンポーネント」 Workstation コンポーネント BEA Tuxedo Workstation には、次のコンポーネントがあります。 ワークステーション・クライアント − クライアントは、BEA Tuxedo Workstation を使用して BEA Tuxedo システムに接続し ます。BEA Tuxedo システムでは、Windows、Windows NT、UNIX、 および VMS のプラットフォーム上の複数のワークステーショ ン・ク ラ イ ア ン ト の 同 時 実 行 が サ ポ ー ト さ れ て い ま す。 Workstation に よっ てサ ポー トさ れて いる クラ イア ント は、 ATMI を使用できます。 ワークステーション・ハンドラ (WSH) − WSH は、ワークス テーション・クライアントとネイティブ BEA Tuxedo サーバ間 の 1 つ以上の接続を管理し、代理サービス要求を行い、トラン ザクションを管理し、応答を返します。WSH プロセスの開始 および停止は、WSL によって行われます。 ワークステーション・リスナ (WSL) − WSL は、ワークステー ション・クライアントからの接続要求を受け付け、ワークス テーション・ハンドラに接続を割り当てます。また、ロード要 求に応じてワークステーション・ハンドラのプロセスの開始と 停止を行い、これらのプロセスのプールを管理します。 BEA Tuxedo システム入門 4-29 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 図 4-15 Workstation コンポーネント WebLogic Enterprise を使用したクライアント / サーバ・ アーキテクチャの開発 WebLogic Enterprise (WLE) は、ミッション・クリティカルなアプ リケーションに依存する企業や組織に、BEA Tuxedo システムの強 力さ、堅牢さ、定評のある信頼性と共に、Common Object Request Broker Architecture (CORBA) に準拠した Enterprise Java Beans (EJB) プログラミング・モデルの利点をもたらします。WLE の運用イン フラストラクチャは、BEA Tuxedo システムに基づいて、管理され た環境にトランザクションに関与する安全な分散アプリケーショ ンを配置します。従来の手続き型の OLTP 関数は、BEA Tuxedo ATMI を基盤とする WLE ATMI によって提供されます。 4-30 BEA Tuxedo システム入門 WebLogic Enterprise を使用したクライアント / サーバ・アーキテクチャの開発 図 4-16 WebLogic Enterprise BEA WebLogic Enterprise を使用すると、ローカルまたは各地に散 在する何千ものコンピュータに分散できる電子商取引アプリケー ションを高い信頼性で開発できます。BEA WebLogic Enterprise は 標準に準拠した製品であり、スケーラビリティ、信頼性、拡張性 を実現します。CORBA、Java、C++、C、COBOL、Java 2 Enterprise Edition (J2EE)、Enterprise Java Beans (EJB) など、開発モデルとプロ グラミング言語の幅広い柔軟性を単一のパッケージで提供しま す。また、WLE を使用すると、何百万というオンライン電子商取 引の顧客を高い信頼性でサポートするサーバを介して、アプリ ケーションを運用できます。CORBA オブジェクト、BEA Tuxedo サービス、EJB コンポーネントなどを同じアプリケーション上に 混在させることも可能です。さらに、BEA WebLogic Enterprise は、 Web からメインフレームまでのエンド・ツー・エンドの統合のた めのプラットフォームを提供します。そのため、スタンドアロン の Web サイトに代わる電子ビジネスの IT インフラストラクチャ を強化することによって、より競争力のある製品とサービスを提 供できます。 BEA Tuxedo システム入門 4-31 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 信頼性の高い BEA Tuxedo エンジンの上に構築されているため、 BEA WebLogic Enterprise には、安全な電子商取引のソリューショ ンを迅速に配布するために必要なあらゆる機能が用意されていま す。 図 4-17 WebLogic Server と WebLogic Enterprise Java ベースの分散アプリケーションの開発と管理 : BEA WebLogic Server BEA WebLogic Server は、大規模な分散型の Web アプリケーショ ン、ネットワーク・アプリケーション、およびデータベース・ア プリケーションの開発、統合、運用、および管理を行うための Java アプリケーション・サーバです。BEA WebLogic Server を使用する と、移植可能でスケーラブルなアプリケーションを構築し、ほか のアプリケーションやシステムとシームレスに相互運用すること ができます。 BEA WebLogic Server の最大の利点は、ソフトウェア開発サイクルに もたらす効果にあります。低レベルのネットワーク・サービス ( ソ ケットなど ) は、より高レベルの BEA WebLogic Server の機能 (RichSockets™ および接続プールの仕様など) によって自動的に分離 されて処理されます。WebLogic Beans や WebLogic/JDBC などの高レ ベルのコンポーネントによって、WebLogic 環境用に拡張された JavaBeans および JDBC の開発サービスが提供されます。 4-32 BEA Tuxedo システム入門 Java ベースの分散アプリケーションの開発と管理 : BEA WebLogic Server 図 4-18 BEA WebLogic Server WebLogic Server のインプリメンテーション BEA WebLogic Server には、次のインプリメンテーションが提供さ れています。 BEA WebLogic Server は、分散アプリケーション・スイートの 核であり、分散コンピューティング・フレームワークで、広範 囲にわたるソフトウェアおよびハードウェアのサービスを管 理できます。 BEA Tuxedo システム入門 4-33 第4章 BEA Tuxedo 製品ファミリとエンタープライズ・システムの統合 BEA WebLogic Server/JDBC には、Type 3 の JDBC がインプリ メントされているため、Java アプレットまたはアプリケーショ ンと 使用 でき ます。BEA WebLogic Server/JDBC に は、BEA WebLogic アプリケーション・サーバで利用可能な Enterprise Java 標準サービスのサブセットが提供されています。これらの サービスには、セキュリティ、サーバ側プログラミングの HTTP サーブレット・サポート、ネーム・サービス、アクセス 制御リストなどがあります。BEA WebLogic Server/JDBC には、 業界 をリー ドす る WebLogic 2 層 型 JDBC ド ライ バと して、 Oracle、Sybase、MS SQL Server のいずれかに対応したドライバ が提供されています。 BEA WebLogic Server JDBC ドライバは、業界で最も広く使用 されている JDBC ドライバです。このドライバには、Oracle、 Sybase、および MS SQL Server データベース用の Type 2 (2 層 ) JDBC インプリメンテーションと、Microsoft SQL Server および Informix 用の Type 4 インプリメンテーションが含まれていま す。 BEA WebLogic Server の利点 Enterprise Java 標準が包括的にサポートされているため、投資 が保護されます。また、ほかのアプリケーションやシステムと シームレスに相互運用できる移植可能でスケーラブルなアプ リケーションを構築できます。 Enterprise JAVA API の大部分 (12 個のうちの 10 個 ) が完全 にインプリメントされています。 セッション Bean および エンティティ Bean を含め、 Enterprise JavaBeans 1.0 仕様の最も包括的なインプリメン テーションが提供されています。 BEA のエンド・ツー・エンドのエンタープライズ・ミドルウェ ア・ソリューションに、クリティカルなフロント・エンドの Web コンポーネントが提供されています。 4-34 BEA Tuxedo システム入門