NonStop™ DOM/MPユーザーズ・ガイド

NonStop™ DOM/MP
ユーザーズ・ガイド
概要
NonStop DOM (NonStop Distributed Object Manager/MP) は、Tandem プラット
フォーム上での分散オブジェクトコンピューティングのインフラストラクチャを
提供します。このインフラストラクチャによって、オブジェクト指向技術を使用
した分散アプリケーションおよびシステムソフトウェアの実装を実現できます。
NonStop DOM は CORBA 2.1 準拠システムであり、開発者はこれを使用して
Tandem OSS (Open Systems Services) システム上で実行するクライアント、サー
バ、およびオブジェクトを作成することができます。
NonStop DOM マニュアルセットは、『入門ガイド』、『管理者ガイド』、『プログラ
マーズ・ガイド』、『NonStop™ JTS/OTS ユーザーズ・ガイド』の 4 マニュアルで
構成されています。これらのマニュアルでは、NonStop DOM のインストール、
NonStop DOM システムの構成・管理、NonStop DOM 環境でのプログラミングと
いったトピックをカバーしています。
製品バージョン
NonStop™ DOM/MP、バージョン 2.0
リリース ID
Independent Product
マニュアル番号
140418J
発行日
2000 年 2 月
コンパックコンピュータ株式会社
140418J
本書のプログラムを含むすべての内容は、著作権法上の保護を受けており
ます。著者、発行者の許諾を得ず、無断で複写、複製をすることは禁じら
れております。
COMPAQ および Compaq 製品名は、米国コンパック・コンピュータコー
ポレーションの商標または登録商標です。
その他の社名および製品名は、それぞれの各社の商標または登録商標です。
原 典
Document History
Edition
Part Number Product Version Earliest Supported Release Published
First
Second
136051
141431
NSJ1.0
NSJ1.5
November 1997
June 1998
New editions incorporate any updates issued since the previous edition.
A plus sign(+) after a release ID indicates that this manual describes function added to the
base release, either by an interim product modification(IPM) or by a new product version on
a .99 site update tape(SUT).
Copyright
Copyright© 1993 by Tandem Computers Incorporated. Printed in the U.S.A. All rights
reserved. No part of this document may be reproduced in any form, including photocopying
or translation to another language, without the prior written consent of Tandem Computers
incorporated.
Ordering Information
For manual ordering information: domestic U.S. customers, call 1-800-243-6886;
international customers, contact your local sales representative.
Document Disclaimer
Information contained in a manual is subject to change without notice. Please check with
your authorized Tandem representative to make sure you have the most recent information.
Export Statement
Export of the information contained in this manual may require authorization from the U.S
Department of Commerce.
Examples
Examples and sample programs are for illustration only and may not be suited for your
particular purpose. Tandem does not warrant, guarantee, or make any representations
regarding the use or the results of the use of any examples or sample program in any
documentation. You should verify the applicability of any example or sample program
before placing the software into productive use.
U. S.Government Customers FOR U.S. GOVERNMENT CUSTOMERS REGARDING THIS DOCUMENTATION AND
THE ASSOCIATED SOFTWARE;
These notices shall be marked on any reproduction of this data, in whole or in part.
NOTICE: Notwithstanding any other lease or license that may pertain to, or accompany the
delivery of, this computer software, the rights of the Government regarding its use,
reproduction and disclosure are as set forth in Section 52.227-19 of the FARS Computer
Software-Restricted Rights clause.
RESTRICTED RIGHTS NOTICE: Use, duplication or disclosure by the Government is
subject to the restrictions as set forth in subparagraph(c)(1)(ii) of the Rights in Technical
Data and Computer Software clause at DFARS 52.227-7013.
RESTRICTED RIGHTS LEGEND: Use, duplication or disclosure by the Government is
subject to the restrictions as set forth in paragraph(b)(3)(B) of the Rights in Technical Data
and Computer Software clause at DAR 7-104.9(a). This computer software is submitted
with “restricted rights.” Use, duplication or disclosure is subject to the restrictions as set
forth in NASA FAR SUP 18-52 227-79(April 1985) “Commercial Computer Software Restricted Rights (April 1985).” If the contract contains the Clause at 18-52 227-74 “Rights
in Data General” then the “Alternate III” clause applies.
U. S Government Users Restricted Rights—Use, duplications or disclosure restricted by
GSA ADP Schedule Contract.
Unpublished—All rights reserved under the Copyright Laws of the United States.
140418J
著作権
Copyright © 1998, Tandem Computers Incorporated. 本書の内容は予告なく変更することがあります。最
新情報については、認可されている Compaq 販売店にお問い合わせください。
OSF は、本資料に関して、その市場商品力および特定目的への適合性の黙示的な保証を含む一切の保証
はいたしません。
OSF は本書中の誤り、ならびに本書に従って設置、稼動、使用した結果生じる損害に対して一切責任を
負いません。
Copyright © 1990, 1991, 1992, 1993 Open Software Foundation, Inc.
本書および関連ソフトウェアの一部は、以下の提供元からの資料に基づきます。
Copyright © 1987, 1988, 1989 Carnegie-Mellon University .Copyright © 1989, 1990, 1991 Digital Equipment
Corporation .Copyright © 1985, 1988, 1989, 1990 Encore Computer Corporation .Copyright © 1988 Free
Software Foundation, Inc .Copyright © 1987, 1988, 1989, 1990, 1991 Hewlett-Packard Company .Copyright ©
1985, 1987, 1988, 1989, 1990, 1991, 1992 International Business Machines Corporation .Copyright © 1988, 1989
Massachusettsb Institute of Technology .Copyright © 1988, 1989, 1990 Mentat Inc .Copyright © 1988 Microsoft
Corporation .Copyright © 1987, 1988, 1989, 1990, 1991, 1992 SecureWare, Inc .Copyright © 1990, 1991
Siemens Nixdorf Informationssysteme AG .Copyright © 1986, 1989, 1996, 1997 Sun Microsystems,
Inc.Copyright © 1989, 1990, 1991 Transarc Corporation.
本ソフトウェアおよびマニュアルの一部は、Regents of the University of California からのライセンスに
基づいて、Berkeley Software Distribution 第 4 版をベースにしています。弊社では、以下の方々ならびに機
関が開発に果たした役割に対して、謝辞を申し上げます。
Kenneth C.R.C. Arnold、Gregory S. Couch、Conrad C. Huang、Ed James、Symmetric Computer Systems、
Robert Elz Copyright © 1980, 1981, 1982, 1983, 1985, 1986, 1987, 1988, 1989 Regents of the University of
California.
All Rights Reserved. Printed in the U.S.A.
本書のいかなる部分も、Compaq Computer Corporation からの書面による事前承諾を得ていないかぎり、
複写、翻訳などいかなる形態であっても無断で複製することは禁じられています。
使用許諾契約
ここに記載されている本マニュアルおよびソフトウェアは、使用許諾書に従って提供されるものです。
したがって、その使用および複製については、上述の著作権に関する注意書きとともに許諾条項に従いま
す。マニュアルおよびソフトウェアの所有権は、OSF またはその許諾者に帰属します。
140418J
第1部
NonStop™ DOM
入門ガイド
概要
このガイドでは、NonStop™ Distributed Object Manager/MP (NonStop™ DOM)
の概要を紹介します。また、マニュアルセットの概説、NonStop™ DOM を最
初に使用する際のそのインストール方法と設定方法も説明します。このガイ
ドの終りの方では、本製品に含まれるサンプルプログラムの 1 つを実行する方
法を紹介します。
製品バージョン
NonStop™ DOM/MP、バージョン 2.0
リリース ID
Independent Product
マニュアル番号
140418J
発行日
2000 年 2 月
Document History
Edition
Part Number Product Version Earliest Supported Release Published
First
Second
Third
Fourth
127557
131054
138003
134268
D40
D41
D41
D42
November 1996
January 1997
October 1997
November 1997
New editions incorporate any updates issued since the previous edition.
A plus sign(+) after a release ID indicates that this manual describes function added to the
base release, either by an interim product modification(IPM) or by a new product version on
a .99 site update tape(SUT).
140418J
-1
目 次 目 次
第1章
はじめに
1.1 NonStop DOM のマニュアルセットについて....................................................................... 1-1
1.1.1 マニュアルセットの概要 ............................................................................................. 1-1
1.1.2 関連マニュアル ............................................................................................................ 1-2
1.1.3 表記規約........................................................................................................................ 1-5
1.2 分散オブジェクトコンピューティングと CORBA の概要 .................................................. 1-7
1.2.1 分散オブジェクトコンピューティング ...................................................................... 1-7
1.2.2 CORBA 定義の標準インタフェースとサービス ..................................................... 1-11
第2章
NonStop DOM の概要
2.1 NonStop DOM について ....................................................................................................... 1-13
2.1.1 NonStop DOM の利点 ................................................................................................ 1-13
2.1.2 他製品にはない NonStop DOM の優れた機能 ......................................................... 1-14
2.1.3 主な特徴と機能性 ...................................................................................................... 1-17
2.2 NonStop DOM のシステム要件 ........................................................................................... 1-19
2.2.1 システムのハードウェア要件 ................................................................................... 1-19
2.2.2 システムのソフトウェア要件 ................................................................................... 1-19
第3章
NonStop DOM のインストールと実行
3.1 NonStop DOM のインストール ........................................................................................... 1-21
3.1.1 NonStop DOM pax ファイル ..................................................................................... 1-21
3.1.2 インストール先 .......................................................................................................... 1-24
3.1.3 NonStop DOM をデフォルトのファイル場所にインストールする ....................... 1-25
3.1.4 ユーザ設定のインストール先を指定する ................................................................ 1-26
3.1.5 インストール用サブディレクトリ ............................................................................ 1-26
3.2 クイック構成 ......................................................................................................................... 1-28
3.2.1 env.sh ファイルのカスタマイズ................................................................................ 1-28
3.2.2 env.sh ファイルのソース化 ....................................................................................... 1-31
3.2.3 NonStop DOM EMS テンプレートの設定 ................................................................ 1-31
i
140418J
目 次
3.2.4 初期化スクリプトのカスタマイズ ............................................................................1-32
3.2.5 NonStop DOM システムの構成 .................................................................................1-33
3.2.6 NonStop DOM PATHMON プロセスのカスタマイズ .............................................1-34
3.3 NonStop DOM の開始と停止 ................................................................................................1-35
3.3.1 NonStop DOM システムの開始 .................................................................................1-35
3.3.2 NonStop DOM システムの停止 .................................................................................1-36
第4章
サンプルプログラムの実行
4.1 スタック例の実行 ..................................................................................................................1-37
4.1.1 スタック例の概要 .......................................................................................................1-37
4.1.2 スタック例の構築 .......................................................................................................1-37
4.1.3 スタック例の実行 .......................................................................................................1-38
図
図 1-1
分散オブジェクトコンピューティング ...........................................................................1-8
図 1-2
Common Object Request Broker Architecture (CORBA) ..............................................1-12
表 1-1
Tandem 関連マニュアルと情報 ........................................................................................1-3
表 1-2
OMG ドキュメント ...........................................................................................................1-4
表 1-3
NonStop DOM 2.0 に必要な支援ソフトウェア.............................................................1-20
表 1-4
NonStop DOM pax ファイル .........................................................................................1-22
表 1-5
NonStop DOM のデフォルトのファイル場所 ...............................................................1-25
表 1-6
NonStop DOM サブディレクトリ ..................................................................................1-27
表 1-7
環境変数の設定 ...............................................................................................................1-29
表 1-8
NonStop DOM STDOUT、STDERR、および トレースファイル ...............................1-36
表
140418J
ii
第 1 章 はじめに
第 1 章 はじめに
1.1 NonStop DOM のマニュアルセットについて
サブトピックス
□ マニュアルセットの概要
□ 関連マニュアル
□ 表記規約
1.1.1 マニュアルセットの概要
NonStop Distributed Object Manager/MP (NonStop DOM) のマニュアルは、次のようなドキュメントの
セットで構成されています。
□ 第 1 部 NonStop™ DOM 入門ガイド
□ 第 2 部 NonStop™ DOM 管理者ガイド
□ 第 3 部 NonStop™ DOM プログラマーズ・ガイド
□ 第 4 部 NonStop™ JTS/OTS ユーザーズ・ガイド
□ 用語解説
□ 索引
これらのドキュメントはそれぞれが特定の分野をカバーする一方で、全ドキュメントが連結しており、
必要な資料に簡単にアクセスすることができます。各ドキュメントの概要を次に示します。各ドキュメン
トのトピックをご覧になりたい場合は、ドキュメントの目次ページを参照してください。
第 1 部 NonStop™ DOM 入門ガイド
『第 1 部 NonStop™ DOM 入門ガイド』は、NonStop DOM を起動して実行するために必要な情報を提供
します。このガイドの最初は、分散型オブジェクトコンピューティングの簡単な紹介説明と、NonStop DOM
の概念図への適合方法の説明になります。その後、NonStop DOM のインストール手順、クイック設定に必
要な手順、サンプルプログラムの 1 つを実行する手順の説明が続きます。
第 2 部 NonStop™ DOM 管理者ガイド
『第 2 部 NonStop™ DOM 管理者ガイド』は、ご利用の NonStop DOM システムを設定し実行するための
支援として使用します。このガイドでは、NonStop DOM が使用するコンフィギュレーションファイルの詳
細と、Configuration Tool の使用方法を説明します。また、NonStop DOM システムで実行する NonStop TS/
MP プロセスのカスタマイズ方法など、NonStop DOM システムを最適化する方法についても説明します。
140418J
1-1
第 1 章 はじめに
第 3 部 NonStop™ DOM プログラマーズ・ガイド
『第 3 部 NonStop™ DOM プログラマーズ・ガイド』では、NonStop DOM を使用した分散オブジェクト
このマニュアルは、NonStop
によるクライアント / サーバアプリケーションの開発方法について説明します。
DOM の新規および見込みユーザのすべてを対象に、NonStop DOM アプリケーションおよびコンポーネン
トオブジェクトの設計、開発、管理について解説します。
NonStop DOM を使用して、Tandem システムを含む複数の異機種ネットワークで分散オブジェクト指向
アプリケーションとコンポーネントを開発することができます。NonStop DOM で作成したアプリケー
シ ョン コン ポー ネン トは、Object Management Group ® (OMG ™) の Common Object Request Broker
Architecture (CORBA® ) 標準に準拠します。
第 4 部 NonStop™ JTS/OTS ユーザーズ・ガイド
NonStop™ JTS (Java Transaction Service) および NonStop™ OTS (Object Transaction Service) は、既存の
NonStop™ JORB/MP および NonStop™ DOM/MP システムのインストールにアドオンする CORBA® サー
ビスです。このガイドでは、Tandem NonStop™ Kernel システム上での、JTS と OTS のインストールと構
成、および JTS と OTS を使ったプログラミングについて解説します。
用語解説
NonStop DOM のマニュアルセット全体を通して使用されている用語を定義したものです。
『用語解説』
は、
索引
『索引』を使用すると、NonStop DOM マニュアルセットのトピックとサブトピックスをすばやく検索す
ることができます。
1.1.2 関連マニュアル
□ 関連マニュアル
□ 関連 Tandem マニュアル
□ OMG™ (Object Management Group) 情報
関連マニュアル
以下は、NonStop DOM、CORBA®、および分散オブジェクトプログラミング関連の参考文献のリストです。
□ Mowbray, Thomas、William Ruh 著 『Inside CORBA. Massachusetts』(Addison-Wesley、1997 年 )
□ Orfali, Robert、Dan Harkey 著 『Client/Server Programming with JAVA and CORBA』(New York: John
Wiley & Sons、1997 年 )
□ Orfali, Robert、Dan Harkey、Jeri Edwards 著 『The Essential Distributed Objects Survival Guide』(New
York: John Wiley & Sons、1996 年 )
□ Orfali, Robert、Dan Harkey、Jeri Edwards 著『Instant CORBA』(New York: John Wiley & Sons、1997 年 )
□ Otte, Randy; Paul Patrick、Mark Roy 著 『Understanding CORBA』(New Jersey: Prentice Hall、1996 年 )
1-2
140418J
第 1 章 はじめに
□ Ousterhout, John K 著 『Tcl and the Tk Toolkit』(Massachusetts: Addison-Wesley、1994 年 )
□ Pope, Alan 著 『The CORBA Reference Guide』(Massachusetts: Addison-Wesley、1998 年 )
□ Rosenberger, Jeremy 著 『Teach yourself CORBA in 14 Days』(Indiana: Sams Publishing、1998 年 )
□ Siegel, Jon 著 『CORBA Fundamentals and Programming』(New York: John Wiley & Sons、1996 年 )
関連 Tandem マニュアル
表 1-1 に、NonStop DOM アプリケーションの設計と NonStop DOM システムの管理に必要とされる知識
の取得に役立つ、マニュアル、コース、およびその他の資料をリストします。これらの資料のほかに、ラ
イブラリまたはフレームワークのための CORBA 準拠の情報およびインタフェースの定義などの情報を得
るために、サードバーティベンダ提供の資料を参考にすることもできるでしょう。
「Dx Manuals」CD-ROM に提供されています。また、「Tandem
ほとんどの Tandem マニュアルは、
Information Manager (TIM)」ビューアからもこれらのマニュアルをご利用になれます。TIM を使用すると、
どの CD-ROM にあるマニュアルであっても、まるでそれらが同一の場所にあるかのように検索することが
できます。NonStop DOM マニュアルのような個別の Tandem ソフトウェア製品のマニュアルは、製品固有
の CD-ROM で提供されています。
表 1-1 Tandem 関連マニュアルと情報
マニュアル名
140418J
備 考
NonStop TS/MP Pathsend and
Server Programming Manual、
NonStop TS/MP Management
Programming Manual、
NonStop TS/MP and Pathway
System Management Guide、
NonStop TS/MP System
Management Manual
NonStop TS/MP サーバプール、PATHCOM インタフェース
NonStop DCE Application
Programming Guide
DCE スレッド
TACL Reference Manual
TACL コマンドのリファレンス
Introduction to NonStop SQL/MP
Tandem データベース製品
OSS Programmer’s Guide、
Open System Services User’s
Guide、
Open System Services Shell &
Utilities Reference Manual
Open System Services のシェルとユーティリティ、ライブラリとシ
ステムコール
1-3
第 1 章 はじめに
マニュアル名
備 考
SCF Reference Manual for
G-Series Releases、
SCF Reference Manual for
TCP/IP、
SCF Reference Manual for
TLAM、
SCF Reference Manual for QIO、
SCF Reference Manual for
X25AM
Subsystem Control Facility (SCF) の構成
TLAM Configuration and
Management Manual
TLAM (QIO) の管理
X25AM Configuration and
Management Manual
X25AM の管理
NonStop TM/MP Operations and
Recovery Guide、
NonStop TM/MP Reference
Manual
NonStop TM/MP データベース、TMFCOM の管理
Event Management Service
(EMS)
Analyzer User’s Guide and
Reference Manual
EMS 構成と管理
TCP/IP Configuration and
Management Manual
TCP/IP の構成と管理
DNS ブートとドメインデータファイルの構成
Shared Runtime Library (SRL)
Reference Manual
SRL リファレンス
OMG (Object Management Group) 情報
OMG の Web サイトから、CORBA および OMG 準拠に関する豊富な情報が得られます。発行済みの
OMG 仕様とドキュメントは、OMG Public Document Listings に提供されています。
次の表は、関連の OMG 刊行物のうちの一部をリストしたものです。
表 1-2 OMG ドキュメント
ドキュメント名
OMG ドキュメント番号
入手可能なドキュメント
1-4
CORBA 2.0 specification
ptc/96-03-04
CORBA IDL Interfaces
1995/95-12-15
CORBAservices IDL Interfaces
tc/96-02-01
Java Language Mapping RFP
orbos/96-08-01
140418J
第 1 章 はじめに
ドキュメント名
OMG ドキュメント番号
Common Facilities Architecture draft 4.0
1995/95-01-02
Universal Networked Objects (UNO)
UNO Submission、Revised Compliance
セクション
1994/94-12-02
OMG メンバーのドキュメント
ORB Portability Specification
97-05-15
Common Object Services Specification、
Volume 1
95-3-31
ORB Initialization
94-10-24
C++ Language Mapping
94-9-14
Interface Repository
94-11-7、95-1-7
Object Services Architecture、Revision 8.1
95-1-47
1.1.3 表記規約
このマニュアルで使用する構文表記規約の要約を以下に説明します。
大文字表記
大文字の表記は、キーワードと予約語を表します。これらのアイテムは、表示どおり正確に入力してく
ださい。アイテムを括弧でくくる必要はありません。例 :
MAXATTACH
< > 角括弧
角括弧 < > は、入力する変数アイテムを表します。アイテムは括弧でくくる必要はありません。次の例
の、<UserDir> は変数のディレクトリ名です。
/projectX は表示どおり正確に入力してください。
<UserDir>/projectX
[ ] 角括弧
括弧 [ ] はオプションの構文アイテムを囲みます。例 :
TERM [\system-name.]$terminal-name
INT[ERRUPTS]
括弧にくくられたアイテムのグループは選択肢のリストであり、その中から 1 つを選択するか、または
何も選択しません。リストされるアイテムは、縦に並べることも横に並べることもできます。縦に並べる
場合は、複数の括弧でくくり、それらの括弧が縦に一列になるようにそろえます。横に並べる場合は、1 つ
の括弧でくくり、中を縦線で区切ります。例 :
140418J
1-5
第 1 章 はじめに
LIGHTS [ ON
]
[ OFF
]
[ SMOOTH [ num ] ]
K [ X | D ] address-1
{ } 中括弧
中括弧 { } は、その中から 1 アイテムを選択する必要のある、アイテムのリストをグループ化します。
リストされるアイテムは、縦に並べることも横に並べることもできます。縦に並べる場合は、複数の括弧
でくくり、それらの括弧が縦に一列になるようにそろえます。横に並べる場合は、1 つの括弧でくくり、中
を縦線で区切ります。例 :
LISTOPENS PROCESS { $appl-mgr-name }
{ $process-name }
ALLOWSU { ON | OFF }
| 縦線
縦線は、括弧または中括弧で囲まれ列挙されたリスト内の各選択肢を区切ります。例 :
INSPECT { OFF | ON | SAVEABEND }
... 省略記号
省略記号 ... は括弧または中括弧の直後に付けられて、括弧でくくられた構文アイテムのシーケンスを何
度でも反復できることを示します。例 :
M address-1 [ , new-value ]...
[ - ] {0|1|2|3|4|5|6|7|8|9}...
省略記号が単一の構文アイテムの直後に付いている場合は、その構文アイテムを何度でも反復できるこ
とを示します。例 :
"s-char..."
" " 引用符
定義されている構文記号 ( たとえば、括弧や中括弧など ) が引用符 " " で囲まれている場合、表示どおり
に入力しなければならない実際の文字を表します。例 :
"[" repetition-constant-list "]"
その他の句読点
コマンド構文が 1 行に収まらないほど長い場合、次に続く行はそれぞれ 3 スペース分インデントします。
最初のスペースで、ブランク行による前の行と区別します。スペースを入れることによって次行のアイテ
ムと、縦の選択肢リストのアイテムとを区別することができます。例 :
ALTER [ / OUT file-spec / ] CONTROLLER
[ , attribute-spec ]...
長いコマンド
上記以外の句読点記号 ( 括弧 ()、カンマ、セミコロンなど ) は表示どおりに入力してください。例 :
error := NEXTFILENAME (<file-name>) ;
LISTOPENS SU $<process-name>.#<su-name>
1-6
140418J
第 1 章 はじめに
1.2 分散オブジェクトコンピューティングと CORBA の概要
サブトピックス
□ 分散オブジェクトコンピューティング
□ CORBA 定義の標準インタフェースとサービス
1.2.1 分散オブジェクトコンピューティング
分散オブジェクトコンピューティングとは、アプリケーションのコンピューティング体系のことであり、
アプリケーションはプロセス間およびネットワーク間に分散しているオブジェクトベースのコンポーネン
トで構成されます。分散オブジェクト環境においては、オブジェクトはメッセージベースのインタフェー
スを使用して通信します。
分散オブジェクトコンピューティングは、クライアント / サーバシステムを実装する方法として急速に
普及しつつあります。クライアント / サーバ型コンピュータアプリケーションは、一言でいうと、相互接
続するシステムのセットとして定義できます。クライアント / サーバシステムでは、オブジェクトのリク
エストを生成するプロセスをクライアント、オブジェクトが実行されるシステムをサーバと呼びます。こ
のシステムにおいては、サーバは、クライアントが生成したリクエストを処理し、そして通常はクライア
ントに結果を戻します。
一般的に、クライアントはユーザと対話するプログラム ( たとえば、データベースのクエリを実行する
入力システムなど )、サーバはクライアントプログラムが生成したリクエストを処理するプログラムと考え
られています。ただし、クライアントとサーバという用語は相対的に使われており、同一プロセスがリク
エストを生成し、かつ、それを受け取るという両方の動作を実行することもできます。図 1-1 にはいくつ
かのクライアントアプリケーションの例が示されています。これらのクライアントアプリケーションは、
ワークステーションで実行し、トランザクションリクエストを他のシステム上にあるサーバプロセスに送
信します。一方、これらのサーバはデータベースリクエストを、第 3 のシステム上で実行しているサーバ
プロセスに送ります。トランザクションサーバは、第 3 のシステムのクライアントプロセスになっています。
140418J
1-7
第 1 章 はじめに
図 1-1 分散オブジェクトコンピューティング
ユーザインタフェース、トランザクション処理、データベース機能を分離させるアプリケーションモデ
ルは、3 階層アーキテクチャと呼ばれています。オブジェクト技術は、タイプおよび階層数が異なるさま
ざまなタイプのアプリケーションモデルに適合します。
備考 : 分散オブジェクトコンピューティングとオブジェクト指向の設計についての詳細説明は、1.1.2 関連マニュア
ルにサードパーティから発行されている本、定期刊行物、URL を掲載しています。これらの資料により、オ
ブジェクト技術、オブジェクト指向の設計、および CORBA に関する詳細な知識が得られます。
NonStop DOM を用いたクライアント / サーバコンピューティング
NonStop DOM アプリケーションは、Common Object Request Broker Architecture (CORBA) 2.0 準拠のコ
ンピュータシステムおよびネットワーク上で実行する、クライアント / サーバアプリケーションです。ク
ライアントとサーバは同一の Tandem システム上で実行することもできますが、NonStop DOM サーバはリ
モートクラアイントのリクエストを処理することもできます。また、NonStop DOM クライアントは、リ
モートの NonStop DOM サーバや他の ORB のサーバで処理されるリクエストも生成することができます。
1-8
140418J
第 1 章 はじめに
NonStop DOM アプリケーションサーバ
NonStop DOM アプリケーションサーバは、Tandem NonStop Kernel 上で実行する CORBA 準拠のサー
バプロセスです。NonStop DOM アプリケーションサーバは、NonStop DOM システムに対してローカルお
よびリモートの両方のクライアントに対応するサーバプロセスとして動作します。
NonStop DOM クライアント
NonStop DOM クライアントは、NonStop Kernel 上で実行する CORBA クライアントプロセスです。
NonStop DOM クライアントは、CORBA クライアントとして、そのリクエストを処理する NonStop DOM
アプリケーションサーバと同一のシステムに常駐することができます。あるいは、他の CORBA 準拠の
ORB にあるアプリケーションサーバにネットワークを介して相互接続することによって、
「ネットワーク」
または「リモートクライアント」として動作することも可能です。
ネットワーククライアント
ネットワーククライアント ( リモートクライアントとも呼ばれる ) は、そのリクエストを処理する
NonStop DOM アプリケーションサーバと同一の Tandem システムに常駐しません。CORBA 準拠のネット
ワークプロトコルである Internet InterORB Protocol (IIOP™) を使用して、ネットワーククライアントは、
ORB を介して NonStop DOM サーバにサービスのリクエストを送ります。ネットワーククライアントは、
他の NonStop DOM システムで実行することも、他ベンダの CORBA 準拠の ORB で実行するクライアン
トとして動作することも、どちらも可能です。
NonStop DOM では、アプリケーションサーバがどこにあるのかをネットワーククライアントが認識し
ている必要はありません。ネットワーククライアントがオブジェクトのリクエストを作成すると、NonStop
DOM ソフトウェアが、クライアントのリクエストを処理する NonStop DOM サーバとのリンクを透過的に
確立します。
分散オブジェクトコンピューティングの利点
オブジェクト指向技術を分散処理に適用することは、いくつかの利便性をプログラマおよび組織にもた
らします。それらの利便性には次のものがあります。
□ 既存コンポーネントの再利用
□ サービスの展開と特殊化
□ サーバ実装の詳細とクライアントプログラムとの分離
□ レガシーアプリケーションのマイグレーションとインテグレーション
これらの分散オブジェクトコンピューティングの各利点について、次に説明していきます。
既存コンポーネントの再利用
再利用の可能性というのは、プログラマの作業能力から生まれます。つまり、プログラマが多目的のオ
ブジェクトクラスを設計し、それらをクラスライブラリおよびフレームワークとしてパッケージ化するこ
とによって、新規アプリケーションに活用することが可能になります。再利用により、新規ソフトウェア
を開発する際に、すべて新規コードを作成してテストすることを必要としたプロジェクトに比べて、より
速く低コストで高い品質のソフトウェア開発を実現することができます。
140418J
1-9
第 1 章 はじめに
再利用に関連して、複数の異なるベンダの既製のコンポーネントを結合して、新規のアプリケーション
を構築する可能性が考えられます。このアプローチは、コンポーネントベースの開発と呼ばれます。組織
はこのアプローチを用いることで、多数のアプリケーションに共通した機能の再生成にその労力を注ぐの
ではなく、特殊な機能の開発に労力を集中させることができます。
サービスの展開と特殊化
継承はオブジェクト技術の機能であり、サービスの展開と特殊化を実現します。この原理により、ある
クラスの特性を持たせた新しいクラスを定義し、特殊な機能をそこに追加したり、ベースとなるクラス ( ま
たは親クラス ) の機能を置換 ( オーバーライド ) することができます。
オブジェクトの継承を使うと、あるオブジェクトとその親オブジェクトとの間の「isa」関係を定義する
ことができます。たとえば、
「哺乳類」クラスを作成するとします。すると次に、哺乳類クラスの全特性を
継承する「犬」クラスを作成することができます。このコンテキストでは、犬クラスは哺乳類クラスと
「isa」関係にあります。つまり。犬は哺乳類である (isa) ということです。この機能により、既存コードに
対して複雑なインライン変更を加えるのではなく、個別の拡張を追加していくことが可能となります。い
くつかのオブジェクト指向プログラミングシステムおよびオブジェクト指向プログラミング言語 (CORBA
および C++ など ) では、多重継承を使用できます。多重継承においては、新しいクラスは複数のクラスの
特性を継承します。
サーバ実装の詳細とクライアントプログラムとの分離
オブジェクト指向システムでは、カプセル化とポリモフィズムによって、サーバに実装されているオブ
ジェクトの詳細からクライアントオブジェクトを切り離すことができます。
オブジェクト指向プログラミングでは、カプセル化を使用して、サーバオブジェクトのデータスペース
がクライアントリクエストからアクセスされないように保護します。カプセル化によって、クライアント
が起動できるのは、オブジェクトのデータを操作する機能だけとなります。つまり、クライアントはオブ
ジェクトのデータスペースに直接アクセスしないということです。カプセル化を使用することで、サーバ
オブジェクトの実装の詳細とデータを、サーバリクエストを生成するクライアントオブジェクトから保護
することができます。
ポリモフィズムを用いると、概念的には同じ関数ではあっても、異なるタイプのオブジェクトに対して
はそれぞれ異なる動作をしなければならない関数に対して、同一の呼出し手順をクライアントで使用する
ことができます。ポリモフィズムでは、単一のインタフェースを使用して異なる機能を定義できます。た
とえば、関数呼出しの際に与えられる引数の数に従って、異なる形状を描く関数があるとします。ポリモ
フィズムを用いると、同じ関数を使って円、三角形、長方形、多角形を描くことができます。システムは、
ターゲットのオブジェクトタイプに基づいて適切なコードを選択して実行します。この描画関数では、関
数に渡されるパラメータの数に基づいてコードが選択されています。他のケースでは、渡されるパラメー
タの型に基づいて関数が選択される場合もあるでしょう。
レガシーアプリケーションのマイグレーションとインテグレーション
ラッピングと呼ばれる機能を使用することで、従来の技術で開発されたサーバが、従来のインタフェー
スを使ってこれまでのクライアントにもアクセス可能としながら、新しいクライアントに対してはオブ
ジェクト指向インタフェースを提供することが可能になります。同様に、ある環境で開発されたオブジェ
クトクラスの集合をラッピングして、別の環境で利用可能なオブジェクトとして活用することもできます。
1-10
140418J
第 1 章 はじめに
分散オブジェクトコンピューティングの問題点
分散オブジェクトコンピューティングが与える利便性は非常に魅力あるものですが、一方で、現実的な
問題点もいくつかあります。これらの問題が、異機種ネットワーク、オンライントランザクション処理
(OLTP)、電子商取引といった用途にオブジェクト技術を採用する上での障害となってきました。これらの
問題点を以下に示します。
□ オブジェクト技術は、本質的にはアプリケーションコンポーネントの相互接続性およびそのロケーショ
ンの独立性を提供していません。特に異機種環境においてはそうです。
□ いくつかのオブジェクト指向言語では ( 特に C++)、既存アプリケーションの上位互換性を保証しない
ものもあります。また、ほとんどのオブジェクト指向言語では、オブジェクトの使用を同一言語で記述
されたクライアントに限定しています。同一言語の同一ベンダのバージョンに限定してる場合さえあり
ます。通常、ライブラリを変更すると、ユーザはそれらのプログラムを再コンパイルする必要がありま
す。再コンパイルはさらにライブラリソースコードへのアクセスを必要とし、ユーザが外部ソースから
ライブラリを取得した場合には使用不可になります。
□ ほとんどのプラットフォームでは、OLTP
アプリケーションと電子商取引に必要とされる可用性、ス
ケーラビリティ、およびトランザクション保護が保証されません。
問題点の解決に向けたチャレンジ
これらは難しい問題ではありますが、CORBA 2.0 で Object Management Group® (OMG™) によって定義
された分散オブジェクトアーキテクチャは、従来のオブジェクト指向システムで解決されなかった問題に
取り組むための長い道のりを進んでいます。
CORBA の定義が発表されて以来、多数のベンダが Object Request Brokers (ORB)、プログラミングツー
ル、CORBA 準拠のアプリケーション対応のランタイム環境を発表してきました。ORB™ の機能とサービ
スの標準セットの提供に加え、以前のオブジェクト指向システムで、実用上の制限に取り組むことによっ
て、ある種の製品がコンポーネントベースの開発技術を促進させてきました。
1.2.2 CORBA 定義の標準インタフェースとサービス
図 1-2 に図示されている Common Object Request Broker Architecture (CORBA) は、Object Management
Group (OMG) と呼ばれるベンダのコンソーシアムによって定義されたものです。CORBA では、Object
Request Broker (ORB) というアーキテクチャコンポーネントが、Internet InterORB Protocol (IIOP) を用いて
異機種ネットワーク間におけるクライアントとサーバ間のメッセージを伝送します。IIOP は、OMG によっ
て標準化されているプロトコルです。
クライアントは次のうちどちらかの方法でサーバのオブジェクトを起動します。
□ Static Invocation Interface (SII) では、クライアントはコンパイル時にオブジェクトインタフェースを認
識している必要があります。
□ Dynamic Invocation Interface (DII) では、コンパイル時にオブジェクトインタフェースを認識していな
い場合、クライアントは実行時にリクエストを生成します。クライアントは、Interface Repository (IR)
と呼ばれるデータベースでオブジェクトのインタフェースを検索できます。
サーバにはオブジェクトアダプタが含まれています。NonStop DOM では、オブジェクトアダプタは
CORBA 2.1 の Portable Object Adapter (POA) の実装であり、これが ORB とオブジェクトの実装との間の
インタフェースを提供します。
140418J
1-11
第 1 章 はじめに
これらのコンポーネントに加えて、CORBA では次のものを規定します。
□ Interface Definition Language (IDL)。IDL を使用すると、オブジェクトまたはクライアントの実装に用
いるプログラミング言語が何であるかにかかわりなく、オブジェクトがそのクライアントに提供するイ
ンタフェースを記述することできます。
□ IDL から C++ などの特定のプログラミング言語へのマッピング ( バインディングともいう )。IDL 仕様を
コンパイルすると、IDL コンパイラは言語固有のスタブファイルを生成して、クライアントプログラムと
言語固有のスケルトンファイルにそれらをインクルードし、オブジェクト実装のベースとして使用します。
□ InterORB プロトコル (IOP)。システム間の情報伝送に使用します。IIOP は、OMG が ORB 間の通信の
標準として定義しているインターネットプロトコルです。
図 1-2 Common Object Request Broker Architecture (CORBA)
CORBA と関連して、CORBAservices™ とも呼ばれる Common Object Services (COS) というものがあり
ます。これらのサービスの例を以下に示します。
□ Naming Service: オブジェクト名のバインディングを格納するためのサービスです。
□ Event Service: オブジェクト間で非同期通信をするためのサービスです。
□ Object Transaction Service (OTS): リクエストがデータベースまたは状態リポジトリに対する複数の更新
を含むときに、データベースの一貫性を確保するためのサービスです。
クライアントアプリケーションとオブジェクトサービスが CORBAservices に準拠しているため、それら
のシームレスな相互接続を実現することができます。つまり、クライアントは、ローカルオブジェクトお
よびリモートオブジェクトのロケーションを知らなくても、それらを参照することができます。
備考 : CORBA 準拠の ORB は、CORBA 1.0 または CORBA 2.x のいずれかを実装することができます。NonStop
DOM は CORB 2.0 ORB の完全準拠を実装します。また、NonStop DOM は、OMG CORBA 2.1 仕様に
よって規定されている Portable Object Adapter (POA) も実装します。
1-12
140418J
第 2 章 NonStop DOM の概要
第 2 章 NonStop DOM の概要
2.1 NonStop DOM について
サブトピックス
□ NonStop DOM の利点
□ 他製品にはない NonStop DOM の優れた機能
□ 主な特徴と機能性
NonStop Distributed Object Manager/MP (NonStop DOM) は、Tandem NonStop Kernel で実行する分散オ
ブジェクトアプリケーションおよびコンポーネントの開発に利用できる、インフラストラクチャと開発環
境を提供します。NonStop DOM のインフラストラクチャによって提供されるサービスとツールは、ソフト
ウェア開発者が C++ プログラミング言語を使用してオブジェクト指向のコンポーネントと分散オブジェ
クトシステムを構築する上での支援となります。これらのシステムは、アプリケーションレベル、システ
ムレベルで、またはミドルウェアソフトウェアとして実装することができます。
NonStop DOM 2.0 は、Object Management Group (OMG) が定義および推進している Common Object
Request Broker Architecture (CORBA) の実装です。NonStop DOM 2.0 は OMG によって定義されている
CORBA 2.0 に準拠しているため、NonStop DOM で開発したアプリケーションクライアントおよびコン
ポーネントは、さまざまなプラットフォームで動作する CORBA 準拠の他サーバと相互接続できます。
このトピックでは、分散オブジェクトコンピューティングの利点と実際面での問題点について述べ、
NonStop DOM とそのもととなっている技術による、これらの問題点の解決法を示します。
2.1.1 NonStop DOM の利点
NonStop DOM は OMG の Object Management Architecture (OMA) の強力な実装であり、大規模なエン
タープライズ規模のミッションクリティカルなシステムに採用できます。
NonStop DOM システムのアーキテクチャは、オブジェクト技術の柔軟性とトランザクション処理モニ
タの強靭性の結合を実現しています。このユニークな結合によって、ミッションクリティカルなアプリケー
ションに必要とされる可用性と拡張性を提供します。また、NonStop DOM はそのデータストアの整合性を
保証しており、アプリケーションに対して安全性の高い環境を維持することができるオブジェクトトラン
ザクションサービスを提供します。
NonStop DOM は、CORBA 2.0 準拠のオブジェクト指向の開発システムを提供します。NonStop DOM
が他の CORBA 準拠システムと大きく異なる点は、拡張性、可用性、およびデータの整合性 ( トランザク
ション保護 ) にあります。Tandem のトランザクションサービスとトランザクションモニタとが強固に統合
しており、NonStop DOM はオブジェクトトランザクションモニタの真の機能性を実現します。
スケーラビリティは、使用量の増大にともなってシステムを動的に拡張していくことを可能にします。
NonStop DOM では次の領域でスケーラビリティを実現しています。
□ ネットワーク接続
140418J
1-13
第 2 章 NonStop DOM の概要
□ Object Request Broker (ORB) プロセス
□ アプリケーションプロセス
NonStop DOM はトランザクション処理用に最適化されており、リソースを効率的に共有することによ
り、多数のクライアントを少数のサーバにマッピングすることができます。NonStop DOM システムのプロ
セスは NonStop TS/MP で実行するため、CORBA 準拠の環境で強力な Tandem のトランザクションサービ
ス ( プロセスの管理、可用性、およびロードバランシングのための ) を利用できます。
CORBA 2.0 準拠
NonStop DOM は、Object Management Group (OMG) の CORBA 2.0 の仕様 [96-03-04] に準拠します。
CORBA に準拠しているということは、NonStop DOM が他の CORBA 準拠の ORB (Object Request Broker)
との相互接続が可能であることを意味します。NonStop DOM は、CORBA によって定義されている IIOP
(Internet InterORB Protocol) を使用することにより、CORBA IIOP プロトコルに準拠している他の異機種の
OMA ベース環境と相互接続することができます。
また、NonStop DOM は、OMG の CORBA 2.1 ORB Portability 仕様 [97-05-15] の言語およびオブジェク
トアダプタにも準拠しているため、NonStop DOM で作成するコンポーネントの相互接続性がさらに強化さ
れます。
CORBA 2.0 準拠のクライアントおよびサーバオブジェクトを記述することにより得られる利便性は、次
のとおりです。
□ 他の CORBA 準拠の ORB との相互接続性
□ 国際的なネットワーク標準に基づいた、広域ネットワーク (WAN) およびローカルエリアネットワーク
(LAN) の接続性
□ 分散オブジェクトアーキテクチャによるレガシーアプリケーションのラッピング (NonStop DOM の利
点の 1 つ )
2.1.2 他製品にはない NonStop DOM の優れた機能
NonStop DOM で提供される ORB では、NonStop TS/MP サーバプールを使用する特定のシステム固有
のプロセスを実装することによって、他の CORBA 準拠の ORB には見られない可用性と拡張性を提供し
ます。NonStop TS/MP のランタイムコードは、NonStop DOM を実行するすべての ORB に常駐しており、
ご利用の NonStop DOM アプリケーションサーバにもまた組み込むことができます。
NonStop DOM ORB は、Tandem NonStop Kernel で実行します。C++ で記述した NonStop DOM アプリ
ケーションサーバは、リモートクライアントとの通信にこの ORB を使用します。NonStop DOM で提供さ
れる ORB が他の ORB と差別化できる優れた機能として、主なものに次の機能があります。
□ より高いスループットを実現する、ORB のスケーラビリティ
□ 複数の CPU 間にまたがるアプリケーションサーバプロセスのスケーラビリティ
□ 可用性と耐障害性
□ ORB によって管理されるデータストアのトランザクション保護
□ ホストに必要な IP ポート数を軽減する、ネットワークセッションのコンセントレーション
1-14
140418J
第 2 章 NonStop DOM の概要
Object Request Broker(ORB) のスケーラビリティ
NonStop DOM を用いると、アプリケーションの実行を妨げることなく、ORB 機能を強化することがで
きます。NonStop DOM では、ORB そのものを拡張する方法をいくつか提供しています。それらの方法は
次のとおりです。
□ 新規クライアントは、クライアントワークステーションまたは Tandem サーバ上で 必要となる構成変
更を行わずに、NonStop DOM ORB に接続できます。
□ NonStop DOM システム管理者は、リクエストのトラフィックの増大をサポートするために、Comm
Server の数を増やすことができます。
□ NonStop DOM システム管理者は、クライアントとサーバ間のリンケージ数の増大をサポートするため
に、クライアントとサーバ間の初期リンクを確立する Location Service Daemon の数を増やすことがで
きます。
□ 管理者は、外部ポートの接続を追加するために、Tandem TCP/IP の複数インスタンスを NonStop DOM
システムに追加することができます。Tandem TCP/IP の各インスタンスは、使用可能な TCP/IP ポート
の数を増やし、結果として、ORB がサポートできるクライアント数を増やします。Tandem TCP/IP の
複数インスタンスによって、Comm Server は同一 IP アドレスまたは異なる IP アドレスでのリスンが可
能です ( ポート番号は、TCP/IP プロセスの有効範囲内で一意でなければなりません )。
□ NonStop DOM システムは、Tandem システムの範囲内で、アプリケーションプロセス間の通信用
NonStop TS/MP、Comm Server、およびアプリケーションサーバを使用します。これによって、ORB
で必要とされる Tandem IPC リソースを最小限にしながら、スループットを向上することができます。
NonStop DOM ORB に接続するリモートクライアントの数を増やすために、クライアントワークステー
ションまたは NonStop DOM システム上のいずれにおいても構成変更は必要ありません。リモートクライ
アントが最初に ORB に接続する際、NonStop DOM システムが既存のポート番号をそのクライアントに透
過的に割り当てます。
実際には、単一の Comm Server で最大数百までのクライアントを扱うことができます。また、TCP/IP
プロセスは最大数百までの Comm Server を扱うことができます。
アプリケーションサーバプロセスのスケーラビリティ
NonStop DOM は、NonStop TS/MP サーバプールの使用をサポートすることで、アプリケーションサー
バプロセスのスケーラビリティを実現します。NonStop TS/MP サーバプールは、複数のプロセス (CPU リ
ソース ) から成り、それらは同一のアプリケーションロジックを実装します。NonStop TS/MP ではロード
バランシングを採用し、プール内のサーバ間でリクエストを分配します。
オブジェクトクラスがサーバプールで実行するのか、または個々のサーバプロセスで実行するのかと
いったことを、クライアントプログラムが認識する必要はありません。実際、同じサーバプロセスがどち
らのモードにおいても正常に実行できます。実行したいモードを、それぞれのサーバのコンフィギュレー
ションファイルで指定します。(Tandem では、可用性、自動再起動、スケーラビリティ、ロードバランシ
ングを実現するために、サーバプールのご利用をお勧めしています。)
140418J
1-15
第 2 章 NonStop DOM の概要
NonStop DOM コンポーネントの互換性
NonStop DOM では、CORBA 2.0 および OMG のポータビリティ仕様に準拠したアプリケーションのた
めにソースコードのポータビリティを提供します。スケーラビリティなどの Tandem の他とは異なる優れ
た機能のほとんどが透過的にご利用になれます。Tandem システムに移植されたアプリケーションサーバは
変更の必要なく、NonStop DOM のスケーラビリティを実現します。
可用性と耐障害性
オブジェクト指向のランタイム環境では、連続可用性をサポートするために、次の 3 レベルで耐障害性
を提供する必要があります。
1. システムのプラットフォーム
2. ORB
3. アプリケーションコンポーネント
NonStop DOM システムは、NonStop Kernel 上で実行することによって 1 番目のレベルの耐障害性を実
現します。NonStop Kernel は、対の NonStop プロセス、ミラーリングされたディスクコントローラ、耐障
害性を備えた通信サブシステムを提供します。
ORB は、ORB プロセスのプロセスマネージャとして NonStop Transaction Services/MP (NonStop TS/MP)
を使用することによって耐障害性をサポートします。サーバプロセスに問題が生じると、NonStop TS/MP
によって自動再始動が実行されます。自動再始動は、NonStop TS/MP サーバプールを使用するアプリケー
ションコンポーネントでも利用可能です。
トランザクション保護とデータの整合性
NonStop DOM では、Object Transaction Service (OTS) のアドオンパッケージを用いて、アプリケーショ
ントランザクションの保護とデータの整合性を提供します。OTS は、NonStop DOM ORB が管理するデー
タストアに対してトランザクション保護を提供します。特に、Naming Service と ORB の構成情報を搭載し
た Implementation Repository データベースにおけるデータストアを OTS は保護します。
NonStop DOM OTS は、トランザクション保護のもととなるメカニズムとして NonStop TM/MP を使用
します。これによって、Tandem の基本機能と一致したトランザクション保護とデータ整合性を確実に実現
します。
アプリケーション自体がトランザクション保護を必要とするときや、クライアントの実装がトランザク
ション保護を要求するとき、OTS を使用してアプリケーション固有のデータを保護することができます。
ネットワークセッションのコンセントレーション
NonStop DOM システムでは、ネットワークセッションのコンセントレーションによって、ホストで必
要となる TCP/IP ポートの数を減らすことができます。NonStop DOM は、Comm Server の使用とともに
ネットワークセッションのコンセントレーションを提供します。Comm Server は NonStop DOM システム
のコンポーネントであり、リモートクライアントとローカルサーバ間のリンケージを管理します。Comm
Server が使用するプロトコルには次のものがあります。
□ Internet InterORB Protocol (IIOP)。TCP/IP を介したリモートコンポーネントとの通信用プロトコルとし
て、OMG 仕様の Universal Networked Objects (UNO) [94-12-02] で定義されています。リモートクライ
1-16
140418J
第 2 章 NonStop DOM の概要
アントは、クライアントが使用するサーバ数に関係なく単一の TCP/IP ポート番号を使って ORB に接
続します。
□ NonStop TS/MP プロトコル。NonStop TS/MP サーバプールとの通信に使用します。
□ NonStop Kernel ファイルシステムプロトコル。NonStop システム上の個々のプロセスとの通信に使用
します。
2.1.3 主な特徴と機能性
NonStop DOM は、CORBA 2.0 仕様で定義されている CORBA オブジェクトモデルをベースにしていま
す。NonStop DOM では、CORBA 準拠の ORB に次の機能を実装します。
□ IIOP プロトコルサポート
□ IDL コンパイラ
□ C++ 言語のバインディング
□ Portable Object Adapter (POA)
□ Object Method Invocation
□ Naming Service
□ Event Service
□ エラーログとトレース機能
□ レガシーラッパインタフェース
□ Static Invocation Interface (SII)
IIOP プロトコルサポート
Internet InterORB Protocol (IIOP) は、さまざまな ORB がインターネットを介して通信する際に使用する
標準プロトコルです。このプロトコルは、OMG によって標準化されています。NonStop DOM で作成され
たオブジェクトは、IIOP 準拠を用いて、他の ORB およびクライアントが使用できます。NonStop DOM ク
ライアントは、他の IIOP 準拠の ORB にあるオブジェクトを使用できます。
IDL コンパイラ
NonStop DOM IDL コンパイラ (NSDIDL) は、OMG によって定義された CORBA 2.0 および Portable
Object Adapter (POA) 仕様に準拠しています。コンパイラは、クライアントとサーバオブジェクトのため
に、それぞれスタブとスケルトンを生成します。
言語バインディング
NSDIDL は、OMG CORBA および POA 仕様で定義されている、OMG の標準 C++ 言語のバインディン
グをサポートしています。
140418J
1-17
第 2 章 NonStop DOM の概要
Portable Object Adapter
NonStop DOM Portable Object Adapter (POA) は、CORBA 2.1 のポータビリティ仕様で定義されていま
す。これは、CORBA 2.0 定義されていた Basic Object Adapter (BOA) に代わるものです。Object Adapter
は、ORB が提供するサービスにオブジェクトの実装がアクセスする際の主要な方法です。
NonStop DOM POA によって、以下が可能となります。
□ 移植可能なオブジェクトソリューションの開発
□ 永続性のあるオブジェクトの提供
□ サーバントが複数のオブジェクトを 1 つの論理オブジェクトとして管理する
( サーバントはユーザ定義のオブジェクトであり、インタフェースのメソッドの実装を提供します )
□ POA の複数の互いに異なるインスタンスがサーバに存在する
□ 非永続オブジェクトのサポート
□ 静的または動的あるいは静的かつ動的なスケルトンを使用するアプリケーションのサポート
□ ポリシーとオブジェクトを関連付けるための拡張可能なメソッドの提供
□ スレッド化されたオブジェクトのサポート
アプリケーションプログラマは BOA から POA にアップグレードする際に、設計について再考する可能
性があります。というのも、POA を利用するには、おそらく、そのアプリケーションインタフェースを変
更する必要があると考えられるからです。ただし、基本的な BOA の使用は基本的な POA の使用に簡単に
マップさせることができます。
オブジェクトのメソッドの起動
NonStop DOM は、Static Invocation Interface (SII) をサポートしています。
Naming Service
Naming Service は、人が理解できるオブジェクトの名前を NonStop DOM オブジェクトにバインディン
グし、クライアントリクエストにおけるこれらの名前のオブジェクトを識別します。NonStop DOM の
Naming Service は、CORBA 2.0 の仕様に完全に準拠します。NonStop DOM における Naming Service の
データベースは、構造化された Enscribe ファイルとして実装されています。
Event Service
Event Service では、イベントチャネルを使用することによって、イベントのコンシューマとサプライヤ
との間の非同期の通信を実現します。サプライヤとコンシューマはイベントチャネルに登録します。登録
では、サプライヤ / コンシューマはプッシュモデルまたはプルモデルのどちらかを指定します。プッシュ
モデルを使用する場合、サプライヤがイベントの転送を起動します。プルモデルの場合は、コンシューマ
がイベントの転送をリクエストします。NonStop DOM では、汎用の通信モデルと類型的な通信モデルのど
ちらもサポートします。
1-18
140418J
第 2 章 NonStop DOM の概要
エラーログとトレース機能
NonStop DOM のすべてのサーバプールとシステムのインフラストラクチャでは、ユーザ設定可能なエ
ラーログ、トレース、イベントチャネルのメッセージ機能を提供します。アプリケーションプログラマは、
これらのデバッグ機能をオブジェクトに装備することができます。
また、NonStop DOM は、エラーログファシリティへの IDL インタフェースも提供しており、これを使
用することによって開発者はアプリケーション固有の情報をロギングすることができます。
レガシーラッパインタフェース
レガシープログラムのラッピングは決して容易な作業ではありません。しばしばレガシープログラム自
体が変更を必要とします。しかし、Tandem が提供する汎用のレガシーラッパのセットは、レガシープログ
ラムに対する統合フレームワークとして動作します。つまりこれは、レガシープログラムの変更が必要な
いことを意味し、レガシープログラムは既存の CORBA オブジェクトおよびコンポーネントと透過的に相
互接続することができます。
2.2 NonStop DOM のシステム要件
サブトピックス
□ システムのハードウェア要件
□ システムのソフトウェア要件
2.2.1 システムのハードウェア要件
NonStop DOM の Software Development Kit (SDK) リリースおよび Runtime リリースはどちらも、RISC
テクノロジを採用した NonStop システム上で実行します。NonStop システムは、NonStop Kernel バージョ
ン D42 以降を実行しているか、G05 S- シリーズシステム以降でなければなりません。C++ 例外を使用する
つもりであれば、オペレーティングシステムとしてバージョン D46 または G06 をご使用になることを強く
お勧めします。
このハードウェアに加えて、NonStop DOM の SDK または Runtime 版をインストールするには、およそ
20 MB の使用可能なディスク記憶装置がシステムに搭載されていなければなりません。
2.2.2 システムのソフトウェア要件
NonStop DOM 2.0 の各リリース (SDK と Runtime リリース ) にはそれぞれ、3 版 ( エディション ) のソ
フトウェアパッケージが含まれています。それらは次のとおりです。
□ T7888D43 / T7889D43: D42 システム以上で実行。C++ 例外はサポートしない。
□ T7888D46 / T7889D46: D45/G05 システム以上で実行。C++ 例外をサポートする。ただし、スレッド化
の例外はサポートしない。
□ T7888G06 / T7889G06: D46/G06 システム以上で実行。C++ 例外を完全サポートする。
NonStop DOM をインストールするには、上記のハードウェアおよびソフトウェアに加えて、表 1-3 に示
140418J
1-19
第 2 章 NonStop DOM の概要
す追加のシステムソフトウェアがご利用の NonStop Kernel システムにあらかじめインストールされていな
ければなりません。
表 1-3 NonStop DOM 2.0 に必要な支援ソフトウェア
ソフトウェア製品
1-20
必須 / オプション
備
考
OSS
(Open System Services)
必須
NonStop DOM 2.0 でのアプリケーションの実行に必須
NonStop TS/MP
(Pathway)
必須
サーバプールおよび自動再起動に必須
OTS アドオンパッケージ用に必須
アプリケーション開発用に推奨
NonStop TM/MP
必須
NonStop DOM 操作用に推奨されるが、起動には必須
ではない
NonStop Server for Java
必須
IDL コンパイラに必須
Rogue Wave Tools.h++
必須
標準ライブラリパッケージ
Tandem TCP/IP
オプション
リモート接続用に IIOP で必須
X25AM
オプション
広域ネットワーク接続用に IIOP で必須
TLAM/QIO
オプション
ローカルエリアネットワーク接続用に IIOP で必須
140418J
第 3 章 NonStop DOM のインストールと実行
第 3 章 NonStop DOM のインストールと実行
3.1 NonStop DOM のインストール
サブトピックス
□ NonStop DOM pax ファイル
□ インストール先
□ NonStop DOM をデフォルトのファイル場所にインストールする
□ ユーザ設定のインストール先を指定する
□ インストール用サブディレクトリ
このトピックでは、NonStop DOM 製品を NonStop Kernel システムにインストールするための手順を詳
しく解説します。NonStop DOM にはインストールユーティリティが提供されています ( スクリプト形式
で )。このトピックはインストールプロセスの参考用としてご活用ください。
3.1.1 NonStop DOM pax ファイル
NonStop DOM バージョン 2.0 では、2 種類の異なる製品パッケージを用意しています。1 つは NonStop
DOM Software Development Kit (SDK) を含むパッケージであり、もう 1 つは製品のランタイムのみの
Runtime バージョンを含むパッケージです。NonStop DOM クライアントまたはサーバのアプリケーション
の開発を行う場合、製品の SDK リリースが必要となります。既存の NonStop DOM アプリケーションを実
行するだけの場合には、Runtime リリースが用意されています。
SDK および Runtime 製品リリースは、別々のコンパクトディスク (CD) で提供されます。どちらの CD
にも NonStop DOM の 3 種類のエディションが入っています。このエディションはそれぞれ、サポートさ
れている各オペレーティングシステム (D42、D45、D46、G05、G06) に対応しています。各エディション
は圧縮コンテナファイルである pax ファイルで提供されており、それにはテキストファイルとバイナリ
ファイルが含まれています。この NonStop DOM ファイルをアンパックし、ソフトウェアを OSS(Open
System Services) システムにインストールするには、OSS の pax ユーティリティを使用します。
次の表は、NonStop DOM の SDK 版と Runtime 版の pax ファイルのファイル場所とファイル名の一覧で
す。
140418J
1-21
第 3 章 NonStop DOM のインストールと実行
表 1-4 NonStop DOM pax ファイル
NonStop DOM
リリース CD
NonStop DOM
SDK CD
NonStop DOM
Runtime CD
製品バージョン
対
応
プラットフォーム
pax ファイル
SOFTDOC
ファイル
備
考
T7888D43
D42 以上
(G- シリーズは
サポートしていない )
D43
\T7888PAX
D43
\T7888D43
C++ 例外はサポートし
ない
T7888D46
D45、G05 以上
D46
\T7888PAX
D46
\T7888D46
C++ 例外をサポートし
ている。ただし、ス
レッド化の例外はサ
ポートしない。
T7888G06
D46、G06 以上
G06
\T7888PAX
G06
\T7888G06
C++ 例外を完全サポー
トしている。
T7889D43
D42 以上
(G- シリーズは
サポートしていない )
D43
\T7889PAX
D43
\T7889D43
T7889D46
D45、G05 以上
D46
\T7889PAX
D46
\T7889D46
T7889G06
D46、G06 以上
G06
\T7889PAX
G06
\T7889G06
G05) は、C++ のキーワードの catch と throw
備考 : T7888D46 製品リリース ( 対応プラットフォームは D45、
を処理する C++ 例外 をサポートしていますが、ネイティブの C++ 例外処理はシングルスレッド環境でのみ
使用することをお勧めします。スケーラブルかつマルチスレッドの NonStop DOM アプリケーションでは常
に、 CATCH および THROW マクロの使用によってサポートされている例外環境を使用してください。
T7888G06 製品リリースにはこの制限がありません。
SOFTDOC ファイル
各製品 CD-ROM にはそれぞれ、製品の各エディションに対して 1 ファイルずつ、計 3 種類 の SOFTDOC
ファイルが含まれています。各製品エディションに対応した SOFTDOC ファイルは、CD 上で、それと関
連する pax ファイルと同じディレクトリにあります。それぞれのファイル名は、対応する製品バージョン
にちなんで付けられます。
SOFTDOC ファイルには、製品に関連した最新情報が含まれています。ソフトウェアのインストール作
業を続ける前に、SOFTDOC ファイルを確認して、インストール手順で更新されているものはないかどう
1-22
140418J
第 3 章 NonStop DOM のインストールと実行
かチェックします。NonStop DOM のインストールが完了したら、参照がしやすいように SOFTDOC ファ
イルを NonStop DOM の docs サブディレクトリにコピーします。
NonStop DOM フレームワークを Tandem システムに転送する
NonStop DOM をインストールするには、該当する pax ファイルを CD から目的の Tandem システムに
転送する必要があります。FTP は 2 台のコンピュータ間におけるファイル転送に広く使用されている、最
も便利なプロトコルです。FTP を使用するには、NonStop DOM の CD を搭載しているコンピュータで FTP
クライアントアプリケーションを実行します。そしてさらに、目的の Tandem システムで Tandem の FTP
サーバ製品を実行します。
次の手順では、製品 CD-ROM を搭載しているシステムが Windows ベースのシステムであり、コマンド
ラインで FTP クライアントを実行するものと仮定します。グラフィカルユーザインタフェース (GUI) を備
える FTP アプリケーションを使用している場合、ここに示すコマンドを無視して、ご利用の FTP ツールの
グラフィカルコマンドを使用してください。
pax ファイルをコピーするには、以下の手順に従います。
1. 製品 CD-ROM を搭載しているシステムで、コマンドプロンプト (MS-DOS プロンプト ) ウィンドウを
開き、次のコマンドを入力して、FTP クライアントアプリケーションを起動します。
> ftp
次のような FTP プロンプトが表示されます。
ftp>
2. 次のようにして、目的の Tandem システムに接続します。
ftp> open <tandem system host name> | <IP address>
3. FTP プログラムのプロンプトで、ログイン名およびそれに続いてパスワードの入力を求められます。
Tandem システムの有効なログイン名とパスワードを入力します。Tandem システムにログインしたら、
この Login ID に $SYSTEM ボリュームへの書込みアクセスがあることを確認してください。
4. 以下のコマンドを入力して、API を oss に設定します。これでディレクトリ名を指定するために OSS
構文を使用することができます。
ftp> quote oss
5. NonStop DOM の SDK 版をインストールする場合、ディレクトリをリモート (Tandem) システムの /G/
SYSTEM/ZDOMSD20 に変更します。
ftp> cd /G/SYSTEM/ZDOMSD20
NonStop DOM の Runtime 版をインストールする場合、ディレクトリをリモート (Tandem) システムの
/G/SYSTEM/ZDOMRT20 に変更します。
140418J
1-23
第 3 章 NonStop DOM のインストールと実行
ftp> cd /G/SYSTEM/ZDOMRT20
6. ローカルシステム上で、CD 上の該当する製品ディレクトリにいきます。たとえば、CD がドライブ D:
であり、G05 Tandem システムに製品をインストールしたい場合、次のコマンドを入力します。
ftp> lcd D:\G05
7. FTP の転送モードをバイナリに設定します。
ftp> binary
8. NonStop DOM PAX ファイルを転送します。
ftp> put NSDFWPAX
9. FTP クライアントの実行を終了します。
ftp> quit
3.1.2 インストール先
処理を続ける前に、製品のインストール先を、デフォルトの NonStop DOM ファイル場所にするか、ま
たはユーザ設定のファイル場所にするかを決定します。ユーザ設定のファイル場所は、ファイルをアンパッ
クする際に指定します。
たとえば、単一システム上で複数の NonStop DOM インストールを行う場合、別々のセットアップを指
定するためにユーザ設定のファイル場所を使用する必要があるでしょう。また、$SYSTEM への書込みア
クセスがない場合、カスタマイズしたインストールを行う必要があるでしょう。
カスタマイズしたファイル場所にインストールするには、
「ユーザ設定のインストール先を指定する」の
手順に従ってください。
1-24
140418J
第 3 章 NonStop DOM のインストールと実行
3.1.3 NonStop DOM をデフォルトのファイル場所にインストールする
デフォルトでは、NonStop DOM は unpax コマンドによって以下の場所にインストールされます。
表 1-5 NonStop DOM のデフォルトのファイル場所
ファイルの種類
ファイル場所
OSS ファイル
/usr/tandem/nsdoms/
Guardian ファイル
/G/SYSTEM/ZDOMSD20
(NonStop DOM の SDK 版 )
Guardian ファイル
/G/SYSTEM/ZDOMRT20
(NonStop DOM の Runtime 版 )
該当する pax ファイルを CD からご使用のシステムにコピーし、次の手順に従って NonStop DOM ファ
イルをデフォルトのファイル場所に解凍してください。
1. システムにログインして OSS シェルをまだ起動していなかった場合は、TACL プロンプトから次のコ
マンドを入力してそれを行います。
> osh
2. /usr/tandem というディレクトリが存在しているかを確かめ、現行のユーザ ID に /usr ディレ
クトリへの書込みアクセスがあることを確認します。
3. 次の OSS コマンドを入力して、pax ユーティリティを実行し、NonStop DOM ファイルをそれらのデ
フォルトのファイル場所にアンパックします。<NSDFW_Path> には、NonStop DOM の pax ファイ
ルが存在する完全ファイルパスを指定します。
> pax -rvf <NSDFW_Path>NSDFWPAX -W clobber
たとえば、SDK 版をインストールする場合、pax ファイルを /G/SYSTEM/ZDOMSD20 ディレクトリ
にコピーしていたとして、次のコマンドを実行してファイルをアンパックします。
> pax -rvf /G/SYSTEM/ZDOMSD20/NSDFWPAX -W clobber
注意 :
140418J
-W clobber スイッチは、既存の Guardian システムファイルを上書きするように pax ユーティリティ
に対して指示します。このスイッチがないと、システム上の既存の Guardian ファイルが新しい NonStop
DOM システムファイルに更新されません。
1-25
第 3 章 NonStop DOM のインストールと実行
3.1.4 ユーザ設定のインストール先を指定する
NonStop DOM のインストール手順は、Guardian ファイル領域と OSS ファイル領域の両方にファイルを
インストールします。デフォルトでファイルは、表 1-5 のファイル場所にインストールされます。
ユーザ設定のインストール先を指定するには、pax プログラムの -s オプションを使用します。-s オプ
ションを使って、NonStop DOM OSS ファイルと Guardian ファイルの両方に対して目的のディレクトリを
指定します。
次のコマンドを使用して、NonStop DOM システムファイルをアンパックします。<NSDFW_Path> に
は、NonStop DOM の pax ファイルが常駐している完全ファイルパスを指定します。
> pax -rvf <NSDFW_Path>NSDFWPAX
[-s:/usr/tandem/nsdoms:<your-dir>:]
[-s:<default-subvolume>:/G/<your-vol-subvol>:] -W clobber
このコマンドで、パラメータ <your-dir> には、OSS ファイルのインストール先にするベース OSS
ディレクトリを指定します。パラメータ <default-subvolume> には、デフォルトの Guardian ファ
イルの場所を指定します。SDK 版が ZDOMSD20、Runtime 版が ZDOMRT20 です。パラメータ <your-
vol-subvol> には、Guardian ファイルを常駐させる場所を指定します。
たとえば、製品の SDK 版をインストールする場合、pax ファイルを
/G/SYSTEM/ZDOMSD20 ディ
レクトリにコピーしていたとすると、次のコマンドを実行してファイルをアンパックします。
> pax -rvf /G/SYSTEM/ZDOMSD20/NSDFWPAX
[-s:/usr/tandem/nsdoms:<your-dir>:]
[-s:/G/SYSTEM/ZDOMSD20:/G/<your-vol-subvol>:] -W clobber
Runtime 版をインストールする場合は、以下のコマンドを使用します。
> pax -rvf /G/SYSTEM/ZDOMRT20/NSDFWPAX
[-s:/usr/tandem/nsdoms:<your-dir>:]
[-s:/G/SYSTEM/ZDOMRT20:/G/<your-vol-subvol>:] -W clobber
3.1.5 インストール用サブディレクトリ
NonStop DOM ファイルをアンパックするとき、pax ユーティリティはファイルをいくつかのサブディレ
クトリに入れます。これらのサブディレクトリはアンパック処理中に作成されます。これらのサブディレ
クトリはすべて、NonStop DOM のメインディレクトリの下に作成されます。NonStop DOM のデフォルト
のメインディレクトリは /usr/tandem/nsdoms/ です。
インストールプロセスで作成されるサブディレクトリの一覧を次の表に示します。
1-26
140418J
第 3 章 NonStop DOM のインストールと実行
表 1-6 NonStop DOM サブディレクトリ
サブディレクトリ
ディレクトリの中身
bin
実行可能プログラム。このセクションおよび他のセクションで説明されている構
成関連の全ツールを含む。
docs
このディレクトリは最初、空になっている。NonStop DOM のマニュアルセット
のプレースホルダである。
etc
その他のシステムファイル。env.sh ファイル、default.db ファイルなど
が入っている。
140418J
idl
nsdidl.jar ファイル。
include
C++ ヘッダファイル。NonStop DOM アプリケーションのコンパイル時に使用す
るファイルである。
include_env
D46 エディションおよび G06 エディションでのみ作成される。このディレクトリ
には、環境例外を使用するプログラムに固有のヘッダファイルが含まれる。
(D43 エディションでは、これらのファイルは include ディレクトリに含まれ
る。)
lib
Naming Service と Event Service のクライアントに必要なオブジェクトファイル。
Event Service のサンプルアプリケーションにこれらのファイルの使用方法が示さ
れている。
lib_env
D46 エディションおよび G06 エディションでのみ作成される。このディレクトリ
には、環境例外を使用するプログラムに固有のヘッダファイルが含まれる。
(D43 エディションでは、これらのファイルは lib ディレクトリに含まれる。)
log
これは作成されるログファイルのプレースホルダである。
samples
製品に付属している全サンプルプログラムのソースコード。
/G/vol/subvol
Guardian ファイルシステムに常駐する NonStop DOM ファイル。SRL および ems
テンプレートファイルなどが入っている。
1-27
第 3 章 NonStop DOM のインストールと実行
3.2 クイック構成
サブトピックス
□ env.sh ファイルのカスタマイズ
□ env.sh ファイルのソース化
□ NonStop DOM EMS テンプレートの設定
□ 初期化スクリプトのカスタマイズ
□ NonStop DOM システムの構成
□ NonStop DOM PATHMON プロセスのカスタマイズ
ご使用の OSS(Open Services System) システムに NonStop DOM をインストールしたら、システムを実行
する前に必ずセットアップを構成してください。
このトピックでは、NonStop DOM システムの構成に必要となる基本的な手順について説明します。こ
れらの構成手順の詳細、およびセットアップ後の NonStop DOM システム構成の保守手順の詳細について
は、『第 2 部 NonStop™ DOM 管理者ガイド』を参照してください。
構成プロセスでは、いくつかのシステムのスクリプトファイルをカスタマイズします。これらのファイ
ルは、さまざまな環境変数の設定、および NonStop DOM の起動に使われます。NonStop DOM システムの
詳細については、トピック「NonStop DOM のアーキテクチャ」を参照してください。
このトピックでは、クイック構成によって、NonStop DOM システムの起動と実行ができるようにガイ
ドします。このプロセスを完了すると、NonStop DOM インストールの
samples ディレクトリにある、
スタック例を実行できます。
構成プロセスを開始する前に、NonStop Dom インストールのベースディレクトリにいきます。このディ
レクトリのデフォルトは、/usr/tandem/nsdoms/ です。
3.2.1 env.sh ファイルのカスタマイズ
「ユーザ設定のインストール先を指定する」の記述に従って NonStop DOM をユーザ設定のファイル場所
にインストールした場合、カスタマイズしたインストール先を反映させるために
env.sh ファイルを変
更する必要があります。デフォルトのインストール先を使用した場合は、次のサブトピック「env.sh ファ
イルのソース化」はとばすことができます。
env.sh スクリプトファイルは、NonStop DOM のインストールに対してデフォルトの環境変数を設定
します。このファイルは、etc/ サブディレクトリにあります。このサブディレクトリは、NonStop DOM
インストールのベースディレクトリの中にあります。
env.sh で設定される環境変数
次の表では、env.sh スクリプトで設定されている環境変数の簡単な記述を示します。また、デフォル
トのスクリプト設定も示します。
1-28
140418J
第 3 章 NonStop DOM のインストールと実行
表 1-7 環境変数の設定
変
数
デフォルト設定
記
述
NSD_ROOT
/usr/tandem/nsdoms
NonStop DOM インストールのルート OSS
ディレクトリを設定する。
MY_ROOT
$NSD_ROOT
ユーザ設定の NSD_ROOT を設定して、
カスタマイズした複数のインストールを実
行できるようにする。デフォルト設定は
NSD_ROOT と同じ。
NSD_DIR
/G/SYSTEM/ZDOMSD20
NonStop Kernel ファイルに対して NonStop
DOM Guardian ボリュームおよびサブボ
リュームを指定する。この設定は OSS
ディレクトリ形式で表されなければならな
い。
NSD_SUBVOL
"\$SYSTEM.ZDOMSD20"
NSD_DIR と同じであるが、NonStop
Kernel (Guardian) 形式 ( ドル記号の前に
バックスラッシュを付け、2 重引用符で囲
む ) で表される。
MY_SUBVOL
$NSD_SUBVOL
ユーザ設定の NSD_SUBVOL を設定す
る。これにより複数のインストール処理が
実行可能になる。デフォルト設定は
NSD_SUBVOL と同じ。
140418J
NSD_SRL_SUBVOL
$NSD_SUBVOL
NonStop DOM SRL が常駐する、Guardian
ボリュームおよびサブボリュームを
Guardian 形式で指定する。デフォルト設
定は NSD_SUBVOL と同じ。
NSD_SRL_DIR
$NSD_DIR
NonStop DOM SRL が常駐する、Guardian
ボリュームおよびサブボリュームを OSS
形式で指定する。デフォルト設定は
NSD_DIR と同じ。
NSDOM_CFG_DBM
$MY_SUBVOL.NSDCFGDB
構成および Naming Service データベース
が常駐する、Guardian ボリュームおよび
サブボリュームを指定する。NonStop
Kernel 形式で設定されなければならない。
PATH
$PATH:$NSD_ROOT/bin:
$COMP_ROOT/usr/lib:
$JAVA_HOME/bin
bin と lib ディレクトリを現行パスに追加
する。
MY_PREFIX
Z
NonStop DOM システムのプロセス名に対
して固有の接頭辞を指定する。単一システ
ムで複数の NonStop DOM インストール処
理を行う場合、この環境変数によって、プ
ロセス名の競合が回避される。この変数
は、大文字 1 文字で設定してください。
1-29
第 3 章 NonStop DOM のインストールと実行
変
数
MY_COLLECTOR
デフォルト設定
"\$0"
COMP_ROOT
記
述
NonStop DOM に使用される EMS コレク
タプロセスを指定する。名前は、NonStop
Kernel 形式で定義される。システムのデ
フォルトである $0 とは異なるコレクタを
使用する場合、この行を変更してくださ
い。
使用するツール (c89 など ) があるルート
位置を指定する。システムのデフォルト以
外の場所に使用したいツールがある場合
は、この行を変更してください。
JAVA_HOME
/usr/tandem/java
NonStop DOM のパスを設定する。
NonStop Java のインストールが別の場所に
ある場合にはこの行を変更してください。
あるいは、.profile ファイルに
JAVA_HOME を設定する場合、この行を
コメントアウトしてください。(NonStop
Java は IDL コンパイラで使用されます。)
CLASSPATH
$CLASSPATH;
$NSD_ROOT/idl/nsdidl.jar
これは、NonStop DOM DOM IDL コンパ
イラに対して CLASSPATH 環境変数を設
定する。この設定では、CLASSPATH が
すでに NonStop Java に対して設定されて
いるものとしている。
PATH
$PATH:$NSD_ROOT/bin:
$COMP_ROOT/usr/lib:
現行パスに lib ディレクトリを追加する。
env.sh ファイルを注意深く読み、適切な環境変数値が設定されていることを確認することが重要で
す。ほとんどの環境変数が、NonStop DOM システムのディレクトリへの参照を設定します。上記の環境変
数のいずれかを変更して、NonStop DOM のインストールをカスタマイズすることができます。また、
.profile ファイルで対応する環境変数を設定する場合、このファイルで行をコメントにしてください。
ユーザ設定のディレクトリへのインストール
NonStop DOM をユーザ設定のディレクトリにインストールした場合、少なくとも 3 つの export 文
を変更する必要があります。これによって、NonStop DOM をインストールしたときに指定したユーザ設定
のファイル場所 ( これらは -s pax オプションで指定したファイル場所です ) を反映させることができます。
NSD_ROOT 値の代わりに、NonStop DOM インストールの新しい OSS パスを入力します。
NSD_DIR 値の代わりに、NonStop DOM SRL(Shared Runtime Library) ファイルの新しい Guardian パス
を入力します。次の形式を使用します。
/G/volume/ subvolume
1-30
140418J
第 3 章 NonStop DOM のインストールと実行
NSD_SUBVOL 値の代わりに、NonStop DOM SRL ファイルの Guardian パスを入力します。次の表記
を使用します。
$volume.subvolume
3.2.2 env.sh ファイルのソース化
NonStop DOM を構成または実行する前に、etc/env.sh スクリプトファイルをソース化して、適切
に NonStop DOM 環境を設定する必要があります。これを行うには、NonStop DOM ベースディレクトリか
ら次のような OSS シェルコマンドを実行します。
> cd etc
> . env.sh
NonStop DOM 環境設定の自動化
env.sh スクリプトを OSS の .profile ファイルに追加する場合、OSS シェルを入力するたびにス
クリプトのソース化が行われます。これによってご使用の NonStop DOM に対する環境設定が効果的に自
動化されます。
3.2.3 NonStop DOM EMS テンプレートの設定
スクリプトファイル config-ems は、ご使用の Guardian システムにインストールされた NonStop
DOM EMS ファイルを変更します。EMS テンプレートを作成しカスタマイズしたら、NonStop DOM シス
テムを使用してエラーメッセージをロギングすることができます。
EMS テンプレートの作成
NonStop DOM ソースファイルの正しいファイルコードを設定するには、次のようにして configems スクリプトを実行します。
> config-ems
スクリプトの実行後、次の手順に従って NonStop DOM EMS テンプレートファイルをカスタマイズし、
構築します。
1. ファイル
$SYSTEM.ZDOMRT20.BLDDICT で、テキストの <CHANGE_ME> を変更して、
Guardian ファイルシステムで zspiddl ファイルと zemsddl ファイルが常駐しているボリューム
およびサブボリュームの場所を指定します。
2. ファイル $SYSTEM.ZDOMRT20.BLDTMPI で、テキストの<CHANGE_ME> を変更して、Guardian
ファイルシステムで template ファイルが常駐しているボリュームおよびサブボリュームの場所を指定
します。
3. NonStop DOM EMS テンプレートを作成するには、TACL プロンプトで次のコマンドを入力します。
> OBEY $SYSTEM.ZDOMRT20.OBEYEMS
NonStop
DOM
備考 : ユーザ設定のファイル場所に
をインストールした場合、上記の手順で指定した
$SYSTEM.ZDOMRT20 をユーザ設定のファイル場所に置き換えてください。
140418J
1-31
第 3 章 NonStop DOM のインストールと実行
3.2.4 初期化スクリプトのカスタマイズ
NonStop DOM の構成データベースを初期化するには、初期化スクリプトをカスタマイズして実行しま
す。NonStop DOM の etc/ サブディレクトリにある、default.db ファイルを初期化スクリプトの
テンプレートとして使用してください。
備考 : デフォルトでは、 configure スクリプトが default.db ファイルでソース化を行い、NonStop
DOM 構成データベースを初期化します。 default.db 以外の名前を使って初期化スクリプトを作成す
る場合には、 configure スクリプトが適切なファイルをソース化することを確認してください。
初期化スクリプトをカスタマイズするには、<CHANGE_ME> タグを含んだ新規ファイルの中の 2 行を
変更します。この 2 行は、スクリプトのトップ近くにあり、次のようなスクリプト行になります。
# Set the hostname in the next line.
set hostname <CHANGE_ME>
# Set the base port in the next line. This port number and the
next two
# sequential ports will be used allocated for NSDOM 2.0.
set portnumber0 <CHANGE_ME>
set portnumber1 [expr $portnumber0 + 1]
set portnumber2 [expr $portnumber1 + 1]
<CHANGE_ME> タグは、システム固有のホスト名とポート番号を参照します。システム固有のホスト
名とポート番号に置き換えて、スクリプトを変更してください。
hostname は、NonStop DOM フレームワークを実行するホスト名を表します。システムの設定の仕
方によって、ホストのシンボリック名、ホストの実 IP アドレス、またはホストのフルシンボリック名 ( た
とえば、k2.area86@your_company.com) のいずれかを使用します。ホスト名の定義の 1 つに問
題がある場合、他の定義の 1 つを試してください。
パラメータ
portnumber0 は、この特定の構成に使用できる第 1 番目のポート番号を表します。デ
フォルトでは、スクリプトが、NonStop DOM フレームワークに対して 3 ポートを初期化します。利用可
能な最初のポート番号の値を示す、portnumber0 の値を設定する必要があります。これを設定すると、
スクリプトがこのポート番号をインクリメントして、portnumber1 と portnumber2 のスクリプト
値を得ます。この場合、スクリプトは、使用可能なポートが続き番号になっているものとみなしています。
連続したポート番号を使用できない場合、個別にこれらのポート番号を設定する必要があります。たとえ
ば、次のスクリプト例のように設定します。
set portnumber0
set portnumber1
set portnumber2
5270
5253
5134
備考 : ポ ー ト 番 号 と ホ ス ト 名 の 組 合 せ は、 ZNCA@comm_server、 ZNCB@comm_server、お よ び
lsd1@ORB の各エンティティ間で一意でなければなりません。
1-32
140418J
第 3 章 NonStop DOM のインストールと実行
TCP/IP のホスト名の指定
ホスト名を一度指定すると、スクリプトによってその名前がスクリプト内の他のシステムのエンティ
ティに割り当てられます。デフォルトでは、これらのエンティティは、2 つの Comm Server、Location
Service Daemon (LSD)、Event Service、および TCP サーバです
ホスト名が単一の IP アドレスに解決される場合、ホスト名の
<CHANGE_ME> タグの代わりにその名
前を入力できます。
ホスト名が複数の IP アドレスに解決される場合、ホスト名としてそのアドレスを使用できません。代わ
りに、単一 IP アドレスに解決されるエイリアスを使用するか、またはスクリプトに記述されている各エン
ティティの固定 IP アドレスを使用します。固定 IP アドレスのフォーマットは、
nnn.nnn.nnn.nnn になります。
ポート番号の指定
システムのホスト名を指定した後、2 つの Comm Server と Location Service Daemon (LSD) に対して静的
なポート番号を指定します。ここで唯一考慮すべきことは、指定したポート番号は、サーバの IP アドレス
空間内で他のプロセスによって使用されてはならないということです。
portnumber0 <CHANGE_ME> タグを、これらのサーバに対して使用される固定ポート番号に置き
換えます。
3.2.5 NonStop DOM システムの構成
NonStop DOM システムを構成する前に、データベースファイルの NAMINGDB と NSDCFGDB がシス
テム上にないことを確認してください。これらのファイルがシステムに存在する場合、それらは、NonStop
DOM システムの NonStop DOM Guardian サブボリュームにあります。このディレクトリのデフォルトは、
$SYSTEM.ZDOMSD20 です。
既存の
NAMINGDB および NSDCFGDB ファイルを除去する必要がある場合、unconfigure スクリプト
を実行することができます。
これで NonStop DOM システムを構成できます。OSS シェルから次のコマンドを入力して、configure ス
クリプトを実行します。
> configure
備考 : デフォルトでは、configure スクリプトが default.db ファイルをソース化して、NonStop DOM
構成データベースを初期化します。configure スクリプトを実行する前に、スクリプトに含まれている
カスタマイズした初期化スクリプトの名前が正しいことを確認してください。
configure スクリプトを実行すると、以下の出力に類似したものが出力されます。
configure コマンドの実行
> configure
cfgmgt initialization Completed
LSD initialization Completed
Initializing Naming Service.
140418J
1-33
第 3 章 NonStop DOM のインストールと実行
Creating POA for Naming Contexts.
Initializing Naming Database.
Creating Root Naming Context IOR.
Root Naming Context IOR saved to config database.
Naming Service initialization complete.
この実行手順が動作したことを確かめるには、NonStop DOM フレームワークの Guardian サブボリュー
ムに新しく作成された
NAMINGDB および NSDCFGDB データベースが存在していることをチェックし
ます。
警告 : NonStop DOM システムの構成データベースを再作成および再構成する必要がないかぎり、configure
スクリプトを再実行しないでください。
3.2.6 NonStop DOM PATHMON プロセスのカスタマイズ
NonStop DOM は PATHMON プロセスのもとで実行されます。PATHMON プロセスを起動および構成
nsdstart スクリプトを使用します。デフォルトにより、configure スクリプトが次のプ
ロセスを起動します。
するには
起動されるサーバ
( 括弧内はサーバ数 )
起動
CPU 数
デフォルトの
プロセス名
Comm Server (2)
1∼2
$ZNCA
$ZNCB
コメント
新しい Comm Server は最後の文字がインクリメン
トされて、$ZNCA ∼ $ZNCZ がそれらの Comm
Server に指定される。
最大 26 までの Comm Server が可能。
Event Service (1)
1∼2
Name Service (2)
Maxservers は 4
1∼3
$ZND0
新しい Name Service には生成された名前が指定さ
れる。
nsdstart スクリプトは、0 から 3 の CPU がシステムで使用できるものと想定してい
ます。システム構成がこれとは異なる場合、実際のセットアップに合致するように nsdstart スクリプ
デフォルトの
トを変更する必要があります。
スクリプトを変更する場合、次の手順に従います。
1. スクリプトファイル nsdstart に、書込み許可を与えます。
2. スクリプトの cpu エントリを変更して、構成される CPU の数を変更します。
3. サーバクラス CS(Comm Server) の maxservers の数を増やした場合、スクリプト内での続くエント
リの名前が連続しており、各 Comm Server の対応するエンティティが構成データベースに存在してい
ることを確認します。
備考 : NonStop DOM プロセス名の第 1 文字は、環境変数
定されています。デフォルトの設定値は Z です。
1-34
$MY_PREFIX を使用して env.sh ファイルで設
140418J
第 3 章 NonStop DOM のインストールと実行
3.3 NonStop DOM の開始と停止
サブトピックス
□ NonStop DOM システムの開始
□ NonStop DOM システムの停止
3.3.1 NonStop DOM システムの開始
「クイック構成」で説明したように構成スクリプトをカスタマイズした後、nsdstart スクリプトを実
行して、NonStop DOM システムのプロセスを開始することができます。
nsdstart スクリプトを実行することによって、NonStop DOM システムを制御する PATHMON シス
テムの起動および構成を行います。
デフォルトでは、このスクリプトは、システムに搭載されている使用可能な CPU 数 は 0 ∼ 3 であると
想定しています。このセクションに出てくるスクリプトのカスタマイズについては、
「NonStop DOM
PATHMON プロセスのカスタマイズ」のセクションを参照してください。
NonStop DOM システムを開始するには、OSS シェルで次のコマンドを実行します。
> nsdstart
$ZNDM PATHMON プロセスが存在していることをチェックすることによって、この手順が動作したこ
とを検証できます。このプロセスを表示するには、次のコマンドを実行します。
> PATHCOM $ZNDM
デフォルトのスクリプトを使用すると、次の例に類似した出力が得られます。
例 1. PATHCOM $ZNDM スクリプトによるデフォルトの出力
$X8HA: PATHCOM - T8344D44 - (05MAY97)
COPYRIGHT TANDEM COMPUTERS INCORPORATED 1980 - 1985, 1987 - 1997
=STATUS SERVER *
SERVER #RUNNING ERROR INFO
CS 2
ES 1
LSD 1
NS 4
=
エラーが発生した場合 ( たとえば、1 または複数の NonStop DOM サーバが正しく起動しない場合 )、次
の表にリストされているファイルをチェックしてください。
140418J
1-35
第 3 章 NonStop DOM のインストールと実行
表 1-8 NonStop DOM STDOUT、STDERR、および トレースファイル
ログファイル
プロセス
etc/cs.log
Comm Server STDOUT、STDERR、および トレースファイル
etc/es.log
Event Service STDOUT、STDERR、および トレースファイル
etc/lsd.log
Location Service Daemon STDOUT、STDERR、およびトレースファイル
etc/ns.log
Naming Service STDOUT および STDERR ファイル
<STDOUT>
トレースファイル
3.3.2 NonStop DOM システムの停止
NonStop DOM セッションを終了するには、次のコマンドを使用して nsdstop スクリプトを実行しま
す。
> nsdstop
このコマンドは、NonStop DOM システムを実行させる PATHMON プロセスを終了させ、NonStop DOM
アプリケーションサーバが実行されている ORB をシャットダウンします。このスクリプトをいったん実行
すると、アプリケーションサーバにリモートクライアントのリクエストを受け取らせたい場合は、NonStop
DOM システムを再始動する必要があります。
1-36
140418J
第 4 章 サンプルプログラムの実行
第 4 章 サンプルプログラムの実行
4.1 スタック例の実行
サブトピックス
□ スタック例の概要
□ スタック例の構築
□ スタック例の実行
NonStop DOM をインストールし (「NonStop DOM のインストール」参照 )、「クイック構成」によって
実行した後、単純な CORBA プログラムを実行することによって、NonStop DOM システムの操作をテス
トすることができます。
スタック例は、ご使用のシステムのテストに役立ちます。スタック例は単純ではあっても、C++ で実装
されているクライアントとサーバの両方を含んだ CORBA プログラムを動作します。
このトピックでは、スタック例の実行に必要な手順を示して、その実行を見ていきます。プログラムの
動作に関する詳細は、example ディレクトリにある ReadMe ファイルを参照してください。
4.1.1 スタック例の概要
スタック例は、NonStop DOM インストールの samples/stack サブディレクトリにあります。この
ディレクトリにある
README ファイルで、このプログラムの動作方法、および example に含まれている
他のファイルの機能について説明しています。
4.1.2 スタック例の構築
スタック例には、Makefile というファイルが含まれています。このファイルを使用することによっ
て、NonStop DOM 上にスタックのサンプルを構築することができます。Makefile は、実行可能コンポー
ネントを構築するのに必要な全ステップを実行します。Makefile で使用されるマクロは、
etc/macros.mk で定義されています。
サンプルを構築するには、次の手順を実行します。
1. NonStop DOM インストールの samples/stack ディレクトリにいることを確かめます。または
ファイルを新しいディレクトリにコピーします。
2. env.sh スクリプトをソース化したことを確かめます。env.sh スクリプトによって必要な環境変数が
設定されます ( このファイルのカスタマイズとソース化については「クイック構成」を参照してくださ
い )。
3. 次のコマンドを使用して、make スクリプトを実行します。
make
140418J
1-37
第 4 章 サンプルプログラムの実行
Makefile スクリプト
Makefile スクリプトを実行すると、このスクリプトは以下の処理を行います。
□ NonStop DOM IDL コンパイラを使用して、stack.idl に含まれているインタフェースを処理する。
□ サーバコンポーネントをコンパイルするために、C++ コンパイラを使用してサーバ実行可能ファイルを
構築する。
□ サーバコンポーネントを構築するために、C++ コンパイラを使用してクライアント実行可能ファイルを
構築する。
NonStop DOM IDL コンパイラ (NSDIDL) は stack.idl を入力として、次の 4 ファイルを作成します。
□
stack_client.h
□
stack_client.cpp
□
stack_server.h
□
stack_server.cpp
これらのファイルの内容を表示したり、それを理解する必要はありません。単純にそれらを置くだけで、
それらにはインタフェース定義の、CORBA 指定の C++ 言語マッピングの変換処理が含まれています。ク
ライアントプログラムは、stack_client コンポーネントを使用して、クライアントインタフェース
を実装します。また、サーバプログラムは、stack_server コンポーネントを使用して、サーバイン
タフェースを実装します。
4.1.3 スタック例の実行
スタック例を実行する前に、ご使用になっている特定のシステムに対してスタックサーバを構成する必
要があります。それには、スタックサーバの構成スクリプト config.src を編集し、次にソース化を行
います。以下の手順に従います。
1. config.src ファイルを編集して、<CHANGE_ME> 値を有効な tcp ホスト名またはアドレスに変更しま
す。
2. Configuration Tool を使用して、スタックサーバの構成スクリプトをソース化します。それには、OSS
プロンプトおよび Configuration Tool プロンプトで以下のコマンドを実行します。
> cfgmgt
> source config.src
> exit
これらのコマンドが、sample_stack@ORB エンティティをロードします。
これでスタック例を構築し構成したので、トライアルを実行することができます。ただし、スタック例
の実行前に、トピック「NonStop DOM の開始と停止」の説明に従って NonStop DOM システムを起動して
ください。
1-38
140418J
第 4 章 サンプルプログラムの実行
スタック例を実行するには、2 つの OSS ウィンドウを開きます。ウィンドウの 1 つはプログラムのクラ
イアント部分、もう 1 つはサーバ部分です。どちらのウィンドウでも、構築されたスタックサンプルが置
かれているディレクトリに移動します。通常、このディレクトリは、NonStop DOM インストールの
samples/stack サブディレクトリです。プログラムの実行前に、各ウィンドウに正しい NonStop DOM
環境が適切に装備されていることを確認してください。この環境は、前述したように、env.sh スクリプ
トをソース化することによって得られます。
次のコマンドを使って、一方のウィンドウでサーバプログラムを開始します。
server -ORBprofile sample_stack
もう一方のウィンドウでクライアントプラグラムを開始します。
client
クライアントプログラムを開始すると、クライアントウィンドウに次のような出力が表示されます。
例 1. スタック例の出力
Top: 100
Top: 200
Top: 300
Top: 400
Top: 500
Top: 600
Top: 700
Top: 800
Top: 900
Top: 1000
Got STACK_OVERFLOW exception as expected.
Pop: 1000
Pop: 900
Pop: 800
Pop: 700
Pop: 600
Pop: 500
Pop: 400
Pop: 300
Pop: 200
Pop: 100
Got STACK_UNDERFLOW exception as expected.
プログラムの詳細については、このトピックの対象外であり、ここでは説明しません。上記のような出
力が表示されれば、NonStop DOM システム上でスタック例の構築および実行が成功したとお考えください。
これで、ご使用の NonStop DOM システムで CORBA クライアントおよびサーバの開発を開始すること
ができます。
上記のような出力が表示されなかった場合、何か問題が生じています。NonStop DOM のインストール
および構成が適切でなかったり、またはサンプルプログラムが正しく実行されなかったかのどちらかです。
問題を予想するのは難しいことですが、PATHCOM を使用して NonStop DOM のサーバプールプロセスの
状態を表示することによって、プロセスのデバッグを開始できます。
140418J
1-39
索 引
索 引
（英数字）
C
COBRA
概要
1-7
I
IDL コンパイラ
概要 1-17
IIOP プロトコルサポート 1-17
N
NonStop DOM
概要 1-13
スクリプトの開始と停止
特徴と機能性
ハードウェア要件
利点
1-35
1-17
1-19
1-13
ソフトウェア要件
1-19
P
POA (Portable Object Adapter)
概要 1-18
（五十音順）
か
開始と停止、NonStop DOM
可用性と耐障害性
1-35
1-16
す
スケーラビリティ
ORB
1-15
アプリケーションサーバプロセス
1-15
ふ
分散オブジェクトコンピューティングの概要 1-7
ま
マニュアル
表記規約 1-5
マニュアルの概要
140418J
1-1
1-41
第2部
NonStop™ DOM
管理者ガイド
概要
このマニュアルでは、NonStop™ Distributed Object Manager/MP (NonStop™
DOM) の構成と管理に必要な情報について概略します。
製品バージョン
NonStop™ DOM/PM、バージョン 2.0
リリース ID
Independent Product
マニュアル番号
138122J
発行日
2000 年 2 月
Document History
Edition
Part Number Product Version Earliest Supported Release Published
First
Second
Third
Fourth
127557
131054
138003
134268
D40
D41
D41
D42
November 1996
January 1997
October 1997
November 1997
New editions incorporate any updates issued since the previous edition.
A plus sign(+) after a release ID indicates that this manual describes function added to the
base release, either by an interim product modification(IPM) or by a new product version on
a .99 site update tape(SUT).
140418J
-1
目 次 目 次
目 次
第1章
NonStop DOM のアーキテクチャ
1.1 NonStop DOM アーキテクチャ ............................................................................................. 2-1
1.1.1 NonStop DOM の概要 .................................................................................................. 2-1
1.1.2 NonStop DOM フレームワーク................................................................................... 2-2
1.1.3 NonStop DOM ORB (Object Request Broker）............................................................ 2-4
1.1.4 NonStop DOM CORBA サービス ............................................................................... 2-6
1.1.5 NonStop TS/MP Process Management ......................................................................... 2-7
1.1.6 NonStop DOM フレームワークデータベース ............................................................ 2-8
1.1.7 NonStop DOM 伝送プロトコル................................................................................... 2-9
第2章
NonStop DOM システムの構成
2.1 NonStop DOM の構成........................................................................................................... 2-13
2.1.1 構成アーキテクチャ .................................................................................................. 2-13
2.1.2 NonStop DOM スクリプトファイル ......................................................................... 2-14
2.1.3 環境変数と env.sh のセットアップ ........................................................................... 2-16
2.1.4 スクリプトファイルの構成 ....................................................................................... 2-16
2.1.5 構成データベース ...................................................................................................... 2-17
2.1.6 初期化スクリプト ...................................................................................................... 2-18
2.1.7 NonStop DOM フレームエンティティ ..................................................................... 2-19
2.1.8 エンティティ作成 ...................................................................................................... 2-20
2.1.9 既存のエンティティファイルの削除 ........................................................................ 2-21
2.1.10 デフォルト NonStop DOM エンティティ ................................................................ 2-21
2.1.11 NonStop DOM フレームワーク構成の削除 ............................................................. 2-25
2.2 Configuration Tool の使用 .................................................................................................... 2-25
2.2.1 構成ツールの概要 ...................................................................................................... 2-25
2.2.2 構成ツール構文 .......................................................................................................... 2-26
2.2.3 構成ツールコマンド .................................................................................................. 2-27
2.2.4 構成ツールの実行例 .................................................................................................. 2-29
i
140418J
目 次
第3章
NonStop DOM のランタイム管理
3.1 分散オブジェクト環境の管理 ...............................................................................................2-33
3.1.1 分散オブジェクト環境 ...............................................................................................2-33
3.1.2 NonStop DOM のフレームワーク構成管理 ..............................................................2-34
3.1.3 NonStop DOM のフレームワークパフォーマンス調整 ...........................................2-34
3.1.4 NonStop DOM フレームワークのトラブルシューティング....................................2-35
3.1.5 必要な予備知識 ...........................................................................................................2-35
3.2 アプリケーションプロセス管理 ...........................................................................................2-36
3.2.1 アプリケーション環境 ...............................................................................................2-37
3.2.2 アプリケーション構成管理 ........................................................................................2-37
3.2.3 アプリケーションサーバの拡張 ................................................................................2-38
3.2.4 アプリケーションパフォーマンスの調整 .................................................................2-41
3.2.5 アプリケーションのトラブルシューティング .........................................................2-41
3.2.6 必要な予備知識 ...........................................................................................................2-41
第4章
NonStop DOM サーバプールの構成
4.1 NonStop TS/MP プロセスの起動と停止 ..............................................................................2-43
4.1.1 PATHMON プロセスについて ..................................................................................2-43
4.1.2 スクリプトを使用した NonStop TS/MP の起動と停止 ............................................2-44
4.1.3 nsdstart スクリプトの使用..........................................................................................2-45
4.1.4 nsdstop のスクリプトの使用 ......................................................................................2-49
4.2 PATHCOM インタフェース を使用して NonStop TS/MP プロセスを維持するには ......2-49
4.2.1 PATHCOM インタフェースの使用 ...........................................................................2-50
4.2.2 プロセスの起動と再起動 ............................................................................................2-50
4.2.3 ステータスの監視 .......................................................................................................2-51
4.2.4 変更要件に基く基本パラメータの修正 .....................................................................2-56
4.2.5 サーバプールの再構成 ...............................................................................................2-57
4.3 サーバプールの PATHMON プロセスへの割当て ..............................................................2-58
4.3.1 nsdstart の編集によるサーバプロセスの追加 ...........................................................2-59
4.3.2 nsdstart の編集による Comm Server プールプロセスの削除 ...................................2-60
4.4 NonStop TS/MP パフォーマンスの注意点 ...........................................................................2-61
4.4.1 ダイナミックおよびスタティックアプリケーションサーバプロセスの構成 ........2-61
4.4.2 Comm Server プロセス間でのクライアント要求ロードバランシング ...................2-62
140418J
ii
目 次 4.4.3 ステートフルおよびステートレスサーバプロセスの使用...................................... 2-62
4.5 アプリケーションサーバプロセスのロードバランシング ................................................ 2-62
4.5.1 キーとなるサーバ構成パラメータ ............................................................................ 2-63
4.5.2 CPU への処理の明示的割当て .................................................................................. 2-66
4.5.3 NonStop TS/MP アプリケーションサーバのリンク管理 ........................................ 2-67
第5章
NonStop DOM 構成ファイル
5.1 env.sh ソースファイル.......................................................................................................... 2-69
5.1.1 env.sh ソース .............................................................................................................. 2-69
5.2 default.db ソースファイル .................................................................................................... 2-70
5.2.1 default.db ソース ........................................................................................................ 2-70
5.3 構成ソースファイル ............................................................................................................. 2-72
5.3.1 configure ソース ......................................................................................................... 2-72
5.4 nsdstart ソースファイル ....................................................................................................... 2-73
5.4.1 nsdstart ソース ............................................................................................................ 2-73
5.5 nsdstop ソースファイル ........................................................................................................ 2-78
5.5.1 nsdstop ソース ............................................................................................................ 2-78
5.6 unconfigure ソースファイル................................................................................................. 2-78
5.6.1 unconfigure ソース ..................................................................................................... 2-78
索 引
図
iii
図 2-1
CORBA (Common Object Request Broker Architecture) ................................................ 2-2
図 2-2
NonStop DOM フレームワークの詳細 ........................................................................... 2-3
図 2-3
NonStop DOM フレームワークの構成 ......................................................................... 2-14
図 2-4
NonStop DOM ランタイムコンポーネント .................................................................. 2-33
図 2-5
NonStop DOM アプリケーションコンポーネント ...................................................... 2-37
図 2-6
MAXLINKS = 1、LINKDEPTH = 適用不可 の場合の結果 ........................................ 2-64
図 2-7
MAXLINKS=2、LINKDEPTH=1 の場合の結果 ......................................................... 2-65
図 2-8
MAXLINKS=2、LINKDEPTH=2 の場合の結果 ......................................................... 2-66
140418J
目 次
表
表 2-1
140418J
PATHCOM コマンド ......................................................................................................2-51
iv
第 1 章 NonStop DOM のアーキテクチャ
第 1 章 NonStop DOM のアーキテクチャ
1.1 NonStop DOM アーキテクチャ
サブトピックス
□ NonStop DOM の概要
□ NonStop DOM フレームワーク
□ NonStop DOM ORB (Object Request Broker)
□ NonStop DOM CORBA サービス
□ NonStop TS/MP Process Management
□ NonStop DOM フレームワークデータベース
□ NonStop DOM 伝送プロトコル
1.1.1 NonStop DOM の概要
NonStop DOM 製品は、NonStop Kernel システムプロセスで構成され、これらのプロセスには CORBA
準拠の ORB (Object Request Broker)、CORBA サービス、アプリケーション開発環境、および特殊なツー
ルとユーティリティが含まれます。
NonStop DOM では、C++ プログラミング言語を使用して CORBA 準拠のクライアントアプリケーショ
ンおよびアプリケーションサーバを記述します。作成した NonStop DOM クライアントおよびサーバは
Tandem NonStop Kernel で実行され、それらは互いに相互接続したり、異機種ネットワーク間で他の
CORBA 準拠のアプリケーションと相互接続することが可能です。IIOP (Internet InterORB Protocol) を利用
することで、CORBA 準拠のリモートクライアントはインターネットを介して NonStop DOM アプリケー
ションサーバと対話することができます。
NonStop DOM システムは、ORB の基盤として、CORBA 準拠の ORB および CORBA サービスから成
るシステムプロセスを実装します。NonStop DOM システムでは、これらのプロセスを、Tandem のプロセ
ス管理製品である NonStop TS/MP のもとで実行するサーバプロセスとして実装します。単一の NonStop
TS/MP モニタプロセスによって、すべての NonStop DOM システムプロセスが管理されます。これらのプ
ロセスには、Naming Service や Event Service などの OMG (Object Management Group) 指定のサービスが
含まれます。
NonStop DOM アプリケーションは、ORB 間の通信に NonStop DOM を使用するクライアントおよび
サーバアプリケーションから成ります。NonStop DOM システムプロセスのような、NonStop TS/MP プロ
セスのもとで実行する自分の NonStop DOM アプリケーションサーバを構成することをお勧めします。パ
フォーマンスおよび管理のしやすさに対して、作成したアプリケーションサーバをサポートしている
NonStop TS/MP プロセスは、NonStop DOM システムを実行しているものとは異なります。
NonStop DOM アプリケーション開発ツールは、主に、IDL (Interface Definition Language) コンパイラと
SRL (Shared Runtime Library) になります。補助ツールを使用して、Naming Service データベースの検索と
140418J
2-1
第 1 章 NonStop DOM のアーキテクチャ
管理、NonStop DOM 構成データベースの管理と保守、およびイベントチャネルの監視を行うことができま
す。
1.1.2 NonStop DOM フレームワーク
NonStop DOM システムは、CORBA 2.0 準拠の ORB を実装します。この ORB は、すべての OMG ORB
が使用している高水準レイアウトを使用します。図 2-1 を参照してください。
図 2-1 CORBA (Common Object Request Broker Architecture)
図 2-1 は、
どのようにしてクライアントプログラムが SII (Static Invocation Interface ) または DII (Dynamic
Invocation Interface) を介して ORB 間 でアプリケーションサーバ ( 図中の「オブジェクト実装」) と通信す
るのかを図示しています。ORB がクライアントの要求をマーシャル化し、サーバサイドでそれらをマー
シャル形式から復元します。サーバサイドでは、ORB が POA (Portable Object Adapter) を使用して、要求
を適切なアプリケーションサーバに渡します。
図 2-2 は、どのようにして NonStop DOM システムがクライアントとサーバに接続するかを図示してい
ます。図を見ると、NonStop DOM システムを実行するシステムに対してクライアントはローカルでもリ
モートでも可能であることがわかります。図では、NonStop DOM システムに含まれている主要コンポーネ
ントを詳しく記述しています。これらのコンポーネントには、Comm Server、Location Service Daemon、
Naming Service、Event Service があります。NonStop DOM アプリケーションサーバ (C++ で作成したサー
バ ) は、NonStop TS/MP サーバプールとして実装するか、またはスタンドアロンのサーバプロセスとして
実装することができます。
2-2
140418J
第 1 章 NonStop DOM のアーキテクチャ
図 2-2 NonStop DOM フレームワークの詳細
NonStop DOM システムは、特殊な通信コンポーネントを使用して、アプリケーションクラアイントと
オブジェクトサーバ間の通信を実現します。この特殊な通信コンポーネントが、Comm Server と Location
Service Daemon (LSD) です。
CORBA 準拠の ORB として、NonStop DOM システムは異機種ネットワーク間を通信することができま
す。さらに、NonStop DOM システムは、Naming Service、Event Service、Transaction Service といった他
の OMG サービスも実装します。アプリケーションクライアントとオブジェクトサーバはいずれも、これ
らの CORBA サービスを使用できます。
140418J
2-3
第 1 章 NonStop DOM のアーキテクチャ
1.1.3 NonStop DOM ORB (Object Request Broker）
NonStop DOM ORB 間の通信は、以下に示す NonStop DOM システムプロセスによってサポートされて
います。
□ Location Service Daemon (LSD)
□ Comm Server
これらのコンポーネントは、要求と応答を適切なオブジェクトまたはクライアントに確実に渡します。
また、これらのコンポーネントは、接続リソースの再利用、オブジェクトへのアクセスを実現し、システ
ム固有の通信を使用・管理するインフラストラクチャも提供します。
セクション「接続の確立」で、これらのコンポーネントがどのようにクライアントとアプリケーション
サーバ間の接続を処理するのか詳しく説明します。
備考 : これらの NonStop DOM システムプロセスは、クライアントとサーバの対話に対して透過的です。CORBA
2.0 準拠のクライアントは、他の CORBA 準拠の ORB で要求するのとまったく同じように、NonStop DOM
アプリケーションサーバに対して要求することができます。ORB のユーザと NonStop DOM アプリケー
ションの開発者からは、LSD と Comm Server の使用は見えず、完全に隠されています。
Location Service Daemon (LSD)
Location Service Daemon (LSD) は 2 つの機能を持ちます。まず第 1 に、それは外部クライアントの初期
接続に対するエントリポイントとして動作します。そして第 2 に、外部クライアントを Comm Server に
ロードバランシング ( またはマッピング ) します。LSD は、NonStop DOM の Comm Server とともに動作
して、サーバをクライアントの要求に割当てます。
リモートクライアントが NonStop DOM アプリケーションサーバへの接続を要求すると、その要求はま
ず LSD にいきます。LSD は最もビジーでない Comm Server の TCP/IP アドレスとポートを返します。次
に、Comm Server が、クライアントと NonStop DOM アプリケーションサーバとの間で要求と応答の受け
渡し ( ルーティング ) を行います。
LSD が Comm Server を選択する際の支援となるように、データベース (CSMAP と呼ばれる ) にはリモー
トクライアントのホストと Comm Server プロセス間の関連付けが格納されています。
LSD は CSMAP をチェックし、サーバアドレスを返します。クライアントはこのサーバアドレスを使用
して、NonStop DOM システムにアクセスします。ロケーションは、TCP/IP アドレスとポート番号のペア
であり、通常、Comm Server のロケーションを指します。そのポイントから、Comm Server は クライアン
トと NonStop DOM アプリケーションサーバ間の要求と応答の受け渡し ( ルーティング ) を行います。
クライアントの要求を処理する Comm Server を特定するために、LSD は CSMAP をチェックして、構
成済みの Comm Server プロセスにリモートクライアントのホストがマッピングされているかどうかを判定
します。LSD が関連付けを見つけると、Comm Server のアドレス情報が返されます。リモートクライアン
トのホストが CSMAP に登録されていない場合、LSD は 動的割当てに対して構成された Comm Server を
チェックし、このグループから、現在割当てられている負荷に基づいて Comm Server を選択します。その
結果、LSD は、選択した Comm Server の TCP/IP アドレスとポート番号を戻します。
また、LSD の TCP/IP アドレスも構成データベースに登録されています。このアドレスが、NonStop DOM
ORB を介して要求を行うクライアントの最初の接続ポイントです。
2-4
140418J
第 1 章 NonStop DOM のアーキテクチャ
Comm Server
NonStop DOM Comm Server は、リモートクライアントと NonStop DOM サーバとの通信を可能にする
ルータです。NonStop DOM は、1 つまたは複数の Comm Server を使用して、リモート CORBA クライア
ントとローカル NonStop DOM アプリケーションサーバプロセスとの間のルーティングを行います。これ
によって、クラアイントは、単一のポートを使用して任意の数のアプリケーションサーバにアクセスする
ことが可能になります。
ORB プラットフォームのなかには、クライアントが、接続する各サーバのそれぞれに対して個別のポー
ト番号を使用しなければならないものもあります。この動作によって、一度に ORB に接続できるリモート
クライアントの数が劇的に制限される可能性があります。
NonStop DOM システムでは、Comm Server を使用してリモートクライアントが単一の Comm Server プ
ロセスに接続することが可能です。リモートクライアントは、この Comm Server プロセスを通じて、シス
テム上のどの NonStop DOM アプリケーションサーバにでもアクセスすることができます。各クライアン
トが各アプリケーションサーバに直接接続するのではなく、Comm Server を通して通信することによって、
ネットワークリソースの消費を減らし、システムのパフォーマンスを大幅に改善します。Comm Server を
通して通信しないと、多数のクライアントがサーバリソースを要求する場合には、パフォーマンスに悪い
影響を及ぼす可能性があります。
NonStop TS/MP とともに Comm Server を使用すると、リモートクライアントは単一のポートレベルで
のネットワーク接続 (Comm Server との ) を維持しながら、NonStop TS/MP によって、サーバプールとし
て構成されているアプリケーションサーバプロセス間でロードバランシングが行われます。単一の Comm
Server プロセスは多数のリモートクライアントを同時に処理しますが、アプリケーションのロードが増大
するにともない、追加の Comm Server プロセスを構成することもできます。
リモートクライアントの要求をルーティングする機能に加え、Comm Server はまた、ローカルクライア
ントの要求をリモートサーバにマッピングします。ローカル NonStop DOM クライアントがリモート
NonStop DOM サーバ ( または、他の CORBA 準拠のサーバ ) にアクセスしようとすると、Comm Server は
クライアントの要求を Tandem ファイルシステムプロトコルから CORBA IIOP プロトコルに透過的にマッ
ピングします。
接続の確立
NonStop DOM システムの通信コンポーネント (LSD と Comm Server) は、クライアント要求と、その要
求を処理するアプリケーションサーバとの間の接続を実現します。CSMAP を使用することによって、
NonStop DOM システムは、確実に最もビジーでないアプリケーションサーバがクライアント要求を受け取
るようにします。
LSD のアドレスは「周知」になっています。このことは、クライアントがこのコンポーネントと直接対
話できるように、Naming Service が LSD の TCP/IP アドレスを発行していることを意味します。これによ
り、LSD は、サービスを要求する全クライアントと NonStop DOM で使用可能なオブジェクトに対する初
期接続ポイントとなります。
LSD の役割は、クライアントの要求を適切にルーティングすることです。LSD は、要求の種類によっ
て、それを Comm Server に割当てるか、または直接アプリケーションサーバに割当てます。Comm Server
に接続することによって、NonStop DOM システムは、NonStop TS/MP サーバプールとして構成されてい
るアプリケーションサーバを利用することができます。
LSD は要求のオブジェクトキーを調べることによって、要求が永続か非永続かを特定します。要求が非
永続の場合、それはダイレクト TCP サーバを介して処理することができます。NonStop DOM システムに
140418J
2-5
第 1 章 NonStop DOM のアーキテクチャ
使用可能なダイレクト TCP サーバが含まれている場合は、LSD はそのサーバの TCP/IP アドレスを返しま
す。クライアントは、要求の持続期間の間そのダイレクトサーバと直接通信することができます。( 使用可
能なダイレクト TCP サーバがない場合、LSD は要求を使用可能な Comm Server にルーティングします。)
要求が永続の場合、LSD は Comm Server の TCP/IP アドレスを返します。この Comm Server がクライアン
トの要求を処理します。
要求のルーティング
使用可能なアプリケーションサーバと Comm Server を特定するために、LSD は、構成データベースに含
まれている CSMAP テーブルを使用します。この CSMAP テーブルが load_table と map_table です。ダイ
レクト TCP サーバの可用性を判定するのは難しくありません。LSD はまず、map_table をチェックし
て、サーバが NonStop DOM システムで構成されているかどうかを調べます。ダイレクト TCP サーバが存
在する場合、load_table をチェックして、そのサーバの可用性を調べます。このプロセスは、ダイレ
クト TCP サーバが割当てられるまで、または LSD が要求の処理に Comm Server を割当てることを決定す
るまで繰返されます。
プロセスは、永続要求の通信を確立する場合と似ています。LSD は
map_table と load_table
をチェックして、要求の処理に最適な Comm Server を特定します。Comm Server が一度特定されると、そ
のサーバは、該当するクライアントによって作成された残りの要求をすべて処理します。
永続要求を解決するとき、LSD は最初に map_table を調べて、クライアントの TCP/IP アドレスが
すでに Comm Server に割当てられているかどうかをチェックします。クライアントが Comm Server に割
当てられていた場合、LSD は Comm Server の TCP/IP アドレスを返します。クライアントは、要求の持続
期間の間そのアドレスを使用することができます。
クライアントに関連付けられている Comm Server が map_table のリストにない場合、LSD は
load_table を使用して、Comm Server を要求に割当てます。LSD は、構成済みの Comm Server 間を
循環するラウンドロビンアルゴリズムで現在の負荷に基づいて Comm Server を選択します。選択された
Comm Server は、 map_table でクライアントと関連付けられます。これによって、今後発生するクラ
イアント要求が適切に処理されることになります。
複数の構成済み Comm Server を装備する大規模なシステムでは、Configuration Tool を使用してクライ
map_table に追加して、固定的にクライアントを特定の
Comm Server にルーティングすることができます。これは高度な技術ではあっても、特別に注意を要する
タスクを抱えている場合に利用できます。
アントと Comm Server の関連付けを直接
1.1.4 NonStop DOM CORBA サービス
NonStop DOM 2.0 は、次のような CORBA サービスを今回のリリースで実装しています。
□ Naming Service
□ Event Service
□ Transaction Service
今後のリリースでさらに多くのサービスが提供される予定です。
Naming Service
NonStop DOM Naming Service は、OMG COS CORBA Naming Service 仕様の完全な実装であり、CORBA
2-6
140418J
第 1 章 NonStop DOM のアーキテクチャ
2.0 に完全に準拠しています。Naming Service は、NonStop DOM アプリケーションオブジェクトの名前と
位置のリポジトリを提供します。
開発者は、Naming Service を使用して、実行時にオブジェクト名を登録することができます。Naming
Service のデータベースでは、ネーミングコンテキストとそれらに関連付けられたオブジェクト参照が階層
的な名前空間に編成されています。クライアントアプリケーションは、Naming Service を使用して、ネー
ミングコンテキストの階層を検索することによって使用したいオブジェクトの名前とオブジェクト参照を
検出することができます。
NonStop DOM Naming Service は、Tandem の Transactional Service と Transactional Management に完全
かつ透過的に統合されています。その結果、Naming Service は、完全にスケーラブルで信頼性が高く、高
パフォーマンスを実現します。
Naming Service は、Naming Server 実行可能プログラム ( サーバプールとして配布されている ) とその
個々の Naming Service データベースで構成されています。Naming Server は、ネーミングデータベースを
キー順 Enscribe ファイルで保守します。アプリケーションは、Naming Service への CORBA 定義のオブ
ジェクトインタフェースを使用して、名前をオブジェクトにバインドし、それらを検出することができま
す。
Event Service
NonStop DOM の Event Service は、OMG CORBA Events Service 仕様の完全な実装であり、CORBA 2.0
に完全に準拠しています。Event Service は、CORBA オブジェクト間の非同期通信を提供します。
Event Service を使用することによって、
「供給者オブジェクト」はイベントチャネルを介して通信し、任
意の数の「消費者オブジェクト」に対してそれらが「サブスクライブする」イベントの発生を通知するこ
NonStop DOM Event Service は、Tandem の Transactional Service と Transactional Management
とができます。
に完全かつ透過的に統合されています。その結果、Event Service は、完全にスケーラブルで信頼性が高く、
高パフォーマンスを実現します。
Event Service は、Event Server 実行可能プログラムで構成され、またサーバプールとして配布されます。
Event Server は、そのデータベースをキー順 Enscribe ファイルで保守します。アプリケーションは、Event
Service への CORBA 定義のオブジェクトインタフェースを使用して、Event Server 上にオブジェクトを生
成します。
Transaction Service
NonStop DOM は、OMG 指定の Transaction Service をアドオン製品として提供しています。OTS (Object
Transaction Service) として実装されている、Transaction Service は、オブジェクト指向のトランザクション
処理システムです。Tandem の立証済みのスケーラブルかつ信頼性の高い、大規模なトランザクション管
理・サービスのインフラストラクチャを利用することによって、アプリケーションプロバイダは、トラン
ザクションサービスの ACID プロパティを完全にサポートする高信頼のオブジェクトを提供することがで
きます。
1.1.5 NonStop TS/MP Process Management
NonStop DOM のシステムプロセス (LSD、Comm Server、Naming Server、Event Server) は、NonStop
TS/MP (NonStop Transaction Services/MP) を実行するサーバプールとして提供されています。NonStop TS/
MP プロセスは、スケーラビリティと耐障害性を実現します。
140418J
2-7
第 1 章 NonStop DOM のアーキテクチャ
単一の NonStop TS/MP モニタプロセスは、すべての NonStop DOM システムプロセスを管理します。
NonStop DOM システムプロセスを NonStop TS/MP サーバプールとして構成することによって、次のよう
な NonStop TS/MP としての有効な利点を得ることができます。
□ NonStop DOM システム構成の属性の一部を、一貫した、既知の、安全性の高い環境で保守する ( 他の
構成属性は、構成データベースで維持される )。
□ すべての NonStop DOM プロセスの構成と自動起動を管理する。これには Comm Server の複数のイン
スタンスの構成と開始が含まれる。
□ プロセスの永続性を実現し、異常終了となったサーバの新規コピーを自動的に再起動する。異常終了に
なるケースには、たとえば、サーバが ABEND を呼び出したリ、CPU 障害が発生する場合などがある。
Tandem では、NonStop Kernel 上で 実行する基幹の NonStop DOM アプリケーションサーバプロセスも
また NonStop TS/MP サーバプールとして構成することを強くお勧めします。NonStop TS/MP が NonStop
DOM システムに対して提供している利点に加え、NonStop TS/MP はアプリケーションサーバプロセスに
も次のようなメリットを与えます。
□ TCP/IP 接続を介して要求が送信されると、NonStop TS/MP は、クライアントの要求が着信したときに
何も実行されていなければ自動的にサーバプロセスを起動する。
□ すべてのサーバプールにまたがるスケーラビリティをサポートする。
□ 動的なロードバランシングを提供する。PATHMON プロセスが、サーバの需要増大に対応するために、
サーバプロセスの追加コピーを起動する。需要が下がり、キューイングが減少すると、PATHMON プ
ロセスは自動的に不要なサーバプロセスを削除する。
NonStop TS/MP サーバプールによって、アプリケーションサーバのスループットが向上します。サーバ
プール内の各プロセスは、同じアプリケーションロジックを実行します。NonStop TS/MP 構成でサーバ
プールを定義する際、プロセス数を設定するか、または最大プロセス数を指定して NonStop TS/MP にプロ
セスを開始・停止させることができます。NonStop TS/MP モニタプロセスを使用すると、ロードバランシ
ングを実行できます。
備考 : NonStop TS/MP マニュアルを参照すると、
「サーバクラス」という用語が使われています。この用語は、こ
のマニュアルでは「サーバプール」として使用されているものを指します。
1.1.6 NonStop DOM フレームワークデータベース
NonStop DOM システムでは、次のようなデータベースを使用します。
□ 構成データベース
□ Interface Repository データベース
□ Naming Service データベース
データベースはすべて、キー順 Enscribe ファイルを使用して実装されています。
構成データベース
構成データベースには、種々の NonStop DOM システムコンポーネントの設定値が含まれています。こ
れ ら の 設 定値 は、初 期 化 スク リ プ ト を実 行 す る と初 期 化 さ れま す。ま た、構 成 デー タ ベ ー スに は、
CSMAP@load_table と CSMAP@map_table という 2 種類のテーブルも含まれています。LSD (Location
2-8
140418J
第 1 章 NonStop DOM のアーキテクチャ
Service Daemon) は、これらのテーブルを使用して、クライアントの要求を処理するサーバの位置を格納お
よび解決します。
Interface Repository データベース
Interface Repository (IR) は、NonStop DOM アプリケーションサーバ上でサポートされるオブジェクトイ
ンタフェースの定義を記述したファイルセットです。IR に含まれる情報は、クライアントによって使用さ
れます。これらのクライアントは、CORBA 2.0 仕様で定義されているように、DII (Dynamic Invocation
Interface) を使用してサーバにアクセスします。
開発者は、CORBA の Interface Repository 仕様に定義されているインタフェースを通じてプログラムに
よって IR データベースにアクセスします。
Naming Service データベース
Naming Server は、Naming Service データベースを保守し、ユーザ定義の名前とそれらの各オブジェク
ト間の関連付けを格納します。
NonStop DOM のシステム管理者が構成スクリプトを実行すると、初期データベースが作成されます。
1.1.7 NonStop DOM 伝送プロトコル
伝送プロトコルは、クライアントとサーバ間の要求 / 応答の伝送のために NonStop DOM システムが使
用する基本的な通信プロトコルです。クライアントとサーバが互いに通信する必要がある場合、それらは
共通のプロトコルを少なくとも 1 つはサポートしていなければなりません。
NonStop DOM システムでは、Comm Server との通信プロトコルとして 3 種類のプロトコルをサポート
しています。事前定義済みの 3 種類の伝送コンポーネントは、別々のプロトコルをサポートしており、そ
れらは次のようになります。
□ Internet InterORB Protocol (IIOP) はリモートシステムとの通信に使用される。このプロトコルは TCP/
IP 接続を使用する。
□ Pathway プロトコルは NonStop TS/MP サーバプールとの通信に使用される。このプロトコルは、
NonStop TS/MP のコンテキスト依存の Pathsend 機構で使用される。
□ ファイルシステムプロトコルは個々のプロセスとの通信に使用される。このプロトコルは、ファイルシ
ステムのプロセス間通信 (IPC) と連動して使用される。
サーバは、これらのプロトコルの次のいずれの組合せでもサポートします。
□ Pathway と TCP/IP
□ ファイルシステムと Pathway
□ ファイルシステムと TCP/IP
□ ファイルシステムと TCP/IP と Pathway
NonStop DOM アプリケーションサーバに対するプロトコルの設定について詳細は、
「アプリケーション
サーバの拡張」を参照してください。
140418J
2-9
第 1 章 NonStop DOM のアーキテクチャ
IIOP (Internet InterORB Protocol)
IIOP メッセージ送信はすべて、もととなるプロトコルとして TCP/IP を採用しています。このため、リ
モートクライアントは、NonStop DOM サーバプロセス上でサポートされているオブジェクトにアクセスす
るために、TCP/IP を使用しなければなりません。TCP/IP は、Pathway およびファイルシステムプロトコル
と組み合わせて使用することができます。
NonStop DOM アプリケーションサーバは、NonStop DOM Comm Server のサービスとともに TCP/IP を
使用することも、NonStop DOM Comm Server なしで TCP/IP を使用することも可能です。サーバが Comm
Server を使用するように構成されている場合、アプリケーションサーバは、ファイルシステムプロトコル
または Pathway プロトコルのいずれかを使用して Comm Server と通信します。
Comm Server を使用しない場合、リモートクライアントは NonStop DOM サーバと直接通信しなければ
なりません。この種のアクセスに対しては、TCP/IP を使用するように NonStop DOM サーバを構成する必
要があります。
NonStop DOM サーバが Pathway または ファイルシステムプロコルもサポートする場合、ローカルクラ
イアントは、これらのプロトコルのどちらかを使用してサーバと通信します。Comm Server はこの場合に
は動作しません。
Tandem クライアントが、リモート IIOP 準拠アプリケーションサーバにアクセスする必要がある場合、
クライアントは TCP/IP (IIOP) を使用して通信を確立しなければなりません。この場合に、Comm Server は
使用されません。
コネクティビティ
NonStop DOM は、CORBA 2.0 に準拠し、ネットワーク通信用に IIOP および TCP/IP を使用します。
Tandem NonStop TCP/IP では、次に示す基本的な通信プロトコルのどれであっても使用可能です。
□ X.25
□ IEEE 802.2 Logical Link Control 1 ( コネクションレス )
□ Ethernet および IEEE 802.3 (Ethernet と同種 )
□ IEEE 802.5 ( トークンリング )
Pathway プロトコル
Tandem では、基幹サーバを Pathway プロトコル (NonStop TS/MP) で構成することを強くお勧めします。
これによってプロセスの管理機能、プロセスの永続性、ロードバランシング、およびスケーラビリティを
活用できるからです。
NonStop TS/MP をサポートするサーバは、スタンドアロンプロセスとしても、またはサーバプール内の
プロセスとしても、どちらでも構成可能です。( サーバプールは、NonStop TS/MP 環境内のプロセスのグ
ループです。) いずれの場合であっても、クライアントのメッセージとサーバの応答は、NonStop TS/MP
のプロセス間通信 (IPC) を使用して送信されます。
NonStop TS/MP は、NonStop DOM に対する内部プロトコルです。すべての ORB 間の通信で、この
NonStop DOM プロトコルを使用することができます。ただし、異機種間の ORB 通信は、やはり IIOP が
使用する TCP/IP プロトコルを介して行う必要があります。
2-10
140418J
第 1 章 NonStop DOM のアーキテクチャ
ファイルシステムプロトコル
ファイルシステムプロトコルのみをサポートするサーバは、単一の名前のプロセスとしてのみ実装する
ことができます。このサーバは、サーバプールに統合することはできません。NonStop DOM システムは、
プロセス間通信 (IPC) を使用して、ファイルシステムサーバへのクライアントのアクセスを管理します。
クライアントは、このプロトコルのみをサポートしているサーバと対話するには、ファイルシステムプ
ロトコルを使用しなければなりません。
140418J
2-11
第 2 章 NonStop DOM システムの構成
第 2 章 NonStop DOM システムの構成
2.1 NonStop DOM の構成
サブトピックス
□ 構成アーキテクチャ
□ NonStop DOM スクリプトファイル
□ 環境変数と env.sh のセットアップ
□ スクリプトファイルの構成
□ 構成データベース
□ 初期化スクリプト
□ NonStop DOM フレームエンティティ
□ エンティティ作成
□ 既存のエンティティファイルの削除
□ デフォルト NonStop DOM エンティティ
□ NonStop DOM 構成の削除
『第 1 部 NonStop™ DOM 入門ガイド』には、NonStop DOM のインストール方法 (「NonStop DOM のイ
ンストール」) と NonStop DOM を最初に使用する際の構成方法 (「クイック構成」) を解説しているトピッ
クがあります。
このトピックでは、
「クイック構成」のトピックに説明されている手順の詳細を解説します。また、特定
のニーズに対応した NonStop DOM システムのカスタマイズ方法についても説明します。次のトピック
「Configuration Tool の使用」では、NonStop DOM システムがいったん起動して実行した後の保守およびカ
スタマイズ方法を説明します。
2.1.1 構成アーキテクチャ
NonStop DOM システムが、Tandem NonStop Kernel 上で実行する CORBA 準拠の ORB と CORBA サー
ビスをどのように実装しているかについては、トピック「NonStop DOM のアーキテクチャ」で説明します。
ユーザ記述の NonStop DOM クライアントおよびサーバアプリケーションは、NonStop DOM システム
を使用して、リモート CORBA クライアントと通信します。この点を考慮すると、NonStop DOM システ
ムの構成では、NonStop DOM システムを編成しているプロセスの構成と保守が大部分を占めます。
備考 : ユーザ作成の NonStop DOM アプリケーションサーバおよび NonStop DOM クライアントアプリケーショ
ンの構成は、NonStop DOM システムの構成とは別の問題です。このトピックでは、NonStop DOM システ
ムの構成の詳細を扱います。NonStop DOM で作成する C++ アプリケーションの構成についての詳細は、
「分散オブジェクト環境の管理」および「アプリケーションプロセス管理」で解説します。
140418J
2-13
第 2 章 NonStop DOM システムの構成
NonStop DOM システムの構成情報は、構成データベースファイルに格納されています。このファイル
のほかにも、さまざまな環境変数の設定値が NonStop DOM システムの構成を形成します。
図 2-3 は、NonStop DOM システムコンポーネントと、それらのコンポーネントがどのようにシステム構成
に統合されているかを図示しています。
図 2-3 NonStop DOM フレームワークの構成
NonStop DOM 製品にはスクリプトファイルのセットが含まれており、これを使用して、システムプロ
ファイルの作成、システム環境変数の設定、構成データベースの作成と初期化、および NonStop DOM フ
レームワークプロセスの開始と停止を実行することができます。また、NonStop DOM 製品には、システム
から NonStop DOM を削除するスクリプトも含まれています。
2.1.2 NonStop DOM スクリプトファイル
NonStop DOM には 6 つのスクリプトファイルが用意されています。これらは次のような機能を提供し
ます。
□ NonStop DOM 構成データベースの構成・作成
□ NonStop DOM システムを実行する Pathway システムの構成・開始
□ NonStop DOM システムプロセスの停止と、そのファイルのシステムからの削除
2-14
140418J
第 2 章 NonStop DOM システムの構成
NonStop DOM フレームワークの構成
以下のスクリプトファイルは、NonStop DOM システム用の環境変数を設定し、構成データベースと
Naming Service データベースを作成します。
□ env.sh
□ configure
□ default.db ( 初期化スケルトンスクリプト )
NonStop DOM システムの開始
NonStop DOM システムを構成しているプロセスを開始する前に、システムが使用するさまざまな環境
env.sh が、適切な環境変数を設定します。この
スクリプトを実行する前に、変数の設定値が特定のシステムセットアップを反映するように変数を変更し
変数を設定する必要があります。スクリプトファイル
てください。
システム変数を設定し終えたら、configure スクリプトを使用して NonStop DOM データベースを
作成および初期化します。この手順が完了すると、NonStop DOM システムのプロセスを開始することがで
きます。
nsdstart スクリプトは、NonStop DOM システムを制御する Pathway プロセスを構成および開始し
ます。Pathway プロセスが開始した後は、NonStop DOM システムは連続的に実行しながら、クライアント
の要求を受信・配布するのを待ちます。要求が着信すると、NonStop DOM システムは、要求を適切な
NonStop DOM アプリケーションサーバに転送します。
NonStop DOM システムの停止
以下のスクリプトを使用すると、NonStop DOM システムの停止と、システムから構成および Naming
Service データベースを削除することができます。
□ nsdstop
□ unconfigure
nsdstop スクリプトは、NonStop DOM システムを実行する Pathway システムをシャットダウンしま
す。NonStop DOM システムが停止した後、nsdstart スクリプトを使用して ORB を再起動する必要が
あります。
unconfigure スクリプトは、NonStop DOM データベースをご使用のシステムから削除します。
nsdstop スクリプトを使用して NonStop DOM プロセスを終了した後でないと、このスクリプトを実行
することができません。unconfigure を実行するとき、どのようなシステムプロセスであっても構成
データベースおよび Naming Service データベースを開くこともアクセスすることもできません。
注意 :
unconfigure スクリプトを実行すると、NonStop DOM 構成データベースおよび Naming Service デー
タベースはシステムから永久に削除されます。このスクリプトは、既存の NonStop DOM セットアップをシ
ステムから削除したい場合にのみ使用してください。
140418J
2-15
第 2 章 NonStop DOM システムの構成
2.1.3 環境変数と env.sh のセットアップ
各 NonStop DOM セットアップは、固有の環境変数セットを使用します。env.sh ファイルは製品のサ
etc にあります。このファイルによって、他の NonStop DOM スクリプトで使われる
NonStop DOM 環境変数が設定されます。
ブディレクトリ
主に
env.sh では、さまざまな NonStop DOM コンポーネントが入っているディスクボリュームとサ
ブボリュームを参照する、環境変数を設定します。このため、自分固有の NonStop DOM セットアップの
ディレクトリ位置を反映させるには、デフォルトの
env.sh スクリプトをカスタマイズする必要があり
ます。
env.sh スクリプトをカスタマイズしたら、NonStop DOM システムを開始する環境へ入るたびごとに、
env.sh スクリプトをソース化しなければなりません。このプロセスは、NonStop DOM システムを実行
する OSS (Open System Services) シェルへ入るたびにスクリプトをソース化することによって自動化する
ことができます。それには、システムを実行するシェルを開始する OSS ユーザ名の .profile ファイル
にある env.sh スクリプトをソース化します。
ボリュームとサブボリューム情報の設定に加えて、env.sh ファイルを使用して NonStop DOM システ
ムのインストール特性を設定します。これを使用することで、1 システムのフレームワークの複数のイン
ストールを構成できます。
NonStop DOM をインストールすると、インストールプロセスが Guardian ボリュームおよびサブボ
リューム上に NonStop DOM サブディレクトリを作成します。この Guardian ボリュームおよびサブボ
リュームは、インストールプロセス中に指定します。これらのサブディレクトリの場所は、env.sh ファ
イルに設定されている NonStop DOM 環境変数の多くが使用します。これについては「環境変数の設定」
テーブルに詳しく記述されています。
2.1.4 スクリプトファイルの構成
configure スクリプトによって、以下の処理が実行されます。
□ Configuration Tool を開始する
□ 構成データベースを作成する
□ 構成データベースを初期化する、初期化スクリプトをソース化する。
□ 構成データベースに新規エンティティを作成する。これが LSD (Location Service Daemon) の IP アドレ
スを初期化する。
□
ns_init を実行する。これが Naming Service データベースを作成・初期化する。
□
NS@name_service_settings エンティティにルートネーミングコンテキスト IOR を作成す
る。
□ NonStop DOM SRL (NonStop DOM Shared Runtime Library) のファイルコードを 700 に設定する
注意 :
configure スクリプトは、NonStop DOM データベースの新規セットを作成したい場合にのみ実行して
ください。このスクリプトをもう一度実行すると、スクリプトで指定されているデータベースが再度作成さ
れて初期化されます。この結果、データベースファイルに行った変更がすべて上書きされてしまいます。
configure スクリプトを実行すると、次のような出力が表示されます。
2-16
140418J
第 2 章 NonStop DOM システムの構成
configure コマンドの実行
> configure
Bad database construct. "$SYSTEM.ZDOMRT20.NSDCFGDB"
Cannot FILE_GETINFOBYNAME_ for file "$SYSTEM.ZDOMRT20.NSDCFGDB"
cfgmgt initialization Completed
LSD initialization Completed
Initializing Naming Service.
Creating POA for Naming Contexts.
Initializing Naming Database.
Creating Root Naming Context IOR.
Root Naming Context IOR saved to config database.
Naming Service initialization complete.
「Bad
database construct」および「Cannot FILE_GETINFOBYNAME_」とあります
が、これらは正常なメッセージであり、予期されている応答メッセージです。
2.1.5 構成データベース
構成データベースには、NonStop DOM システムの構成に使用される設定値が含まれています。また、構
成データベースは、すべての NonStop DOM プロセスの構成情報も調整し、統合化した情報リポジトリを
提供します。NonStop DOM システムを開始する前に構成データベースを作成する必要があります。
NonStop DOM システムのセットアップの複雑さによっては、構成データベースの作成のプロセスが長
くなる可能性があります。構成データベースを再作成するには、NonStop DOM システムをシャットダウン
する必要があるので、システムのセットアップについては慎重に計画し、最初の時点で適切な構成設定を
行うようにしてください。
構成データベースの作成
bin サブディレクトリにある configure スクリプトは、Configuration Tool を呼び出して、NonStop
DOM 構成データベースを初期化します。Configuration Tool はいったんロードされると、初期化スクリプ
トのコマンドを解釈して、構成データベースファイルを作成し、NonStop DOM エンティティを初期化しま
す。configure スクリプトは、ns_init を呼び出して Naming Service データベースを初期化し、
NonStop DOM Naming Service を開始すると終了します。
以下に示す行は
configure スクリプトに記述されている行です。ここでは、Configuration Tool で
セッションを初期化し、空のデータベースを作成し、初期化スクリプトをソース化して ( この場合、ファ
イルは custom.db)、Configuration Tool セッションを終了します。
Line
Line
Line
Line
Line
Line
1:
2:
3:
4:
5:
6:
cfgmgt <<\END
dbcreate
;# Create a database
set myExit 0
;# default exit code
set myExit [catch {source $env(MY_ROOT)/etc/custom.db}]
exit $myExit
END
これらのコマンドの詳細は次のとおりです。
1． Line 1 は、Configuration Tool を開始します。ヘッダは単純にツールのバージョン番号を示し、属性を
起動します。Configuration Tool が正しく起動しない場合、スクリプトは Line 6 の END タグにジャン
プします。
140418J
2-17
第 2 章 NonStop DOM システムの構成
2． Line 2 は、空の構成データベースを作成します。
3． Line 3 は、myExit フラグを 0 値に設定します。
4． Line 4 は、Configuration Tool が custom.db ファイルを解釈してデータベースのエントリを作成し
ます。
システムがこのスクリプトを解釈して何らかのエラーをリストする場合、ファイルを編集してエラーを
修正してからもう一度 configure を実行してください。custom.db の解釈でエラーが発生しな
ければ、後で更新する場合にデータベースを再作成する必要はありません。この場合、Line 2 の
dbcreate コマンドをコメントアウトして、スクリプトを再実行することができます。
5. Line 5 は、Line 4 で設定した終了コードで Configuration Tool を終了します。
上記のステップで明らかなように、構成データベースの初期設定は初期化スクリプトファイルのコマン
ドを使用して行われます。このケースでは、スケルトンスクリプトファイル default.db に変更を加え
た custom.db と呼ばれるファイルが初期化スクリプトになります。
構成データベースをチェックするには、Configuration Tool を実行して、entities コマンドを発行し
ます。このコマンドは、データベースの全エンティティの一覧を作成します。この一覧をチェックするこ
とによって、データベー スに含まれているエンティティのセットが適切であるかを確認できます。
Configuration Tool で使用できるコマンドの詳細については、サブトピック「構成ツールコマンド」を参照
してください。
複数の構成
単一の NonStop DOM システムを利用する、複数の構成データベースを作成することができます。この
場合、単一の NonStop DOM ORB は異なるアプリケーションサーバセットのために機能し、各データベー
スは異なる環境変数およびエンティティのセットを使用します。このような設定を作成するには、新しい
データベースを初期化する前に、env.sh スクリプト、初期化スクリプト、configure スクリプトの
カスタマイズ版を作成する必要があります。
2.1.6 初期化スクリプト
NonStop DOM は初期化スクリプトを提供して、構成データベースに最初の構成情報を作成します。初
期化スクリプトのテンプレートである、default.db は etc サブディレクトリにあります。
備考 : 初期化スクリプトを default.db 以外の名前で作成する場合、確実に configure スクリプトにお
いて、Configuration Tool で初期化ファイルをソース化する行でその新しいファイル名を参照するようにし
てください。
スケルトンスクリプトと肉付けされたスクリプト
ファイル
default.db は「スケルトンスクリプト」として知られており、初期化スクリプトに指定
しなければならない入力用のテンプレートです。
スケルトンスクリプトを修正して、そこに NonStop DOM システムに搭載されている各構成可能コン
ポーネントの詳細情報が含まれるようにします。NonStop DOM システムおよび NonStop DOM サーバの両
方の全コンポーネントに対するデフォルトの構成設定をそのスケルトンスクリプトに記述すると、そのス
クリプトは「肉付けされたスクリプト」となります。
configure スクリプトを実行すると、Configuration Tool が肉付けされたスクリプトを読み込みます。
2-18
140418J
第 2 章 NonStop DOM システムの構成
この肉付けされたスクリプトが構成データベースを初期化します。肉付けされたスクリプトをソース化す
ると、Configuration Tool がエラーをチェックし、エラーがあればエラーメッセージを生成します。
Configuration Tool は肉付けされたスクリプトの内容の文法的スキャンのみを実行します。そのため、
Configuration Tool では多種類のエラーを捕捉できません。たとえば、IP アドレスは、実際に存在しない場
合であっても肉付けされたスクリプトに構成されることがあります。同様に、プロセス名が重複している
ことがあり、そのプロセスが要求された場合にはエラーが発生します。ボリューム、サブボリューム、ま
たはシステム名がスクリプトファイルに構成されていても、そのファイル場所が存在していないことがあ
ります。ファイルの許可によって問題が生じる場合もあります。こういった種類の操作上の問題点は、必
要に応じて対処する必要があり、適切な変更を行って、ご使用の NonStop DOM システムを正しく構成し
なければなりません。
スクリプトの意味
スクリプトファイルのコメントは、ハッシュ文字 (「#」) で始まります。インタプリタは、ハッシュ文
字の右の行はすべて無視します。
行の継続は、行末の文字をバックスラッシュ (「\」) にして始まります。行末のバックスラッシュによっ
て、次行全体が前の行と連結します。先頭のスペースは ( ある場合 ) 連結する行の一部になります。
2.1.7 NonStop DOM フレームエンティティ
初期化スクリプトは、NonStop DOM の「エンティティ」で構成データベースを初期化します。
スクリプト内でエンティティは ASCII タグによって定義されており、ASCII タグによってキーと値のペ
アの集合に名前が付けられます。単純化すると、エンティティとはオブジェクトの特定のインスタンスと
なるものの構成と考えてください。Configuration Tool は初期化スクリプトを解釈すると、リストされる各
エンティティを構成データベースに格納します。
NonStop DOM の各構成データベースは、エントリがまったくないか、または最低 1 つ以上のエントリ
を含みます。エンティティは、情報の辞書へアクセスするための ASCII 文字列を提供します。各エンティ
ティは、1 つまたは複数のキーと値のペアにアクセスします。エンティティキーは、ASCII 文字列値であ
り、関連する値へのアクセスに使われます。NonStop DOM では、エンティティ名、キー名、または値の情
報について長さの制限はありません。ただし、空白は 2 重引用符 (" ") で囲まなければなりません。
エンティティ構文
スクリプトでは、エンティティの記述はキーワード
entity で開始し、その後にエンティティ名を続
けます。エンティティ名は必ず次の構文に従います。
profile@attribute
次の例は、初期化スクリプトの特定のエンティティ名の例です。
NSD@ORB
default@ORB
各エンティティ名は、NonStop DOM 構成データベース内で一意でなければなりません。既存のエンティ
ティ名を定義しようとすると、Configuration Tool が暗黙にその既存の値を上書きしてしまいますので注意
してください。
140418J
2-19
第 2 章 NonStop DOM システムの構成
キーワード
entity およびエンティティ名の後には、キーと値のペアのリストが続きます。これらの
ペアによって、エンティティの状態が設定されます。実際は多少異なることが予想されますが、次の例で
は初期化スクリプトのエンティティの基本形式を示します。
default.db のエンティティ形式
entity NS@ORB {
use_comm_server
tcp_server
fs_server
tsmp_server
server_class
}
true
true
true
true
NS
2.1.8 エンティティ作成
初期化スクリプトのエンティティは、次の 2 種類の方法で作成できます。
□ 波括弧 ({ }) を使用して、複数のキー / 値ペアを同時に追加する
□
entityaddkeyvalue キーワードを使用して、単一のキー / 値ペアを追加する
{ } を使用するには、{ はエンティティ宣言と同一行に置く必要があり、エンティティ宣言とはスペース
で区切ります。} でエンティティと関連付けられるキー / 値ペアを閉じます。1 つのエンティティに対する
キー / 値ペアの数に制限はありません。
備考 : キーまたは値に空白を入れることができます。ただし、空白を入れる場合には、キー全体または値全体を 2
重引用符で囲み、それがひとかたまりの語彙単位であることを示す必要があります。
ファイル内では、各キー / 値ペアは 1 行を占め、キー / 値ペアを囲む { } の中にコメントを入れることは
できません。大文字と小文字を区別するかどうかは実際使用されるかどうかに依存します。キー / 値ペア
には入力したとおり正確な値が入ります。項目のなかには、論理的に大文字小文字の区別がないものもあ
りますが ( たとえば true、TRUE、True)、ほとんどの項目はそうではありません。すべての値は入力した
とおりのまま格納されます。
エンティティ名の後に { } ( 空のキー / 値リスト ) を記述した場合、エンティティの定義は無視されます。
空のリストは、後でキー / 値ペアを追加できるエンティティのプレースホルダとして使用することができ
ます。興味深いのは、定義を無視するという動作が、Enscribe データベースが空のレコードを格納しない
ことから生じているということです。
備考 : NonStop DOM の構成データベースは、通常、同一の ASCII 文字列を持つキーを含みます。しかし、キーが
重複した場合は、異なるエンティティに存在しなければなりません。単一のエンティティでキー名を重複す
ると、2 番目のキー / 値ペアは前の定義の値情報を上書きします。
環境変数を含んだエンティティの追加
Configuration Tool は、上記で説明した { } で囲まれる環境変数の文字列を展開しないことに注意してく
ださい。したがって、マクロ展開を含んだエンティティ情報を追加する場合は別の方法を使用しなければ
なりません。
次は、初期化スクリプトのなかで、環境変数を定義するために
entityaddkeyvalue キーワード
を使用している例です。
2-20
140418J
第 2 章 NonStop DOM システムの構成
entityaddkeyvalue NS@ORB pathmon \$$env(MY_PREFIX)ndm
コード $env(MY_PREFIX) は、外部環境変数 MY_PREFIX の値に展開し、テキストを事前に定義
されている変数値に置き換えます。この結果エンティティ NS@ORB に対して、キー pathmon には、
「$」
の値と、展開された環境変数 MY_PREFIX に文字列 ndm が連結したものが指定されます。
データベースには、括弧内のテキストは変更せずそのまま格納されます。Configuration Tool は 括弧で
囲まれた文字列を展開しないので、修正した NonStop Kernel のファイル名 ($0 などのように ) をデータベー
スに簡単に挿入することができます。この実行形式によってプログラミングの柔軟性を実現できます。文
字列を entityaddkeyvalue キーワードに連結でき、Tcl インタプリタの完全な値は使用可能なまま
です。Tcl 言語の詳細については、リファレンスを参照してください。
2.1.9 既存のエンティティファイルの削除
初期化スクリプトの catch
{entitydelete NS@ORB} 行によって、NS@ORB エンティティと
それに関連付けられているキー / 値ペア ( 存在する場合 ) が構成データベースから削除されます。新しい値
のエンティティが初期化される前に、エンティティは削除されます。この機能により、スクリプトを複数
回実行しても、確実にデータベースに含まれるのはファイルに指定されている各エンティティのキー / 値
ペアのみとなります。
エンティティの削除
catch {entitydelete NS@ORB}
entityaddkeyvalue NS@ORB pathmon \$$env(MY_PREFIX)ndm
entity NS@ORB {
use_comm_server
true
tcp_server
true
fs_server
true
tsmp_server
true
server_class
NS
}
catch キーワードは、｛ ｝で指定された操作に対して、NS@ORB がデータベースに存在しない場合に
生じる可能性のある、例外をとらえます。これによって、エンティティが存在しているかどうかに関係な
く、エンティティの削除が適切に実行されます。
entitydelete コマンドは、確実にデータベースに古い情報が残らないようにします。初期化スク
entitydelete コマンドを使用して
リプトから完全にエンティティを削除する場合には、必ず、同じ
構成データベースから個々のエンティティを削除してください。
2.1.10 デフォルト NonStop DOM エンティティ
デフォルトの初期化スクリプト
default.db は、以下の NonStop DOM エンティティを初期化しま
す。
□ NS@ORB
□ NS@name_service_settings
□ default@ORB
□ ZNCA@comm_server
140418J
2-21
第 2 章 NonStop DOM システムの構成
□ ZNCB@comm_server
□ lsd1@ORB
□ event_service@ORB
□ event_service@event_service_settings
□ tcp_client@ORB
□ tsmp_client@ORB
□ fs_server@ORB
□ fs_client@ORB
□ default@trace
NS@ORB
このエンティティは、アプリケーション固有のプロファイルに対して Naming Service を初期化します。
このエンティティのデフォルト設定は、次のとおりです。
entityaddkeyvalue NS@ORB pathmon \$$env(MY_PREFIX)ndm
entity NS@ORB {
use_comm_server true
tcp_server
true
fs_server
true
tsmp_server
true
server_class
NS
}
このエンティティの初期化によって以下のように処理されます。
□
use_comm_server true により、Comm Server サーバが使用可能にする
□
tcp_server true により、TCP/IP サーバが使用可能になることを意味する
□
fs_server true により、ファイルシステムが使用可能になることを意味する
□
tsmp_server true により、NonStop TS/MP サーバが使用可能にする
□
server_class NS により、Naming Service のサーバクラスが NS として定義される
NS@name_service_settings
このエントリは、Naming Service データベースの名前を指定します。値の一部で環境変数を展開する形
式により、この特定の部分を変更することができます。これを { } でくくった場合は、それは展開されま
せん。
catch {entitydelete NS@name_service_settings}
entityaddkeyvalue NS@name_service_settings DatabaseName \
$env(MY_SUBVOL).NAMINGDB
entityaddkeyvalue NS@name_service_settings
RootNamingContextIORFile \
$env(MY_ROOT)/etc/root_nc.ior
2-22
140418J
第 2 章 NonStop DOM システムの構成
NS@name_server_settings を使用可能な Tandem NonStop Kernel サブボリュームに完全に展
開するためには、ユーザ定義の環境変数 MY_SUBVOL を設定する必要があります。
default@ORB
このエンティティは、他のエンティティで欠如しているキー / 値ペアに対してデフォルトのプロファイ
ルを提供します。
entityaddkeyvalue default@ORB trace_file <STDOUT>
entityaddkeyvalue default@ORB nsdom_ir $env(MY_ROOT)/etc/
nsdom.ir
entityaddkeyvalue default@ORB log_file $env(MY_COLLECTOR)
環境変数 MY_ROOT および MY_COLLECTOR は、それぞれの環境変数の値に展開します。
nsdom_ir 値は、IR (Interface Repository) データベースへの検索パスに対して用意されています。セ
ミコロンで区切ると複数の IR データベースを使用することができます。1 番右側にリストされたデータ
ベースは、新規の追加 IR エンティティに対する更新を受け取ります。IR を変更するとき、検索は左から
開始し、適切な IR が見つかるまで続行します。更新された IR は同じデータベース内の既存の IR を置き換
えます。
通常の配置では、最初 ( 最も左 ) の IR データベースにシステムの IDL が置かれます。
log_file によ って NonStop Kernel EMS ロ ガー 名が 命名 され てお り、通常 $0 です。環 境変 数
MY_COLLECTOR が、NonStop Kernel に対してロギングエラーとその他の情報のコレクタ名を提供しま
す。
Comm Server
以下の宣言では、特定の Comm Server のポート番号とホスト名を記述しています。
catch {entitydelete $env(MY_PREFIX)NCA@comm_server}
entityaddkeyvalue $env(MY_PREFIX)NCA@comm_server \
host_name
$hostname
entityaddkeyvalue $env(MY_PREFIX)NCA@comm_server \
port_number
$portnumber0
#
catch {entitydelete $env(MY_PREFIX)NCB@comm_server}
entityaddkeyvalue $env(MY_PREFIX)NCB@comm_server \
host_name
$hostname
entityaddkeyvalue $env(MY_PREFIX)NCB@comm_server \
port_number
$portnumber1
初期化スクリプトには、各 NonStop DOM Comm Server のエントリが含まれていなければなりません。
環境変数
MY_PREFIX によって、全 Comm Server プロセスの名前の先頭に、env.sh スクリプトファ
イルで指定した文字が付けられます。この接頭辞の文字によって、NonStop Kernel で実行する単一システ
ム上で種々の NonStop DOM システムをセットアップすることができます。
複数の Comm Server が存在する場合、システムのセットアップに適合するように
nsdstart ファイ
ルを変更する必要があります。
140418J
2-23
第 2 章 NonStop DOM システムの構成
lsd1@ORB
LSD (Location Service Daemon) は、このエンティティから、構成情報を取得します。エンティティの記
述は次のとおりです。
catch {entitydelete lsd1@ORB}
entityaddkeyvalue lsd1@ORB
entityaddkeyvalue lsd1@ORB
entity lsd1@ORB {
tcp_server
true
}
host_name
port_number
$hostname
$portnumber2
LSD に対して特定のポート番号を指定しなければならないことに注意してください。システム選択の
ポート番号を LSD に使用することはできません。
event_service@ORB と event_service_settings@ORB
次の設定は、Event Server に使用されます。
catch {entitydelete event_service@ORB}
entityaddkeyvalue event_service@ORB
host_name
$hostname
entity event_service@ORB {
tcp_server
true
port_number
0
}
catch {entitydelete event_service@event_service_settings}
entity event_service@event_service_settings {
EventServiceID "NSDOM ES"
EventServiceFactory true
}
entityaddkeyvalue event_service@event_service_settings \
EventServiceIORFile $env(MY_ROOT)/etc/es.ior
エンティティの event_service@ORB と event_service@event_service_settings は、
イベントサービスを構成します。
EventServiceID によって、Naming Service におけるイベントサービスオブジェクト参照が識別さ
れます。Even Service factory を TRUE に設定すると、Event Service は factory オブジェクトを生成し、そ
のオブジェクト参照を Naming Service データベースに入れます。Even Service factory を FALSE に設定す
ると、Event Service はイベントチャネルを生成し、そのオブジェクト参照を Naming Service データベース
に入れます。
EventServiceIORFile で、Event Service のオブジェクト参照を記述するための
ファイル名を指定します。EventServiceIORFile のファイル設定がない場合、Event Service はこ
オプションの
のファイルを作成しません。
その他のデフォルトエンティティ
初期化スクリプトのエンティティ tcp_client@ORB、tsmp_client@ORB、fs_server@ORB、
fs_client@ORB、default@trace は、ORB のサンプルで使用されており、想定されるさまざま
な設定を示します。
2-24
140418J
第 2 章 NonStop DOM システムの構成
2.1.11 NonStop DOM フレームワーク構成の削除
既存の NonStop DOM セットアップをシステムから削除する必要がある場合、unconfigure スクリプトを
NonStop DOM Naming Service および構成データベースファイルの NAMINGDB と NSDCFGDB
使用して、
をそれぞれ削除します。
NonStop DOM システムの構成を削除する前に、nsdstop スクリプトをその前に実行していること、
NAMINGDB と NSDCFGDB がどのプロセスによってもオープンされてい
ないことを確認してください。これらのファイルは、NonStop DOM システムの Guardian サブボリューム
にあります。デフォルトでは、これは $SYSTEM.ZDOMRT20 です。
およびデータベースファイル
NonStop DOM システムの構成を削除するには、OSS シェルで次のコマンドを実行します。
> unconfigure
その結果、次のような出力が表示されます。
unconfigure コマンドの実行
> unconfigure
**************************************************************
**
nsdstop must be run prior to running this script and
NSDCFGDB and NAMINGDB database files cannot be opened.
This will PERMANENTLY purge the NSDCFGDB and NAMINGDB databases.
Do you want to proceed (y/n):
y
$SYSTEM.ZDOMRT20.NSDCFGDB PURGED.
1 FILE PURGED
$SYSTEM.ZDOMRT20.NAMINGDB PURGED.
1 FILE PURGED
2.2 Configuration Tool の使用
サブトピックス
□ 構成ツールの概要
□ 構成ツール構文
□ 構成ツールコマンド
□ 構成ツールの実行例
2.2.1 構成ツールの概要
NonStop DOM には Configuration Tool が用意されており、NonStop DOM システムとその関連の構成デー
タベースを構成します。ツールは実行可能プログラムであり、OSS (Tandem Open System Services) 環境で
実行します。Configuration Tool は、NonStop DOM システムの構成設定を格納している Enscribe データ
ベースを作成および保守します。
140418J
2-25
第 2 章 NonStop DOM システムの構成
備考 : NonStop DOM システムでは、NonStop DOM アプリケーションサーバが使用する ORB (Object Request
Broker) を提供します。Configuration Tool は、NonStop DOM の構成と保守に使用します。NonStop DOM
アプリケーションプロセスの構成と保守については、トピック「アプリケーションプロセス管理」で解説し
ます。
Configuration Tool には、豊富なコマンドセットを含んだ Tcl(Tool Command Language) が組み込まれて
います。Tcl インタプリタのコマンドセットを使用することによって、NonStop DOM インストールの構成、
参照、編集、試験、実行、および監視を行うことができます。また、Tcl コマンドを使用して、NonStop
DOM をシャットダウン ( 停止 ) したり、構成を削除することも可能です。
Configuration Tool の実行プログラム cfgmgt では、次に示す Tcl サポートファイルが、
$Tcl_LIBRARY 環境変数によって指定される NonStop DOM ディレクトリにロードされていなければ
なりません。
□
instcfg.tcl
□
skel.tcl
□
init.tcl
□
parray.tcl
□
tclIndex
これらのサポートファイルは、NonStop DOM をインストールするとロードされます。これらのファイ
ルを変更することはできません。
Tcl (Tool Command Language)
Configuration Tool には、完全な Tcl 7.4 コマンドセットが搭載されています。このコマンドセットは、
Enscribe データベースとして実装されている、NonStop DOM 構成データベースにアクセスするための特殊
な拡張を備えます。
Tcl コマンドを使用すると、プロファイル、データベースのエントリ、および複雑なルーチンを簡単に
作成することができます。Tcl を使用することによって、NonStop DOM システムの構成設定の全体を柔軟
に制御することができます。NonStop DOM システムコンポーネントのデータベース項目 (Comm Server、
LSD、Naming Service など ) は、Configuration Tool に用意されている Tcl コマンを使用して構成、参照、
編集することが可能です。
また、Configuration Tool の Tcl インタプリタはスクリプトの使用もサポートしています。NonStop DOM
のインストールは、NonStop DOM 構成データベースの初期構成と起動を実行するいくつかの重要なスクリ
プトを使用して完了します。
2.2.2 構成ツール構文
Configuration Tool は実行可能ファイル cfgmgt です。このファイルは、NonStop DOM インストール
の /bin サブボリュームにあります。
Configuration Tool を起動するには、次のコマンド構文を使用します。
cfgmgt [<dbName>]
2-26
140418J
第 2 章 NonStop DOM システムの構成
この OSS コマンドを入力すると、Configuration Tool のプロンプトが表示され、そのプロンプトからツー
ルコマンドを入力できます。exit コマンドを入力すると、OSS プロンプトに戻ります。
<dbName>
オプションの <dbName> パラメータには、後続のコマンドに使用するデータベースの名前を指定しま
す。データベースは、Guardian ファイルシステムに常駐していなければなりません。また、データベース
の場所を特定するために、ロケーション修飾を指定しなければならない場合があります。
コマンドでは、特殊文字の前にバックスラッシュ (「\」) を付ける必要があります。これは「エスケー
プ」文字と呼ばれ、これを使うとコマンドインタプリタに対して特殊文字として認識せず、ただの文字定
数とみなすよう指示することになります。したがって、Guardian パスのドル記号 (「$」) を表すには、ド
ル記号の前にバックスラッシュを付ける必要があります。同様に、バックスラッシュ文字の前には、
「エス
ケ ープ」の バッ クス ラッ シュ を付 けな けれ ばな りま せん。た とえ ば、\kt22.$nsdoms2.db.
xaction という名前の Guardian データベースファイルは、次のように入力します。
\\kt22.$nsdoms2.db.xaction
ユーザは、指定のボリュームおよびサブボリュームによって適切なファイル場所が指定されていること
と、データベースを変更するための適切なファイル許可も保有していることを確認する必要があります。
dbName パラメータの入力時に、既存のデータベースが存在している必要はありません。新規のデータ
ベースを作成するつもりであれば、Configuration Tool コマンドラインに新規データベースの名前を指定し
ます。
2.2.3 構成ツールコマンド
次に示すユーザコマンドのリストは、Configuration Tool で使用できる包括的なコマンドセットの解説で
す。コマンドのなかには NonStop DOM ORB の既存の状態に依存するものもあることに注意してください。
dbcreate [<dbName>]
このコマンドは、データベースを作成します。dbcreate 自体は、データベース名として環境変数
NSDOM_CFG_DBM の値を取得します。コマンド dbcreate <dbName> は、作成するデータベース
を指定します。このデータベース名は、部分修飾または完全修飾の Guardian ファイル名になります。デー
タベースの作成に続いて、環境変数 NSDOM_CFG_DBM が、与えられた <dbName> 値を引き取ります。
dbname [<dbName>]
このコマンドはデータベース名を設定したり、データベース名の問合せを行います。デフォルトのデー
タベース名は、環境変数の NSDOM_CFG_DBM から取得します。コマンド dbname にパラメータを付け
な いと、N S D O M _ C F G _ D B M
環 境変 数に 設定 され てい る現 行の デー タベ ース 名を 返し ます。
NSDOM_CFG_DBM がまだ存在していない場合は、エラーメッセージが返されます。
dbname <dbName> の形式によって、続く Configuration Tool コマンドが参照するデータベース名
として <dbName> が指定されます。データベースの場所を示す Guardian ファイル名が必要です。データ
ベース名の前にボリュームまたはサブボリュームをつけないと、オペレーティングシステムにログオンし
たユーザのデフォルトのボリュームおよびサブボリュームを使用します。
140418J
2-27
第 2 章 NonStop DOM システムの構成
dbremove [<dbName>]
このコマンドは、データベースを削除します。データベース名に <dbName> パラメータを指定すると、
そのデータベースが削除されます。コマンドにデータベースを指定しない場合には、Configuration Tool は
現在指定されているデータベースを削除します。
dumpdb <File>
このコマンドは、現行データベースを <File> という名前の ASCII ファイルにダンプします。
テキストファイル出力は、構成データベース設定値の「肉付けされたスクリプト」の表示になります。
スクリプトファイルなので、ファイルを編集して構成設定値を変更することができます。その後、source
コマンドを使って、変更した肉付けスクリプトからデータベースを作成または修正することができます。
dumpdb が 現在の構成設定値を含んだ ASCII テキストファイルを生成するので、保存 ( アーカイブ )、
内容の検証、データベースの比較にコマンドを使用することができます。また、現行システムの設定値を
編集または変更して、それらを再ロードしたり、データベース構成を他のシステムに転送することもでき
ます。
entities
entities コマンドは、現行データベースの全エンティティをリストします。Configuration Tool は
ハッシュオーダになっているデータベース全体を横断して、既存のエンティティすべてをリストします。(
エンティティのリストは、アルファベット順ではありません。)
entity [<Entity> [ { <Key1> <Value1> <Key2> <Value2> ... } ]]
このコマンドは、<Entity> に一連のキーと値を追加します。エンティティが存在する場合、コマン
ドはキーと値をその集まりに追加します。<Entity> がデータベースに現在存在していない場合には、
コマンドは <Entity> という名前のエンティティを作成してから、リストされているキーと値をそれに
割当てます。
内部手順では、キー / 値ペアを個別の行にリストすることが要求されます。行の最終文字としてバック
スラッシュ文字を追加して、次の行に値を続けることができます。この場合、値は最初の文字をスペース
にしないでキーの最終文字に続けます。値に先行スペースが必要な場合は、2 重引用符でその文字列をく
くります。
entity <Entity> の形式は、<Entity> 中の現在のキーをダンプします。
これより短いコマンド形式
entity は、現行データベース中の全エンティティの名前のをダンプしま
す。
entityaddkeyvalue <Entity> <Key> <Value>
現行データベースの <Entity> に対して、<Key> とその関連値 <Value> を追加します。エンティ
ティは、存在していても存在していなくてもかまいません。<Key> がすでに既存のエンティティに存在
している場合は、<Value> が前の値に置き換わります。
entitydelete <Entity>
データベースが、リストされたエンティティを削除します。現行データベースにエンティティが存在し
ない場合は、エラーメッセージが返されます。
2-28
140418J
第 2 章 NonStop DOM システムの構成
entitydeletekey <Entity> <Key>
<Entity> と <Key> を指定すると、<Entity> からキーを削除します。更新されたエンティティ
が、データベース内の前のエンティティに置き換わります。<Entity> または <Key> のいずれかが現
行データベースに存在しない場合は、エラーが発生します。
entitykeys <Entity>
現行データベース内の既存のエンティティを指定すると、entitykeys コマンドが
<Entity> の
すべてのキーを表示します。
entitykeysvalues <Entity>
現行 デー タベ ース 内の 既存 のエ ンテ ィテ ィを 指定 する と、entitykeysvalues コ マ ンド が
<Entity> のすべてのキーと値を表示します。
profile [<appName>]
profile コマンドは、データベースにプロファイルされているアプリケーション名を設定または問い
合わせます。profile コマンドを単独で使用した場合は、現行アプリケーション名のプロファイルを返
します。アプリケーション名を指定した場合は、指定した <appName> にプロファイルを設定します。
source <ScriptFile>
このコマンドは、特別にフォーマットされた初期化スクリプトファイル <ScriptFile> を読み出し
て、処理します。
NonStop DOM スクリプトを入力用に使用する場合は、通常の Tcl の「source」コマンドの代わりにこの
コマンドを使用しなければなりません。その理由は、ドル記号 (「$」) とバックスラッシュ (「\」) 文字を
使用する特殊な NonStop Kernel のファイル名にあります。これらの文字は、Tcl の予約文字であり、イン
タプリタが直接読み取る際に特殊な意味を持ちます。スクリプトでは、これらの特殊文字の前に「エスケー
プ」としてバックスラッシュを付けなければなりません。こうした小さな違いを除けば、入力スクリプト
ファイルと Tcl スクリプトファイルはまったく同一です。
2.2.4 構成ツールの実行例
以下の実行例は、いくつかの Configuration Tool コマンドの使用方法、および予想される応答表示のタ
イプを示します。
1. Configuration Tool プログラムを開始するには、OSS シェルプロンプトで cfgmg と入力します。その
結果、次のような出力が表示されます。
cfgmgt
NSDOM 2.0 Configuration Tool, v1.0
[dbname:qatest] 1>
2. entities コマンドを使用して、既存のエンティティをリストします。出力は、データベースの構成
によって異なります。
[dbname:qatest] 1>entities
"appQA@client_attr_protocols"
"appQA@comm_server"
140418J
2-29
第 2 章 NonStop DOM システムの構成
"appQA@csmap_binding"
"appQA@LSD"
"appQA@pathmon"
"appQA@policies"
"appQA@server_attr_protocols"
"appQA@system_services"
"appQA@trace"
"appQA@user_services"
3. 特定のエンティティをリストします。
[dbname:qatest] 2>entity appQA@trace
orb_giop_connections
false
poa
0
orb_request_queue
false
orb_proxy
false
name_svc
false
event_socket
false
event_context_free
false
threads false
event_core
false
event_time
false
comm_server
false
event_file_system
false
4. orb_proxy トレースを使用可能にします。
entity appQA@trace {
orb_proxy true
}
5. アプリケーション appQA に対してトレーススイッチをダンプします。これによって、トレーススイッ
チが設定されていることを検証できます。
[dbname:qatest] 3>entity appQA@trace
orb_giop_connections
false
poa
0
orb_request_queue
false
orb_proxy
true
name_svc
false
event_socket
false
event_context_free
false
threads false
event_core
false
event_time
false
comm_server
false
event_file_system
false
6. dumpdb コマンドを使用して、現行のデータベース設定値を表す ASCII テキストファイルを作成しま
す。
[dbname:qatest] 4>dumpdb qatest.db
ASCII ファイル qatest.db には、データベースの「肉付けされたスクリプト」形式が含まれます。
2-30
140418J
第 2 章 NonStop DOM システムの構成
このファイルを再ロードすると、dbname コマンドを使用して別のデータベースを指定しないかぎり、常
に qatest という名前のデータベースが作成されることに注意してください。
7. qatest.db ファイルのキー / 値ペアに何らかの変更を加えた後、ファイルを再ロードして構成デー
タベースを変更します。
[dbname:qatest] 5>source qatest.db
このコマンドの出力は、qatest.db ファイルの内容によって異なります。エラーが報告されなけれ
ば、新たにロードされたデータベースの使用は可能となります。
8. new_database という名前の新規のデータベースを作成します。
[dbname:qatest] 6>dbname new_database
new_database
[dbname:new_database] 7>dbcreate
9. qatest.db にリストされている値で新規データベースをロードします。
[dbname:new_database] 8>source qatest.db
10. new_database ファイルを編集して構成データベースをカスタマイズします。この操作の実行のた
めに、Configuration Tool を終了させる必要はありません。次のコマンドを入力するだけです。
[dbname:new_database] 9>vi new_database.db
11. 変更を構成データベースにマージします。
[dbname:new_database] 10>source new_database.db
ファイルをソース化するとき、変更に何らかのエラーがあればリストされます。new_database.db
ファイルのエラーを修正して、再度それをソース化します
12. 変更した特定のエンティティをダンプすることによって、データベースの変更を検証することができま
す。この例では、default@trace スイッチがロードされているものとします。
[dbname:new_database] 11>entity
orb_giop_connections
poa
0
orb_request_queue
orb_proxy
false
name_svc
false
event_socket
false
event_context_free
threads false
event_core
false
event_time
false
comm_server
false
event_file_system
default@trace
true
true
false
false
これでデータベースを使用することができます。
140418J
2-31
第 3 章 NonStop DOM のランタイム管理
第 3 章 NonStop DOM のランタイム管理
3.1 分散オブジェクト環境の管理
サブトピックス
□ 分散オブジェクト環境
□ NonStop DOM フレームワーク構成管理
□ NonStop DOM のフレームワークパフォーマンス調整
□ NonStop DOM フレームワークのトラブルシューティング
□ 必要な予備知識
このセクションでは、NonStop DOM 分散オブジェクト環境の管理と関係しているタスクの概要につい
て説明します。
「インストール」のトピックで説明されているように、NonStop DOM システムは Tandem
NonStop Kernel 上に ORB を実装しています。NonStop DOM 分散オブジェクト環境を管理するには、
NonStop DOM システムの設定を構成し、変更する必要があります。この環境の管理には、NonStop DOM
システムに含まれているシステムプロセスの監視、もととなるネットワークリソースの監視、パフォーマ
ンス向上のためのシステム構成の調整、ORB のトラブルシューティングがありです。
3.1.1 分散オブジェクト環境
図 2-4 は、NonStop DOM システムのランタイム環境の主要コンポーネントと、各タイプのコンポーネン
トの管理に使用するツールを示しています。
図 2-4 NonStop DOM ランタイムコンポーネント
140418J
2-33
第 3 章 NonStop DOM のランタイム管理
3.1.2 NonStop DOM のフレームワーク構成管理
NonStop DOM システムは、NonStop TS/MP (NonStop Transaction Services/MP) を使用するアプリケー
ションとして実装されています。NonStop TS/MP によって、スケーラビリティとロードバランシングが提
供されます。これは、同一タスクを実行するために複数のプロセスを並列して動作させることによって実
現しています。また、NonStop TS/MP によって可用性も提供されており、プロセスに欠陥があると
PATHMON と呼ばれる監視プロセスがそれを自動的に再起動します。NonStop TS/MS が NonStop DOM シ
ステムに対して全プロセスの管理を提供するので、NonStop DOM システムプロセスの構成および管理に
は、NonStop TS/MS インタフェースを使用します。
NonStop TS/MP のユーザインタフェースは、PATHCOM と呼ばれるライン指向のユーティリティです。
PATHCOM には、構成オプションの設定とチェック、プロセスの開始と停止、およびプロセスの状態と使
用に関する情報収集のための各コマンドが搭載されています。コマンドファイルを使って PATHCOM をイ
ンタラクティブに使用することができます。また、PATHCOM で利用できる機能を実行するために SPI
(Subsystem Programmatic Interface) を使用するアプリケーションを記述することもできます。
ネットワークリソース (TCP/IP、TLAM、QIO、X25AM) の構成を定義および保守するには、SCF
(Subsystem Control Facility) を使用するか、SPI を使用するアプリケーションを作成します。SCF および対
応するプログミングインタフェースには、構成オプションの設定とレビューのためのコマンドと、通信ラ
イン / プロセス / 関連リソースの状態と使用に関する情報収集のためのコマンドが搭載されています。
3.1.3 NonStop DOM のフレームワークパフォーマンス調整
NonStop DOM システムのランタイム環境のパフォーマンス調整は、LSD (Location Service Daemon)、
Comm Server、および TCP/IP プロセス間の関係と数を決定することが主要な問題です。それは次のように
処理されます。
1. PATHCOM を使用して、Comm Server の数を決定します。
2. Configuration Tool を使用して、LSD、Comm Server、TCP/IP プロセス、リモートクライアント、アプ
リケーションサーバ間の関係を決定します。
3. PATHCOM を使用して、NonStop DOM システムのパフォーマンスの問題を見つけ、それを解決します。
TCP/IP によるネットワークリソース (X25AM と TLAM) の使用によってもまた、NonStop DOM のラン
タイム環境のパフォーマンスに影響します。SCF を使用して、これらのリソースの関係を確立し、監視し
ます。
注意 : NonStop DOM では、Comm Server に対しては、NonStop TS/MP を使用して自動ロードバランシングを
行いません。代わりに、LSD 構成によってクライアントと Comm Server 間の関係が決定されます。した
がって、NonStop TS/MP のロードバランシングとパフォーマンス調整についての前提は、必ずしも常に
NonStop DOM ランタイム環境の管理に適用されるわけではありません。
たとえば、サーバプール内の他のサーバがアイドルの場合であっても、Comm Server ではボトルネック
が生じる可能性があります。この場合、パフォーマンスを改善するには、PATHCOM を使用して Comm
Server プロセスを追加するのではなく、Configuration Tool を使用してクライアントの Comm Server への
割当てを変更します。
NonStop DOM システムパフォーマンスに関する問題の多くは、実際、アプリケーションの設計や構成
が原因で生じます。たとえば、ステートフルオブジェクトに対する要求や、頻繁にデータを交換するオブ
ジェクトの場所と設計などもそうした原因になります。
2-34
140418J
第 3 章 NonStop DOM のランタイム管理
3.1.4 NonStop DOM フレームワークのトラブルシューティング
NonStop DOM システムの操作における障害で最も一般的に生じる問題を以下に挙げます。
□ 構成エラー
□ NonStop DOM システムと、それと通信する他システムとの間の構成の不一致
□ その他の相互接続性における障害。たとえば、異なるプラットフォーム上の CORBA 定義の機能の実装
の違いなど。
□ 一時的なネットワーク障害
NonStop DOM システムと他の ORB との間のインタラクションにおいて発生する障害については、通常、
リモート管理者の協力が必要になります。この目的での最適なツールが、NonStop DOM と SCF 構成ファ
イルの最新のフルセットです。ただし、いくつかの自動化ツールもまた、ローカルな NonStop DOM シス
テムのトラブルシューティングに役立ちます。それらのツールには次のものがあります。
□ PATHCOM を使用すると、NonStop DOM ランタイムプロセスの現行構成を検証できます。
□ NonStop DOM のエラーログは、NonStop DOM の実行エラーに関しての主要な資料です。NonStop DOM
構成ファイルの変数がエラーロギングを制御します。
□ NonStop DOM のトレースファシリティを使用すると、アプリケーションの制御の流れをたどって、エ
ラーが発生した時と場所を検出できます。各コンポーネントは、そのコンポーネントに対してのトレー
スを制御する構成ファイルに変数があります。
□ SCF を使用すると、ネットワークリソースの構成の検証、アドレス指定情報の検査、再発するエラーの
検出、およびラインとプロトコルのトレースを行うことができます。
□ Ptrace ユーティリティは、SCF トレースの解釈に役立ちます。
□ EMS (Event Management Service) は、複数のインタラクティブなプログラム用インタフェースを備えて
おり、NonStop TS/MP、NonStop TM/MP、オペレーティングシステム、ネットワークサービスなどさ
まざまなプロセスによって通知されるエラー情報を捕らえて統合する際の支援となります。
3.1.5 必要な予備知識
NonStop DOM のランタイム環境を管理するには、以下の知識が必要です。
□ NonStop TS/MP サブシステムの管理手順と留意事項
□ NonStop TCP/IP、TLAM (QIO)、X25AM の管理手順と留意事項
□ 以下のユーティリティの構文と使用方法
140418J
●
PATHCOM インタフェース
●
SCF (Subsystem Control Facility)
●
Configuration Tool
●
NonStop DOM エラーログファシリティ
●
NonStop DOM トレースファシリティ
2-35
第 3 章 NonStop DOM のランタイム管理
●
Ptrace
●
EMS (Event Management Service)
□ 以下のファイルの形式と意味
●
OSS .profile ファイル
●
初期化ファイル (default.db)
●
PATHCOM 構成ファイル (nsdstart)
●
SCF 構成ファイル
●
TCP/IP HOSTS ファイルまたは DNS ブートおよびドメインデータファイル
□ ns_init、Naming Service 初期化ユーティリティ
『関連マニュアル』には、上記に挙げた様々なシステムに関する情報を含んだ Tandem マニュアルについ
ての参考資料があります。
3.2 アプリケーションプロセス管理
サブトピックス
□ アプリケーション環境
□ アプリケーション構成管理
□ アプリケーションサーバの拡張
□ アプリケーションパフォーマンスの調整
□ アプリケーションのトラブルシューティング
□ 必要な予備知識
NonStop DOM アプリケーションの管理は、NonStop DOM システムの管理と同様、アプリケーションプ
ロセスの構成および監視、システムパフォーマンスの調整、トラブルシューティングなどのタスクがあり
ます。
NonStop DOM アプリケーションサーバを作成するとき、NonStop TS/MP サーバプールとしてそれらを
構成するためのオプションが用意されています。サーバプールが提供する可用性と拡張性の利点を得られ
るので、これを利用することをお勧めします。
サーバプールで実行するようにサーバを構成することは、そのサーバに対して特別に構成されている
PATHMON プロセスのもとでアプリケーションサーバを実行する必要があることを意味します。この
PATHMON プロセスを設定する最も簡単な方法は、NonStop DOM システムを構成および起動するスクリ
プトファイルをコピー・編集することです。
このセクションでは、NonStop DOM 環境で実行するアプリケーションコンポーネントを管理する際に
必要なタスクの概要を示します。
2-36
140418J
第 3 章 NonStop DOM のランタイム管理
3.2.1 アプリケーション環境
図 2-5 は、管理の必要があると思われる、アプリケーションエンティティのいくつかを図示しています。
これらのエンティティとして、ステートフルサーバプールとステートレスサーバプール、単一プロセス ( ク
ライアントとサーバ )、分散型データベースがあります。
図 2-5 NonStop DOM アプリケーションコンポーネント
備考 : 図のデータベースは NonStop SQL/MP データベースになっていますが、アプリケーションは他のタイプの
データベースにアクセスすることができます。
このトピックでは、構成管理、パフォーマンスの調整、および NonStop DOM アプリケーションコンポー
ネントのトラブルシューティングに関係ある問題について解説します。
3.2.2 アプリケーション構成管理
NonStop DOM では、アプリケーションサーバとして次のタイプのプロセスを使用することができます。
□ ステートレスサーバプール
□ ステートフ ルサーバプール
□ 単一プロセス
次のような 2 種類の構成手順によって、サーバがサーバプールまたは単一プロセスのどちらで実行する
かが決まります。
□ サーバがサーバプールとして実行する場合、PATHCOM 構成ファイルにサーバを定義する必要があり
ます。そのファイルでは、サーバプール内のサーバ数およびプロセス管理にとって重要なその他の特性
を指定します。
スクリプトを使用して、アプリケーションサーバを構成し実行することを推奨します。これらのスクリ
プトは、NonStop DOM システムを開始および実行するために使用するスクリプトと同じものです。ス
クリプトでは、NonStop DOM システムプロセスが構成されるのと同じ方法で、「エンティティ」とし
てサーバを構成します。
140418J
2-37
第 3 章 NonStop DOM のランタイム管理
□ サーバの全タイプに対して、サーバがサポートするプロトコルをサーバの構成ファイルに示します。た
とえば、Pathway プロトコルを使用するものとしてサーバを指定した場合、そのサーバはサーバプール
として実行します。
サーバプールが受け取るオブジェクトがステートフルかステートレスかは、そのオブジェクトクラスが
要求する処理がステートフルかステートレスかによって決まります。
ステートレス処理では、オブジェクトクラスをサポートするサーバプールのどのプロセスにでも要求を
送ることができます。ステートフル処理では、オブジェクトに対して要求するクライアントは特定のプロ
セスへのリンクを取得します。それ以降は、同一オブジェクトへの要求は、複数のクライアントからであっ
ても、同一のプロセスに送られます。オブジェクトクラスがステートフルかステートレスかは、オブジェ
クト定義によります。
同一のサーバプールは、それがホストするオブジェクトの要求しだいで、ステートフルとステートレス
のどちらの処理もサポートすることができます
備考 : ここでの説明では、サーバプールがステートレス処理を要求するオブジェクトのみサポートする場合、その
サーバプールはステートレスです。ステートフル処理を要求する 1 つまたは複数のオブジェクトをホストす
る場合には、そのサーバプールはステートフルです。
ステートフルサー バプールもステートレスサー バプールも、NonStop TS/MP (NonStop Transaction
Services/MP) で管理されます。NonStop TS/MP はスケーラビリティとロードバランシングを提供し、複数
のプロセスが並列して動作して同一のタスクを実行することが可能です。また、NonStop TS/MP は、可用
性も提供しており、PATHMON と呼ばれるその監視プロセスは、失敗したプロセスを自動的に再起動しま
す。NonStop TS/MP は NonStop DOM システムの全プロセスを管理するので、ライン指向の PATHCOM
ユーティリティまたは対応するプログラムインタフェース (SPI に基づいた ) に対する NonStop TS/MP イ
ンタフェースを使用して、NonStop DOM システムプロセスを構成および管理します。同じことが、NonStop
TS/MP プロセスとして構成する NonStop DOM アプリケーションプロセスについてもあてはまります。
NonStop TS/MP は、通常、ファイルシステムプロトコルまたは IIOP によって直接アクセスできる単一
サーバプロセスを管理しません。Guardian 環境または OSS (Open System Services) 環境のプロセス管理機
能を使用して、単一プロセスの起動、監視、および再起動を制御できます。
3.2.3 アプリケーションサーバの拡張
NonStop DOM は、そのアプリケーションサーバのスケーラビリティを以下のプロトコルでサポートし
ます。
□ ファイルシステムプロトコル
□ NonStop TS/MP プロトコル
ファイルシステムプロトコル
NonStop DOM アプリケーションサーバは、NonStop Kernel ファイルシステムプロトコルを介して
NonStop DOM または NonStop DOM クライアントと通信することができます。そのためには次の構成プロ
ファイルをアプリケーションサーバに追加する必要があります。
fs_server
true
このプロファイルは、Configuration Tool を使用して追加することができます。あるいは、サーバの
2-38
140418J
第 3 章 NonStop DOM のランタイム管理
PATHMON プロセスを初期化する際にこのプロトコルでサーバアプリケーションを構成することができ
ます。
またオプションで、NonStop DOM アプリケーションサーバのプロファイルに以下の設定を含めること
もできます。
tcp_server
true
use_comm_server true
この 2 つのプロファイルをアプリケーションサーバに追加すると、CORBA 準拠のクライアントであれ
ばいずれも NonStop DOM アプリケーションサーバと通信することができます。この場合、NonStop DOM
システムに含まれている Comm Server は、リモートクライアントとの通信に TCP/IP を使用します。そし
て、Comm Server とアプリケーションサーバ間の通信にはファイルシステムプロトコルが使用されます。
ファイルシステムプロトコルを使用するには、サーバプログラムを実行しなければなりません。これは、
アプリケーションサーバを実行する PATHCOM プロセスを初期化するスクリプトファイルで実行できま
す。
ファ イル シス テム プロ トコ ルを 使用 して、NonStop DOM ク ライ アン トを NonStop DOM また は
NonStop JORB アプリケーションサーバと通信させたい場合、クライアントプロファイルで以下のように
指定する必要があります。
fs_client
true
Configuration Tool を使用して、これをクライアントプロファイルに追加することができます。
さらに、NonStop DOM アプリケーションサーバのプロファイルで次のように指定していると仮定しま
す。
fs_server
tcp_server
use_comm_server
true
true
true
この場合、リモートクライアントは IIOP を介して TCP/IP を使用し、NonStop DOM アプリケーション
サーバと通信できます。このとき、クライアントは TCP/IP を介して Comm Server と通信し、Comm Server
はファイルシステムプロトコルを使用して要求をアプリケーションサーバに渡します。
さらに、NonStop DOM または NonStop JORB クライアントが同一サーバに要求する場合、クライアン
トは、IIOP を介して TCP/IP を使用することができます。その場合、クライアントのプロファイルで次の
ように指定しています。
tcp_client
true
NonStop TS/MP プロトコル
NonStop DOM アプリケーションサーバは、以下のプロファイルをアプリケーションサーバに追加する
ことによって、NonStop TS/MP プロトコルを介して NonStop DOM または NonStop JORB クライアントと
通信することが可能です。
tsmp_server
pathmon
server_class
140418J
true
<pathmon>
<server-class>
2-39
第 3 章 NonStop DOM のランタイム管理
このプロファイルは、Configuration Tool を使用して追加することができます。あるいは、サーバの
PATHMON プロセスを初期化する際にこのプロトコルでサーバアプリケーションを構成することができ
ます。
またオプションで、NonStop DOM アプリケーションサーバのプロファイルに以下を含めることもでき
ます。
tcp_server
true
use_comm_server true
この 2 つのプロファイルを追加すると、CORBA 準拠のクライアントであればいずれも NonStop DOM
アプリケーションサーバと通信することができます。この場合、NonStop DOM システムに含まれている
Comm Server は、TCP/IP を使用して、リモートクライアントと通信します。そして、Comm Server とアプ
リケーションサーバ間の通信には NonStop TS/MP が使用されます。
NonStop TS/MP プロトコルを介して通信できるようにするには、アプリケーションサーバを NonStop
TS/MP サーバとして構成しなければなりません。これには、スクリプトを使用して、PATHCOM プロセス
としてアプリケーションサーバを初期化することが最も簡単でます。NonStop DOM 製品では、このような
スクリプトの記述例をいくつか用意しています。
NonStop TS/MP プロトコルを使用して、NonStop DOM クライアントと NonStop DOM または NonStop
JORB アプリケーションサーバと通信させたい場合、クライアントプロファイルで以下を指定する必要が
あります。
tsmp_client
true
Configuration Tool を使用して、これをクライアントプロファイルに追加することができます。
さらに、NonStop DOM アプリケーションサーバのプロファイルで次のように指定していると仮定しま
す。
tsmp_server
tcp_server
use_comm_server
true
true
true
この場合、リモートクライアントは IIOP を介して TCP/IP を使用し、NonStop DOM アプリケーション
サーバと通信できます。このとき、クライアントは TCP/IP を介して Comm Server と通信し、Comm Server
はファイルシステムプロトコルを使用して要求をアプリケーションサーバに渡します。
さらに、NonStop DOM または NonStop DOM クライアントが同一サーバに要求する場合、クライアン
トは、IIOP を介して TCP/IP を使用することができます。その場合、クライアントのプロファイルでは次
のように指定しています。
tcp_client
2-40
true
140418J
第 3 章 NonStop DOM のランタイム管理
3.2.4 アプリケーションパフォーマンスの調整
NonStop DOM アプリケーションサーバに対してのアプリケーションパフォーマンスの調整には、次の
処理があります。
□ クライアント、サーバ、およびデータの相対的な最適ロケーションを決定する
□ アプリケーションサーバプールをうまく管理する
サーバプール管理には、各プールが要求するサーバプロセスの数を決定することと、サーバプロセスの
数が不足している以外の要因でパフォーマンスに問題が生じている場合を検出することとがあります。
一般に、ステートレスサーバプールのパフォーマンス調整は簡単です。十分なサーバプロセス数を確保
できるように PATHCOM 構成ファイルのサーバプールを定義すると、NonStop TS/MP は自動的にプロセ
スを追加および削除して、作業負荷の変化に適応させます ( ちょうど店が当番の店員数を変えるように )。
PATHCOM を使ってプール内のプロセスの使用を知ることによって、構成するプロセス数の最大数を増や
す必要があるかどうかの決定に役立てることができます。
ステートフルサーバプールの調整はこれよりも複雑です。特定のオブジェクトに対する全要求が、要求
の持続中、同一プロセスに送られるため ( サーバプール内の他のプロセスがアイドル状態であっても )、
NonStop TS/MP はプール内のサーバ間でロードバランシングを完全に実行することができません。同一オ
ブジェクトクラスに対する異なるインスタンスへの要求は、サーバプール内のプロセス間でロードバラン
シングができますが、1 つまたは複数のクライアントによる同一インスタンスへの要求は、同一サーバに
送らなければなりません。このため、いくつかのサーバプロセスがオーバーワークになっている一方で、
他のサーバプロセスはアイドル状態になっているということが起こります。
PATHCOM を使用して、そうした問題を検出することはできますが、問題を解決するにはしばしばアプ
リケーション設計の変更をともないます。解決策としては、たとえば、オブジェクトクラスを再定義して、
ステートレス要求をもっと受け入れるようにすることができます。また、アプリケーションオブジェクト
への要求をより小さくすることによって同一トランザクションを実行できるように、オブジェクトを再定
義することもできます。
3.2.5 アプリケーションのトラブルシューティング
NonStop DOM アプリケーションサーバのトラブルシューティングは、通常、プログラムのトラブル
シューティングが関係してきます。ただし、ときとして障害は不完全または不正確な構成が原因で生じま
す。NonStop DOM システムのトラブルシューティングに関する詳細は『プログラマーズ・ガイド』を参照
してください。
3.2.6 必要な予備知識
NonStop DOM アプリケーションコンポーネントを管理するには、以下についての知識が必要です。
□ NonStop TS/MP サーバプールを管理するための手順と要点。特にステートフルおよびステートレス処
理の管理方法
□ OSS (Open System Services) 環境でプロセスを管理するための手順と要点
□ 以下のユーティリティの構文と使用方法
●
140418J
PATHCOM 構成インタフェース
2-41
第 3 章 NonStop DOM のランタイム管理
●
TACL (OSS 環境での gtacl)
●
OSS シェルとユーティリティ
●
EMS (Event Management Service )
●
NonStop DOM エラーログファシリティとトレースファシリティ
□ NonStop TS/MP によって保護されているデータベースを管理するための手順と要点
『関連マニュアル』には、Tandem マニュアルおよびその他の NonStop DOM アプリケーションサーバ管
理に必要な情報を含んだ資料がリストされています。また、NonStop DOM アプリケーションと対話する他
のコンポーネントについても知る必要があるでしょう。
2-42
140418J
第 4 章 NonStop DOM サーバプールの構成
第 4 章 NonStop DOM サーバプールの構成
4.1 NonStop TS/MP プロセスの起動と停止
サブトピックス
□ PATHMON プロセスについて
□ スクリプトを使用した NonStop TS/MP の起動と停止
□
nsdstart スクリプトの使用
□
nsdstop スクリプトの使用
このトピックでは、システムに提供されているスクリプトを使用して NonStop DOM システムおよびそ
のアプリケーションサーバプロセスを起動・停止する方法を説明します。
4.1.1 PATHMON プロセスについて
NonStop DOM システムのサーバプロセスは、NonStop TS/MP のサービスを使用して構成されます。
NonStop TS/MP によって定義されているプロセスは、NonStop TS/MP モニタである、PATHMON プロセ
スの制御のもとで実行されます。PATHCOM は、PATHMON プロセスへのインタフェースを提供します。
NonStop TS/MP のもとで実行するプロセスを構成および起動するには、Guardian 環境で特定の一連の手
順を実行する必要があります。NonStop DOM に提供されている nsdstart スクリプトは、これらの手
順を自動的に実行します。nsdstart は OSS シェルから実行しますが、スクリプトは次のような
Guardian コマンドのセットを OSS 環境から実行します。
1. NonStop DOM のプロセス名 (Comm Server や Naming Server のプロセス名など ) を指定する環境変数
を設定します。
2. PATHMON プロセスを起動します。
3. PATHCOM を使用して、基本環境 ( プロファイル ) パラメータを設定します。このパラメータは、
NonStop DOM システムプロセスを実行する NonStop TS/MP 構成を定義するものです。
4. NonStop TS/MP 環境 (PATHMON 環境とも呼ばれる ) を起動します。
5. この PATHMON プロセスで実行される個々のサーバクラスを構成します。
NonStop TS/MP 環境は、env.sh および nsdstart スクリプトファイルで構成および起動されます。
この NonStop TS/MP 環境は、上記の手順 5 の後はいつでも、順番通りにシャットダウンすることができま
す。
PATMON プロセスと、スクリプトに使用される PATHCOM コマンドの詳細については、
『NonStop TS/
MP System Management Manual』を参照してください。
140418J
2-43
第 4 章 NonStop DOM サーバプールの構成
Tandem
備考 : NonStop DOM システムプロセスは、NonStop TS/MP のサービスによって構成・配布されています。
(Compaq) では、アプリケーションサーバプロセスの構成・配布にも NonStop TS/MP のサービスを利用す
ることを強くお勧めします。
4.1.2 スクリプトを使用した NonStop TS/MP の起動と停止
NonStop DOM では、OSS シェルスクリプト nsdstart を提供しています。nsdstart は、NonStop
TS/MP 環境を作成して、NonStop DOM プロセスを開始するコマンドセットを実行します。また、別のシェ
ルスクリプト nsdstop も提供しており、これは NonStop TS/MP 環境と実行中の全プロセスを終了しま
す。これらのスクリプトは、NonStop DOM セットアップ時の bin ディレクトリにあります。
NonStop DOM に用意されているサンプルアプリケーションのなかには、PATHMON プロセスの制御下
にある NonStop DOM アプリケーションサーバプロセスを作成、開始、停止するカスタムスクリプトを含
むものもあります。これらのスクリプトは、関連のサンプルアプリケーションのサブディレクトリに入っ
ています。必要であれば、これらのスクリプトを変更して、自分自身のアプリケーションサーバプロセス
を構成、起動、停止することができます。
備考 : スクリプトは個別のセットで用意されています。その理由は、NonStop DOM システムプロセス用の NonStop
TS/MP 環境と、NonStop TS/MP を使用して実装した任意のアプリケーションプロセス用の NonStop TS/
MP 環境という、2 つの固有の NonStop TS/MP 環境を作成することを強く推奨しているためです。
それぞれ固有の NonStop TS/MP 環境は、固有の PATHMON プロセスによって制御されています。自分
用の環境に多数の複雑なアプリケーションを含める場合に、より多くの NonStop TS/MP 環境に追加の
PATHMON プロセスを構成したいと考えることもあるでしょう。このような場合には、ガイドラインとし
て『NonStop TS/MP System Management Manual』を参照してください。
スクリプトの処理動作
nsdstart スクリプトを実行するたびに、nsdstart スクリプトは以下の処理を行います。
1. NonStop DOM のプロセス名 (Comm Server や Naming Server のプロセス名など ) を指定する環境変数
を設定します。
2. 基本パラメータを使用した新規の構成ファイルと、スクリプトに含まれるサーバプールの設定値を作成
します。
3. PATHMON プロセスを起動します。このスクリプトの実行は、「コールドスタート」処理を行います。
4. 定義されている全サーバプロセスを開始します。
nsdstop スクリプトは以下の処理を行います。
1. NonStop TS/MP 構成の全サーバプロセスをシャットダウンします。
2. 制御中の PATHMON プロセスを停止します。
スクリプトの使用と PATHCOM インタフェースの使用
スクリプトを用いて単一コマンドを実行することによって、構成全体を開始または停止することができ
ます。したがって、NonStop TS/MP 構成で基本パラメータを変更する必要がある場合、nsdstart ファ
2-44
140418J
第 4 章 NonStop DOM サーバプールの構成
イルでそれらのパラメータを編集して、次にスクリプトを実行できます。(NonStop DOM システムが実行
中の場合は、nsdstop スクリプトを実行してから nsdstart スクリプトでシステムを再起動してくだ
さい。)
一方、NonStop TS/MP 構成の基本構成パラメータを変更していなくて、その NonStop TS/MP 構成を再
起動する必要がある場合、PATHMON プロセスのインタフェースである PATHCOM を使用してそれを行
うことができます。同様に、単一のサーバプールまたはサーバプロセスの属性を変更する必要がある場合、
NonStop TS/MP 環境全体を停止する必要はありません。PATHCOM インタフェースを使用すると、より効
率的に 1 つまたは複数のサーバプロセスを変更することができます。これについては「PATHCOM インタ
フェース を使用して NonStop TS/MP プロセスを維持するには」の解説に従ってください。
4.1.3 nsdstart スクリプトの使用
nsdstart を実行する前には 必ず、env.sh ファイルをソース化した かを確認してください。
env.sh ファイルは、環境設定をご利用の OSS シェル環境にロードします。
.profile ファイルで env.sh ファイルをソース化すると、シェルを入力するたびに NonStop DOM
環境設定は自動的にロードされます。
通常、nsdstart スクリプトは実行してもそれを表示しません。ただし、スクリプトオプションの v を nsdstart コマンドに付けて実行すると、スクリプトコマンドの長いリストが表示されます。次の
リストは、-v オプションを使用したときの nsdstart スクリプトの実行を示します。
nsdstart コマンドの実行
/nsdoms> nsdstart -v
$Z06T: PATHCOM - T8344D42 - (03JUN96)
COPYRIGHT TANDEM COMPUTERS INCORPORATED 1980 - 1985, 1987 - 1996
=
=
set pathway maxassigns
8
=
set pathway maxparams
8
=
set pathway maxserverclasses
4
=
set pathway maxserverprocesses 40
=
set pathway maxstartups
40
=
set pathway maxtcps
0
=
set pathway maxterms
0
=
set pathway maxdefines
27
=
set pathway maxpathcoms
8
=
set pathway maxspi
8
=
set pathway maxlinkmons
16
=
set pathway maxexternaltcps
0
=
set pathway maxprograms
4
=
=
start pathway cold !
PATHWAY CONTROL FILE DATED: 25 MAR 1998, 16:44:39
=
=[ configure LSD
=
=
reset server
=
=
set server processtype oss
=
set server pri
150
=
set server cwd
/usr/tandem/nsdoms
=
set server program
/usr/tandem/nsdoms/bin/lsd
=
=
set server hometerm $ztnt.#pty000a
140418J
2-45
第 4 章 NonStop DOM サーバプールの構成
=
set server stdin /dev/null
=
set server stdout /usr/tandem/nsdoms/log/lsd.out
=
set server stderr /usr/tandem/nsdoms/log/lsd.out
=
=
[ set server debug on
=
[ set server env NSDOM_CFG_TRACE_ORB=TRUE
=
[ set server env NSDOM_CFG_TRACE_GIOP_FW=TRUE
=
[ set server env NSDOM_CFG_TRACE_SOCKEH=TRUE
=
=
set server env NSDOM_CFG_DBM=$SYSTEM.ZDOMSD20.NSDCFGDB
=
set server env MY_PREFIX=Z
=
set server define =_SRL_01, class map, file
$SYSTEM.ZDOMSD20.NSDSRL
=
=
set server createdelay 0 secs
=
set server deletedelay 0 secs
=
set server TIMEOUT
0 SECS
=
set server MAXLINKS
16
=
set server LINKDEPTH
1
=
=
set server maxservers 1
=
set server numstatic 1
=
set server cpus (1,2)
=
=
set server AUTORESTART 10
=
set server arglist "-ORBprofile", "lsd1"
=
add server LSD
=
start server LSD
$Z06T: SERVER LSD, STARTED
=
=[ configure comm server(s)
=
=
reset server
=
=
set server processtype oss
=
set server pri
150
=
set server cwd
/usr/tandem/nsdoms
=
set server program
/usr/tandem/nsdoms/bin/cs
=
=
set server hometerm $ztnt.#pty000a
=
set server stdin /dev/null
=
set server stdout /usr/tandem/nsdoms/log/cs.out
=
set server stderr /usr/tandem/nsdoms/log/cs.out
=
=
[ set server debug on
=
[ set server env NSDOM_CFG_TRACE_CS=TRUE
=
[ set server env NSDOM_CFG_TRACE_SOCKEH=TRUE
=
[ set server env NSDOM_CFG_TRACE_GFSEH=TRUE
=
[ set server env NSDOM_CFG_TRACE_GCFEH=TRUE
=
=
set server env NSDOM_CFG_DBM=$SYSTEM.ZDOMSD20.NSDCFGDB
=
set server define =_SRL_01, class map, file
$SYSTEM.ZDOMSD20.NSDSRL
=
=
set server createdelay 0 secs
=
set server deletedelay 0 secs
=
set server TIMEOUT
0 SECS
=
set server MAXLINKS
16
=
set server LINKDEPTH
1
=
2-46
140418J
第 4 章 NonStop DOM サーバプールの構成
=
set server maxservers 2
=
set server numstatic 2
=
set server process
$ZNCA (cpus 1:2)
=
set server process
$ZNCB (cpus 2:1)
=
=
set server AUTORESTART 10
=
add server CS
=
start server CS
$Z06T: SERVER CS, STARTED
=
=[ configure naming service
=
=
reset server
=
=
set server processtype oss
=
set server pri
150
=
set server cwd
/usr/tandem/nsdoms
=
set server program
/usr/tandem/nsdoms/bin/name_servant
=
=
set server hometerm $ztnt.#pty000a
=
set server stdin /dev/null
=
set server stdout /usr/tandem/nsdoms/log/ns.out
=
set server stderr /usr/tandem/nsdoms/log/ns.out
=
=
[ set server debug on
=
[ set server env NSDOM_CFG_TRACE_POA=TRUE
=
[ set server env NSDOM_CFG_TRACE_PROXY=TRUE
=
[ set server env NSDOM_CFG_TRACE_ORB=TRUE
=
[ set server env NSDOM_CFG_TRACE_GIOP_FW=TRUE
=
[ set server env NSDOM_CFG_TRACE_GFSEH=TRUE
=
[ set server env NSDOM_CFG_TRACE_GCFEH=TRUE
=
=
set server env NSDOM_CFG_DBM=$SYSTEM.ZDOMSD20.NSDCFGDB
=
set server define =_SRL_01, class map, file
$SYSTEM.ZDOMSD20.NSDSRL
=
=
set server createdelay
0 secs
=
set server deletedelay 15 secs
=
set server TIMEOUT
30 SECS
=
set server MAXLINKS
16
=
set server LINKDEPTH
4
=
=
set server maxservers 4
=
set server numstatic 2
=[ the following process 689111070NAME_SERVER will be used to
support the file
=[ system protocol access.
=
set server process $ZND0 (cpus 1:2)
=
set server cpus (2:1,3:2,2:3)
=
=
set server AUTORESTART 10
=
set server arglist "-ORBprofile", "NS"
=
add server NS
=
start server NS
$Z06T: SERVER NS, STARTED
=
=[ configure Event Service
=
=
reset server
=
140418J
2-47
第 4 章 NonStop DOM サーバプールの構成
=
set server processtype oss
=
set server pri
150
=
set server cwd
/usr/tandem/nsdoms
=
set server program
/usr/tandem/nsdoms/bin/EventService
=
=
set server hometerm $ztnt.#pty000a
=
set server stdin /dev/null
=
set server stdout /usr/tandem/nsdoms/log/es.out
=
set server stderr /usr/tandem/nsdoms/log/es.out
=
=
[ set server debug on
=
[ set server env NSDOM_CFG_TRACE_ES=TRUE
=
=
set server env NSDOM_CFG_DBM=$SYSTEM.ZDOMSD20.NSDCFGDB
=
set server define =_SRL_01, class map, file
$SYSTEM.ZDOMSD20.NSDSRL
=
=
set server createdelay 0 secs
=
set server deletedelay 0 secs
=
set server MAXLINKS
16
=
set server LINKDEPTH
1
=
=
set server maxservers 1
=
set server numstatic 1
=
set server cpus (1,2)
=
=
set server AUTORESTART 10
=
set server arglist "-ORBprofile", "event_service"
=
add server ES
=
start server ES
$Z06T: SERVER ES, STARTED
=
備考 : NonStop DOM の Software Development Kit (SDK) 版をインストールしていた場合、ファイルはサブディ
レクトリ ZDOMSD20 にインストールされています。NonStop DOM のランタイム版を使用している場合
は、NonStop DOM ファイルセットは サブディレクトリ ZDOMRT20 にあります。
システムのメッセージは、ホームターミナルの Guardian 名が
$ztnt.#pty000a であることと、
Z06T PATHMON プロセスと NonStop TS/MP 環境が問題なく開始されていることを確認しています。ま
た、各サーバプールが nsdstart スクリプトによって定義および開始されると、PATHCOM もメッセー
ジを表示します。
LSD および Comm Server プロセスだけが、スタティックサーバとして構成されなければならないシステ
ムプロセスですが、デフォルトの nsdstart スクリプトでは全システムプロセスをスタティックサーバ
として定義し、全プロセスを開始します。
対象となっている NonStop TS/MP 環境がすでに実行しているとき、nsdstart を実行しようとする
と、エラーメッセージが表示されます。次の例は、NonStop DOM に対して NonStop TS/MP 環境がすでに
実行しているとき、nsdstart ファイルを実行した場合の結果表示です。
nsdstart コマンドの実行 : エラー状態
/nsdoms> nsdstart -v
gtacl[5]: unable to run $SYSTEM.SYSTEM.PATHMON, error (11, 12):
\
process name error - The file is in use
2-48
140418J
第 4 章 NonStop DOM サーバプールの構成
$Z070: PATHCOM COPYRIGHT TANDEM
=
=
set pathway
set pathway
$Z070: ERROR
T8344D42 - (03JUN96)
COMPUTERS INCORPORATED 1980 - 1985, 1987 - 1996
maxassigns
maxassigns
8
8
- *1009* PATHWAY CONFIGURATION CAN’T BE CHANGED
この例では、スクリプトは、起動コマンドを伝えるために、NonStop DOM システムプロセス対応の
PATHMON プロセスをオープンしようとしてようとしています。しかし、システムは、プロセスがすでに
使用中であることを検知して、エラーメッセージを返しています。
4.1.4 nsdstop のスクリプトの使用
NonStop DOM システムが構成され開始された後、nsdstop スクリプトを使用して NonStop DOM シ
ス テム を停 止し ます。シ ステ ムが シャ ット ダウ ンし てい るこ とを 確認 する ため に、NonStop DOM
PATHMON プロセスで状態コマンドを実行することができます。この PATHMON プロセスのデフォルト
は $ZNDM です。
4.2 PATHCOM インタフェース を使用して NonStop TS/MP プロセスを維
持するには
サブトピックス
□ PATHCOM インタフェースの使用
□ プロセスの起動と再起動
□ ステータスの監視
□ 変更要件に基く基本パラメータの修正
□ サーバプールの再構成
NonStop TS/MP のサービスを使用して、NonStop DOM システムのサーバプロセスを構成します。
NonStop TS/MP によって定義されているプロセスは、NonStop TS/MP モニタである、PATHMON プロセ
スの制御のもとで実行されます。
PATHCOM は PATHMON プロセスへのインタフェースを提供します。
Guardian 環境で TACL プロンプトから、PATHCOM プロセスを起動します。これらのプロセスの開始
手順について詳しくは、『NonStop TS/MP System Management Manual』を参照してください。ここには、
全 PATHCOM コマンドの詳細な構文と記述も記載されています。
このトピックでは、PATHCOM を使用して、NonStop TS/MP 構成でグローバルおよびプロセス固有の
構成パラメータを変更する方法の概要について解説します。
NonStop DOM システムとアプリケーションプロセスの維持および微調整には、以下のタスクが含まれ
ます。
□ PATHCOM インタフェースを使用することによってステータスとパフォーマンスを監視し、NonStop
140418J
2-49
第 4 章 NonStop DOM サーバプールの構成
TS/MP 環境およびサーバプールに関する情報を表示する。
□ 変更要件に基いてグローバルパラメータを修正する。
□ パフォーマンスキューまたは変更要件に基づいてサーバプールとプロセスを追加、削除、または修正す
る。
□ ロードバランシングの問題などのパフォーマンスの留意点に基づいて変更する。
4.2.1 PATHCOM インタフェースの使用
NonStop DOM に用意されている OSS スクリプトを使用することによって、単一コマンドを実行して
NonStop TS/MP 構成を起動 ( または停止 ) することができます。これらのスクリプトで NonStop DOM シ
ステムプロセスのすべてをコールドスタートおよび停止することが可能ですが、これらのスクリプトは実
行システムを適切に管理するために必要となる制御を欠いています。
nsdstart スクリプトはコールドスタートを実行して構成をブートし、それによって PATHMON が
NonStop TS/MP 構成ファイル全体を再構築します。この処理は時間が長くなる可能性があります。グロー
バル構成パラメータを変更しなかった場合は、この構成ファイルを再構築する必要はありません。
PATHCOM を使用すると、既存の NonStop TS/MP システム構成を再構築せずに、PATHMON プロセス
を直接管理することができます。
PATHCOM プロセスの起動
PATHCOM コマンドを実行するには、まず PATHCOM プロセスを起動して、NonStop TS/MP 環境を制
御する PATHMON プロセスと通信する必要があります。TACL プロンプトで次のように入力します。
> PATHCOM $ pmon
このコマンドでは、$pmon パラメータに PATHMON プロセス名を指定して ( たとえば
$nsdm)、
PATHCOM セッションを開始します。システムは、次のような PATHCOM プロンプトを返します。
=
4.2.2 プロセスの起動と再起動
PATHCOM インタフェースを使用して実行できることの 1 つに、NonStop DOM システムプロセスの再
起動があります。以下の手順を実行します。
1. 実行中の PATHMON プロセスと通信するために、PATHCOM プロセスを開始します。
2. PATHMON プロセスを再開します。
以下のコマンドを考えてみます。
> PATHMON /NAME $NSDM, NOWAIT/
> PATHCOM $NSDM
= START PATHWAY COOL
最初の TACL コマンドは、プロセス名が
$NSDM の PATHMON プロセスを起動します。2 番目のコマ
ンドでは、PATHCOM プロセスを開始して実行中の PATHMON プロセスと通信します。
2-50
140418J
第 4 章 NonStop DOM サーバプールの構成
そして、既存の構成ファイルを使用して、PATHCOM プロンプトから、$NSDM 構成を再起動します。
これは、START
PATHWAY コマンドの開始オプション COOL を使用して実行します。
COOL コマンドは、PATHMON プロセスが、指定された任意の PATHMON バックアッププロセスを開
始して操作環境の構築に基づいて既存の構成ファイルを使用するように指示します。既存の構成ファイル
には、システムが停止した ( シャットダウンまたは障害のため ) ときの PATHMON 構成が含まれます。
4.2.3 ステータスの監視
PATHMON プロセスは、プロセスの構成、プロセスのステータス、および操作統計の情報を保持しま
す。表 2-1 は PATHCOM コマンドとその実行結果の一覧です。
表 2-1 PATHCOM コマンド
PATHCOM コマンド
実行結果
INFO
現行の構成情報を返す
STATUS
現行のプロセス状態を返す。たとえば、RUNNING、STOPPED、
または SUSPENDED。
STATS
プロセスの利用統計を返す
これらのコマンドによって得られるステータスおよび統計情報は、そのほとんどが Pathsend API と
LINKMON プロセスによって収集されています。
Pathsend API は、Tandem ベースのクライアントが NonStop TS/MP サーバプロセスにアクセスするため
に使用するプロシージャコールを提供します。LINKMON プロセスはリンクマネージャであり、Pathsend
要求に対してリンク管理機能を提供します。
備考 : 統計情報は Comm Server と LSD には使用できません。情報を収集する Pathsend API または LINKMON
プロセスが、Comm Server と LSD にアクセスしないからです。ただし、Naming Server と Event Server
に対して、および NonStop TS/MP アプリケーションサーバプロセスのすべてに対しては、ステータスおよ
び統計情報が取得可能です。
構成情報の表示
構成情報を表示するには、INFO コマンドを使用します。NonStop TS/MP 環境全体について、PATHMON
プロセスについて、環境内の特定のサーバプールについての構成情報を表示するために、以下のコマンド
を使用できます。
□ INFO PATHWAY
□ INFO PATHMON
□ INFO SERVER
INFO PATHWAY コマンド
NonStop TS/MP 環境全体の基本パラメータを表示するには、次のように入力します。
= INFO PATHWAY
140418J
2-51
第 4 章 NonStop DOM サーバプールの構成
次の例は、NonStop DOM システムプロセスを実行中の NonStop TS/MP 環境に対して INFO PATHWAY
を実行したときに表示される情報です。
INFO PATHWAY の表示
=info pathway
PATHWAY
MAXASSIGNS 8
MAXDEFINES 27
MAXEXTERNALTCPS 0
MAXLINKMONS 16
MAXPARAMS 4
MAXPATHCOMS 8
MAXPROGRAMS 4
MAXSERVERCLASSES 4
MAXSERVERPROCESSES 40
MAXSPI 8
MAXSTARTUPS 4
MAXTCPS 0
MAXTELLQUEUE 4
MAXTELLS 32
MAXTERMS 0
MAXTMFRESTARTS 5
OWNER \OSS2.190,0
SECURITY "N"
=
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
[CURRENTLY
0]
4]
0]
0]
0]
1]
0]
4]
8]
0]
0]
0]
[CURRENTLY 0]
[CURRENTLY 0]
この 出力 は、グロ ーバ ル NonStop TS/MP 環 境変 数 の現 行値 を示 して いま す。これ らの 変数 は、
nsdstart シェルスクリプトによって設定されているか、または SET PATHWAY コマンドを使用して
値を入力することによって設定されています。
備考 : NonStop DOM アプリケーションに対して関係のないパラメータもあり、それらは NonStop DOM システム
を構成する際にゼロに設定してあります。MAXEXTERNALTCPS、MAXTCPS、MAXTERMS といったパ
ラメータがそれに該当します。
INFO コマンドを使用すると、現行の基本パラメータの制限値に達しているかがわかります。表示の左
に最大制限値、右に実際の現行トータル値が示されます。上記の例の構成では、任意の時間に実行される
最大サーバプロセスは 40 であり、実行中のサーバプロセスの現行トータルは 8 サーバプロセスです。全グ
ローバルパラメータの詳細な構文と記述については、『NonStop TS/MP System Management Manual』を参
照してください。
INFO PATHMON コマンド
PATHMON プロセスのパラメータセットに関する情報を表示するには、次のような PATHCOM コマン
ドを入力します。
= INFO PATHMON
次は、INFO PATHMON コマンドを実行したときに表示される情報の例です
INFO PATHMON の表示
PATHMON
BACKUPCPU 4
2-52
140418J
第 4 章 NonStop DOM サーバプールの構成
DUMP ON (FILE \SYS.$VOL1.TESTING.MONDUMP)
このサンプル表示は、CPU 4 で実行している PATHMON バックアッププロセスを示しています。
P A T H M O N プロ セス が内 部エ ラー に遭 遇し た場 合、デー タス タッ ク情 報を \ SYS .$V OL1 .
TESTING.MONDUMP に出力します。
INFO SERVER コマンド
次は、単一サーバプールの構成パラメータを表示するために入力するコマンド例です。
= INFO SERVER CS
このコマンドにおける CS は、NonStop TS/MP 構成でサーバに対して定義されている論理名を示します。
この例では、コマンドは Comm Server のパラメータを表示します。これらは、NonStop TS/MP 構成が
nsdstart スクリプトまたは PATHCOM インタフェースによって作成されたとき、SET SERVER コマ
ンドで定義された属性です。
INFO SERVER の表示
= info server cs
SERVER CS
PROCESSTYPE OSS
AUTORESTART 10
CREATEDELAY 0 SECS
CWD /cust7/r1488.user/tandem/nsd2.0/nsd.e05
DEBUG OFF
DEFINE =_SRL_01,CLASS MAP,
FILE \OSS2.$DATA07.NSDE5.NSDSRL
DELETEDELAY 0 SECS
ENV NSDOM_CFG_DBM=$DATA07.NSDE5.NSDCFGDB
HIGHPIN OFF
HOMETERM \OSS2.$ZTN0.#PTPFULC
LINKDEPTH 1
MAXLINKS 16
MAXSERVERS 2
NUMSTATIC 2
OWNER \OSS2.190,0
PRI 150
PROCESS $YC01 (CPUS 0:1)
PROCESS $YC02 (CPUS 1:0)
PROGRAM /cust7/tandem/nsd2.0/nsd.e05/bin/cs
SECURITY "N"
STDERR /cust7/tandem/nsd2.0/nsd.e05/log/cs.out
STDIN /dev/null
STDOUT /cust7/tandem/nsd2.0/nsd.e05/log/cs.out
TIMEOUT 0 SECS
TMF OFF
VOLUME \OSS2.$DATA07.DEREK
=
140418J
2-53
第 4 章 NonStop DOM サーバプールの構成
ステータス情報の表示
STATUS コマンドを使用して、NonStop TS/MP 環境、PATHMON プロセス、およびサーバオブジェク
トについての各ステータス情報を表示します。
環境ステータスの表示
NonStop TS/MP 環境全体に対するステータスを表示するには、次の PATHCOM コマンドを実行します。
= STATUS PATHWAY
以下は、このコマンドを実行したときに表示される環境の状態 ( 例 :
RUNNING) の表示例です。実行、
停止、解除などの状態にあるサーバプールの数、サーバプロセス数、LINKMON の数も表示されます。
STATUS PATHWAY の表示
= status pathway
PATHWAY -- STATE=RUNNING
RUNNING
EXTERNALTCPS
0
LINKMONS
0
PATHCOMS
1
SPI
0
RUNNING STOPPED
THAWED
SERVERCLASSES
3
1
4
RUNNING STOPPED PENDING
SERVERPROCESSES
7
1
0
TCPS
0
0
0
RUNNING STOPPED PENDING
TERMS
0
0
0
=
FROZEN
0
FREEZE
PENDING
0
SUSPENDED
0
PATHMON ステータスの表示
PATHMON プロセスに関する情報を表示するには、次のように入力します。
= STATUS PATHMON
この
STATUS コマンドは、PATHMON プロセスが実行している場所、PATHMON 制御ファイルが置
かれている場所、ログファイルがオープンしているかどうかといった情報を表示します。
STATUS PATHMON の表示
= status pathmon
PATHMON \OSS2.$YNSD2 -- STATE=RUNNING
PATHCTL (OPEN)
$DATA07.DEREK.PATHCTL
LOG1 S
(CLOSED)
\OSS2.$Z6GR.#INTER
LOG2
(CLOSED)
REQNUM
1
FILE
PATHCOM
PID
$Z7YJ
PAID
190,0
CPUS 1:0
ERROR=201
WAIT
=
2-54
140418J
第 4 章 NonStop DOM サーバプールの構成
サーバプールのステータスの表示
ORDR-1 という名前の 単一サーバプールのステータス情報を表示する場合、次のように入力します。
= STATUS SERVER ORDR-1
実行、フリーズ、解除、または停止といった各状態のサーバプロセス数を表示します。また、STATUS
SERVER コマンドにオプションを付けて実行することもできます。これによってコマンドは、たとえば、
サーバプールで実行している各プロセスについての詳細情報を提供したり、複数のサーバプールのステー
タスを表示します。
STATUS SERVER コマンドの有効なバリエーションの 1 つに PROCESSES オプションがあります。
これを使用すると、現在サーバプロセスにリンクしている LINKMON プロセスを一覧表示することができ
ます。コマンドは次のようになります。
= STATUS SERVER <server-name>, PROCESSES
ここで、<server-name> には、情報表示の対象となるサーバ名を指定します。
次の例では、コマンド出力によって OSS サーバプール
ORDR-2 のリンクが表示されています。この
サーバプールでは、$ZTX0、$ZTX1、$ZTX2、$ZTX3、$ZTX4 という 5 つのプロセスが実行してお
り、$ZTX6 というサーバプロセスが停止しています。実行プロセスのいくつかが、複数の LINKMON プ
ロセスにリンクしていることに注意してください (LINKER 欄を参照 )。
STATUS SERVER の表示
SERVER
ORDR-2
PROCESS
$ZTX0
#RUNNING
4
STATE
RUNNING
LINKER
L¥SYS.$ZL12
L¥SYS.$ZL13
PROCESS
$ZTX1
STATE
RUNNING
LINKER
L¥SYS.$ZL14
PROCESS
$ZTX2
STATE
RUNNING
LINKER
L¥SYS.$ZL15
L¥SYS.$ZL10
PROCESS
$ZTX3
STATE
RUNNING
LINKER
L¥SYS.$ZL08
L¥SYS.$ZL09
140418J
ERROR
INFO
ERROR
INFO
#LINKS
5
WEIGHT
11
#LINKS
3
WEIGHT
08
#LINKS
2
WEIGHT
05
#LINKS
6
WEIGHT
12
LINK COUNT
003
002
ERROR
INFO
LINK COUNT
003
ERROR
INFO
LINK COUNT
001
001
ERROR
INFO
LINK COUNT
003
003
2-55
第 4 章 NonStop DOM サーバプールの構成
PROCESS
$ZTX4
STATE
RUNNING
LINKER
L¥SYS.$ZL01
L¥SYS.$ZL02
PROCESS
$ZTX6
ERROR
INFO
#LINKS
3
WEIGHT
07
#LINKS
0
WEIGHT
0
LINK COUNT
001
002
STATE
STOPPED
ERROR
INFO
STATUS SERVER コマンドに PROCESSES オプションを付けると、リンクは均一に割当てられてい
ているか、NonStop DOM アプリケーション環境で複数のサーバプロセス間で平均的に割当てられているか
どうかを判断する助けとなります。
#LINKS フィールドには、任意のサーバプロセスに割当てられている現行リンクの総数が表示されます。
WEIGHT フィールドには、そのサーバプロセスが、サーバプール内の他のプロセスの使用量に相対してど
の程度使用されているかが表示されます。上記の例では、$ZTX3 プロセスでは 6 リンクが割当てられて
おり、使用ウエイトが 12 です。したがって、$ZTX3 がこの時点でのサーバプール内で最も作業量の多い
プロセスになっています。
統計情報の表示
PATHMON プロセスに関する統計情報を表示するには、次のような PATHCOM コマンドを入力します。
= STATS PATHMON
このコマンドの実行出力については詳しくは、PATHMON のマニュアルを参照してください。
4.2.4 変更要件に基く基本パラメータの修正
アプリケーションのニーズが変わるにつれて、NonStop TS/MP 構成の要件も変化します。アプリケー
ションを拡張する場合、トランザクションのスループットおよび応答時間の要件を満たし、システムの更
新または拡張で必要なリソースを提供するように、調整が必要です。
たとえば、サーバへのリンク需要の増大に対応するために、可能なアプリケーションサーバプロセスの
最大数を増やす必要があるとします。変更要件に対応して、サーバプールの新しい属性だけなく、NonStop
TS/MP 環境の新しい限界値およびパラメータを指定する必要があるでしょう。
注意 : PATHMON 環境が実行している間は、新しい基本パラメータを指定できません。まず最初に構成全体をシャッ
トダウンしてから、新しいパラメータを設定してください。
アプリケーションが複雑な場合、システムをシャットダウンするとかなりのダウン時間が生じるので、
最初に環境を構成するときに、拡張が十分可能であるようにあらかじめ限界値を高く設定しておくことを
お勧めします。
基本パラメータを再構成しなければならない場合、強制的にシャットダウンを実行して、変更する限界
だけでなく、すべての限界を再指定する必要があります。このため、PATHCOM を使用して各パラメータ
を指定していくよりも、nsdstart を編集して基本パラメータを変更するほうが効率的です。
2-56
140418J
第 4 章 NonStop DOM サーバプールの構成
Nsdstart スクリプトで関係のあるパラメータを編集して基本パラメータを変更したら、スクリプト
を実行して、新規パラメータで NonStop TS/MP 環境をコールドスタートします。
PATHCOM を使用して全パラメータを再指定する場合、必ず SET PATHWAY コマンドのスタートオ
プション COLD を使用して、NonStop TS/MP 環境を再起動してください。
4.2.5 サーバプールの再構成
アプリケーションの要件やパフォーマンスキューを変更した場合、サーバリソースの再構成が必要にな
ることがあります。たとえば、ある特定のアプリケーションサーバプールが想定していた要求よりも多く
の要求を処理しているとき、一方で他のアプリケーションサーバプールでは想定していた数の要求以下し
か受け取っていないことがわかったとします。この状態に対処する 1 つの方法は、前者のサーバプールに
対して開始されるプロセスの最大数を増大することです。より複雑なアプローチをとるのであれば、前者
のサーバプールへのリンクアクセスを見なおして、LINKDEPTH や MAXLINKS などのリンク関連のサー
バ属性を修正します。
これらの属性および、それらを使用してサーバプロセス間でのロードバランシングをうまく実行するた
めの方法については、「アプリケーションサーバプロセスのロードバランシング」を参照してください。
環境をシャットダウンして、サーバプールを再構成する必要はありません。nsdstart スクリプトを
編集および実行する場合は完全に環境をシャットダウンする必要があるので、適切な PATHCOM コマンド
を使用してサーバプールを再構成するほうが効率的であるといえるでしょう。
サーバプールの追加
サーバプールを追加するには、SET SERVER および ADD SERVER コマンドを使用します。その後、
START SERVER コマンドを使用してそれを開始します。どのように処理されているのかについて詳し
くは、nsdstart スクリプトを参照してください。
実行中のサーバプールの修正
実行中のサーバプールを削除または変更するには、以下の手順を実行してください。
1. サーバプールをフリーズします
2. サーバプールを停止します
3. サーバプールを削除または変更します
4. 修正済みのサーバプールを解除します
5. 修正済みのサーバプールを開始します
実行中のサーバプールの停止
実行中のサーバプールを修正する前に、必ずそれを停止する必要があります。まず最初に、FREEZE
SERVER コマンドで環境内の他のプロセスとのサーバ通信を使用不可にします。サーバプールをフリーズ
した後は、STOP SERVER コマンドを実行してサーバプールを停止することができます。
たとえば、以下のコマンドによって、サーバプール SVR-2 内の全サーバプロセスが停止します。
= FREEZE SERVER SVR-2
= STOP SERVER SVR-2
140418J
2-57
第 4 章 NonStop DOM サーバプールの構成
NonStop TS/MP 構成における全サーバプールを停止するには、以下の 2 種類のコマンドを使用します。
= FREEZE SERVER *
= STOP SERVER *
サーバプールがフリーズまたは停止していることを確認するには、STATUS SERVER コマンドを使用し
ます。
サーバプールが停止した後は、PATHCOM コマンドを使用して、サーバプールを削除したりサーバ属性
を変更することができます。
サーバプールの再開
サーバプール SVR-2 を再開するには、まず最初にサーバを解除し、次にそれを開始します。次の よう
に 2 種類のコマンドを使用します。
= THAW SERVER SVR-2
= START SERVER SVR-2
以下のコマンドを実行すると、全サーバプロセスが再開します。
= THAW SERVER *
= START SERVER *
サーバプールの変更
ALTER SERVER コマンドを使用することによって、サーバプールを変更します。たとえば、以下の
一連のコマンドは、サーバ TRANS-1 が実行する優先度を変更します。
ALTER SERVER コマンド
=
=
=
=
=
FREEZE SERVER TRANS-1
STOP SERVER TRANS-1
ALTER SERVER TRANS-1, PRI 50
THAW SERVER TRANS-1
START SERVER TRANS-1
FREEZE コマンドが STOP および ALTER コマンドより先にくることに注意してください。また、
THAW コマンドは、START コマンドより先に実行しなければなりません。
4.3 サーバプールの PATHMON プロセスへの割当て
サブトピックス
□
nsdstart の編集によるサーバプロセスの追加
□
nsdstart の編集によるプールプロセスの削除
NonStop DOM アプリケーションサーバプールを既存の PATHMON プロセスに追加する場合、NonStop
DOM システムを実行している PATHMON プロセスにサーバプールを追加するための手順に従うことがで
きます。サーバプールプロセスの削除も事実上同じです。
NonStop DOM システムで、サーバプールプロセスを追加および削除するには、nsdstart スクリプ
2-58
140418J
第 4 章 NonStop DOM サーバプールの構成
トを編集します。これについて以下のサブトピックスで、Comm Server をサーバプールプロセスの例とし
て用いて解説します。ユーザのアプリケーションサーバを実行しているプロセスなどのような他の
PATHMON プロセスからサーバプロセスを追加および削除する場合も、同じ手順に従います。
備考 : NonStop DOM PATHMON プロセスの設定を変更する場合、NonStop DOM システムの構成データベース
も同時に変更する必要があります。
また、実行中の PATHMON プロセスのサーバプール設定を変更できないことに注意してください。ま
ず最初にプロセスをシャットダウンしなければなりません。
4.3.1 nsdstart の編集によるサーバプロセスの追加
現在実行中の NonStop DOM システムに $ZC01 と $ZC02 という 2 つの Comm Server が含まれている
とします。
そして、
ここに 3 番目の $ZC03 という名前の Comm Server プロセスを追加することを考えます。
備考 : このセクションの例では、 env.sh スクリプトの
のと仮定します。
MY_PREFIX を Z 値に等しくなるように設定したも
1. NonStop DOM システムプロセスが実行中の場合、OSS から nsdstop スクリプトを実行してそれら
のプロセスを停止します。
> nsdstop
2. nsdstart スクリプトのなかの Comm Server を指定するセクションを探します。次の例が、2 つの
プロセスの Comm Server を構成する、nsdstart のセクションです。
2 つの Comm Server の構成
#...
COM_SERVER1="$MY_PREFIX"c01
COM_SERVER2="$MY_PREFIX"c02
#...
set server maxservers 2
set server numstatic 2
set server process
\$$COM_SERVER1 (cpus 1)
set server process
\$$COM_SERVER2 (cpus 0)
set server AUTORESTART 10
add server CS
start server CS
#...
3. このセクションを編集して、もう 1 つのサーバプロセス $ZC03 を追加します。次のようにします。
Comm Server を nsdstart スクリプトに追加
#...
COM_SERVER1="$MY_PREFIX"c01
COM_SERVER2="$MY_PREFIX"c02
#...
set server
set server
set server
set server
set server
set server
add server
140418J
maxservers 3
numstatic 3
process
\$$COM_SERVER1 (cpus 1)
process
\$$COM_SERVER2 (cpus 0)
process
\ZC03 (2:3)
AUTORESTART 10
CS
2-59
第 4 章 NonStop DOM サーバプールの構成
start server CS
#...
4. 必ず新しい Comm Server プロセス $ZC03 を構成データベースに追加します。詳細は、
「NonStop DOM
の構成」および「Configuration Tool の使用」を参照してください。
5. OSS から nsdstart スクリプトを実行して、NonStop DOM システムプロセスを再起動します。
> nsdstart
4.3.2 nsdstart の編集による Comm Server プールプロセスの削除
現在の NonStop DOM システムが 2 つの Comm Server $ZC01 と $ZC02 を含むように構成されている
とします。ここから $ZC02 プロセスを削除することを考えます。
1. NonStop DOM システムプロセスが実行中の場合、OSS から nsdstop スクリプトを実行してそれら
のプロセスを停止します。
> nsdstop
2. nsdstart スクリプトのなかの Comm Server 仕様のセクションを探します。次の例が、2 つのプロ
セスを含む Comm Server を構成する nsdstart のセクションです。
2 つの Comm Server の構成
#...
COM_SERVER1="$MY_PREFIX"c01
COM_SERVER2="$MY_PREFIX"c02
#...
set server maxservers 2
set server numstatic 2
set server process
\$$COM_SERVER1 (cpus 0:1)
set server process
\$$COM_SERVER2 (cpus 1:0)
set server AUTORESTART 10
add server CS
start server CS
#...
3. このセクションを編集して、$ZC02 を削除します。次のようにします。
nsdstart からの Comm Server の削除
#...
COM_SERVER1="$MY_PREFIX"c01
#...
set server maxservers 2
set server numstatic 2
set server process
\$$COM_SERVER1 (cpus 0:1)
set server AUTORESTART 10
add server CS
start server CS
#...
2-60
140418J
第 4 章 NonStop DOM サーバプールの構成
4. Configuration Tool を使用して、構成データベースから $ZC02 を削除します。これらのホストからの
要求を受信し続ける場合は、残りの Comm Server プロセスにそれらを関連づけるか、ダイナミック関
連付け機能を用いてサーバを要求に割当てる必要があります。
5. OSS から nsdstart スクリプトを実行して、NonStop DOM システムプロセスを再起動します。
> nsdstart
4.4 NonStop TS/MP パフォーマンスの注意点
サブトピックス
□ ダイナミックおよびスタティックアプリケーションサーバプロセスの構成
□ Comm Server プロセス間でのクライアント要求のロードバランシング
□ ステートフルおよびステートレスサーバプロセスの使用
このトピックでは、システムのパフォーマンスに影響を与える要因について解説します。これらの要因
は次のとおりです。
□ ダイナミックおよびスタティックアプリケーションサーバプロセスの構成
□ Comm Server プロセス間でのクライアント要求のロードバランシング
□ ステートフルおよびステートレスサーバプロセスの使用
4.4.1 ダイナミックおよびスタティックアプリケーションサーバプロセスの構成
アプリケーションサーバプールに対して、PATHCOM の
START SERVER コマンドを実行すると、
PATHMON プロセスが、プールに定義されているスタティック・サーバの数に等しい数のアプリケーショ
ンサーバプロセスをそのプールで開始します。スタティック・サーバの数は、SET
SERVER コマンドの
NUMSTATIC 属性によって定義されます。
ダイナミック・サーバプロセスは、
起動するのに START
サーバプロセスのもう 1 つのタイプ、
SERVER
コマンドは必要ありません。ダイナミック・サーバプロセスは、スタティック・サーバプロセスが特定の
時間内に LINKMON プロセスに対して利用可能にならなかった場合、PATHMON プロセスによってダイ
ナミックに開始されます。( この特定の時間は、サーバプールの
CREATEDELAY 属性によって決定され
SERVER
ます。) サーバプールに対して起動可能なダイナミック・サーバプロセスの潜在的な数は、SET
コマンドの MAXSERVERS と NUMSTATIC の値の差と等しくなります。これについては、
『NonStop TS/
MP System Management Manual』に記述されています。
ダイナミック・サーバプロセスは、LINKMON プロセスがそれと通信しているかぎり実行されます。
PATHMON プロセスは、サーバプールの DELETEDELAY 属性で定義されている時間に基づいて、使用さ
れないダイナミック・サーバプロセスを削除します。
多くのダイナミック・サーバを含んだアプリケーションを構成した場合、いくらかのパフォーマンス低
下が生じる可能性があります。これらのプロセスは、トランザクションパスの一部としてスタートアップ
ペナルティを生じるからです。高いシステムパフォーマンスが要求される場合には、ダイナミック・サー
バプロセスを使用しないでください。
140418J
2-61
第 4 章 NonStop DOM サーバプールの構成
備考 : Comm Server のサーバプールにはダイナミック・サーバプロセスを含めることはできません。これらのシ
ステムプロセスに対する NonStop TS/MP 構成では、 MAXSERVERS 属性の値は常に NUMSTATIC 属
性の値と等しくなります。
4.4.2 Comm Server プロセス間でのクライアント要求ロードバランシング
典型的な NonStop TS/MP アプリケーションでは、PATHMON プロセスはロードバランシング機能を提
供します。つまり、クライアントがサーバプールに対して要求を発すると、現在実行中のサーバプロセス
にリンクが可能かどうかを PATHMON プロセスが判定します。可能なリンクがない場合、前述したよう
に、PATHMON プロセスがダイナミック・サーバプロセスを開始して要求を処理します。
ただし、PATHMON プロセスは、NonStop DOM システムの LSD および Comm Server コンポーネント
に対してロードバランシングサービスを実行しません。代わりに、任意の Comm Server プロセスをクライ
アントの要求に最終的に結び付ける割当てを構成時に修正するか、またはその割当てを LSD がダイナミッ
クに行います。
システム管理者は、構成ファイルで Comm Server プロセスとリモートホストとの間のスタティックな結
合を構成します。その後、任意のリモートホストからくるすべての要求は、そのホストと結合するように
構成した Comm Server に転送されます。したがって、スタティックなアプリケーションのロードの分散を
予測してから、NonStop DOM システムコンポーネントを構成する必要があります。
システムが実働を開始した後、クライアント要求のロードが計画とは違ったように分散された場合、ク
ライアントアプリケーションのユーザは、遅い応答時間を経験することがあります。その場合、スタティッ
クな構成をもう一度評価しなおして、Comm Server プロセスとリモートホストとの間の結合を再配分する
ことによってアプリケーションパフォーマンスを改善できるかどうか判断する必要があります。
4.4.3 ステートフルおよびステートレスサーバプロセスの使用
NonStop DOM アプリケーションサーバプールは、ステートフルまたはステートレスプロセスのどちら
かで実装することができます。ステートレスオブジェクトは、ある要求から次の要求まで状態情報を保持
しません。サーバオブジェクトがステートレスのとき、入ってくる要求はプール内の任意の使用可能なサー
バプロセスに割当てることができます。同一オブジェクトに対する要求は、起動するたびに異なるサーバ
プロセスで処理することが可能です。
サーバオブジェクトが状態情報を保持しなければならないケースもいくつかあります。たとえば、プロ
セスが、複数の NonStop SQL 問合せ要求の間でカーソル位置を保持しなければならない場合などのような
ケースです。こうしたステートフルサーバオブジェクトに対して NonStop DOM システムでは、クライア
ントとサーバプロセス間でファイルシステムの接続を確立します。接続は、クライアントがサーバオブジェ
クトのインスタンスを削除しないかぎり持続します。
4.5 アプリケーションサーバプロセスのロードバランシング
サブトピックス
□ キーとなるサーバ構成パラメータ
□ CPU への処理の明示的割当て
□ NonStop TS/MP アプリケーションサーバのリンク管理
2-62
140418J
第 4 章 NonStop DOM サーバプールの構成
このトピックでは、NonStop DOM アプリケーションサーバプロセス間のロードバランシングの強化を
実現するための注意点について解説します。これらの NonStop DOM アプリケーションサーバプロセスは、
NonStop TS/MP によって構成されており、TCP/IP を介してアクセスされます。
NonStop TS/MP で構成される NonStop DOM サーバプロセスへのアクセスは、PATHMON プロセスお
よびリンクモニタプロセスの LINKMON によって制御されます。各 CPU を監視する LINKMON プロセス
がそれぞれ 1 つあります。アクセスは、構成時に各サーバプールに対して設定されたパラメータのセット
が基になります。ある特定のパラメータに対して選択した値によって、クライアントの要求がシステムプ
ロセス間でどの程度うまくロードバランシングされるかが決まります。
4.5.1 キーとなるサーバ構成パラメータ
以下に記すキーとなるサーバパラメータは、アプリケーションのロードバランシングに影響します。サー
バパラメータの定義とサーバプールの構成手順について詳細は、『NonStop TS/MP System Management
Manual』を参照してください。
備考 : NonStop TS/MP のマニュアルでは、サーバプールは「サーバクラス」と呼ばれています。
MAXSERVERS パラメータ
MAXSERVERS サーバパラメータは、任意のサーバプールで同時に実行できるサーバプロセスのコピー
の最大数を指定します。サーバプロセスはスタティックまたはダイナミックのどちらも可能です。スタ
ティック・プロセスは、NonStop TS/MP 環境が開始すると自動的に開始されます。一方、ダイナミック・
プロセスは、PATHMON プロセスによって必要に応じて開始されます。サーバプール内のスタティック・
プロセス数は、別の構成変数 NUMSTATIC パラメータによって決定されます。ダイナミック・サーバプ
ロセスの最大数は、MAXSERVERS から NUMSTATIC をマイナスした値になります。サーバプールの使
用可能なリンクの最大数を特定するには、公式 MAXSERVERS * MAXLINKS を使用します。
LINKDEPTH パラメータ
このパラメータは、任意の LINKMON プロセスがサーバプール内の個々のサーバプロセスに対して確立
できるリンクの最大数を指定します。
リンクは、LINKMON プロセスと特定のサーバプロセス間の接続です。サーバへの要求の送信とサーバ
からの返答の受信にリンクが使用されます。
LINKMON プロセスはリンクマネージャであり、Pathsend プロトコルを使用して発せられるクライアン
ト要求を処理します。1 つの LINKMON プロセスが、Tandem システム上の各 CPU で実行します。サーバ
プロセスへのリンクがあると、LINKMON プロセスは、監視している CPU における全クライアントに代
わって、そのリンクを用いてサーバプロセスとの間で要求の受け渡しを行います。
LINKDEPTH 値が 1 の場合、LINKMON プロセスはサーバプールの 1 サーバプロセス につき 1 リンク
しか確立できません。一方、LINKDEPTH 値が 10 であると、各 LINKMON プロセスは各サーバプロセ
スに対して最大 10 までの同時リンクが可能です。
MAXLINKS パラメータ
MAXLINKS パラメータは、プール内のサーバプロセスがシステム内の全 LINKMON プロセスに対して
確立できるリンクの最大数を指定します。したがって、サーバプロセスが要求を処理しているとき、サー
バにキューイング可能なリクエスト数は、最大で MAXLINKS から 1 をマイナスした値になります。
LINKDEPTH の設定値が 10 であり、システムには 3 CPU が装備されている場合、サーバプロセスで
140418J
2-63
第 4 章 NonStop DOM サーバプールの構成
のキューイングを避けるには MAXLINKS を 30 に設定しなければなりません。
備考 :
MAXLINKS の値を設定することを強く推奨します。デフォルトにすると、リンク数に制限がありません。
図 2-6、7、8 はさまざまなパラメータの構成について想定される結果を図示しています。図示されてい
るリンクは、指定されたパラメータ値に基づいてシステムが動作する可能性のあるシナリオのみであるこ
とに注意してください。たとえば、図 2-6 では、プール内のサーバプロセスにリンクを確立している 3 つ
の LINKMON プロセスを示しています。しかし、1 つのビジーな LINKMON プロセスが 3 つのサーバプ
ロセスすべてにリンクを要求し確立することも可能であり、それによって他の LINKMON プロセスを
シャットアウトする可能性があります。
図 2-6 MAXLINKS = 1、LINKDEPTH = 適用不可 の場合の結果
2-64
140418J
第 4 章 NonStop DOM サーバプールの構成
図 2-7 MAXLINKS=2、LINKDEPTH=1 の場合の結果
140418J
2-65
第 4 章 NonStop DOM サーバプールの構成
図 2-8 MAXLINKS=2、LINKDEPTH=2 の場合の結果
4.5.2 CPU への処理の明示的割当て
PATHMON プロセスによって任意のプロセスに対して CPU リソースを割当てる代わりに、パフォーマ
ンスを強化したい重要なプロセスに対して明示的に CPU を指定することができます。通常、CPU を手動
で割当てる必要はありません。PATHMON プロセスがリソース割当てをうまく行ってくれるからです。し
かし、重要なプロセスに対して明示的に CPU を指定する必要があれば、割当て方法を利用することができ
ます。
通常は、PATHMON プロセスが NonStop DOM アプリケーションプロセスに対して CPU を割当てます。
この動作は、次の PATHCOM コードで設定されます。
set server cpus (<n>,...)
このステートメントによって、NonStop DOM アプリケーションプロセスには引数 (<n>, ...) で指定され
る CPU が割当てられます。PATHMON プロセスは、これらの CPU を NonStop DOM システムが発する要
2-66
140418J
第 4 章 NonStop DOM サーバプールの構成
求に割当てます。
nsdstart スクリプトを修正して特定の CPU
特定のプロセスに対して CPU を明示的に設定するには、
とプロセス間の関係をセットアップします。たとえば、Comm Server $ZC02 に対して特定の CPU を設定
するには、Comm Server を構成するセクションで次のコードを入力します。
set server process $ZC02 (cpus <p>:<b>)
これによって、(cpus
<p>:<b>) 値で指定される CPU が Comm Server $ZC02 のプロセスを処理し
ます。値 <p> は プライマリ CPU を表し、値 <b> はバックアップ CPU を表します。
4.5.3 NonStop TS/MP アプリケーションサーバのリンク管理
NonStop TS/MP サーバプロセスの構成は、複雑な仕事になることがあります。システムが実行している
と、多数の要因が関係してきます。そのため、実働構成において実際のサーバプロセスの動作は多様化す
る可能性があります。前述の図 2-6、7、8 は、特定のサーバパラメータ値のセットを指定した結果による
想定可能な動作しか表していません。
実際にいつ、そしてどのようにしてクライアント要求がサーバプロセスに到達するかは、LINKMON プ
ロセスと PATHMON プロセス (NonStop TS/MP モニタプロセス ) との、サーバプロセスへのリンク割当て
における共同作業の結果となります。システム構成をうまく動作させるためには、リンク割当ての適切な
管理が不可欠です。
リンクの動きについて簡単な概要を次に示します。NonStop TS/MP リンク管理に関する詳細な説明は、
『NonStop TS/MP System Management Manual』を参照してください。
PATHMON プロセスは、PATHMON 環境の全サーバプールにあるすべてのアプリケーションサーバプ
ロセスに対して利用可能なリンクのグローバルリストを維持します。LINKMON プロセスがサーバプール
内のサーバプロセスへのアクセスを初めて必要とするとき、LINKMON プロセスは PATHMON プロセス
に要求を送り、サーバプール内のプロセスへのリンクを求めます。
PATHMON プロセスは、その内部のサーバプールリンクテーブルを参照します。全リンクが使用中の場
合、PATHMON プロセスは LINKMON プロセスにエラーを返します。この状態は、システムの CPU 間で
クライアントアクティビティが不均衡に配分されているために生じている可能性があります。よりビジー
な他の LINKMON プロセスが利用可能なリンクを使用し続けている場合は、ビジーでない LINKMON プ
ロセスがリンクを獲得できなくなります。
リンクが利用可能な場合、PATHMON はサーバプロセス名を LINKMON プロセスに渡します。また、
PATHMON プロセスは、タイマーパラメータの CREATEDELAY および DELETEDELAY の値も渡しま
す。その後、PATHMON プロセスは、渡されるリンクを反映させてそのリンクテーブルを更新します。
アク ティ ブな サー バプ ロセ スの 数が その サー バプ ール の
MA XSE RVE RS 値よ り少 ない 場合、
PATHMON プロセスはサーバプロセスの別のコピーを起動します。
LINKMON プロセスは、いったんリンクを取得したら、そのリンクを使用して、LINKMON プロセスの
CPU における全クライアントに代わって、リクエストを処理します。
リンクは一度に 1 クライアントに対してのみ使用できます。LINKMON プロセスは、リンクされたサー
バプロセスにクライアントからの要求を渡します。LINKMON プロセスは最初の要求に対する応答を受け
取るまで、クライアントの別な要求をそのサーバプロセスに送りません。追加のクライアント要求は、同
一クライアントからの要求であっても、リンクが空くまで待機になります。
140418J
2-67
第 4 章 NonStop DOM サーバプールの構成
要求が待機中の場合、LINKMON プロセスはタイマーをサーバプールの
CREATEDELAY パラメータ
値に設定します。タイマーが終了する前に LINKMON プロセスがサーバプロセスから返答を受け取った場
合、LINKMON プロセスは即座に存在しているリンクを使用して、次の要求をサーバプロセスに渡します。
タイマーは取り消されます。サーバプロセスが返答する前にタイマーが終了した場合、LINKMON プロセ
スは PATHMON プロセスに対して、そのサーバプール内のプロセスサーバへの別のリンクを要求します。
PATHMON プロセスはそのリンクテーブルをチェックして、MAXLINKS を使ってそのサーバプールへの
全リンクが使用中かどうかを判定します。全リンクが使用中ではない場合、PATHMON プロセスはアルゴ
リズムを使って、LINKMON プロセスがリンクするサーバプロセスを決定します。
このアルゴリズムでは、サーバプール内の全サーバプロセスにまたがるリンクの現行配分を調べます。
また、アルゴリズムは LINKDEPTH 設定を調べて、LINKMON プロセスに対してすでにリンクされてい
る同一サーバプロセスへの別のリンクが可能かどうかも判定します。
LINKDEPTH が 1 に設定されており、LINKMON がすでにリンクしているサーバプロセスが利用可能
な唯一のリンクである場合、新たなリンク接続は拒否されます。LINKMON プロセスはエラーメッセージ
を受け取ります。
LINKMON プロセスに現在サーバプロセスからくる未処理の要求がない場合、LINKMON プロセスはタ
イマーをそのサーバプールの DELETEDELAY 値に設定します。クライアントから別の要求を受け取る前
にタイマーが終了した場合、LINKMON プロセスは PATHMON プロセスへリンクを返し、PATHMON プ
ロセスはそのリンクテーブルを更新します。サーバプロセスへのリンクを持つすべてのリンクマネージャ
がそれぞれのリンクを返してきた場合、PATHMON プロセスは、サーバプロセス自体が停止するのを待ち
ます。停止したら、PATHMON プロセスは、リンクテーブルでそのサーバプロセスを停止プロセスとして
マークし、次の要求がリンクを求めるのを待ちます。
NonStop TS/MP アプリケーションサーバプロセスを構成するとき、
『NonStop TS/MP System Management
Manual』で各サーバパラメータの記述を慎重に確認してからリンク構成の方策を立ててください。おそら
く、まず最初にクライアント要求と利用可能なサーバプロセスを予測することから始め、その後で経験に
従って構成を微調整することが必要でしょう。
2-68
140418J
第 5 章 NonStop DOM 構成ファイル
第 5 章 NonStop DOM 構成ファイル
5.1 env.sh ソースファイル
5.1.1 env.sh ソース
配布 env.sh ファイル
備考 : NonStop DOM の Software Development Kit (SDK) 版をインストールした場合、ファイルはサブディレク
トリの ZDOMSD20 にインストールされます。NonStop DOM のランタイム版を使用する場合には、
NonStop DOM ファイルセットはサブディレクトリ ZDOMRT20 にインストールされます。
以下のリストは、ソフトウェアの SDK 版をインストールした場合を想定しています。
export NSD_ROOT=/usr/tandem/nsdoms
export MY_ROOT=$NSD_ROOT
# NSDOM Guardian File System Directory
# If altering, keep both forms of the name syncronized and
# move the NS-DOM files to the specified location.
export NSD_DIR=/G/SYSTEM/ZDOMSD20
export NSD_SUBVOL="\$SYSTEM.ZDOMSD20"
# Set location of nsdcfgmgt and namingdb database
export MY_SUBVOL=$NSD_SUBVOL
# SRL
export NSD_SRL_SUBVOL=$NSD_SUBVOL
export NSD_SRL_DIR=$NSD_DIR
add_define =_SRL_01 class=map file=$NSD_SRL_SUBVOL.NSDSRL
# NSDOM CONFIG DBM
export NSDOM_CFG_DBM=$MY_SUBVOL.NSDCFGDB
# NonStop DOM installation character setting
export MY_PREFIX=Z
# NonStop DOM collector
export MY_COLLECTOR="\$0"
# Root directory for your tools.
export COMP_ROOT=
# Sets JAVA_HOME environment for NonStop Java
# Comment out the following line if you set JAVA_HOME in your
.profile
export JAVA_HOME=/usr/tandem/java
# CLASSPATH setting for IDL compiler
export CLASSPATH=.:$CLASSPATH:$NSD_ROOT/idl/nsdidl.jar
# Add NS-DOM to the path.
export PATH=$PATH:$NSD_ROOT/bin:$COMP_ROOT/usr/lib:$JAVA_HOME/
bin
140418J
2-69
第 5 章 NonStop DOM 構成ファイル
5.2 default.db ソースファイル
5.2.1 default.db ソース
配布 default.db ファイル
# All the entities get reloaded
# Set the hostname in the next line.
set hostname <CHANGE_ME>
# Set the base port in the next line. This port number and the
next two
# sequential ports will be used allocated for NSDOMS 2.0.
set portnumber0 <CHANGE_ME>
set portnumber1 [expr $portnumber0 + 1]
set portnumber2 [expr $portnumber1 + 1]
catch {entitydelete NS@ORB}
entityaddkeyvalue NS@ORB pathmon \$$env(MY_PREFIX)ndm
entity NS@ORB {
use_comm_server true
tcp_server
true
fs_server
true
tsmp_server
true
server_class
NS
}
#
catch {entitydelete NS@name_service_settings}
entityaddkeyvalue NS@name_service_settings DatabaseName
$env(MY_SUBVOL).NAMINGDB
entityaddkeyvalue NS@name_service_settings
RootNamingContextIORFile $env(MY_ROOT)/etc/root_nc.ior
#
catch {entitydelete default@ORB}
entityaddkeyvalue default@ORB trace_file <STDOUT>
entityaddkeyvalue default@ORB nsdom_ir $env(MY_ROOT)/etc/
nsdom.ir
entityaddkeyvalue default@ORB log_file $env(MY_COLLECTOR)
#
catch {entitydelete $env(MY_PREFIX)NCA@comm_server}
entityaddkeyvalue $env(MY_PREFIX)NCA@comm_server
host_name
$hostname
entityaddkeyvalue $env(MY_PREFIX)NCA@comm_server
port_number
$portnumber0
#
catch {entitydelete $env(MY_PREFIX)NCB@comm_server}
entityaddkeyvalue $env(MY_PREFIX)NCB@comm_server
host_name
$hostname
entityaddkeyvalue $env(MY_PREFIX)NCB@comm_server
port_number
$portnumber1
#
catch {entitydelete lsd1@ORB}
entityaddkeyvalue lsd1@ORB
host_name
$hostname
entityaddkeyvalue lsd1@ORB
port_number
$portnumber2
entity lsd1@ORB {
tcp_server
true
2-70
140418J
第 5 章 NonStop DOM 構成ファイル
}
#
catch {entitydelete event_service@ORB}
entityaddkeyvalue event_service@ORB
host_name
$hostname
entity event_service@ORB {
tcp_server
true
port_number
0
}
catch {entitydelete event_service@event_service_settings}
entity event_service@event_service_settings {
EventServiceID "NSDOM ES"
EventServiceFactory true
}
ent it ya dd ke yv alue event_service@event_service_settings
EventServiceIORFile $env(MY_ROOT)/etc/es.ior
#
catch {entitydelete tcp_client@ORB}
entity tcp_client@ORB {
fs_client
false
tsmp_client
false
}
#
catch {entitydelete tsmp_client@ORB}
entity tsmp_client@ORB {
fs_client
false
tcp_client
false
}
#
catch {entitydelete fs_server@ORB}
entity fs_server@ORB {
tcp_client
false
tsmp_client
false
fs_server
true
}
#
catch {entitydelete fs_client@ORB}
entity fs_client@ORB {
tcp_client
false
tsmp_client
false
}
#
# Trace flags that map to environmental variables.
# Please see documentation for mapping.
catch {entitydelete default@trace}
entity default@trace {
comm_server
false
event_core
false
event_context_free
false
event_file_system
false
orb_giop_connections false
orb_request_queue
false
orb_proxy
false
event_socket
false
threads
false
timer
false
poa
0
ir
false
es
false
}
# For a successful interpretation, return a code of 0
return 0
140418J
2-71
第 5 章 NonStop DOM 構成ファイル
5.3 構成ソースファイル
5.3.1 configure ソース
配布 configure ファイル
#!/bin/sh
# Set filecode for SRLs
gtacl -p fup "alter $NSD_SUBVOL.nsdgsrl, code 700"
gtacl -p fup "alter $NSD_SUBVOL.nsdsrl, code 700"
cfgmgt <<\END
dbcreate
;# Create a database
set myExit 0
;# default exit code
set myExit [catch {source $env(MY_ROOT)/etc/default.db}]
exit $myExit
END
if [ $? -ne 0 ]
then
echo "cfgmgt initialization Failed"
exit 1
else
echo "cfgmgt initialization Completed"
fi
# Force the LSD to record its actual tcp address
lsd -ORBprofile lsd1 -configure
LSD_RETURN_CODE=$?
if [ LSD_RETURN_CODE -eq 0 ]; then
echo "LSD initialization Completed"
else
if [ LSD_RETURN_CODE -ne 126 ]; then
echo "LSD initialization Failed"
exit 1
else
echo "\nFixing SRL and lsd and re-try initialize lsd\n"
nld -L $NSD_DIR -l nsdsrl -l ZCPLSRL -l zcresrl -l
zcrtlsrl -srl_fixup lsd > /dev/null
cd $NSD_DIR
gtacl -p nld "-l zcplsrl -l zcresrl -l zcrtlsrl -l
zossfsrl -l zossesrl -l zinetsrl -srl_fixup nsdsrl" > /dev/null
lsd -ORBprofile lsd1 -configure
LSD_NEW_RETURN_CODE=$?
if [ LSD_NEW_RETURN_CODE -eq 0 ]; then
echo "LSD initialization Completed"
else
if [ LSD_NEW_RETURN_CODE -ne 126 ]; then
echo "LSD initialization Failed"
exit 1
else
echo "\nLSD initialization Failed. Due to an
unexpected problem with nld fixup command."
exit 2
fi
fi
fi
2-72
140418J
第 5 章 NonStop DOM 構成ファイル
fi
# Startup the Name Service init
run -name=/G/"$MY_PREFIX"nd0 ns_init -ORBprofile NS
if [ $? -ne 0 ]
then
exit 1
fi
5.4 nsdstart ソースファイル
5.4.1 nsdstart ソース
配布 nsdstart ファイル
#! /bin/sh
# Script for starting the NSDOM pathway environment
#
# Usage:
#
nsdstart [-v]
# T h e " n s d s t a r t " script will start the NS DOM pat h way
environment.
# The comm server, location service demon, name service, and
# event service processes are started. If the -v option is
# used with this script you will see the pathway configuration
# command output. Otherwise the pathcom status messages are
# redirected to a file.
#
#
# (C) Copyright 1998 Tandem
#
# Pathway Process and Server names.
export PATHMON="$MY_PREFIX"NDM
COM_SERVER1="$MY_PREFIX"NCA
COM_SERVER2="$MY_PREFIX"NCB
NAME_SERVER="$MY_PREFIX"ND0
# Get -v option if supplied
while getopts ":v" opt; do
case $opt in
v ) VERBOSE="-v" ;;
\? ) print "usage: nsdstart [-v]"
return 1
esac
done
shift $(($OPTIND - 1))
# Set G_HOMETERM to the terminal identifier on which standard
# output is displayed.
if [[ -z "$HOMETERM" ]] then
# HOMETERM variable was not set explicitly, construct
# the Guardian form of the home terminal identifier
#
# Get information about current terminal
ID=$(who -m)
140418J
2-73
第 5 章 NonStop DOM 構成ファイル
# Strip off user name
TEMP=${ID#*\ }
# Get the terminal name
set -A O_HOMETERM $TEMP
# Get tcp process name
TEMP=${TEMP##*/G/}
TCP_PROCESS=${TEMP%%/*}
# Get Guardian form of home terminal
G_HOMETERM=\$$TCP_PROCESS.${O_HOMETERM##*/}
else
G_HOMETERM=\$ZTNT.$HOMETERM
fi
[[ -n $VERBOSE ]] && print "Standard output will appear on
$G_HOMETERM"
# Start a PATHMON envionment for the NSDOM processes:
# 1. Get "default" volume name. This is where the PATHCTL file
is
#
created by PATHMON. We’ll create the PATHMON log file there
as well.
# 2. Blindly create the PATHMON log file.
If it is already
there, ignore
#
the error.
# 3. Start the PATHMON process
PMLOG=$(info_define -detail =_DEFAULTS | awk ’/VOLUME/ {print
$3}’).${PATHMON}LOG
gtacl -c "fup create $PMLOG" > /dev/null 2>&1
gtacl -c "pathmon/name \$$PATHMON,nowait,out $PMLOG/"
sleep 1
# Configure the pathway server pool.
# The command line below turns into something similar to either:
#
gtacl -p pathcom $XNDM << eof
# or
#
gtacl -p pathcom $XNDM > pathcom.log << eof
# depending on whether the "verbose" option was passed to this
script.
# This causes the chatty pathcom output to sent to a file under
normal
# circumstances. If one wants to see the pathcom input, use the
-v
# option when invoking this shell script.
[[ -z $VERBOSE ]] && USELOG=TRUE
eval gtacl -p pathcom \\\$${PATHMON} ${USELOG:+"> $MY_ROOT/log/
pathcom.log"} <<eof
set pathway maxassigns
8
set pathway maxparams
8
set pathway maxserverclasses
5
set pathway maxserverprocesses 40
set pathway maxstartups
40
set pathway maxtcps
0
set pathway maxterms
0
set pathway maxdefines
27
set pathway maxpathcoms
8
set pathway maxspi
8
set pathway maxlinkmons
16
set pathway maxexternaltcps
0
set pathway maxprograms
5
start pathway cold !
2-74
140418J
第 5 章 NonStop DOM 構成ファイル
[ configure LSD
reset server
set
set
set
set
server
server
server
server
processtype
pri
cwd
program
set
set
set
set
server
server
server
server
hometerm $G_HOMETERM
stdin /dev/null
stdout $MY_ROOT/log/lsd.out
stderr $MY_ROOT/log/lsd.out
[
[
[
[
set
set
set
set
server
server
server
server
oss
150
$MY_ROOT
$NSD_ROOT/bin/lsd
debug on
env NSDOM_CFG_TRACE_ORB=TRUE
env NSDOM_CFG_TRACE_GIOP_FW=TRUE
env NSDOM_CFG_TRACE_SOCKEH=TRUE
set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM
set server env MY_PREFIX=$MY_PREFIX
set
server
d efi ne
= _SR L_01 ,
cl ass
$NSD_SRL_SUBVOL.NSDSRL
set
set
set
set
set
server
server
server
server
server
map,
fil e
createdelay 0 secs
deletedelay 0 secs
TIMEOUT
0 SECS
MAXLINKS
16
LINKDEPTH
1
set server maxservers 1
set server numstatic 1
set server cpus (1,2)
set server AUTORESTART 10
set server arglist "-ORBprofile", "lsd1"
add server LSD
start server LSD
[ configure comm server(s)
reset server
set
set
set
set
server
server
server
server
processtype
pri
cwd
program
set
set
set
set
server
server
server
server
hometerm $G_HOMETERM
stdin /dev/null
stdout $MY_ROOT/log/cs.out
stderr $MY_ROOT/log/cs.out
[
[
[
[
[
140418J
set
set
set
set
set
server
server
server
server
server
oss
150
$MY_ROOT
$NSD_ROOT/bin/cs
debug on
env NSDOM_CFG_TRACE_CS=TRUE
env NSDOM_CFG_TRACE_SOCKEH=TRUE
env NSDOM_CFG_TRACE_GFSEH=TRUE
env NSDOM_CFG_TRACE_GCFEH=TRUE
2-75
第 5 章 NonStop DOM 構成ファイル
set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM
set server define =_SRL_01, class map, file
$NSD_SRL_SUBVOL.NSDSRL
set
set
set
set
set
server
server
server
server
server
createdelay 0 secs
deletedelay 0 secs
TIMEOUT
0 SECS
MAXLINKS
16
LINKDEPTH
1
set
set
set
set
server
server
server
server
maxservers
numstatic
process
process
2
2
\$$COM_SERVER1 (cpus 1:2)
\$$COM_SERVER2 (cpus 2:1)
set server AUTORESTART 10
add server CS
start server CS
[ configure naming service
reset server
set
set
set
set
server
server
server
server
processtype
pri
cwd
program
set
set
set
set
server
server
server
server
hometerm $G_HOMETERM
stdin /dev/null
stdout $MY_ROOT/log/ns.out
stderr $MY_ROOT/log/ns.out
[
[
[
[
[
[
[
set
set
set
set
set
set
set
server
server
server
server
server
server
server
oss
150
$MY_ROOT
$NSD_ROOT/bin/name_servant
debug on
env NSDOM_CFG_TRACE_POA=TRUE
env NSDOM_CFG_TRACE_PROXY=TRUE
env NSDOM_CFG_TRACE_ORB=TRUE
env NSDOM_CFG_TRACE_GIOP_FW=TRUE
env NSDOM_CFG_TRACE_GFSEH=TRUE
env NSDOM_CFG_TRACE_GCFEH=TRUE
set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM
set server define =_SRL_01, class map, file
$NSD_SRL_SUBVOL.NSDSRL
set
set
set
set
set
server
server
server
server
server
createdelay
deletedelay
TIMEOUT
MAXLINKS
LINKDEPTH
0 secs
15 secs
30 SECS
16
4
set server maxservers 4
set server numstatic 2
[ the following process \$$NAME_SERVER will be used to support
the file
[ system protocol access.
set server process \$$NAME_SERVER (cpus 1:2)
set server cpus (2:1,3:2,2:3)
2-76
140418J
第 5 章 NonStop DOM 構成ファイル
set server AUTORESTART 10
set server arglist "-ORBprofile", "NS"
add server NS
start server NS
[ configure Event Service
reset server
set
set
set
set
server
server
server
server
processtype
pri
cwd
program
oss
150
$MY_ROOT
$NSD_ROOT/bin/EventService
set
set
set
set
server
server
server
server
hometerm $G_HOMETERM
stdin /dev/null
stdout $MY_ROOT/log/es.out
stderr $MY_ROOT/log/es.out
[ set server debug on
[ set server env NSDOM_CFG_TRACE_ES=TRUE
set server env NSDOM_CFG_DBM=$NSDOM_CFG_DBM
set server define =_SRL_01, class map, file
$NSD_SRL_SUBVOL.NSDSRL
set
set
set
set
server
server
server
server
createdelay 0 secs
deletedelay 0 secs
MAXLINKS
16
LINKDEPTH
1
set server maxservers 1
set server numstatic 1
set server cpus (1,2)
set server AUTORESTART 10
set server arglist "-ORBprofile", "event_service"
add server ES
start server ES
eof
if [[ -z $VERBOSE ]]; then
# "verbose" option is off, indicate whether there with
pathcom errors
grep -q -i error $MY_ROOT/log/pathcom.log
if [[ $? -eq 0 ]] then
print "Error in starting pathcom, refer to $MY_ROOT/log/
pathcom.log for information"
else
print "NSDOM runtime environment was started."
fi
fi
140418J
2-77
第 5 章 NonStop DOM 構成ファイル
5.5 nsdstop ソースファイル
5.5.1 nsdstop ソース
配布 nsdstop ファイル
#! /bin/sh
# Script for shuting down the NSDOM pathway environment
# Tell pathmon to shut down.
gtacl -p pathcom \$${MY_PREFIX}ndm > /dev/null 2>&1 <<eof
shutdown2, mode im, status ag
eof
# Just in case pathway wasn’t configured, kill the pathmon
process.
# If the shutdown above worked, this will have no effect since
# the pathmon process is gone. Otherwise this gets rid of the
# pathmon process.
kill -s GUARDIAN /G/${MY_PREFIX}ndm > /dev/null 2>&1
5.6 unconfigure ソースファイル
5.6.1 unconfigure ソース
配布 unconfigure ファイル
#!/bin/sh
echo "****************************************************************"
echo "nsdstop must be run prior to running this script and"
echo "NSDCFGDB and NAMINGDB database files cannot be opened."
echo ""
echo "This will PERMANENTLY purge the NSDCFGDB and NAMINGDB
databases."
echo "Do you want to proceed (y/n):"
while read in
do
if [ "$in" = "Y" ] || [ "$in" = "y" ]; then
# Purge nsdcfgdb and namingdb databases
gtacl -p fup "purge ! $MY_SUBVOL.nsdcfgdb"
gtacl -p fup "purge ! $MY_SUBVOL.namingdb"
break 1
else
if [ "$in" = "N" ] || [ "$in" = "n" ]; then
break 2
else
echo "This will PERMANENTLY purge you NSDCFGDB and
NAMINGDB databases."
echo "Do you want to proceed (Y/N):"
fi
fi
done
2-78
140418J
索 引
索 引
（英数字）
C
Comm Server
2-60
2-59
削除
追加
ロードバランシング 2-61, 2-62
Configuration Tool
概要 2-25
2-26
構文
2-27
2-29
コマンド
実行例
CORBA サービス
概要 2-6
D
default.db
2-70
E
env.sh ファイル内容 2-69
N
NonStop DOM
COBRA サービス 2-6
TS/MP Process Management
アーキテクチャ 2-1
構成アーキテクチャ 2-13
構成管理 2-34
構成データベース 2-17
初期化スクリプト 2-18
スクリプトファイル 2-14
スクリプトファイルの構成
2-7
2-16
2-8
2-9
データベース
伝送プロトコル
パフォーマンス調整
構成
2-34
2-13
環境変数 2-16
ORB 2-4
NonStop DOM の構成 2-13
nsdstart、ファイル内容 2-73
nsdstop、ファイル内容 2-78
O
ORB 通信処理 2-4
140418J
2-79
索 引 P
PATHCOM
2-50
インタフェース 2-50
概要 2-49
監視 2-51
基本パラメータの修正 2-56
サーバプールの再構成 2-49, 2-57
プロセスの起動と再起動 2-50
T
TS/MS Process Management、NonStop
2-7
（五十音順）
あ
アプリケーション管理
環境 2-37
管理 2-36
構成管理 2-37
トラブルシューティング 2-41
パフォーマンス調整 2-41
い
インタフェース
PATHCOM
2-50
え
エンティティ
概要 2-19
削除 2-21
作成 2-20
デフォルト 2-21
か
環境変数 2-16
き
起動と停止、NonStop TS/MP
PATHMON プロセス 2-43
TS/MP 2-43
スクリプト 2-44
パフォーマンス 2-61
こ
構成
アーキテクチャ 2-13
管理 2-34
データベース 2-17
構成パラメータ
2-63
構成、ファイル内容
2-80
2-72
140418J
索 引
さ
サーバ
基本パラメータ 2-63
ダイナミックおよびスタティック・サーバプロセス
2-61
2-57
サーバプールの再構成
サーバプロセス
ステートフルとステートレス 2-62
ダイナミックとスタティック
2-61
し
初期化スクリプト 2-18
す
スクリプトファイルの構成 2-16
スクリプトファイル、NonStop DOM
2-14
2-61
ステートフルおよびステートレスサーバプロセス 2-62
ステートフルとステートレス 2-62
スタティックおよびダイナミック・サーバプロセス
た
ダイナミックおよびスタティック・サーバプロセス 2-61
て
データベース、NonStop DOM
伝送プロトコル
2-8
2-9
は
パフォーマンス調整 2-34
ふ
分散オブジェクト環境 2-33
ろ
ロードバランシング
Comm Server
概要 2-62
2-62
構成パラメータ
2-63
処理の明示的割当て
リンク管理
140418J
2-66
2-67
2-81
第3部
NonStop™ DOM
プログラマーズ・ガイド
概要
このマニュアルには、NonStop™ Distributed Object Manager/MP (NonStop™ DOM) 環境
でのアプリケーション開発に必要な情報が記載されています。
このガイドでは、NonStop™ DOM を使った、次の作業の実行方法について
簡単に説明してあります。
・分散オブジェクトアプリケーションの設計
・分散オブジェクトアプリケーションの開発
・アプリケーションプロセスの管理
製品バージョン
NonStop™ DOM/MP、バージョン 2.0
リリース ID
Independent Product
マニュアル番号
138125J
発行日
2000 年 2 月
Document History
Edition
Part Number Product Version Earliest Supported Release Published
First
Second
Third
Fourth
127557
131054
138003
134268
D40
D41
D41
D42
November 1996
January 1997
October 1997
November 1997
New editions incorporate any updates issued since the previous edition.
A plus sign(+) after a release ID indicates that this manual describes function added to the
base release, either by an interim product modification(IPM) or by a new product version on
a .99 site update tape(SUT).
140418J
目 次 目 次
第1章
クイックスタート
1.1 ストック例............................................................................................................................... 3-1
1.1.1 ストックオブジェクト ................................................................................................. 3-2
1.1.2 ストックのインタフェース定義 ................................................................................. 3-2
1.1.3 ストックインタフェースの実装 ................................................................................. 3-3
1.1.4 クライアントアプリケーションプログラム .............................................................. 3-3
1.1.5 ストック Makefile ........................................................................................................ 3-4
1.1.6 NonStop DOM 上でのストック例の実行 ................................................................... 3-5
1.1.7 ほかの ORB 上でのストック例の実行 ....................................................................... 3-6
1.1.8 ソースコードファイル ................................................................................................. 3-6
第2章
分散オブジェクトアプリケーション開発の概要
2.1 分散オブジェクトアプリケーションの設計 ....................................................................... 3-13
2.1.1 必要な知識 .................................................................................................................. 3-14
2.2 NonStop DOM アプリケーションの設計 ............................................................................ 3-16
2.2.1 NonStop DOM オブジェクトクラスの設計 ............................................................. 3-17
第3章
NonStop DOM アプリケーションの開発
3.1 アプリケーション開発の概要 .............................................................................................. 3-21
3.2 クライアントアプリケーションの開発 ............................................................................... 3-23
3.2.1 Object Request Broker (ORB) の初期化 .................................................................... 3-23
3.2.2 オブジェクト参照の取得 ........................................................................................... 3-24
3.2.3 オブジェクト参照の限定 ........................................................................................... 3-25
3.2.4 メソッドの呼出し ...................................................................................................... 3-26
3.2.5 例外処理...................................................................................................................... 3-26
3.2.6 オブジェクト参照の解放 ........................................................................................... 3-28
3.2.7 使用不能なシステムコール ....................................................................................... 3-28
3.3 サーバアプリケーションの開発 .......................................................................................... 3-29
3.3.1 実装ヘッダファイルの作成 ....................................................................................... 3-29
i
140418J
目 次
3.3.2 オブジェクト実装の作成 ............................................................................................3-30
3.3.3 ユーザ例外の作成 .......................................................................................................3-31
3.3.4 サーバメインプログラムの作成 ................................................................................3-31
3.4 POA (Portable Object Adapter)..............................................................................................3-33
3.4.1 POA の作成 .................................................................................................................3-37
3.4.2 POA ポリシーオブジェクト ......................................................................................3-39
3.4.3 参照の作成 ..................................................................................................................3-45
3.4.4 Servant Managers.........................................................................................................3-46
3.4.5 永続オブジェクトと非永続オブジェクト .................................................................3-52
3.4.6 Adapter Activator.........................................................................................................3-56
3.5 オブジェクト参照 ..................................................................................................................3-60
3.5.1 オブジェクト参照の取得 ............................................................................................3-60
3.5.2 オブジェクト参照の操作 ............................................................................................3-62
3.5.3 オブジェクト参照の拡大と限定 ................................................................................3-64
3.6 スレッド化 .............................................................................................................................3-65
3.6.1 スレッド化の概要 .......................................................................................................3-65
3.6.2 クライアントアプリケーションのスレッド化 .........................................................3-66
3.6.3 サーバ実装のスレッド化 ............................................................................................3-66
3.6.4 NonStop DOM ポータブルスレッド化インタフェース ...........................................3-67
第4章
インスツルメンテーション用アプリケーション
4.1 エラーログファシリティ ......................................................................................................3-69
4.1.1 エラーログファシリティの設計 ................................................................................3-69
4.1.2 エラーログ情報 ...........................................................................................................3-70
4.1.3 エラーログの有効化 ...................................................................................................3-71
4.1.4 エラーログファシリティの呼出し ............................................................................3-71
4.1.5 エラーログの例 ...........................................................................................................3-73
4.1.6 エラーログファシリティインタフェース .................................................................3-74
4.2 トレースファシリティ ..........................................................................................................3-75
4.2.1 トレースファシリティの設計 ....................................................................................3-75
4.2.2 トレース情報 ...............................................................................................................3-76
4.2.3 トレースファシリティの呼出し ................................................................................3-76
4.2.4 トレース例 ..................................................................................................................3-77
140418J
ii
目 次 4.2.5 トレースファシリティインタフェース .................................................................... 3-78
第5章
NonStop DOM アプリケーションの構築
5.1 OSS 開発環境 ........................................................................................................................ 3-79
5.1.1 OSS を通じた Guardian コマンドとファイルの利用............................................... 3-80
5.1.2 OSS 環境変数と env.sh ファイル .............................................................................. 3-80
5.1.3 OSS 開発およびデバッグツール ............................................................................... 3-81
5.2 NonStop DOM アプリケーションコンポーネントの構築 ................................................. 3-82
5.2.1 Makefiles..................................................................................................................... 3-82
5.2.2 プログラム例 .............................................................................................................. 3-82
第6章
NonStop DOM アプリケーションの実行
6.1 アプリケーションコンポーネントのトラブルシューティング ......................................... 3-83
6.1.1 NonStop DOM のエラーメッセージログ ................................................................. 3-84
6.1.2 トレース...................................................................................................................... 3-85
6.1.3 デバッグ SRL(Shared Runtime Library) の有効化 ................................................... 3-87
第7章
NonStop DOM オブジェクトラッパ
7.1 NonStop DOM 2.0 ブリッジ例 ............................................................................................. 3-89
7.1.1 はじめに...................................................................................................................... 3-89
7.2 CORBA クライアントサーバから支払い勘定サーバへのブリッジ.................................. 3-90
7.2.1 サーバラッパ .............................................................................................................. 3-90
7.2.2 メインの処理 .............................................................................................................. 3-92
7.2.3 Factory::Create の実装 ............................................................................................... 3-92
7.2.4 Worker インタフェースの実装 ................................................................................. 3-93
7.2.5 Worker::do_pathsend の実装 ...................................................................................... 3-93
7.2.6 イベントコア .............................................................................................................. 3-94
7.2.7 Worker::handle_event の実装 ..................................................................................... 3-94
7.3 クライアント支払勘定から CORBA サーバブリッジ ....................................................... 3-94
7.3.1 クライアントラッパ .................................................................................................. 3-95
7.3.2 メインの処理 .............................................................................................................. 3-97
7.3.3 Factory::wait の実装 ................................................................................................... 3-98
7.3.4 Factory::connect_in の実装 ........................................................................................ 3-98
iii
140418J
目 次
7.3.5 Worker::accept の実装 ................................................................................................3-98
7.3.6 Worker::handle_event の実装 .....................................................................................3-98
7.3.7 Worker::handle_writeread の実装 ...............................................................................3-98
7.3.8 Worker::handle_close の実装 ......................................................................................3-98
7.3.9 Worker::find_server の実装 ........................................................................................3-98
7.3.10 thread_function の実装 ................................................................................................3-98
第8章
Event Service
8.1 Event Service の概要..............................................................................................................3-99
8.1.1 OMG 標準....................................................................................................................3-99
8.1.2 イベント通信 ...............................................................................................................3-99
8.1.3 コンシューマとサプライヤ ......................................................................................3-101
8.1.4 Event Service と any データ型..................................................................................3-107
8.1.5 イベントチャネルの作成と配置 ..............................................................................3-107
8.2 Event Service の使用............................................................................................................3-111
8.2.1 プッシュコンシューマの実装 ..................................................................................3-111
8.2.2 プルコンシューマの実装 ..........................................................................................3-112
8.2.3 プッシュサプライヤの実装 ......................................................................................3-113
8.2.4 プルサプライヤの実装 .............................................................................................3-114
8.3 Event Service 使用法の例 ....................................................................................................3-115
8.3.1 プッシュサプライヤ .................................................................................................3-115
8.3.2 プッシュコンシューマ .............................................................................................3-117
8.3.3 追加管理インタフェース ..........................................................................................3-120
第9章
マイナーコード
9.1 General Minor Codes............................................................................................................3-123
9.1.1 一般マイナーコード値 .............................................................................................3-123
9.2 POA Minor Codes ................................................................................................................3-127
9.2.1 POA マイナーコード値 ............................................................................................3-127
9.3 Marshal マイナーコード......................................................................................................3-131
9.3.1 Marshal マイナーコード値 .......................................................................................3-131
9.4 COMM_FAILURE Minor Codes.........................................................................................3-131
9.4.1 COMM_FAILURE マイナーコード ........................................................................3-131
140418J
iv
目 次 9.5 LSD マイナーコード .......................................................................................................... 3-133
9.5.1 LSD マイナーコード値 ............................................................................................ 3-133
9.6 CS マイナーコード ............................................................................................................. 3-134
9.6.1 CS マイナーコード値 .............................................................................................. 3-134
9.7 データ変換マイナーコード ................................................................................................ 3-135
9.7.1 データ変換マイナーコード値 ................................................................................. 3-135
9.8 Context マイナーコード ..................................................................................................... 3-135
9.8.1 Context マイナーコード値 ....................................................................................... 3-135
9.9 OTS マイナーコード .......................................................................................................... 3-136
9.9.1 OTS マイナーコード値 ............................................................................................ 3-136
9.10 Interface Repository Minor Codes....................................................................................... 3-137
9.10.1 インタフェースレポジトリマイナーコード値 ....................................................... 3-137
9.11 DSI マイナーコード ........................................................................................................... 3-138
9.11.1 DSI マイナーコード値 ............................................................................................. 3-138
第 10 章 NonStop DOM システムエラーメッセージ
10.1 NonStop DOM エラーメッセージ...................................................................................... 3-141
10.1.1 Event Framework メッセージ .................................................................................. 3-141
10.1.2 データベースエラーメッセージ ............................................................................. 3-141
10.1.3 トレースエラーメッセージ ..................................................................................... 3-142
10.1.4 ORB エラーメッセージ ........................................................................................... 3-143
10.1.5 Comm Server エラーメッセージ ............................................................................. 3-146
10.1.6 インタフェースレポジトリエラー .......................................................................... 3-148
10.1.7 Event Service エラーメッセージ ............................................................................. 3-149
10.1.8 Naming Service エラーメッセージ ......................................................................... 3-150
付 録
相互運用オブジェクトの参照 ..................................................................................................... 3-153
オブジェクト参照の作成 .................................................................................................... 3-154
オブジェクト参照の内容 .................................................................................................... 3-154
オブジェクトキー ............................................................................................................... 3-155
設定した TCP アドレスと実際の TCP アドレス .............................................................. 3-156
サーバプール上のオブジェクトに対する IOR(Interoperatable Object References)........ 3-157
v
140418J
目 次
図
図 3-1
クライアントとサーバの開発手順 .................................................................................3-22
図 3-2
POA アーキテクチャ .....................................................................................................3-36
図 3-3
NonStop DOM 2.0 ブリッジ例 ......................................................................................3-89
図 3-4
システムコンテキスト - サーバラッパ .........................................................................3-90
図 3-5
サーバラッパの内部プロセスアーキテクチャ .............................................................3-91
図 3-6
クラス階層 .......................................................................................................................3-92
図 3-7
サーバラッパメソッド ...................................................................................................3-93
図 3-8
システムコンテキスト - クライアントラッパ ..............................................................3-95
図 3-9
クライアントラッパの内部プロセスアーキテクチャ ..................................................3-96
図 3-10 クラスの説明 ...................................................................................................................3-97
図 3-11 サプライヤ、イベントチャネル、コンシューマの関係 ............................................3-100
図 3-12 サプライヤ、コンシューマ、プロキシの関係 ............................................................3-101
図 3-13 プッシュサプライヤとプッシュコンシューマ ............................................................3-102
図 3-14 プッシュサプライヤとプルコンシューマ ...................................................................3-103
図 3-15 プルサプライヤとプルコンシューマ ..........................................................................3-104
図 3-16 プルサプライヤとプッシュコンシューマ ...................................................................3-105
図 3-17 複数のサプライヤと複数のコンシューマの組み合わせ ............................................3-106
表
140418J
表 3-1
例外の型 ..........................................................................................................................3-27
表 3-2
RootPOA ポリシー ..........................................................................................................3-37
表 3-3
ServantLocator オブジェクトで使用するポリシー .......................................................3-49
表 3-4
ServantActivator オブジェクトで使用するポリシー ....................................................3-50
表 3-5
エラーログのデータフィールド.....................................................................................3-70
表 3-6
コンポーネント名 ...........................................................................................................3-73
表 3-7
トレースオプション........................................................................................................3-85
vi
第 1 章 クイックスタート
第 1 章 クイックスタート
1.1 ストック例
サブトピックス
□ ストックオブジェクト
□ ストックインタフェース定義
□ ストックインタフェースの実装
□ クライアントアプリケーションプログラム
□ ストック Makefile
□ NonStop DOM 上でのストック例の実行
□ ほかの ORB 上でのストック例の実行
□ ソースコードファイル
NonStop DOM 製品は、サンプルプログラムを多数提供しており、移植性のあるアプリケーション開発
の参考としてお使いいただけます。$NSDOM/samples/stock ディレクトリには、NonStop DOM で
の CORBA プログラミングの基本概念を示したプログラム例があります。
ストック例では、次の内容が示されます。
□ IDL( インタフェース定義言語 ) で書かれたオブジェクトインタフェース定義
□ インタフェース定義によって定義されたインタフェースの実装を持つサーバ
□ ストックオブジェクトのインスタンスを利用するクライアントアプリケーション
また、ストック例から、CORBA アプリケーションの移植性もご理解いただけます。クライアントアプ
リケーションプログラムは、NonStop DOM およびその他の CORBA 準拠の実装のもとで構築し、実行す
ることができます。クライアント構築のスクリプトは、Visigenic の Visibroker、および IONA Technologies
の Orbix という 2 つの実装が提供されています。
この例で紹介できる概念は限られています。スケーラブルなサーバ、POA (Portable Object Adapter)、
Naming Service、および Event Service といった、NonStop DOM のパワフルな機能については、ほかのサ
ンプルプログラムで紹介されています。
140418J
3-1
第 1 章 クイックスタート
1.1.1 ストックオブジェクト
ストックオブジェクトは、株式市況のリソースです。アプリケーション内でこのオブジェクトを使うこ
とによって、株式相場を取得することができます。
CORBA プログラミングの概念を紹介するため、この例はできるだけシンプルにしてあります。たとえ
ば、このストックオブジェクトの動作元となる株式市況データベースは固定されていて、変動がありませ
ん。これ以降のバージョンのプログラムは、この基本構造に基いています。ストックオブジェクトは、あ
るプロセス内で実行しているサーバプログラムにホストされ、ほかのプロセス内で実行しているクライア
ントアプリケーションに使用されます。クライアントとサーバ間の通信には、CORBA 方式のメソッド呼
び出しが使われています。
例からおわかりのように、クライアントとサーバは、同じマシン上で実行されている必要はありません。
また、クライアントとサーバは、別々の CORBA 実装でホストすることができます。クライアントアプリ
ケーションプログラムは、ストックオブジェクトの場所や実装には影響されず、単にインタフェース定義
で定義されたインタフェースを使用するだけです。例で示される中心的な概念は、実際のオブジェクト定
義、実装、およびアプリケーションプログラムに利用できます。
1.1.2 ストックのインタフェース定義
ストックのインタフェースの定義は、stock.idl ファイルにありますが、ここにも示しました。
ストックのインタフェース
interface Stock
{
// status for user defined exceptions
enum operation_status {
NOT_FOUND
// Stock symbol not found
};
// user defined exception
exception operationFailed {
operation_status status;
};
// The type of failure
void quote( in string Symbol, out double Last, out double High,
out double Low, out unsigned long Volume )
raises( operationFailed );
void update( in string Symbol,
in double Price, in unsigned long Volume )
raises( operationFailed );
};
この定義では、Stock のインタフェースが指定されています。また、quote(
) および update( )
メソッドを、ストックオブジェクトのユーザが使用できるようにしています。各メソッドのパラメータと
戻り値が指定されています。メソッドが、例外を検出する可能性もあります。これらは、exception お
よび raises コンストラクトによって定義されています。
3-2
140418J
第 1 章 クイックスタート
1.1.3 ストックインタフェースの実装
C++ 実装ファイルは次の 3 つです。
□ stock_servmain.cpp
□ stock.cpp
□ stock.h
stock_servmain.cpp ファイルに、サーバのメインプログラムが含まれています。コンパイル後、このファ
イルは次の動作を実行します。
□ ORB を初期化する。
□ ストックオブジェクトを作成する。
□ オブジェクトを POA (Portable Object Adapter) に登録する。
□ オブジェクト参照を stock.ior ファイルに書き込む。
□ POA に対して、リクエスト受信準備が完了したことを通知する。
これらの動作の結果、リクエスト受信の準備ができたストックオブジェクトのインスタンスが発生しま
す。オブジェクトの ID と位置は、ファイルに書き込まれたオブジェクト参照にカプセル化されています。
POA は、リクエストを待機します。リクエストが届くと、POA によって、stock.cpp に定義されたメソッ
ドが呼び出されます。
stock.h ファイルには、stock.idl に定義されたインタフェースに対応する、C++ クラス定義が含ま
れています。public インタフェースを構成する個々のメソッドが宣言されており、また、現在のストック
データを含むプライベートインスタンス変数が定義されています。
stock.cpp ファイルには、stock インタフェースで定義されたメソッドの実装が含まれています。これ
らのメソッドは、複雑ではありません。quote(
コンストラクタが初期化します。quote(
) メソッドで使用される保存済みの株式市況データを、
) メソッドはストック記号を受け取り、対応するデータを返
します。定義されていない記号が使われた場合は、operationFailed 例外が上げられます。この例
外は呼び出し元に返されますので、呼び出し元で分析する必要があります。
1.1.4 クライアントアプリケーションプログラム
C++ クライアントアプリケーションファイルは、client.cpp ファイルに含まれています。
クライアントアプリケーションプログラムは、次の動作を実行します。
□ ORB を初期化する。
□
stock.ior ファイルから、ストックオブジェクト参照を読み込む。
□ オブジェクト参照を使用可能な形式に変換し、有効性を検証する。
□ ストックオブジェクト上で操作を実行する。
□ ユーザに対して、進行状況を表示する。
140418J
3-3
第 1 章 クイックスタート
このクライアントアプリケーションは、ストックオブジェクトによって供給される quote(
) メソッ
) メソッドが呼び出され、メソッドから
返された結果が表示されます。定義されていない記号が quote( ) に渡されると、ユーザ例外が上げら
ドを使用します。利益の株式記号それぞれに対して、quote(
れます。
CORBA のプログラミングを行う際は、各メソッド呼び出しの例外を慎重にチェックしてください。例
外は、ネットワーク、オブジェクト、リソースなどが使用できなくなるといった、システムの原因によっ
て発生することがあります。また、メソッド呼び出しに関する情報の通信のため、オブジェクトによって
生成されることもあります。プログラムを正しく動作させるには、このような例外を慎重にチェックする
必要があります。
CORBA 標準には、例外処理のさまざまな実装が備えられています。このクライアントアプリケーショ
ンは、TRY、CATCH などのマクロを使用して、次の 2 種類の状況で処理を行うことができます。1) プロ
グラムのコンパイルに使用した C++ コンパイラが C++ 方式の例外をサポートしている場合は、マクロは、
ネイティブの try と catch ファシリティの名前を変更します。2) C++ 方式の例外をサポートしない
C++ コンパイラの場合は、マクロが CORBA 定義の例外処理機構をカプセル化します。このようなマクロ
によって、各種の例外処理環境への移植性が提供されます。
1.1.5 ストック Makefile
Makefile というスクリプトを使って、NonStop DOM 上でストック例を構築することができます。実
行可能コンポーネントの構築に必要な手順はすべて、Makefile によって実行されます。Makefile で使
用されるマクロは、etc/macros.mk 内に定義されています。例を構築するには、次の手順を実行しま
す。
1. NonStop DOM の samples/stock ディレクトリに移動するか、または別のディレクトリにファイ
ルをコピーします。
2. 必要な環境変数を設定するため、env.sh を実行します (『第 2 部 NonStop™ DOM 管理者ガイド』の
構成情報を参照してください )。
etc/env.sh
3. 次のコマンドを使って、スクリプトを実行します。
make
Makefile の動作
Makefile は、次の動作を実行します。
□ NonStop DOM IDL コンパイラを使って、stock.idl のインタフェースを実行する。
□ C++ コンパイラを使ってコンポーネントをコンパイルし、サーバ実行可能ファイルを作成する。
□ C++ コンパイラを使って、クライアント実行可能ファイルを作成する。
3-4
140418J
第 1 章 クイックスタート
NonStop DOM IDL (NSDIDL) コンパイラは、stock.idl をもとに、次の 4 つのファイルを作成します。
□
stock_client.h
□
stock_client.cpp
□
stock_server.h
□
stock_server.cpp
これらのファイルの内容を表示したり、理解したりする必要はありません。これらのファイルには、
CORBA 指定の「C++ 言語マッピング」によるインタフェース定義の変換が含まれている、とだけ理解し
ておいてください。クライアントプログラムは stock_client コンポーネントを使って、インタフェー
スを利用します。サーバプログラムは stock_server コンポーネントを使って、インタフェースを実
装します。
C++ コンパイルのステップ内では、標準の Tandem NonStop Kernel OSS (Open System Service) ツールを
使って、プログラムがコンパイルおよびリンクされます。NonStop DOM ORB 実装ファイルは、SRL (Shared
Run-time Library) 内に保持されます。プロセッサ内で実行しているすべての NonStop DOM アプリケーショ
ンが、ORB 実装コードを共有するため、メモリリソースが節約されます。
1.1.6 NonStop DOM 上でのストック例の実行
ストック例を実行するには、OSS ウィンドウが 2 つ必要です。どちらのウィンドウも、ストック例が構
築されたディレクトリ内にあり、正しい NonStop DOM 環境変数が設定されている必要があります ( 設定
するには、前述のように env.sh を実行します )。
一方のウィンドウ内で、サーバプログラムを実行します。
server -ORBprofile tcp_server
もう一方のウィンドウ内で、クライアントプログラムを実行します。
client -ORBprofile tcp_client
クライアントウィンドウに、次のように出力されます。
Q u o t e f o r C P Q : L ast =35. 5, Hig h=3 5.8 125 ,
Volume=18285500
Quote for MOB: Last=70.5, High=70.5, Low=69.1875,
Q u o t e f o r X O N : L ast =62. 25, Hig h=6 2.6 25,
Volume=1308200
Quote for IBM: Last=102.875, High=103.188,
Volume=2810700
Quote for MSFT: Last=158.375, High=158.938,
Volume=8613000
Got operationFailed exception as expected.
140418J
Lo w=3 4.3 875 ,
Volume=1462200
L ow= 61. 875 ,
Low=101.563,
Low=156.063,
3-5
第 1 章 クイックスタート
1.1.7 ほかの ORB 上でのストック例の実行
Visigenic の Visibroker または IONA Technologies の Orbix を使用している場合は、CORBA の相互運用
性がよく発揮されます。ストック例のクライアント部分は、これらの ORB のもとで構築および実行するこ
とができます。ほかの CORBA 準拠の ORB も同じように使用できます。ストック例のサーバ部分は、
NonStop DOM のもとで実行されます。
相互運用性を提供するための make スクリプトが 2 つ用意されています。
□
Makefile-visi
Microsoft Visual C++ を使った Visibroker 用
□
Makefile-orbix
Microsoft Visual C++ を使った Orbix 用
これ以外の ORB 実装またはプラットフォームを使用している場合は、これらの make スクリプトを参考
に、独自の make スクリプトを作成してください。
クライアントアプリケーションを実行するマシン上に次のファイルをコピーします。
□
stock.idl
□
client.cpp
□
GetPutIOR.cpp
□
GetPutIOR.h
□
trycatch.h
□
Makefile-visi または Makefile-orbix
提供されている make スクリプトを使って、ORB インストールディレクトリの位置を変更します。
Makefile-visi の VBROKERDIR または Makefile-orbix の ORBIXDIR を修正してくださ
い。Microsoft の nmake ツールを使って make スクリプトを実行します。make スクリプトによって、
client.exe ファイルが作成されます。
make スク リプ トは、前 述し た NonStop DOM で の構 築の 場合 と似 たよ うな 動作 を実 行し ます。
stock.idl 内のインタフェース定義がコンパイルされ、クライアントプログラムが使用するための
C++ 言語マップが作成されます。クライアントプログラムは、言語マッピングとともにコンパイルされ、
クライアントアプリケーションの実行可能ファイルが作成されます。
前述のように、NonStop DOM のもとでストックサーバプログラムを実行します。NonStop DOM 実行
ディレクトリから、クラ イアントアプリケーションプログラムが構築されたプラットフォームへ、
stock.ior ファイルをコピーします。ファイル転送には、ftp や nfs などを使用できます。
1.1.8 ソースコードファイル
□ ストックサーバのメインソースコード
□ ストックソースコード
□ ストックヘッダファイル
3-6
140418J
第 1 章 クイックスタート
ストックサーバのメインソースコード
stock_servmain.cpp の内容
// Copyright (C) 1998, Tandem Computers Incorporated.
// All Rights Reserved.
//
// Permission to use, copy, modify, and distribute this software
and its
// documentation for NON-COMMERCIAL purposes and without fee is
hereby
// granted provided that this copyright notice appears in all
copies.
//
// Tandem, a division of Compaq, MAKES NO REPRESENTATIONS OR
WARRANTIES ABOUT
// THE SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED,
INCLUDING BUT
// NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A
// PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Tandem, a division
of Compaq, SHALL
// NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT
OF USING,
// MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
//
// -----------------------------------------------------------------------#include "stock.h"
#include "GetPutIOR.h"
#include "nsdorb/poa.h"
int main(int argc, char *argv[])
{
// Initialize the ORB
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
// Get object reference for POA Manager
CORBA::Object_ptr pfobj =
orb->resolve_initial_references("RootPOA");
PortableServer::POA_ptr rootPOA;
rootPOA = PortableServer::POA::_narrow(pfobj);
// Create servant
Stock_impl *lp_test_servant = new Stock_impl;
// Let poa know about object, poa generates object ID
//
(and creates "active object map" entry: oid, object)
PortableServer::ObjectId_ptr oid
= rootPOA->activate_object(lp_test_servant);
delete oid;
// create the stringified reference to the servant and write
it to
// file.
char* lp_IOR_string = orb->object_to_string( lp_test_servant
140418J
3-7
第 1 章 クイックスタート
);
if (!PutObjectReference("stock.ior", lp_IOR_string))
return 1;
// Activate the poa
rootPOA->the_POAManager()->activate();
// Service requests
orb->run();
return 0;
} // main
ストックソースコード
stock.cpp の内容
// Copyright (C) 1998, Tandem Computers Incorporated.
// All Rights Reserved.
//
// Permission to use, copy, modify, and distribute this software
and its
// documentation for NON-COMMERCIAL purposes and without fee is
hereby
// granted provided that this copyright notice appears in all
copies.
//
// Tandem, a division of Compaq, MAKES NO REPRESENTATIONS OR
WARRANTIES ABOUT
// THE SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED,
INCLUDING BUT
// NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A
// PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Tandem, a division
of Compaq, SHALL
// NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT
OF USING,
// MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
//
// -----------------------------------------------------------------------#include "stock.h"
#include
Stock_impl::Stock_impl()
{
CountOfStocks = 5;
StockList[0].Symbol = "MOB";
StockList[0].Last
= 70.5;
StockList[0].High
= 70.5;
StockList[0].Low
= 69.1875;
StockList[0].Volume = 1462200;
StockList[1].Symbol = "IBM";
StockList[1].Last
= 102.875;
StockList[1].High
= 103.1875;
StockList[1].Low
= 101.5625;
3-8
140418J
第 1 章 クイックスタート
StockList[1].Volume
StockList[2].Symbol
StockList[2].Last
StockList[2].High
StockList[2].Low
StockList[2].Volume
StockList[3].Symbol
StockList[3].Last
StockList[3].High
StockList[3].Low
StockList[3].Volume
StockList[4].Symbol
StockList[4].Last
StockList[4].High
StockList[4].Low
StockList[4].Volume
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
2810700;
"CPQ";
35.5;
35.8125;
34.3875;
18285500;
"MSFT";
158.375;
158.9375;
156.0625;
8613000;
"XON";
62.25;
62.625;
61.875;
1308200;
}
// Given a stock symbol, return a stock quote
void Stock_impl::quote(const char* Symbol,
CORBA::Double_out Last,
CORBA::Double_out High,
CORBA::Double_out Low,
CORBA::ULong_out Volume,
CORBA::Environment &pr_env)
{
// Search for the given stock symbol
for (unsigned int i=0; i < CountOfStocks; i++)
{
if (!strcmp(Symbol, StockList[i].Symbol))
{ // Found the stock symbol in list of stocks.
// Return the stock information.
Last = StockList[i].Last;
High = StockList[i].High;
Low = StockList[i].Low;
Volume = StockList[i].Volume;
cout << "Returning quote information" << endl;
return;
}
}
// Could not find the stock symbol, inform caller via exception
pr_env.exception(new Stock::operationFailed(NOT_FOUND));
}
// Given a stock simple, update the price and volume
void Stock_impl::update(const char* Symbol,
CORBA::Double Price,
CORBA::ULong Volume,
CORBA::Environment &pr_env)
{
// Search for the given stock symbol
for (unsigned int i=0; i < CountOfStocks; i++)
{
if (!strcmp(Symbol, StockList[i].Symbol))
{ // Found the stock symbol in list of stocks.
// Update the stored information
if (Price > StockList[i].High) StockList[i].High = Price;
else if (Price < StockList[i].Low) StockList[i].Low =
Price;
StockList[i].Last = Price;
140418J
3-9
第 1 章 クイックスタート
StockList[i].Volume += Volume;
}
}
// Could not find the stock symbol, inform caller via exception
pr_env.exception(new Stock::operationFailed(NOT_FOUND));
}
ストックヘッダファイル
stock.h の内容
// Copyright (C) 1998, Tandem Computers Incorporated.
// All Rights Reserved.
//
// Permission to use, copy, modify, and distribute this software
and its
// documentation for NON-COMMERCIAL purposes and without fee is
hereby
// granted provided that this copyright notice appears in all
copies.
//
// Tandem, a division of Compaq, MAKES NO REPRESENTATIONS OR
WARRANTIES ABOUT
// THE SUITABILITY OF THE SOFTWARE, EITHER EXPRESS OR IMPLIED,
INCLUDING BUT
// NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A
// PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Tandem, a division
of Compaq, SHALL
// NOT BE LIABLE FOR ANY DAMAGES SUFFERED BY LICENSEE AS A RESULT
OF USING,
// MODIFYING OR DISTRIBUTING THIS SOFTWARE OR ITS DERIVATIVES.
//
// -----------------------------------------------------------------------#include "stock_server.h"
class Stock_impl: public POA_Stock
{
public:
Stock_impl();
Stock_impl(){}
void quote(const char* Symbol,
CORBA::Double_out Last,
CORBA::Double_out High,
CORBA::Double_out Low,
CORBA::ULong_out Volume,
CORBA::Environment &pr_env);
void update(const char* Symbol,
CORBA::Double Price,
CORBA::ULong Volume,
CORBA::Environment &pr_env);
private:
enum {MaxStocks=20};
3-10
140418J
第 1 章 クイックスタート
struct StockInfo
{
char * Symbol;
CORBA::Double Last;
CORBA::Double High;
CORBA::Double Low;
CORBA::ULong Volume;
};
CORBA::ULong CountOfStocks;
StockInfo StockList[MaxStocks];
};
140418J
3-11
第 2 章 分散オブジェクトアプリケーション開発の概要
第 2 章 分散オブジェクトアプリケーション開発の概要
2.1 分散オブジェクトアプリケーションの設計
サブトピックス
□ 必要な知識
新しいアプリケーションまたはコンポーネントを作成するには、次の手順のすべてまたはいくつかを実
行します。
1. クライアント要件を定義します ( 必要なサービス、パフォーマンス、ほかのシステムとの相互運用性、
データへの同時アクセスなど )。
2. 使用できるクラスライブラリとフレームワークを評価し、既存のソフトウェアで利用可能なものを決定
します。
3. アプリケーションで必要となる新しいクラスを決定し、クラス間の継承と使用の関係を定義します。
4. サーバ実装に関する決定を行います。
5. 新機能の利用を念頭に、クライアントを設計または修正します。
備考 : アプリケーションによっては、オブジェクト指向アーキテクチャ間のブリッジを必要とします。詳しくは、
『第 4 部 NonStop™ DOM JTS/OTS ユーザーズ・ガイド』を参照してください。
仮定的アプリケーションのコンポーネントでは、NonStop DOM およびその他の CORBA 実装を使用す
ることができます。「ローカルオブジェクト」という言葉は、独自の C++ オブジェクトクラスなど、シス
テムでサポートされるあらゆるオブジェクトクラスを指します。「CORBA オブジェクト」とは、CORBA
標準に準拠し、リモートクライアントからアクセス可能なオブジェクトのことです。「NonStop DOM オブ
ジェクト」とは、NonStop DOM で作成する CORBA 準拠のオブジェクトのことです。
アプリケーションを作成するには、次の作業を実行します。
□ 新しいオブジェクトクラスを定義し、新しいクラスライブラリとフレームワークを作成するか、または
アプリケーションに合わせて既存のものを修正します。
□ クライアントプログラムを作成します。
□ サーバプログラムを作成します。NonStop DOM サーバを作成する場合は、オブジェクト実装間をリン
クします。1 つのプログラムをクライアントとしてもサーバとしても動作させることができます。
140418J
3-13
第 2 章 分散オブジェクトアプリケーション開発の概要
オブジェクト指向の設計法
Tandem では、特定のオブジェクト指向設計法を推奨していません。ただし、分散指向の、標準準拠の
コンピューティングを選択するよう推奨しています。
既存の方法を分散環境に適応させることも可能です。たとえば、メッセージコストを重要視しないで、
オブジェクトの実行単位を可能な限り小さくする方法では、分散されたときにアプリケーションの効率性
が悪くなります。NonStop DOM では、一連の小さなオブジェクトを大きなオブジェクトにラップするか、
または特定のオブジェクトが常に同じサーバプロセス内で実行されるようにすることで、パフォーマンス
を落とさずに、小さく分割されたオブジェクトを再利用するという利点を保持することができます。
2.1.1 必要な知識
このセクションには、次のサブトピックスが含まれています。
□ オブジェクトクラスの設計
□ サーバの設計
□ クライアントの設計
□ 必要な予備知識
アプリケーション設計方法は、実装するコンポーネントのタイプによって異なります。一般的には、オ
ブジェクトクラスとサーバのデザインは深く関連していますが、クライアントについては、使用するクラ
スのインタフェースが重要になります。
オブジェクトクラスの設計
オブジェクトクラスを設計する際は、次のことを念頭においてください。
□ 再利用 既存のクラスから新しいクラスを導出することによって、可能な限り既存のソフトウェアを再
利用する方法。
□ 実行単位 分散コンポーネント間の相互動作を減らすことを考えて、メソッドとデータを設計する方法。
□ 並列性 可能な限りステートレスリクエストを使用し、必要な場合だけステートフルリクエストを使用
する方法。ステートレス処理では、1 つのオブジェクトに対して複数のメソッド呼出しを行うと、サー
バプール内の別々のプロセスにリクエストが渡されます。ステートフル処理では、1 つのオブジェクト
に対する複数のリクエストは同じサーバプロセスによって処理されます。このため、サーバが、それら
のリクエストを一続きのものとして扱うことができ、複数のクライアントから 1 つのオブジェクトに対
しての同時アクセスを直列化して処理することができます。
□ サービスのパッケージ化 新しいサービスを、クラスライブラリとして提供するか、またはフレームワー
クとして提供するかの選択。ユーザプログラムは、クラスライブラリ内のクラスを呼び出し、フレーム
ワークは、アプリケーション特有の処理のためにユーザプログラムを呼び出します。
□ 同時性 1 つのプロセス内で、1 つのクラスの複数のインスタンスが共存してよいかどうか、また、複数
のクライアントが同時に 1 つのインスタンスを使用してよいかどうかの選択。
□ 永続性 オブジェクトまたはそのステートが、それらをホストしていたプロセスの停止後にアクセス可
能になっている必要があるかどうかの選択。また、永続オブジェクトへの再利用可能な参照を供給する
3-14
140418J
第 2 章 分散オブジェクトアプリケーション開発の概要
方法。
□ データベースマッピング インスタンスデータと永続ストレージ間のマップ方法 ( リレーショナルデー
タベースなど )。
□ トランザクション管理 同時発生トランザクションの管理方法。特に、トランザクション実行の際にク
ラスが外部フレームワークまたはサービスを使用する場合 ( このようなクラスは、OTS (Object
Transaction Service) のクライアントです )。
□ Factory オブジェクトと Control オブジェクト ほかのクラスの動作を制御するためのクラスを定義す
るかどうかの選択。たとえば、ほかのオブジェクトを作成する場合は factory オブジェクトを使用しま
す。データへの同時アクセスを管理したり、サーバプール内でクラスデータを保持したりする場合は、
control オブジェクトを使用します。
□ 例外とエラー報告
サポートされないリクエストへの応答や、トラブルシューティング用の出力パラ
メータを含め、例外やエラー報告方式の選択。
サーバの設計
サーバ設計の考え方の多くは、そのサーバ内で実行されるオブジェクトどうしの関連性に依存します。
サーバを設計する際は、次のことを念頭においてください。
□ パーティション 最高のパフォーマンスを実現するために、どのオブジェクトクラスを同じサーバにロー
ドするかの選択。NonStop DOM がほかの ORB 実装と違う点は、同じサーバ内で実行されるオブジェ
クトクラスを事前に決定するという点です。実際にサーバ内で実行される一連のオブジェクトは、クラ
イアントのリクエストに応答して、実行時に決定されます。
□ オブジェクト参照 オブジェクト参照構成の調整方法の選択。永続性に必要なアプリケーション要件を
満たし、プロセス内のクラスの単一または複数のインスタンスをサポートし、サーバプールの要件を満
たすための、オブジェクト参照構成の調整。( オブジェクト参照とは、クライアントが既存のオブジェ
クトを参照するのに使用するハンドルです。)
□ 並列性 サーバがスレッドを必要とするか、またはサーバプールとして実行できるかの選択。
クライアントの設計
クライアントを設計する際は、次のことを念頭においてください。
□ ローカル / リモートの透過性 クライアントに対して、オブジェクトの位置を透過的にするかどうかの
選択。オブジェクトの作成と呼出しに特定の呼出しを使用することにより、オブジェクトの場所にかか
わらず、同じコードを使用することができます。
□ 静的または動的呼出し
たとえば、クライアントが、既知の一連のオブジェクトクラスを使用するか、
または実行時に新しいクラスを使用するかの選択。
□ オブジェクトのライフサイクル Naming Service の使用方法を含めた、オブジェクトの作成、配置、解
放に関する問題。
□ サーバの選択 たとえば、特定のサーバにリクエストするか、またはクラスをホストするサーバならど
れでもよいのかという選択。
□ サーバプール サーバプール使用の実装と、サーバプールの使用をアプリケーションに対して透過的に
140418J
3-15
第 2 章 分散オブジェクトアプリケーション開発の概要
するかどうかの選択。
□ トランザクション管理 ネストされたトランザクションをクライアントが処理するのか、
またはオブジェ
クトが処理するのかという選択。
□ 同時性 データへの同時アクセスを、クライアントが調整するのか、またはオブジェクトが調整するの
かという選択。
□ 相互運用性 たとえば、ほかのプラットフォームで開発されたクライアントが、NonStop DOM サーバ
と相互動作できるようにすること。
□ 並列性 クライアントがスレッドを必要とするかどうかの選択。
必要な予備知識
アプリケーションまたはコンポーネントを設計する際は、次のことを理解している必要があります。
□ オブジェクト指向設計の一般原則
□ 継承、オブジェクト参照、既定クラスやフレームワークといった、オブジェクト機能
□ CORBA および関連サービスの定義 ( コンポーネントが、ほかの CORBA 準拠システムと相互運用され
る必要がある場合 )
NonStop DOM およびその他の Tandem 製品の、次の各機能について理解している必要があります。
また、
□ NonStop TS/MP サーバプールを使用する利点と意義
□ ステートレスおよびステートフルリクエスト処理に対する NonStop DOM のサポート
□ スレッドパッケージのインタフェースおよび機能と、NonStop DOM アプリケーションが使用すべきで
ない機能 ( アプリケーションがスレッドを必要とする場合 )
□ ほかの CORBA 環境と NonStop DOM とのインタフェースの違い ( アプリケーションに複数のプラット
フォームのコンポーネントが含まれる場合、または NonStop DOM を使用するために既存のアプリケー
ションを修正する場合 )
□ Tandem データベース製品の機能と利点
2.2 NonStop DOM アプリケーションの設計
サブトピックス
□ NonStop DOM オブジェクトクラスの設計
このセクションでは、オブジェクトクラスの設計について解説します。
オブジェクトクラスの設計には、クラスのオブジェクトを参照するためにクライアントが使用する、オ
ブジェクト参照の作成が含まれます。これらのオブジェクト参照は、サーバに関連付けられたクラスによっ
て作成されます。詳しくは、「オブジェクト参照」を参照してください。
3-16
140418J
第 2 章 分散オブジェクトアプリケーション開発の概要
「クライアント」や「サーバ」という言葉は、プロセスが果たす役割を指します。しかし、1 つのプロセ
スが、クライアントとサーバの両方の役割を果たすこともできます。プロセスがオブジェクト上でメソッ
ドを呼び出すときは、クライアントとして機能しています。メソッドリクエストを受け取るときは、サー
バとして機能しています。両方の役割を持つプログラムを作成する場合は、両方のコンポーネントの注意
点を読んでください。
詳しくは、
「クライアントアプリケーションの開発」および「サーバアプリケーションの開発」を参照し
てください。
2.2.1 NonStop DOM オブジェクトクラスの設計
このセクションの内容は次のとおりです。
□ オブジェクトの役割と関係
□ オブジェクトの分散
□ 並列処理とその意義
NonStop DOM 環境でオブジェクトクラスを設計する際には、次のことを念頭においてください。
□ 各オブジェクトクラスの役割。たとえば、各オブジェクトがデータベース内のそれぞれのエンティティ
を表すのかどうか。また、オブジェクト間の関係。
□ ネットワーク上にユーザ、情報、そしてオブジェクトを分散させることの意義。
□ 並列処理、特に、サーバプールを使用することの利点と、1 つのオブジェクトに対する複数のリクエス
トが、複数のプロセスによって並列的に処理可能かどうか。
□ オブジェクトが永続的であるべきかどうか。サーバプロセス停止後もオブジェクトが保持され、そのオ
ブジェクト参照が有効とされるべきかどうか。
これらの問題をどう取り扱うかは、オブジェクトに対して作成され返されるオブジェクト参照、オブジェ
クトインスタンスの検索と作成方法、およびその他のクラス設計と使用法などの条件によって異なります。
オブジェクトの役割と関係
次に挙げる 3 階層のオブジェクト分類方法は、NonStop DOM に固有のものではありませんが、このセ
クション全体にわたって使用されています。
□ インタフェースオブジェクト 通常、クライアントワークステーションか、または銀行の ATM 装置や
ガソリンスタンドのポンプなどの、エンドユーザデバイス上で実行されます。
□ コントロールオブジェクト 通常、サーバマシン上で実行されます。withdrawFundsFromAccount
や TransferFundsBetweenAccounts といったように、各メソッドが作業単位に対応するた
め、これらのオブジェクトは、「ビジネストランザクションオブジェクト」とも呼ばれます。
□ エンティティオブジェクト OLTP でのビジネストランザクションといった、" 使用中 " として保持され
る必要のある永続データを表します。
これらの分類はあくまで概念的なものであり、CORBA や NonStop DOM で特定のクラスが定義されて
いるものではありません。
140418J
3-17
第 2 章 分散オブジェクトアプリケーション開発の概要
インタフェースオブジェクト
一般的に、
「インタフェースオブジェクト」は、コントロールオブジェクトまたはエンティティオブジェ
クトと相互に動作します。OLTP 環境では通常、ユーザがインタフェースオブジェクトと相互に動作する
ことで、結果的にコントロールオブジェクトと相互動作してトランザクションを開始することになります。
コントロールオブジェクトは、1 つまたは複数のエンティティオブジェクトと相互動作してトランザクショ
ンを実行します。ほとんどの場合、トランザクションは複数のデータベースまたは複数のデータベースレ
コードに対して実行されるため、インタフェースオブジェクトが直接エンティティオブジェクトと相互動
作することはめったにありません。
NonStop DOM では、インタフェースオブジェクトに関してとくに留意すべきことはありません。
コントロールオブジェクト
「コントロールオブジェクト」は、データベースと直接は相互動作しません。データを表したり操作した
りするエンティティオブジェクトと相互動作 ( つまりエンティティオブジェクトを制御 ) します。
1 つのコントロールオブジェクトがトランザクションをすべて実行する場合は、そのコントロールオブ
ジェクトがトランザクションの開始とコミットを行います。
複数のコントロールオブジェクトがトランザクションの各部分をそれぞれ実行する場合は、もう 1 つ別
のコントロールオブジェクトを定義し、作業の調整や、トランザクションの開始およびコミットを実行さ
せる必要があります。
コントロールオブジェクトはビジネストランザクションの外部には存在しないため、共有データリソー
スを表すオブジェクトのように、オブジェクト共有の問題を起こすことはありません。
ただし、オブジェクトがサーバプール内に実装される場合は、設計の際に注意すべき点があります。そ
れは、呼出し間の動的コンテキストを、オブジェクトがどこに保持すべきかという問題です。たとえば、
借方に記入するメソッドは、アカウント ( 番号パラメータ ) を使ってデータベースから必要なコンテキスト
をすべて取得することができるため、動的ステートを保持する必要はありません。結果セットで繰り返さ
れるメソッドは結果セットに対するカーソルの形で動的な状態を維持する必要があるかもしれません。オ
ブジェクトが呼出し間の動的コンテキストを保持するかどうかは、ロードバランシングにも影響を与え、
その結果、
「並列処理とその意義」に記載されているように、アプリケーションスループットにも影響しま
す。
エンティティオブジェクト
「エンティティオブジェクト」は、デバイスを表すこともできますが、通常は、保管されたデータを表し
ます。エンティティオブジェクトは、インタフェースオブジェクトまたはコントロールオブジェクトによっ
て使用されます ( インタフェースオブジェクトは、コントロールオブジェクトを介さずにエンティティオ
ブジェクトと相互動作することもできます )。
エンティティオブジェクトは普通、複数のクライアント ( 通常はコントロールオブジェクト ) に共有さ
れます。そのため、アプリケーションを設計する際は、複数のクライアントが同時に 1 つのオブジェクト
を呼び出す場合のことを考えておく必要があります。
一般にエンティティオブジェクトは、ほかのエンティティオブジェクトを制御しません。ただし、ある
エンティティオブジェクトが、ほかの複数のエンティティオブジェクトの複合体である場合は別です。た
とえば、あるエンティティオブジェクトからの顧客情報と、ほかのエンティティオブジェクトからのトラ
ンザクション履歴を持つ「customer」オブジェクトなどが考えられます。
3-18
140418J
第 2 章 分散オブジェクトアプリケーション開発の概要
永続データを表すオブジェクトは、永続オブジェクトである必要があります。
オブジェクトの分散
アプリケーションとクラスライブラリが、ローカル / リモート透過性を念頭に設計された場合は、クラ
イアントのプログラミングの際に、オブジェクトがローカルであるかリモートであるかに留意する必要は
ありません。しかし、オブジェクト分散には、アプリケーションパフォーマンスの問題がかかわってきます。
可能なかぎり、次のガイドラインに沿ってオブジェクトを設計および分散してください。
□ 相互動作の最も多いオブジェクトどうしを、近くに配置する。
多数のエンティティオブジェクトを順次検索するなど、あるコントロールオブジェクトが 1 つのエン
ティティオブジェクトと頻繁に相互動作する場合で、コントロールオブジェクトがインタフェースオブ
ジェクトに対して、明確に定義されたインタフェースを少数持つ場合は、コントロールオブジェクトを、
エンティティオブジェクトと同じマシン上に配置します。
同様に、コントロールオブジェクトがデータベースを直接使用する場合は、オブジェクトを、データベー
スと同じマシン上に配置します。
□ リモートオブジェクトとの相互動作を最小限におさえる。
リモートオブジェクトとの相互動作に必要なメッセージの数をできるだけ少なくするように、データと
メソッドを設計します。これにより、ターゲットオブジェクトがローカルである場合も、多少はパフォー
マンスが向上します。
たとえば、コントロールオブジェクトまたはエンティティオブジェクトが、多くの「readonly」属性を
持つオブジェクトをクライアントに返す場合、代わりに struct を返すことを検討してください。属性をア
クセスする
get_ メソッドは個々のネットワークメッセージに変換されますが、struct は、それを返すメ
ソッド呼出しの一部として、値によって渡されます。
次の例は、複数の属性を持つオブジェクトの定義例です。
複数の属性を持つオブジェクトの定義
interface account {
readonly attribute string CustomerName;
readonly attribute string CustomerAddress;
}
このようなオブジェクトが分散された場合、クライアントは、各属性を読み込むために個別のメッセー
ジを送信する必要があります。
属性を 1 つだけ持つようなインタフェース定義に変更すれば、クライアントは、すべての情報を取得す
るために 1 つのメッセージを送信するだけで済みます。
単一の属性を持つオブジェクトの定義
interface account {
struct CustomerRecord {
string name;
string address;
};
140418J
3-19
第 2 章 分散オブジェクトアプリケーション開発の概要
readonly attribute CustomerRecord customer;
}
□ オブジェクトを複数の CPU 上に分散する場合は、サーバプールを使用する。可能な限り、同じオブジェ
クトへのリクエストも同様の方法で分散する。「並列処理とその意義」を参照してください。
並列処理とその意義
NonStop DOM では、アプリケーションサーバを NonStop TS/MP サーバプールとして実行することがで
きます。このタイプの実装では、多数のプロセスが 1 つの論理サーバとして動作することができます。そ
れぞれの新しい作業単位は、プール内で最もビジーでないプロセスに送られます。サーバプロセスは、別々
の CPU 内で実行することができ、これにより並列処理が可能になります。サーバプールについて詳しく
は、『第 2 部 NonStop™ DOM 管理者ガイド』を参照してください。
一般に、サーバプール内のオブジェクトの実装は、プログラマに対して透過的です。ただし次の特性は
例外です。
□ 1 つのオブジェクトクラスのクラスデータは、オブジェクトクラス全体ではなく、1 つのプロセス内の
オブジェクトにだけ適用されます。オブジェクトクラス全体には、他のプロセス内のインスタンスが含
まれている場合があります。
□ 永続性を必要とするオブジェクトのロードバランシングは、NonStop TS/MP 上でだけ使用できます。
ステートフルオブジェクトとステートレスオブジェクト
NonStop DOM では、ステートフルオブジェクトもステートレスオブジェクトも使用できます。
オブジェクトがステートレスの場合は、オブジェクトの各メソッド呼出しは、プール内の別々のサーバ
プロセスによって処理することができます。ステートレスオブジェクトでは、ステート情報を 1 つのプロ
セスだけでしか使用できないため、複数の呼出しの間でステート情報をメモリに保持することができません。
オブジェクトがステートフルの場合は、オブジェクトの最初のメソッド呼出しは、プール内の空いてい
るサーバプロセスのどれにでも送ることができます。その後の一連のリクエストはすべて、同じプロセス
に送られます。ステートフルオブジェクトでは、情報にアクセスするプロセスが 1 つしかないため、複数
のメソッド呼出しの間でステート情報をメモリに保持することができます。
1 つのサーバプールで、ステートレスオブジェクトとステートフルオブジェクトの両方をホストするこ
とができます。オブジェクトがサーバプール内にあるか専用の 1 つのサーバ内にあるかは、ステートレス
とステートフルの区別には関係ありません。
重要な検討事項
ORB メソッドルーティングの観点から見れば、ステートフルリクエストに比べて、ステートレスリクエ
ストは格段に効率的です。これは、NonStop TS/MP によって提供されるキューイングの効率性によります
(ATM 1 台ごとに別々の行列をつくる場合と、すべての ATM に対して全員が 1 列で並ぶ場合との違いに似
ています )。このため、スループットを最大化するには、ステートレスなクラスを設計するほうが良いよう
に思われます。
しかし場合によっては、オブジェクトをステートレスにすることによって、不便になったり、費用がか
かったりすることもあります。たとえば、オブジェクトが、「カーソル」を使って、大きな SQL 問合せの
結果をクライアントに返す場合、クライアントは、サーバ上で複数のメソッド呼出しを行う必要がありま
す。オブジェクトがステートレスの場合、その後の一連のメソッド呼出しが別々のサーバプロセスに送ら
れ、それぞれが元の問合せを繰り返すことになります。
3-20
140418J
第 3 章 NonStop DOM アプリケーションの開発
第 3 章 NonStop DOM アプリケーションの開発
3.1 アプリケーション開発の概要
NonStop DOM を使った分散オブジェクトアプリケーションは、次の主要 3 タイプのコンポーネントで
構成されています。
□ オブジェクトクラス
□ サーバ ( 各サーバが 1 つまたは複数のオブジェクトクラスをホストする )
□ クライアント ( サーバ内のオブジェクトを利用する )
1 つのプロセスが、クライアントとしてもサーバとしても動作することができます。つまり、1 つのプロ
セスが、オブジェクトをホストし、なおかつ同じプロセスまたは別のプロセス内でオブジェクトのリクエ
ストを作成することができます。
このセクションでは、単純なクライアントとサーバの開発手順を簡単に紹介します。より複雑なアプリ
ケーション環境を開発する場合は、個々の部分でこれらの手順を使用します。違いは、オブジェクトの数
と、クライアント―オブジェクト間の相互動作の複雑さです。
アプリケーション開発については通常、1 人の開発者がすべてのコンポーネントをコントロールすると
いう前提で解説されますが、オブジェクト指向技術では、それぞれのコンポーネントを開発する際に、相
互動作の相手となるほかのコンポーネントの詳細を知っている必要はありません。
まずは、stock.idl のオブジェクトインタフェース仕様の例を使って、クライアントとサーバ開発
のプロセスを順に見てみましょう。必要な手順は次のとおりです。図 3-1 に図解されています。
1. オブジェクト実装の出発点は、CORBA IDL (Interface Definition Language) です。オブジェクトクラス
を作成する際は、IDL を使ってオブジェクトインタフェースを定義します。
2. IDL 仕様が、IDL コンパイラに入力されます。
3. IDL コンパイラが、次のファイルを生成します。
□ オブジェクトクラスを使用するクライアントプログラムに含まれる、ヘッダファイル
□ コンパイルされ、クライアントプログラムにリンクされる C++ ソースファイル。このファイルには、ク
ライアントスタブが含まれます。
□ オブジェクトクラスを実装するプログラムに含まれる、ヘッダファイル
□ コンパイルされ、実装とリンクされるソースファイル。このファイルには、サーバスケルトンが含まれ
ます。
4. クライアントアプリケーション開発者が、オブジェクトを使用するアプリケーションコードを作成しま
す。これにより、IDL コンパイラによって生成されたクライアントヘッダファイルが含まれます。
5. クライアントアプリケーションコードがコンパイルされ、オブジェクトファイルが生成されます。
6. IDL コンパイラによって生成されたクライアントスタブコードがコンパイルされ、オブジェクトファイ
ルが生成されます。
140418J
3-21
第 3 章 NonStop DOM アプリケーションの開発
7. 2 つのクライアントアプリケーションファイルが ( 通常、ほかのオブジェクトファイルと ) リンクされ、
クライアントプログラムが生成されます。
8. サーバ実装の開発者が、サーバスケルトンヘッダの情報に基いてオブジェクト実装ヘッダファイルを作
成します。
9. サーバ実装の開発者が、サーバのメインプログラムとオブジェクト実装を作成します。IDL インタフェー
ス定義で宣言されたメソッドごとにコードを作成する必要があります。
10. サーバ実装コードがコンパイルされ、オブジェクトファイルが生成されます。
11. IDL コンパイラによって生成されたサーバスケルトンコードがコンパイルされ、オブジェクトファイル
が生成されます。
12. 2 つのサーバ実装ファイルが ( 通常、ほかのオブジェクトファイルと ) リンクされ、サーバプログラム
が生成されます。
13. サーバプログラムが開始されます。NonStop DOM SRL (Shared Runtime Library) に含まれる NonStop
DOM ORB 実装が使用されます。
14. クライアントアプリケーションプログラムが開始されます。ここでも、NonStop DOM SRL が使用され
ます。サーバ内でホストされるオブジェクトのリクエストを作成し、返答を受け取ります。
図 3-1 クライアントとサーバの開発手順
3-22
140418J
第 3 章 NonStop DOM アプリケーションの開発
3.2 クライアントアプリケーションの開発
このセクションでは、NonStop DOM を使ったクライアントアプリケーション開発に必要な、基本的な
項目について簡単に説明します。このセクションで得た知識を使って、次のような動作を実行するクライ
アントアプリケーションを開発することができます。
サブトピックス
□ Object Request Broker (ORB) の初期化
□ オブジェクト参照の取得
□ オブジェクト参照の限定
□ メソッドの呼出し
□ 例外処理
□ オブジェクト参照の解放
□ 使用不能なシステムコール
これらの各項目についてさらに詳しくは、これ以降のセクションで説明しています。
ここでは、先のセクションで紹介したストック例プログラムのクライアント側を使用します。一般的な
NonStop DOM クライアントアプリケーション開発について理解していただくため、このセクションでは、
クライアントプログラムのそれぞれの動作を詳しく見ていきます。
3.2.1 Object Request Broker (ORB) の初期化
NonStop DOM メソッドを使用したり、ユーザ定義オブジェクトのメソッドを呼び出したりする前に、ク
ライアントプログラムが ORB オブジェクトを初期化する必要があります。次のコードは、初期化のようす
を示しています。
ORB の初期化
int main(int argc, char *argv[])
{
// Initialize the ORB
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
ORB_init( ) に渡される値 argc と argv は、メインプログラムに渡されるコマンドライン引数
)
メソッドは、コマンドライン引数を解釈します。特に、-ORBprofile 引数は、このプログラムによっ
て使用される実行プロファイルを指定します。ORB_init( ) は、プロファイル名を使って NonStop
を表します。argc は引数の個数で、argv は引数文字列のリストへのポインタです。ORB_init(
DOM 構成データベースからプロファイル情報を取り込みます。
ORB_init( ) への呼出しが正しく行われると、ORB のオブジェクト参照が返されます。戻り値の型
は CORBA::ORB_ptr です。このオブジェクト参照は後で、ORB オブジェクトに定義されたメソッド
を呼び出す際に使用されます。
140418J
3-23
第 3 章 NonStop DOM アプリケーションの開発
必要に応じて、ORB_init(
) を複数回呼び出すこともできます。複数回呼び出す必要があるのは、
通常、メインプログラム以外のモジュール内にある ORB オブジェクト参照を取得する場合だけです。メイ
ンプログラム内にある場合と同じように、ORB オブジェクト参照は、ORB オブジェクトに定義されたメ
ソッドを呼び出すのに使用されます。
3.2.2 オブジェクト参照の取得
クライアントがオブジェクト上でリクエストを作成するには、そのオブジェクトのオブジェクト参照を
取得する必要があります。オブジェクト参照には、ORB がオブジェクトに到達してメソッドを呼び出すの
に必要な情報が、すべてカプセル化されています。オブジェクト参照について詳しくは、
「オブジェクト参
照」を参照してください。
クライアントがオブジェクト参照を取得する方法には、次の 2 つがあります。
□ ファイルからオブジェクト参照を読み込む。
□ オブジェクト参照を返すメソッドを呼び出す。
ファイルからオブジェクト参照を読み込む
オブジェクトをホストするサーバプログラムは、オブジェクト参照を作成してファイルに書き込むこと
ができます。その後、クライアントプログラムはそのオブジェクト参照を読み込んで使用することができ
ます。
次のコード例は、ファイルからオブジェクト参照を読み込んで、利用可能な形式に変換するようすを示
しています。
ファイルからのオブジェクト参照の読み込み
// Read IOR from file, convert it to an object reference
CORBA::Object_ptr CORBAObject;
FILE *IORFile = fopen("ior.txt", "r" );
char * IORString = new char[1000];
fread( IORString, 1, 1000, IORFile );
CORBAObject = orb->string_to_object( IORString );
delete [] IORString;
メソッドを呼び出してオブジェクト参照を取得する
メソッド呼出しの結果としてオブジェクト参照を返させることもできます。この場合によく使われるの
は、Naming Service です。すでに Naming Service に保管されているオブジェクト参照は、resolve(
)
メソッドを呼び出すことによって取り込むことができます。オブジェクトをホストするサーバは、Naming
Service 内にオブジェクト参照を保管していますので、クライアントプログラムから取り込み可能です。当
然、クライアントプログラムは、まず Naming Service のオブジェクト参照を取得する必要があります。取
得するには、resolve_initial_references(
) メソッドを呼び出します。
次のコード例は、Naming Service からオブジェクト参照を取得するようすを示しています。
3-24
140418J
第 3 章 NonStop DOM アプリケーションの開発
Naming Service のルートコンテキスト取得
CORBA::Object_ptr CORBAObject;
CORBAObject = orb->resolve_initial_references("NameService");
RootNameContext = CosNaming::NamingContext::_narrow(CORBAObject);
// Find the Stock object
name.length(2);
name[0].id = "NSDOM-Samples";
name[0].kind = "";
name[1].id = "StockObject";
name[1].kind = "";
TRY
{
CORBAObject = RootNameContext->resolve(name);
}
CATCH(CORBA::SystemException, exception)
{
cout << "Error: Exception during resolve: " << exception <<
endl;
return 1;
}
ALSO_CATCH(CORBA::UserException, exception)
{
cout << "Error: Unable to find StockObject"
<< " in Naming Service." << endl
<< "
" << exception << endl;
return 1;
}
END_CATCH
3.2.3 オブジェクト参照の限定
オブジェクト上でメソッドを呼び出すには、正しい型のオブジェクト参照が必要です。前述のオブジェ
CORBA::Object 型のオブジェクト参照が作成されますが、必要
なオブジェクトは Stock 型です。オブジェクト参照が実際は Stock オブジェクトを参照すると仮定し
て、_narrow( ) メソッドを使用して正しい型の参照を取得することができます。_narrow( ) メ
クト参照取得の方法では、どちらも
ソッドは、オブジェクトインタフェースを記述する IDL ファイルがコンパイルされる際に、IDL コンパイ
ラによって作成されます。
次のコードは、_narrow(
) 操作の使用例です。
限定操作
Stock_var aStockObject;
// Perform a narrow operation to get a stock object reference
TRY
{
aStockObject = Stock::_narrow(CORBAObject);
}
CATCH (CORBA::Exception, exception)
{
cout << "Unexpected exception during narrow operation." <<
endl
<< exception
140418J
3-25
第 3 章 NonStop DOM アプリケーションの開発
<< endl;
exit(EXIT_FAILURE);
}
END_CATCH
3.2.4 メソッドの呼出し
正しい型のオブジェクト参照が得られたら、クライアントはオブジェクト上でメソッドを呼び出すこと
ができます。オブジェクトのインタフェース定義で定義されているメソッドはどれでも呼び出すことがで
きます。メソッドは、通常の C++ メソッド呼出し構文を使って呼び出します。メソッドのパラメータは、
メソッド宣言で指定されています。次のコード例は、Stock オブジェクトを使ったメソッド呼出しのようす
を示しています。
CORBA::Double Last, High, Low;
CORBA::ULong Volume;
TRY
{
aStockObject->quote("CPQ", Last, High, Low, Volume );
}
CATCH (CORBA::Exception, exception)
{
cout << "Unexpected system exception during quote operation."
<< endl
<< exception
<< endl;
return 1;
}
END_CATCH
この例では、quote(
) メソッドが呼び出されています。IDL 内でのメソッド宣言は次のとおりです。
void quote( in string Symbol, out double Last, out double High,
out double Low, out unsigned long Volume )
raises( operationFailed );
最初のパラメータは、string 型の入力パラメータです。C++ でこれに対応する型は、文字列へのポ
インタです。その他のパラメータは出力パラメータで、quote(
) メソッドによって値が得られます。
double 型 で、1 つは unsigned long 型で す。C++ で対 応す る型 は、
CORBA::Double と CORBA::ULong です。
パ ラメ ータ の内 3 つ は
3.2.5 例外処理
クライアントアプリケーションプログラムがメソッドを呼び出す際は、例外処理に備えておく必要があ
ります。例外は通常、メソッド呼出し中に予期できない状況や異常な状況が発生したことを表しています。
例外には、システム例外とユーザ例外の 2 種類があります。システム例外は、リクエスト処理中にエラー
が発生した場合に上げられます。ユーザ例外は、メソッド実装によって上げられ、リクエスタに対して、
異常な状況を知らせるために使われます。
例外は、CORBA オブジェクト上で行うどのメソッド呼出しでも発生する可能性がありますので、綿密
にチェックしてください。例外が検出されずに残っていると、プログラムが不正な動作を行い、トラブル
3-26
140418J
第 3 章 NonStop DOM アプリケーションの開発
シューティングが難しくなります。例外を検出したら、適切な手順を踏んで、正しい処理が行われるよう
に修正してください。使用されるアプリケーションプログラムに応じて、リクエストを作成し直す、代替
処理パスを使用する、エラーを記録する、またはプログラムを異常終了するなどが考えられます。
環境例外
NonStop DOM アプリケーションの作業を行う際は、マルチスレッドでスケーラブルなアプリケーショ
ン内の例外処理に、環境例外を使用することをおすすめします。環境例外は、NonStop DOM の CORBA 環
境クラスで提供されます。
環境例外を使用するには、プロジェクトの Makefile 内で
には、Makefile の include
NSD_ENV スイッチを設定します。設定する
macros.mk 行の直前に行を追加して、次のようにします。
NSD_ENV=1
include macros.mk
NSD_ENV を設定すると、IDL コンパイラによって、環境例外を利用するためのスタブとスケルトンが
生成されます。環境例外を使用すると、最終パラメータとして環境変数を含む、メソッドシグニチャが IDL
コンパイラによって生成されます。通常、これはデフォルトパラメータとして自動的に供給されます。
これらのマクロを使ったプログラミングパターンは次のとおりです。
例外処理マクロの使用
TRY
{
// user code including NonStop DOM method invocation
}
CATCH (<exception-type>, <variable>)
{
<exception-type>
}
END_CATCH
exception-type の部分には次のどれかが入ります。
表 3-1 例外の型
例外型
使用法
CORBA::Exception
システム例外またはユーザ例外を捕捉
CORBA::SystemException
あらゆるシステム例外を捕捉
CORBA:: 特定の例外名
特定のシステム例外を捕捉
CORBA::UserException
あらゆるユーザ例外を捕捉
ユーザクラス :: ユーザ例外名
特定のユーザ例外を捕捉
複数の例外をチェックするには、ALSO_CATCH 句を使用します。これは、最初の
140418J
CATCH 句と
3-27
第 3 章 NonStop DOM アプリケーションの開発
END_CATCH 句の間に置きます。ALSO_CATCH はいくつでも使用することができます。置かれた順に
評価されます。
複数の例外の捕捉
TRY
{
// user code including NonStop DOM method invocation
}
CATCH ( exception-type , <variable>)
{
<exception-type>
}
ALSO_CATCH ( exception-type , <variable>)
{
<exception-type>
}
END_CATCH
CATCH_ALL マクロを使用して、すべての型の例外を捕捉することもできます。
すべての例外の捕捉
TRY
{
// user code including NonStop DOM method invocation
}
CATCH_ALL
{
<exception-type>
}
END_CATCH
3.2.6 オブジェクト参照の解放
クライアントアプリケーションプログラムは、使い終わったオブジェクト参照を解放する必要がありま
す。オブジェクト参照を解放すると、ORB が、オブジェクト参照に割り当てられたローカルメモリを解放
することができます。オブジェクト参照を解放しても、サーバ内に常駐している実際のオブジェクトには
影響ありません。
オブジェクトの解放
// Release the object (locally)
CORBA::release(aStockObject);
3.2.7 使用不能なシステムコール
クライアントは、あらゆる Guardian および OSS 呼出しを実行できますが、次のことは実行できません。
□ クライアントは、ファイルパラメータに -1 を使って
AWAITIO または AWAITIOX を呼び出すこと
はできません。
□ クライアントが OTS (Object Transaction Service) を使用する場合は、NonStop TM/MP を直接呼び出す
ことはできません。
このような呼出しを行うと、NonStop DOM の実行時に影響を与えます。
3-28
140418J
第 3 章 NonStop DOM アプリケーションの開発
3.3 サーバアプリケーションの開発
このセクションでは、オブジェクト実装をホストするサーバプログラムを作成する際に知っておくべき
次の項目について説明します。
サブトピックス
□ 実装ヘッダファイルの作成
□ オブジェクト実装の作成
□ ユーザ例外の作成
□ サーバメインプログラムの作成
ここで紹介する例は、単一の非永続オブジェクトをホストするサーバについての例です。サーバプログ
ラミング技術について詳しくは、「POA (Portable Object Adapter)」を参照してください。
3.3.1 実装ヘッダファイルの作成
実装ヘッダファイルには、サーバオブジェクト内で実装される、単一または複数のクラスの定義が含ま
れています。クラスには、オブジェクトのコンストラクタおよびデストラクタと、クラス内で実装される
メソッドの宣言が含まれます。
Stock インタフェース定義ファイル stock.idl の場合、IDL コンパイラが実装ヘッダファイルを作成し
ます。このファイルは、デフォルトで stock_header.h と名付けられます。ファイルの内容は次のと
おりです。
例 1. Stock ヘッダファイル
class POA_Stock
: public virtual NSDOM_ServantBase,
public Stock
{
public:
POA_Stock() { }
. . .
// The following operations need to be implemented by the
server.
virtual void quote(
const char* Symbol,
CORBA::Double_out Last,
CORBA::Double_out High,
CORBA::Double_out Low,
CORBA::ULong_out Volume,
CORBA::Environment &pr_env) = 0;
virtual void update(
const char* Symbol,
CORBA::Double Price,
CORBA::ULong Volume,
CORBA::Environment &pr_env) = 0;
140418J
3-29
第 3 章 NonStop DOM アプリケーションの開発
// End of operations to be implemented by the server.
. . .
}
quote( ) と update( ) の 2 つのメソッドの IDL 宣言によって、このクラス内に純仮想メソッド
が生成されました。実装ヘッダファイルには、Stock_impl という新しいクラスが含まれています。
例 2. quote( ) と update( ) の C++ 宣言
#include "stock_server.h"
class Stock_impl: public POA_Stock
{
public:
Stock_impl();
~Stock_impl(){}
void quote(const char* Symbol,
CORBA::Double_out Last,
CORBA::Double_out High,
CORBA::Double_out Low,
CORBA::ULong_out Volume,
CORBA::Environment &pr_env);
void update(const char* Symbol,
CORBA::Double Price,
CORBA::ULong Volume,
CORBA::Environment &pr_env);
};
実装ヘッダファイルは、IDL コンパイラによって作成されたサーバヘッダを含むところから開始されて
います。ここでは新しいクラスを Stock_impl と名付けましたが、ほかの名前でもかまいません。クラ
スは、IDL コンパイラによって生成された POA_Stock クラスから継承される必要があります。コンストラ
クタとデストラクタの宣言も追加しました。quote(
) と update( ) には、それぞれに宣言が与え
られています。これらのメソッドは、オブジェクト実装ファイル内で実装されます。
実装ヘッダファイル内には、インタフェース定義にあるすべてのメソッドの宣言が含まれている必要が
POA_Stock 内の抽象定義をコピーし、virtual
あります。最も簡単にこれらの定義を挿入する方法は、
と =0 の部分を削除することです。
必要に応じて、ほかの一般的な C++ コンストラクト、プライベートインスタンス変数、およびヘルパー
メソッドを追加することができます。
3.3.2 オブジェクト実装の作成
オブジェクト実装には、実際のメソッド実装が含まれます。実装ヘッダファイルに対応する、オブジェ
クト実装ファイルの基本構造は、次のとおりです。
例 3: メソッドの実装
#include "stock.h"
Stock_impl::Stock_impl()
{
// Implementation code for this constructor
3-30
140418J
第 3 章 NonStop DOM アプリケーションの開発
}
void Stock_impl::quote(const char* Symbol,
CORBA::Double_out Last,
CORBA::Double_out High,
CORBA::Double_out Low,
CORBA::ULong_out Volume,
CORBA::Environment &pr_env)
{
// Implementation code for this method
}
void Stock_impl::update(const char* Symbol,
CORBA::Double Price,
CORBA::ULong Volume,
CORBA::Environment &pr_env)
{
// Implementation code for this method
}
まず、実装クラス定義が入っている実装ヘッダファイルを含めます。実装ヘッダファイルからメソッド
シグニチャがコピーされます。メソッド名の前に、クラス名と有効範囲演算子を追加してあります。その
後、メソッドの本体に実装コードを追加してあります。
実装コードは、必要なロジックをすべて実行します。一般に、このロジックでは入力パラメータが使わ
れ、出力値が計算されて、出力パラメータと戻り値を使って呼出し元に渡されます。IDL ファイル内のメ
ソッド定義で、メソッドのユーザ例外が定義されている場合は、環境パラメータを使って例外を返すこと
ができます。
3.3.3 ユーザ例外の作成
メソッドによって異常な状況が検出されると、例外が上げられます。例外はリクエスタに知らされ、リ
クエスタは適切なアクションを実行します。例外が上げられた場合、メソッドの出力パラメータと戻り値
は定義されないままになります。
stock.idl では、operationFailed という例外が定義されています。この例外を上げることができ
るメソッドとして quote( ) が宣言されています。operationFailed 例外の宣言により、IDL コ
ンパイラは、operationFailed クラスを作成します。このクラスのインスタンスを作成し、例外を
上げたときに、この型の例外が投げられます。
例 4: 例外を上げる様子
pr_env.exception(new Stock::operationFailed(NOT_FOUND));
IDL コンパイラによって作成されたメソッドシグニチャでは、ネイティブ C++ コンパイラの例外がサ
CORBA::Environment 変数が含まれています。ここでは、例外を上げるた
めに、CORBA::Environment に定義された exception( ) メソッドを使っています。
ポートされない環境内に
3.3.4 サーバメインプログラムの作成
サーバ実装のメインプログラムでは、リクエスト処理の環境が設定されます。最初の手順は、ORB を初
期化して、ルート POA のオブジェクト参照を取得することです。
140418J
3-31
第 3 章 NonStop DOM アプリケーションの開発
例 5: ORB の初期化とオブジェクト参照の取得
int main(int argc, char *argv[])
{
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
CORBAObject = orb->resolve_initial_references("RootPOA");
PortableServer::POA_ptr rootPOA;
rootPOA = PortableServer::POA::_narrow(CORBAObject);
ORB の初期化は、クライアントプログラムの ORB_init( ) の場合と同じ方法で行われます。POA はサー
バを管理し、サーバがホストするオブジェクト上でメソッドを呼び出します。
resolve_initial_references( ) メソッドを呼び出すことによって、ルート ( 最上位 ) の
POA への参照が取得できます。Stock サーバの場合は、必要なのはルート POA だけです。サーバプロセス
によっては、ほかの POA 機能を使う必要があります。ほかの POA 機能については「POA (Portable Object
Adapter)」を参照してください。resolve_initial_references( ) メソッドによって、CORBA
オブジェクトが返されます。ここではこれを、PortableServer オブジェクト参照に限定しました。
これによって、POA のメソッドを呼び出すことができます。
Stock_impl オブジェクトのインスタンスが作成されます。これは、クライアントから届くリクエス
トを処理するオブジェクトです。このオブジェクトを有効化するよう、POA に伝えられます。有効化され
たあと、このオブジェクトはリクエストを処理することができます。activate_object(
) メソッ
ドは、オブジェクト ID を返します。ここでは必要ないため、削除してあります。
例 6: オブジェクトの有効化
Stock_impl *TestServant = new Stock_impl;
PortableServer::ObjectId_ptr oid
= rootPOA->activate_object(TestServant);
delete oid;
ここで、新しく作成されたオブジェクトについてクライアントに知らせるため、オブジェクト参照を文
字列化 ( 外部形式に変換 ) します。文字列化された形式は、ファイルに書き込まれます。
例 7: 文字列化したオブジェクト参照の外部化
CORBAObject = rootPOA->servant_to_reference(TestServant);
char* IORString = orb->object_to_string( CORBAObject );
FILE *IORFile = fopen( "ior.txt", "w" );
fwrite( IORString, strlen( IORString ) + 1, 1, IORFile );
fclose( IORFile );
最後の手順は、POA を有効化して、リクエストのサービスを開始させることです。
例 8: POA の有効化と実行
rootPOA->the_POAManager()->activate();
orb->run();
return 0;
}
3-32
140418J
第 3 章 NonStop DOM アプリケーションの開発
Stock インタフェース定義ファイル
例 9. stock.idl の内容
interface Stock
{
// status for user defined exceptions
enum operation_status {
NOT_FOUND
// Stock symbol not found
};
// user defined exception
exception operationFailed {
operation_status status;
};
// The type of failure
void quote( in string Symbol, out double Last, out double
High,
out double Low, out unsigned long Volume )
raises( operationFailed );
void update( in string Symbol,
in double Price, in unsigned long Volume )
raises( operationFailed );
};
3.4 POA (Portable Object Adapter)
サブトピックス
□ POA の作成
□ POA ポリシーオブジェクト
□ 参照の作成
□ サーバントマネージャ
□ 永続オブジェクトと非永続オブジェクト
□ Adapter Activator
このセクションでは、関連用語の説明、POA アーキテクチャの図解、POA 実装方法例などを使って、
POA (Portable Object Adapter) の概要を簡単に説明します。
Object Adapter は、サーバ側の CORBA オブジェクトがどのように ORB と相互動作するかを定めた仕様
です。CORBA 2.2 より前のバージョンでは、BOA (Basic Object Adapter) が使われていました。しかし BOA
仕様ではベンダごとに異なる実装を行なっていたため、サーバ側に移植性がありませんでした。CORBA
2.2 では、Basic Object Adapter の代わりに POA (Portable Object Adapter) が使用されています。
POA 仕様では、実装のサーバ側での移植性が提供されており、移植性を高めるためにより厳密な仕様が
定められていて、機能もより豊富です。
まず POA の基本用語について説明します。オブジェクトの実装は、サーバント（servant）と呼ばれ、
140418J
3-33
第 3 章 NonStop DOM アプリケーションの開発
サーバントの作成は、インカネーション (incarnation) と呼ばれます。サーバントをエーテル化する
(etherealize) とは、破壊することです。CORBA オブジェクト参照は、Active Object Map を使ってサーバン
トに関連付けられます。Active Object Map には、各オブジェクト参照が、Object ID によってサーバントに
マップされています。
POA は、次の目的を満たすために設計されました。
□ 異なる ORB 製品間で移植可能なオブジェクト実装を構築すること。
□ 永続的 ID を持つオブジェクトのサポートを提供すること。厳密に言うと、POA は、そのオブジェクト
の参照を持つクライアントから見た存続時間 (lifetime) が、複数のサーバのライフタイムにまたがるよ
うなオブジェクトに対して、一貫したサービスを提供できるオブジェクト実装をプログラマが構築でき
るように設計されました。
□ オブジェクトの透過的有効化をサポートすること。これによりクライアントは、有効化されていないオ
ブジェクトのオブジェクト参照を持つことができます。クライアントはオブジェクト参照を使ってこの
オブジェクト上の操作を呼び出すことができ、それによってサーバ側のオブジェクトが透過的に有効化
されます。
□ 1 つのサーバントが、同時に複数のオブジェクト ID をサポートできるようにすること。
□ POA の異なる複数のインスタンスが、1 つのサーバ内に存在できること。1 つのサーバ内で、異なるポ
リシーをもつ複数の POA を作成することが可能です。
□ 最小限のプログラミングの手間と経費で、非永続オブジェクトをサポートすること。非永続オブジェク
トは、ORB でデフォルトで提供されている RootPOA によって提供されます。
□ POA が割り当てたオブジェクト ID を持つサーバントの黙示的有効化をサポートすること。たとえば、
サーバント上で _this(
) メソッドを呼び出すと、サーバントが POA に登録され、オブジェクト参
照が返されます。
□ オブジェクトの動作を、できる限りオブジェクト実装に制御させること。具体的には、オブジェクト
ID を定義するデータを確立する、オブジェクト ID とオブジェクトステートの関係を限定する、オブ
ジェクトステートの保管と取り込みを管理する、リクエストに対応して実行されるコードを提供する、
特定の時点でオブジェクトが存在するかどうかを決定する、などの手段をとります。
□ ORB が永続ステートを保持しなくてもいいようにすること。永続ステートには、個々のオブジェクト、
その ID、ステートの保管先、特定の ID 値が以前使われたかどうか、オブジェクトが存在しているかど
うか、などが記述されます。
□ ポリシー情報と、POA 内で実装されるオブジェクト間の関連付けに、拡張性のある機構を提供するこ
と。
□ OMG IDL コンパイラにや DSI 実装により生成された静的スケルトンクラスから継承するオブジェク
トの実装の構築を可能とすること。
クライアントのリクエストを満たすため、ORB から POA が 呼び出されます。POA は、クライアント
リクエストで要求された作業を実際に行うサーバントを有効化します。
クライアントリクエストは、CORBA オブジェクト (Object クラス )、または
Object から導出さ
れたクラスに対する呼出しです。クライアントは、ローカル ( 同じプロセス内にある ) でもリモート ( ほか
3-34
140418J
第 3 章 NonStop DOM アプリケーションの開発
のプロセスにある ) でもかまいません。
クライアントリクエストの処理には、次の手順が必要です。
1. 正しい POA を見つけます。有効化されていない場合、以前にアダプタアクティベータが設定されてい
れば、アプリケーションが POA を有効化することができます。
2. POA が見つかったら、ステートがチェックされ、有効かどうかが調べられます。POA マネージャが、
関連付けられたすべての POA のステートを管理します。POA 自体が有効化されている必要がありま
す。ステートが有効でない場合は、リクエストが停止または拒否されます。
3. ステートが有効な場合は、適切なサーバント ( リクエストの実際の対象 ) を見つけます。サーバントの
検索は、リクエストを媒介する POA の Servant Retention ポリシーに依存します（上記の手順 2 を参
照）。どの場合でも、サーバントが見つかるまで、次の手順には進みません。
4. クライアントによって指定されたメソッドが、サーバント上で呼び出されます。
POA 用語
POA の解説では、次の用語が使用されています。解説を読む前に、これらの用語と、一般的なオブジェ
クト指向プログラミング用語および概念について理解しておいてください。
□ アダプタアクティベータ
□ クライアント
□ CORBA オブジェクト
□ オブジェクト
□ オブジェクト ID
□ オブジェクト参照
□ POA マネージャ
□ ポリシー
□ POA (Portable Object Adapter)
□ ルート POA
□ サーバントマネージャ
□ サーバ
□ スケルトン
140418J
3-35
第 3 章 NonStop DOM アプリケーションの開発
アーキテクチャ
図 3-2 POA アーキテクチャ
例
仕様に準拠し、移植性のあるアプリケーションを作成することは、難しいことではありません。次の短
いプログラムは、基本要件の設定方法を示しています。
単純な、移植性のあるサーバ
// My header file contains a declaration of My_Servant_Impl
#include "my_imp.h"
int main(int argc, char *argv[])
{
// Initialize the ORB.
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
// Obtain an object reference for the Root POA.
CORBA::Object_var obj = orb ->
resolve_initial_references("RootPOA");
PortableServer::POA_var poa =
PortableServer::POA::_narrow(obj);
// Incarnate a servant.
My_Servant_Impl servant;
3-36
140418J
第 3 章 NonStop DOM アプリケーションの開発
// Implicitly register the servant with the RootPOA.
obj = servant._this();
// Start the POA listening for requests.
poa -> the_POAManager() ->activate();
// Run the ORB’s event loop.
orb -> run();
// Ready to work
}
3.4.1 POA の作成
このセクションには、次のサブトピックスが含まれています。
□ ルート POA
□ ルート POA 参照の取得
□ チャイルド POA
ルート POA
NonStop DOM ORB では、OMG の要件に従って、ルート POA という POA オブジェクトが提供されて
います。ルート POA の名前は RootPOA で、すべてのサーバおよびアプリケーションで使用可能であり、
ほかの POA が指定されていない場合はデフォルトで使用されます。ORB では、RootPOA のオブジェク
ト参照が提供されています。
RootPOA のデフォルトポリシーは次の表のとおりです。
表 3-2 RootPOA ポリシー
ポリシー
値
Thread( スレッド )
ORB_CTRL_MODEL
Lifespan( ライフスパン )
TRANSIENT
Object Id Uniqueness( オブジェクト ID の一意性 )
UNIQUE_ID
Id Assignment(ID 割り当て )
SYSTEM_ID
Servant Retention( サーバントの保持 )
RETAIN
Request Processing( リクエスト処理 )
USE_ACTIVE_OBJECT_MAP_ONL
Y
Implicit Activation( 黙示的有効化 )
IMPLICIT_ACTIVATION
ルート POA 参照の取得
次の例は、ルート POA 参照の取得方法を示しています。
ルート POA 参照の取得
140418J
3-37
第 3 章 NonStop DOM アプリケーションの開発
CORBA::ORB_ptr = CORBA::ORB_init(argc, argv);
CORBA::Object_ptr pfobj =
orb ->resolve_initial_references("RootPOA");
PortableServer::POA_ptr rootPOA;
rootPOA = PortableServer::POA::narrow(pfobj);
チャイルド POA
アプリケーションが、ルート POA とは別の POA 管理またはポリシーを必要とする場合は、開発者が
チャイルド POA を作成する必要があります。チャイルド POA は、ルート POA とは別のポリシーを使用
することができ、別の POA マネージャを持つことができます。また、チャイルド POA の実装は、アダプ
タアクティベータと、サーバントマネージャを提供します。各チャイルド POA は、アプリケーション実行
のためのネームスペースを作成します。
チャイルド POA を作成するには、ペアレント POA の create_POA( ) メソッドを呼び出します。チャイ
ルド POA の名前は、ペアレント POA の直下で使用されていない名前にしてください。
永続オブジェクトのチャイルド POA
アプリケーションの作成者は、Lifespan ポリシーとして PERSISTENT を持つチャイルド POA には特
別の注意をはらう必要があります。永続オブジェクトの作成に最初に使用された POA は、アプリケーショ
ンによって再作成される必要があります。結果として、このチャイルド POA に関係するすべての祖先 POA
も再作成される必要があります ( チャイルド POA を正しく再作成するには、ペアレントと、常に存在する
RootPOA へのアクセスが必要です。これは、create_POA( ) などを呼び出すのに必要です )。オリ
ジナルのサーバプロセスで使用された POA 名と、これら POA すべてのオリジナルのポリシーがすべて再
作成される必要があります。
これを実行しないと、古い永続参照がクライアントに使用された際に、CORBA::OBJECT_NOT_EXIST
システム例外が発生します。次の例を参照してください。
Root POA からのチャイルド POA の作成
CORBA::ORB_ptr = CORBA::ORB_init(argc, argv);
CORBA::Object_ptr pfobj =
orb ->resolve_initial_references("RootPOA");
PortableServer::POA_ptr rootPOA;
rootPOA = PortableServer::POA::narrow(pfobj);
CORBA::PolicyList my_policies(2);
my_policies[0] = rootPOA ->create_thread_policy(
PortableServer::ThreadPolicy::SINGLE_TH
READ_MODEL);
my_policies[1] = rootPOA ->create_lifespan_policy(
PortableServer::LifespanPolicy::PERSIST
ENT);
PortableServer::POA_ptr poa =
rootPOA ->create_POA("my_poa",
PortableServer::POAManager::nil(),
my_policies);
3-38
140418J
第 3 章 NonStop DOM アプリケーションの開発
3.4.2 POA ポリシーオブジェクト
このトピックでは、次のポリシーについて詳しく説明します。
□ Thread( スレッド ) ポリシー
□ Lifespan( ライフスパン ) ポリシー
□ Id Uniqueness(ID の一意性 ) ポリシー
□ Id Assignment(ID 割り当て ) ポリシー
□ Servant Retention( サーバントの保持 ) ポリシー
□ Request Processing( リクエスト処理 ) ポリシー
□ Implicit Activation( 黙示的有効化 ) ポリシー
□ State( ステート ) ポリシー
ルート POA 以外の POA の性質は、ポリシーを使って作成する際に決まります。一度ポリシーを設定す
ると、POA の存続期間中は変更できません。チャイルド POA は、ポリシーを継承しません。
POA ポリシーインタフェースは、CORBA::Policy から導出されます。これらのインタフェースは、
POA::create_POA( ) 操作とともに使われます。
次の例は、ポリシー作成パターンを示しています。
チャイルド POA ポリシー一覧の作成
CORBA::PolicyList my_policies(2);
my_policies.length(2);
my_policies[0] = rootPOA ->create_thread_policy(
PortableServer::ThreadPolicy::SINGLE_THREA
D_MODEL);
my_policies[1] = rootPOA ->create_lifespan_policy(
PortableServer::LifespanPolicy::PERSISTENT
);
PortableServer::POA_ptr poa =
rootPOA ->create_POA("my_poa",
PortableServer::POAManager::nil(),
my_policies);
Thread ポリシー
POA では、各サーバントを、NonStop DOM 制御下の複数のスレッド内で実行することもできますし、
複数のサーバントを単一のスレッド内で次々に実行することもできます。その場合は、一度に 1 つのリク
エストだけが実行されます。
ThreadPolicy インタフェースを使うオブジェクトを作成するには、POA::create_thread_policy()
操作を呼び出します。結果は POA::create_POA( ) 操作に渡されます。
ThreadPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合は、デフォルト値
である ORB_CTRL_MODEL が使用されます。
ORB_CTRL_MODEL 値によって、複数のスレッドが同時にクライアントリクエストを実行することが
140418J
3-39
第 3 章 NonStop DOM アプリケーションの開発
できます。SINGLE_THREAD 値を使用すると、新しいリクエストは順番に実行されます。POA を続行
させるには、スレッドが前のリクエストの完了を待機しなければならない場合があります。
Thread ポリシーインタフェース
Thread ポリシーインタフェース
enum ThreadPolicyValue
{
ORB_CTRL_MODEL,
SINGLE_THREAD_MODEL
};
interface ThreadPolicy : CORBA::Policy
{
readonly attribute ThreadPolicyValue value;
};
enum の値
ORB_CTRL_MODEL
これはデフォルトのスレッド値です。複数のリクエストが複数のスレッド内で同時に進行することがで
きます。
SINGLE_THREAD_MODEL
クライアントリクエストが、順番に進行します。複数のスレッドが使用される場合でも、POA 上では 1
つのスレッドだけが有効化されています。
Lifespan ポリシー
POA 内で作成される CORBA オブジェクトが永続的か非永続的かを指定するポリシーです。
LifespanPolicy インタフェースを使うオブジェクトを作成するには、
POA::create_lifespan_policy() 操作を呼び出します。結果は POA::create_POA()
操作に渡されます。
LifespanPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合は、デフォルト
値である TRANSIENT が使用されます。
Lifespan ポリシーインタフェース
Lifespan ポリシーインタフェース
enum LifespanPolicyValue
{
TRANSIENT,
PERSISTENT
};
interface LifespanPolicy : CORBA::Policy
{
3-40
140418J
第 3 章 NonStop DOM アプリケーションの開発
readonly attribute LifespanPolicyValue value;
};
enum の値
TRANSIENT
POA が無効化されると、POA によって使用されたオブジェクトが処分されます。このプロセスで生成
されたオブジェクト参照を、プロセスの再開後に再利用しようとすると、CORBA::OBJECT_NOT
_EXIST システム例外が生成されます。
PERSISTENT
このポリシーを使用する POA で作成されるオブジェクトは、TRANSIENT のように、ライフスパンが
サーバプロセスに限定されていません。これは、口座番号のようなデータベースエンティティに対応する
オブジェクトに使用すると便利です。
Id Uniqueness ポリシー
サーバントが、単一の CORBA オブジェクトに関連付けられるのか、または複数の CORBA オブジェク
トに対応するのかを指定するポリシーです。
IdUniquesnessPolicy イン タフ ェー スを 使う オブ ジェ クト を作 成す るに は、POA::
create_id_uniqueness_policy( ) 操作を呼び出します。結果は POA::create_POA()
操作に渡されます。
IdUniquenessPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合は、デ
フォルト値である UNIQUE_ID が使用されます。
Id Uniqueness ポリシーインタフェース
IdUniqueness ポリシーインタフェース
enum IdUniquenessPolicyValue
{
UNIQUE_ID,
MULTIPLE_ID
};
interface IdUniquenessPolicy : CORBA::Policy
{
readonly attribute IdUniquesnessPolicyValue value;
};
enum の値
UNIQUE_ID
POA で使用されるサーバントは、単一の Object Id をサポートします。
MULTIPLE_ID
POA で使用されるサーバントは、単一または複数の Object Id をサポートします。
140418J
3-41
第 3 章 NonStop DOM アプリケーションの開発
Id Assignment ポリシー
POA が Object Id を割り当てるのか、またはアプリケーションが Object Id を提供するのかを指定するポ
リシーです。
Id A s s i g n m e n t P o l i c y イ ンタ フェ ース を使 うオ ブジ ェク ト を作 成す るに は、POA: :
create_id_assignment_policy( ) 操作を呼び出します。結果は POA::create_POA()
操作に渡されます。
IdAssignmentPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合は、デ
フォルト値である SYSTEM_ID が使用されます。
Id Assignment ポリシーインタフェース
Id Assignment ポリシーインタフェース
enum IdAssignmentPolicyValue
{
USER_ID,
SYSTEM_ID
};
interface IdAssignmentPolicy : CORBA::Policy
{
readonly attribute IdAssignmentPolicyValue value;
};
enum の値
USER_ID
POA が作成するオブジェクトには、アプリケーションによって Object Id が割り当てられます。
SYSTEM_ID
POA が作成するオブジェクトには、POA によって Object Id が割り当てられます。このポリシーが使わ
れていて、PERSISTENT ポリシーも有効になっている場合は、割り当てられた Object Id は、この POA
のすべてのインスタンスで一意である必要があります。
Servant Retention ポリシー
POA が、サーバントと CORBA オブジェクト間の関係を保持する必要があるのか、または新しいリクエ
ストごとに新しい関係を確立すべきかを指定するポリシーです。
ServantRetentionPolicy イン タフ ェー スを 使う オブ ジェ クト を作 成す るに は、POA::
create_servant_retention_policy( ) 操 作を 呼び 出し ます。結 果は POA::
create_POA( ) 操作に渡されます。
ServantRetentionPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合は、
デフォルト値である RETAIN が使用されます。
3-42
140418J
第 3 章 NonStop DOM アプリケーションの開発
Servant Retention ポリシーインタフェース
Servant Retention ポリシーインタフェース
enum ServantRetentionPolicyValue
{
RETAIN,
NON_RETAIN
};
interface ServantRetentionPolicy : CORBA::Policy
{
readonly attribute ServantRetentionPolicyValue value;
};
enum の値
RETAIN
有効なサーバントは、Active Object Map 内に保持されます。
NON_RETAIN
サーバントは保持されません。このポリシーを使用する場合は、USE_DEFAULT_SERVANT または
USE_ SE RV AN T_M AN AG ER ポ リシ ーも 使用 する 必要 があ りま す。これ らが 使用 され ない と、
InvalidPolicy 例外が上げられます。
Request Processing ポリシー
POA のリクエスト処理方法を指定するポリシーです。
RequestProcessingPolicy インタフェースを使うオブジェクトを作成するには、POA::
create_request_processing_policy( ) 操作 を呼 び出 しま す。結果 は POA::
create_POA( ) 操作に渡されます。
RequestProcessingPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合
は、デフォルト値である USE_ACTIVE_OBJECT_MAP_ONLY が使用されます。
Request Processing ポリシーインタフェース
Request Processing ポリシーインタフェース
enum RequestProcessingPolicyValue
{
USE_ACTIVE_OBJECT_MAP_ONLY,
USE_DEFAULT_SERVANT,
USE_SERVANT_MANAGER
};
interface RequestProcessingPolicy : CORBA::Policy
{
readonly attribute RequestProcessingPolicyValue value;
};
140418J
3-43
第 3 章 NonStop DOM アプリケーションの開発
enum の値
USE_ACTIVE_OBJECT_MAP_ONLY
Active Object Map 内で、ターゲットオブジェクトの ObjectId に対応するサーバントを探します。対応す
るサーバントが見つからない場合は、POA が CORBA::OBJECT_NOT_EXIST システム例外を上げま
す。
USE_DEFAULT_SERVANT
このポリシーを使用する場合は、MULTIPLE_ID ポリシー値も必要です。必要なポリシーが使用され
ないと、InvalidPolicy 例外が上げられます。
POA が、ターゲットオブジェクトの ObjectId に関連付けられたサーバントを Active Object Map 内に持
たない場合、または NON_RETAIN ポリシー値がこの POA に使用されている場合で、アプリケーション
によってデフォルトサーバントが POA に登録されている場合は、リクエストはデフォルトサーバントに
よって処理されます。デフォルトサーバントが登録されていない場合は、OBJ_ADAPTER 例外が上げら
れます。
USE_SERVANT_MANAGER
ターゲットオブジェクトの ObjectId にサーバントが関連付けられていない場合、または NON_RETAIN
ポリシー値がこの POA に使用されている場合、適切なサーバントの検索にサーバントマネージャが使用さ
れます。サーバントマネージャが登録されていない場合は、OBJECT_ADAPTER 例外が上げられます。
Implicit Activation ポリシー
サーバントの黙示的有効化をリクエストするためのポリシーです。
ImplicitActivationPolicy インタフェースを使うオブジェクトを作成するには、POA::
create_implicit_activation_policy( ) 操作を呼び出します。結果は POA::create
_POA( ) 操作に渡されます。
ImplicitActivationPolicy オブジェクトが create_POA( ) 操作に渡されなかった場合
は、デフォルト値である NO_IMPLICIT_ACTIVATION が使用されます。
Implicit Activation ポリシーインタフェース
Implicit Activation ポリシーインタフェース
enum ImplicitActivationPolicyValue
{
IMPLICIT_ACTIVATION,
NO_IMPLICIT_ACTIVATION
};
interface ImplicitActivationPolicy : CORBA::Policy
{
readonly attribute ImplicitActivationPolicyValue value;
};
3-44
140418J
第 3 章 NonStop DOM アプリケーションの開発
enum の値
IMPLICIT_ACTIVATION
このポリシーを使用する場合は、SYSTEM_ID および RETAIN ポリシーも使用する必要があります。
これらが使用されないと、InvalidPolicy 例外が上げられます。
黙示的有効化は、POA によってサポートされます。
黙示的有効化によって、次の状況下で、POA が自動的にサーバントを有効化することができます。サー
バントを有効化するとは、Active Object Map 内のそのサーバントのエントリを作成することです。
□
□
_this( ) が呼び出されたが、サーバントがまだ有効化されていない。
_this( ) の場合は、サーバントの default_POA( ) 呼出しで返された POA が使用されます。
servant_to_reference( ) が呼び出され、サーバントが有効化されている。
呼出し元が指定した POA が使用されます。
NO_IMPLICIT_ACTIVATION
黙示的有効化はサポートされません。
State Policy
PortableServer::StatePolicy を使って、サーバプールプロセス内で、ステートレスオブ
ジェクトと、永続的なステートフルオブジェクトを共存させることができます。( このポリシーができる前
は、サーバプールプロセス内の永続オブジェクトはステートレスと見なされていました。IOR 内で TS/MP
プロファイルを読み込み、パブリッシュする必要がありました。)
ステートフルオブジェクトは、メソッド呼出し後もステートを保持することができます。たとえば、メ
ソッド呼出しに関連付けられたメモリ内にデータを保管するなどです。ステートフルオブジェクトでは、
クライアントのオブジェクト参照が、そのオブジェクトの特定のインスタンスを指している必要がありま
す。
ステートレスオブジェクトは、メソッド呼出し間でステートを保持しません。クライアントの参照は、
一連のインスタンスのどれを指していてもかまいません。
State ポリシーの値は、STATEFUL と STATELESS の 2 つです。デフォルト値は、LifeSpan
ポリシーの値によって異なります。LifeSpanPolicy が TRANSIENT の場合は、StatePolicy
のデフォルトは STATEFUL です。LifeSpanPolicy が PERSISTENT の場合は StatePolicy
のデフォルトは STATELESS です。
3.4.3 参照の作成
このセクションでは、次のサブトピックについても解説します。
□ クライアントへの参照の引渡し
クライアントが、リクエストに関してサーバと通信するためには、クライアントとサーバが、使用され
ているオブジェクトの ID を認識している必要があります。これを確実にするために、サーバによって作成
されクライアントに伝達されるオブジェクト参照を使用します。
140418J
3-45
第 3 章 NonStop DOM アプリケーションの開発
ORB が、クライアントリクエスト内で使用されるオブジェクト、POA、およびサーバを一意に識別する
ために必要な情報はすべて、オブジェクト参照によって提供されます。
サーバが参照を作成する方法は次のとおりです。
□ サーバアプリケーションが直接、参照を作成する。サーバは、create_reference(
) または
create_reference_with_id( ) 操作を使用することができます。参照は、POA によって提
供された情報を元に生成されるか、またはこれらの操作に渡されたパラメータから導出されます。
これらの操作はオブジェクト参照を作成し、それによってオブジェクトを存在する状態にするだけで
す。オブジェクトと、有効なサーバントを関連付けることはしません。
□ サーバアプリケーションが明示的にサーバントを有効化し、オブジェクト ID と関連付ける。アプリケー
ションは、activate_object(
) または activate_object_with_id( ) 操作を使用
することができます。
サーバントを、対応する参照にマップするために、アプリケーションは servant_to_reference() ま
たは id_to_reference(
) 操作を使用することができます。
□ サーバアプリケーションが、黙示的なサーバント有効化を引き起こす。POA が IMPLICIT_ACTIVATION ポ
リシーで作成されている必要があります。オブジェクト参照が、有効化されていないオブジェクトに対
応している場合は、POA はサーバントに対して一意のオブジェクト ID を生成して割り当てます。その
後 POA は参照されたオブジェクトを有効化します。
このオブジェクトの参照は、有効化されていないサーバントを使った POA::servant_to_ reference( ) 操作から取得することができます。また、_this() 操作を使って参照を取得す
ることもできます。
クライアントへの参照の引渡し
サーバがオブジェクト参照を作成した後、クライアントから利用できるようにするには、次の方法があ
ります。
□ Naming Service
□
ORB::string_to_object( ) 操作を使った文字列への変換。この場合、クライアントが
ORB::string_to_object( ) 操作を使用する必要があります。「オブジェクト参照」を参照
してください。
□ メソッドの、return、out、または inout パラメータを利用。クライアントがオブジェクト上で
メソッドを実行することで、必要なオブジェクト参照がクライアントに返されます。
代表的な例は、factory メソッドです。factory オブジェクトの IOR は Naming Service 内に保管されてお
り、クライアントが factory 上で create(
) メソッドを呼び出すことで新しいオブジェクト参照が返さ
れます。
3.4.4 Servant Managers
このセクションには、次のサブトピックスが含まれています。
□ デフォルトサーバント
□ Servant Locator
3-46
140418J
第 3 章 NonStop DOM アプリケーションの開発
□ Servant Activator
「サーバントマネージャ」は、ServantManager インタフェースから導出されるオブジェクトです。
このオブジェクトは、コールバックオブジェクトとして POA に登録されます。コールバックオブジェクト
は、オンデマンドでサーバントを有効化するのに使用されます。ServantManager からは、Servant
Locator と Servant Activator の 2 つのサブクラスが導出されます。
サーバントマネージャは、次の動作を実行します。
□ 必要なオブジェクトが存在しているかどうか調べる。
□ 適切なオブジェクトをサーバントと関連付ける。
POA が、有効化されていないオブジェクトへのリクエストを受け取ると ( たとえば、RETAIN ポリシー
が使用されていて、AOM 内にオブジェクトの ObjectId エントリがない場合 )、オブジェクトに関連付
けられたサーバントを有効化するために、サーバントマネージャが呼び出されます。オブジェクトが見つ
か らな い場 合は、POA か らク ライ アン トに
OBJECT_NOT_EXIST シ ステ ム例 外が 返さ れま す。
OBJECT_NOT_EXIST はクライアント側で処理する必要があります。リクエストしたオブジェクトが
存在するかどうか確認するのはサーバ側の責任です。
備考 : サーバントマネージャを必要としないアプリケーションもあります。
次のタイプのアプリケーションは、サーバントマネージャを必要としません。
□ 起動時に必要なオブジェクトをすべて有効化するアプリケーション
□ 不明なオブジェクトにかかわるすべてのリクエストにデフォルトサーバントが使用されるよう、明示的
にリクエストするアプリケーション。「デフォルトサーバント」を参照してください。
Request Processing ポリシーの値が USE_SERVANT_MANAGER に設定されている場合は、POA が
サーバントマネージャを起動することができます。使用されるサーバントマネージャは、次の条件によっ
て異なります。
□
NON_RETAIN ポリシー値が設定されている場合は直接 ServantLocator を使用します。
□
RETAIN ポリシー値が設定されている場合は、AOM (Active Object Map) 内でオブジェクトを探しま
す。
□ オブジェクトが AOM 内にリストされていない場合は、ServantActivator を使用します。
ユーザ定義サーバントマネージャを起動してオブジェクトを有効化する際に POA を必要とするよう、
サーバアプリケーションを設計することができます。ユーザ定義サーバントマネージャは POA に登録され
て い る 必 要 が あ り ま す。ア プ リ ケ ー シ ョ ン は、サ ー バ ン ト マ ネ ー ジ ャ の 登 録 時 に
set_servant_manager( ) メソッドを呼び出す必要があります。
サーバントマネージャは、永続オブジェクトまたは非永続オブジェクトを有効化することができるコー
ルバックインタフェースを実装しています。コールバックインタフェースには、必要なサーバントを検索
し、返し、無効化するための操作が含まれています。どのサーバントマネージャが適切かは、アプリケー
ションが使用する POA ポリシーによって異なります。
サーバントマネージャは、登録先の POA オブジェクトを含むプロセスに局所的である必要があります。
140418J
3-47
第 3 章 NonStop DOM アプリケーションの開発
実装について詳しくは、「サーバントマネージャの実装」を参照してください。
Default Servant
アプリケーションは、1 つのサーバントを使ってすべてのオブジェクトを実装することができます。
Request Processing ポリシーの値を USE_DEFAULT_SERVANT に設定することによって、サーバアプリ
ケーションが、ユーザ定義サーバントを起動するよう POA にリクエストします。アプリケーションは、
ユーザ定義サーバントの登録のため、POA の set_servant(
) 操作を呼び出す必要があります。
POA が、ターゲットオブジェクトの ObjectId に関連付けられたサーバントを Active Object Map 内
NON_RETAIN ポリシー値がこの POA に使用されている場合で、アプリケー
に持たない場合、または
ションによってデフォルトサーバントが POA に登録されている場合は、リクエストはデフォルトサーバン
トによって処理されます。デフォルトサーバントが登録されていない場合は、OBJ_ADAPTER 例外が上
げられます。詳しくは、「Request Processing ポリシー」を参照してください。
DSI (Dynamic Skeleton Interface) を提供するアプリケーションや、リクエストの正しい型を持つアプリ
ケーションの場合は、デフォルトサーバントを使用するのが最適です。DSI サーバアプリケーションは、各
オブジェクトに静的スケルトンを必要としません。
サーバアプリケーションが DSI 型ではない場合、デフォルトサーバントは、単一の IDL インタフェース
だけ使用することができます。
Servant Locator
サーバントマネージャオブジェクトは、ServantLocator インタフェース (Locator とも呼ばれます )
から導出されます。あるオブジェクト上のすべてのメソッド呼出しをアプリケーションが制御する必要があ
る場合に、Locator が使用されます。
ServantLocator インタフェースから導出されるコールバックオブジェクトは、preinvoke( )
) 操作を使ってサーバントを無効化します。詳し
操作を使ってサーバントを有効化し、postinvoke(
くは、
「ServantLocator 宣言」を参照してください。
preinvoke( ) 操作は、次のどの方法によっても実装されます。
□ サーバント作成に new 演算子を使用する。
□ 利用可能なサーバントのプールから、空いているサーバントを返す。
□ 操作の ObjectId を使って、作業に固有のサーバントを作成する。
□ メソッド名を使って、メソッドに固有のサーバントを作成する。
サーバントがリクエストを完了すると、postinvoke(
れないと、preinvoke(
) 操作が呼び出されます。この操作が完了さ
) によって割り当てられたリソースが解放されません。
このサーバントマネージャは、次のポリシーで使用してください。
3-48
140418J
第 3 章 NonStop DOM アプリケーションの開発
表 3-3 ServantLocator オブジェクトで使用するポリシー
ポリシー型
ポリシー値
説明
Servant Retention
NON_RETAIN
サーバントは使用後に解放されます。サーバ
ントマネージャを使用する必要があります。
Request Processing
USE_SERVANT_MANAGER
サーバントマネージャを使用するよう POA に
指示します。サーバントマネージャは
set_servant_manager( ) を使って
登録される必要があります。
Servant Activator
サーバントマネージャオブジェクトは、ServantActivator インタフェース (Activator とも呼ばれ
ます ) から導出されます。オブジェクト参照が特定のサーバントに一意に関連付けられる場合に、Activator
が使用されます。
ServantActivator インタフェースから導出されるコールバックオブジェクトは、incarnate( )
) 操作を使ってサーバントを無効化します。こ
操作を使ってサーバントを有効化し、etherealize(
のため、POA は、Activator を呼び出すことによってサーバントをインカネート ( 有効化 ) または エーテル
「ServantActivator 宣言」を参照してください。
化 ( 無効化 ) するように指示されます。詳しくは、
incarnate( ) 操作には、次の機能が実装されます。
□ POA での使用のために新しいサーバントを作成する。
□ 入力として ObjectId パラメータを使うなどして、factory を使って新しいサーバントを返す。
□
UNIQUE_ID が使用されていない場合は、操作が既存のサーバントを返すことができる。
POA が Activator の incarnate( ) 操作を呼び出したあと、Activator によって返されたサーバント
は、POA の AOM 内に保持されます。
備考 : POA の Id Uniqueness ポリシーの値が UNIQUE_ID に設定されている場合は、
サーバントは、その Object
Id に対して一意である必要があります。
サーバントが無効化されるときは常に、etherealize(
) 操作が呼び出されます。POA に認識さ
れていないサーバントをエーテル化しようとすると、予測できない動作が発生する可能性があります。
このサーバントマネージャは、次のポリシーで使用してください。
140418J
3-49
第 3 章 NonStop DOM アプリケーションの開発
表 3-4 ServantActivator オブジェクトで使用するポリシー
ポリシー型
ポリシー値
説明
Servant Retention
RETAIN
サーバントは、使用後に AOM (Active Object
Map) に保持されます。
Request Processing
USE_SERVANT_MANAGER
RETAIN ポリシーが使用されている場合は、
POA は AOM 内でサーバントの Object Id を探
します。AOM 内でオブジェクトが識別できな
いと、POA によってサーバントマネージャが
起動されます。
ServantLocator 宣言
NON_RETAIN ポリシーおよび USE_SERVANT_MANAGER ポリシー
このサーバントマネージャは、
とともに使用します。
これらの宣言は、servantmanager.h ヘッダファイルに含まれます。
Locator 宣言
#include "nsdorb/poa.h"
class My_Locator : public virtual PortableServer::ServantLocator
{
public:
My_Locator() {}
~My_Locator() {}
PortableServer::Servant preinvoke(
const PortableServer::ObjectId&
PortableServer::POA_ptr
const char *
void *&
CORBA::Environment &
oid,
adapter,
operation,
the_cookie,
_env);
void postinvoke(
const PortableServer::ObjectId&
PortableServer::POA_ptr
const char *
void *
PortableServer::Servant
CORBA::Environment &
oid,
adapter,
operation,
the_cookie,
the_servant,
_env);
};
ServantActivator 宣言
このサーバントマネージャは、RETAIN ポリシーおよび
USE_SERVANT_MANAGER ポリシーとと
もに使用します。
これらの宣言は、servantmanager.h ヘッダファイルに含まれます。
3-50
140418J
第 3 章 NonStop DOM アプリケーションの開発
Activator 宣言
class My_Activator : public virtual PortableServer::ServantActivator
{
public:
My_Activator() {}
~My_Activator() {}
PortableServer::Servant incarnate(
const PortableServer::ObjectId& oid,
PortableServer::POA_ptr adapter,
CORBA::Environment &_env);
void etherealize(
const PortableServer::ObjectId& oid,
PortableServer::POA_ptr adapter,
PortableServer::Servant serv,
CORBA::Boolean cleanup_in_progress,
CORBA::Boolean remaining_activations,
CORBA::Environment &_env);
};
サーバントマネージャの実装
これらの宣言は、servantmanager.cpp ソースファイルに含まれます。
サーバントマネージャの実装
#include "servantmanager.h"
#include "myservant.h"
// class definition for My_Servant,
not supplied
#include "myfactory.h"
// class definition for My_Factory,
not supplied
My_Factory gv_my_factory;
// used by My_Activator::incarnate
CORBA::Object_ptr My_Locator::init(PortableServer::POA_ptr
pp_POA)
{
// Application dependent initialization can be implemented
here.
}
PortableServer::Servant My_Locator::preinvoke(
const PortableServer::ObjectId& pr_oid,
PortableServer::POA_ptr
,
const char *
,
void *&
,
CORBA::Environment &
)
{
return new My_Servant;
}
void My_Locator::postinvoke(
const PortableServer::ObjectId&
PortableServer::POA_ptr
const char *
void *
140418J
,
,
,
,
3-51
第 3 章 NonStop DOM アプリケーションの開発
PortableServer::Servant
CORBA::Environment &
pp_servant,
)
{
delete pp_servant;
}
// Create a new servant for use by the POA, to be stored in the
// POA’s active object map (AOM).
// This example assumes a factory that returns a new servant
// given the Object Id as an input.
PortableServer::Servant My_Activator::incarnate(
const PortableServer::ObjectId& oid,
PortableServer::POA_ptr adapter,
CORBA::Environment &_env)
{
return gv_my_factory->make_servant( oid );
}
// Delete the servant from the POA’s active object map.
// If the servant is not being shared by other POAs and
// the fifth parameter of the call is false
// (remaining_activations) then the servant can be deleted.
void My_Activator::etherealize(
const PortableServer::ObjectId &pr_oid,
PortableServer::POA_ptr
pp_adapter,
PortableServer::Servant
pp_servant,
CORBA::Boolean ,
CORBA::Boolean
pv_remaining_activations,
CORBA::Environment &)
{
if ( ! pv_remaining_activations )
delete pp_servant;
}
3.4.5 永続オブジェクトと非永続オブジェクト
このセクションには、次のサブトピックスが含まれています。
□ 非永続オブジェクト
□ 永続オブジェクト
□ 永続オブジェクトアプリケーションの要件
□ システム ID を持つ永続オブジェクト
□ 永続オブジェクトの POA サーバ実装例
非永続オブジェクト
デフォルトでは、オブジェクトのライフスパンは、起動元のサーバプロセスによって決定されます。こ
のようなオブジェクトは、
「非永続的な」ライフスパンを持っているといいます。NonStop DOM のような、
CORBA 準拠の ORB は、デフォルトで、非永続オブジェクトのオブジェクト参照をサーバメモリから削除
します。クライアントが、プロセス終了後に、古いオブジェクト参照を使ってオブジェクトを呼び出そう
とすると、NonStop DOM によって CORBA::OBJECT_NOT_EXIST 例外が上げられます。
3-52
140418J
第 3 章 NonStop DOM アプリケーションの開発
デフォルトの動作では、ORB は、永続ステートを保持する義務から解放されます。POA に対して、永
続オブジェクトを作成し、オブジェクトがサーバプロセスから解放されるべきであるとアプリケーション
が指定した時点までそのオブジェクトを追跡するように、要求するのはアプリケーションの責任です。
POA は、非永続オブジェクトに関して次のサポートを提供しています。
□ 非永続オブジェクトが作成されるたびに、以前のサーバで作成された参照からは区別される。同じ名前
が使用されていても同様です。
□ 非永続オブジェクトは、専用の POA を必要としない。デフォルトで、RootPOA にサポートされます。
ただし、必要に応じて別の POA を使用することも可能です。
永続オブジェクト
「永続的な」オブジェクトとは、サーバプロセス終了後もそのオブジェクト参照が有効であり続けるよう
なオブジェクトのことです。永続的でステートレスなオブジェクトは、同じオブジェクトに複数のメソッ
ド呼出しが向けられた場合に、サーバプール内の別々のプロセスに存在する別々のサーバントへリクエス
トが送られるような、アプリケーションロジックパラダイムを実装します。
永続オブジェクトは、NonStop DOM スケーラビリティのキーとなる機能です。このようなオブジェク
トは「ステートレス」と呼ばれます。これは、このようなオブジェクトのステートは通常、サーバントや
プロセスメモリでなく、ディスク上に永続的に保持されるため、サーバントがステートレスになるからで
す。
アプリケーションが永続オブジェクトをリクエストするには、オブジェクト参照を作成する POA の
Lifespan ポリシー値を PERSISTENT に設定し、サーバ内で NonStop TS/MP プロトコルを有効にします。
NonStop DOM POA は、永続オブジェクトに関して次のサポートを提供しています。
□ サーバプロセスに依存しないライフタイム。
□ サーバプールのどのサーバによってもリクエストを完了することが可能。永続オブジェクトはすべてス
ケーラブルです。
TS/MP プロトコルの有効化
スケーラブルな永続オブジェクトを必要とするアプリケーションでは、NonStop TS/MP プロトコルを有
効にする必要があります。次のコードは、NonStop DOM 製品に含まれる銀行のサンプル内で TS/MP プロ
トコルを有効にする構成エントリ例です。サーバはこの構成エントリを使用します。
構成データベースエントリ例
entity bank_server_pool@ORB {
tcp_server
true
use_comm_server true
tsmp_server
true
pathmon
$smon
server_class
bank-server
tsmp_client
true
fs_client
true
tcp_client
true
}
キーとなる項目は次の 3 つです。
140418J
3-53
第 3 章 NonStop DOM アプリケーションの開発
□
tsmp_server が true に設定されていること。
□ サーバプールの pathmon 名が指定されていること。
□ サーバクラス名も指定されていること。
永続オブジェクトアプリケーションの要件
このサブトピックでは、永続オブジェクトの作成のためにストック例を修正する手順を示しています。
あらかじめ次のトピックをごらんください。
□ アプリケーション開発に必要な通常の手順を解説している「ストック例」
□ チャイルド POA の作成について解説している「永続オブジェクトのチャイルド POA」
永続オブジェクトを使用するアプリケーションの実装には、次の手順がすべて必要です。完全な実装に
ついては、「永続オブジェクトの POA サーバ実装例」サブトピックを参照してください。
1. 永続ポリシーオブジェクト作成のため、次の要領で POA ポリシーの factory 操作を呼び出します。
create_lifespan_policy(
PortableServer::LifespanPolicy::PERSISTENT);
create_id_assignment_policy(
PortableServer::IdAssignmentPolicy::USER_ID);
ポリシーはすべて Policy List に保管されています。
「システム ID を持つ永続オブジェクト」サブトピッ
クも参照してください。
2. 永続オブジェクトの Lifespan ポリシーを使用するチャイルド POA を作成します。ルート POA は非永
続オブジェクトしかサポートしないため、使用できません。アプリケーションは、ペアレント POA 上
で create_POA( ) を呼び出します。
create_POA("my_persistent_POA", my_poa_mgr, my_policies);
create_POA( ) 操作に渡された引数は、次の項目を順に指定します。
1. 作成する POA の名前
2. この POA のマネージャ名 ( ルート POA からデフォルトマネージャを使用することができます )
3. この POA のポリシーすべてを含むポリシーリストの名前
3. 永続オブジェクトの一意の識別子を作成します。次の要領で、文字列とともに
ObjectId( ) メソッドを呼び出します。
string_to_
PortableServer::ObjectId_var oid =
string_to_ObjectId( "myObjId");
3-54
140418J
第 3 章 NonStop DOM アプリケーションの開発
4. オブジェクトを明示的に有効化し、サーバントを登録します。activate_object_with_id()
を呼び出すことにより、POA がオブジェクトとサーバントを Active Object Map に登録します。呼出し
は次のとおりです。
myPOA -> activate_object_with_id( oid, &lp_servant);
システム ID を持つ永続オブジェクト
アプ リケ ーシ ョン が永 続オ ブジ ェク トの POA を 使用 する が Object Id を 供給 しな い場 合は、Id
Assignment ポリシーのデフォルト値である SYSTEM_ID が使用されます。POA が作成するオブジェクト
には、POA によって Object Id が割り当てられます。このポリシーが使われていて、PERSISTENT ポリ
シーも有効になっている場合は、割り当てられた Object Id は、この POA のすべてのインスタンスで一意
である必要があります。
アプリケーションが
create_reference( ) メソッドを呼び出す際に、POA は一意の Object Id
を選びます。この ID は、構成データベース内で特別な POA エントリを探すことによって選ばれる、64
ビットの数字です。POA は未使用の番号を選び、構成データベース内の値を更新します。番号は再利用さ
れません。
備考 : 構成データベースが破棄され再初期化された場合は、番号は 0 から再開され再利用されるかもしれません。
これは、プロパティ要件の侵害です。
永続 Object Id に関連付けられた永続データは、ユーザの責任で保管される必要があります。
永続オブジェクトの POA サーバ実装例
次の例は、ストック例を修正して永続オブジェクトを使うようにする方法を示しています。
例 1. 永続オブジェクトの POA サーバ
#include "stock.h"
#include "nsdorb/poa.h"
int main(int argc, char *argv[])
{
// Initialize the ORB
CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
// Get object reference for root POA in the process
CORBA::Object_var pfobj =
orb -> resolve_initial_references("RootPOA");
PortableServer::POA_var myPOA;
myPOA = PortableServer::POA::_narrow(pfobj);
// Create the POA policies
CORBA::PolicyList my_policies(2);
my_policies.length(2);
my_policies[0] =
myPOA -> create_lifespan_policy(
PortableServer::LifespanPolicy::PERSISTENT);
140418J
3-55
第 3 章 NonStop DOM アプリケーションの開発
my_policies[1] =
myPOA -> create_id_assignment_policy(
PortableServer::IdAssignmentPolicy::USER_ID);
// Create a POA for persistent objects
PortableServer::POAManager_var my_poa_mgr = my_POA;
myPOA -> POAManager();
//
//
//
//
Since we won’t need the POA object that we used to
store the root POA defaults, it can be overwritten now.
myPOA will be a different object now, initialized
with our specifications
myPOA = myPOA -> create_POA(
"my_persistent_POA",
my_poa_mgr,
my_policies);
// Create servant
Stock_impl *lp_servant = new Stock_impl;
// Convert a string to an Object Id
PortableServer::ObjectId_var oid =
string_to_ObjectId( "myObjId");
// Explicitly register the servant with the POA
myPOA -> activate_object_with_id( oid, &lp_servant);
myPOA -> obj = create_reference_with_id( oid,
"IDL::Stock:1.0");
delete oid;
// Activate the POA
myPOA -> the_POAManager() -> activate();
// Service requests
orb -> run();
return 0;
} // main
3.4.6 Adapter Activator
このセクションには、次のサブトピックスが含まれています。
□ unknown_adapter 操作
□ Adapter Activator の関連付け
Adapter Activator を使用して、アプリケーションで必要となるチャイルド POA を作成することができま
す。Adapter Activator は、PortableServer::AdapterActivator インタフェースから導出さ
れるオブジェクトです。
Adapter Activator は既存の POA を有効化し、次の動作のいずれかの結果としてチャイルド POA を作成
します。
□ 明示的にチャイルド POA を指定するリクエストを POA が受け取る。
3-56
140418J
第 3 章 NonStop DOM アプリケーションの開発
□
find_POA( ) 操作が呼び出され、その activate_it パラメータ値が TRUE になっている。
find_POA( ) 操作が正しく呼び出されると、POA が返される。
呼出しに失敗すると、AdapterNonExistent 例外が上げられる。
備考 : Adapter Activator を必要としないアプリケーションもあります。
次のタイプのアプリケーションは、Adapter Activator の実装を必要としません。
□
create_POA( ) 操作を使用して必要な POA を明示的に作成するアプリケーション
□ 起動時に POA をすべて作成するアプリケーション
Adapter Activator を呼び出すには、POA が有効にされている必要があります。
POA が Adapter Activator を呼び出すと、作成される POA およびその下位の POA に対してすべてのリ
クエストがキューに並べられます。並べられたリクエストは、Adapter Activator がチャイルド POA を作成
した後で処理されます。Adapter Activator が POA の作成に失敗すると、最初のリクエストに対して
OBJECT_NOT_EXIST 例外が上げられます。並べられたリクエストは再試行されます。
Adapter Activator は、登録先の POA オブジェクトを含むプロセスに局所的である必要があります。
Adapter Activator は、その POA に関連付けられている必要があります。詳しくは、「Adapter Activator
の関連付け」を参照してください。
The unknown_adapter 操作
このセクションには、次のサブトピックスが含まれています。
□ Adapter Activator の宣言
□ unknown_adapter の実装例
NonStop DOM ORB は、存在しないターゲット POA へのリクエストを受け取ると、登録された Adapter
Activator 上で unknown_adapter( ) を呼び出します。多数の存在しない POA へのリクエストを
ORB が受け取ると、要求された POA ごとに操作が呼び出されます。unknown_adapter( ) 操作は、
チャイルド POA をリクエストするペアレント POA に関連付けられます。unknown_adapter( ) の
実装を調整して、そのポリシーで指定された性質を持つチャイルド POA を作成することができます。
Adapter Activator の宣言
Adapter Activator ヘッダファイルの内容
#ifndef _ADAPTER_H_
#define _ADAPTER_H_
#include "nsdorb/poaclass.h"
// Well-known name of the POA that this adapter will ’activate’
#define GrandChildPOA "RetainBat"
// Example class for an application’s Adapter Activator.
class My_Adapter : public virtual PortableServer:: Adapter Activator
{
140418J
3-57
第 3 章 NonStop DOM アプリケーションの開発
public:
My_Adapter() { }
~My_Adapter() { }
CORBA::Boolean unknown_adapter( PortableServer::POA_ptr
parent,
const char* name,
CORBA::Environment &_env);
};
#endif
unknown_adapter の実装例
この unknown_adapter(
) の実装により、POA を呼び出して別の POA を作成することができま
す。作成される POA の名前は、< pp_name > 引数で指定されます。
「Adapter Activator の宣言」も参照し
てください。
この実装では、次の性質を持つチャイルド POA が作成されます。
□ Request Processing ポリシーの値は
USE_SERVANT_MANAGER。このアプリケーションに指定され
たマネージャを使用します。
□ Id Assignment ポリシーの値は USER_ID。クライアントが Object Id を供給します。
□ Lifespan ポリシーの値は
PERSISTENT。オブジェクト参照の有効性は、プロセスのライフタイムに
依存しません。
これらの性質に加えて、この操作は次のデフォルトポリシー値を持ち、これらはチャイルド POA に適用
されます。
□ Thread ポリシーのデフォルト値は ORB_CTRL_MODEL で、複数のスレッドを使用可能。
□ Servant Retention ポリシーのデフォルト値は RETAIN。
My_Activator について詳しくは、「ServantActivator 宣言」を参照してください。
unknown_adapter( ) の実装
#include "adapter.h"
#include "servantmanager.h"
My_Activator gv_activator;
// Servant Activator
CORBA::Boolean
My_Adapter::unknown_adapter( PortableServer::POA_ptr pp_parent,
const char
*pp_name,
CORBA::Environment
&pr_env)
{
NSDOMAssert( pr_env.ok() );
if (strcmp(pp_name, GrandChildPOA) != 0)
return false; // don’t create if incorrect name
// Set the Request Processing Policy for servant manager
PortableServer::RequestProcessingPolicy_ptr
lp_request_po =
pp_parent->create_request_processing_policy(
3-58
140418J
第 3 章 NonStop DOM アプリケーションの開発
PortableServer::USE_SERVANT_MANAGER, pr_env);
// Set the Id Assignment Policy value for user id
PortableServer::IdAssignmentPolicy_ptr lp_assignment_po =
pp_parent->create_id_assignment_policy(
PortableServer::USER_ID, pr_env);
// Set the Lifespan Policy for persistent objects
PortableServer::LifespanPolicy_ptr lp_lifespan_po =
pp_parent->create_lifespan_policy(
PortableServer::PERSISTENT, pr_env);
// Create policy list
// Note: List ’owns’ policy objects and will release them
CORBA::PolicyList lv_policies(3);
lv_policies.length(3); // must set length before any
access is allowed.
lv_policies[0] = lp_request_po;
lv_policies[1] = lp_assignment_po;
lv_policies[2] = lp_lifespan_po;
PortableServer::POA_ptr lp_child_POA =
pp_parent->create_POA(pp_name,
pp_parent->the_POAManager(),
&lv_policies,
pr_env);
NSDOMAssert( pr_env.ok() );
NSDOMAssert( lp_child_POA );
// Register the servant manager for use with the child POA
lp_child_POA->set_servant_manager( &gv_activator, pr_env
);
return true;
}
Adapter Activator Association
Adapter Activator は、その POA に関連付けられている必要があります。この例では、チャイルド POA
the_activator が使われています。
作成時に my_poa が使用する Adapter Activator の識別のために、
Adapter Activator 関連付けの例
// A POA my_poa can register its Adapter Activator as follows
int main()
{
PortableServer::AdapterActivator_ptr my_adapter = new
My_Adapter;
my_poa->the_activator( my_adapter );
}
140418J
3-59
第 3 章 NonStop DOM アプリケーションの開発
3.5 オブジェクト参照
サブトピックス
□ オブジェクト参照の取得
□ オブジェクト参照の操作
□ オブジェクト参照の拡大と限定
「オブジェクト参照」とは、ある特定のオブジェクトを示す名前です。リクエスト内で使用される特定の
オブジェクト参照は常に同じオブジェクトを識別します ( スペースと時間には現実的な制限があります )。
複数の異なるオブジェクト参照を使って 1 つのオブジェクトを表すこともできます。
クライアントはオブジェクト参照を使って CORBA オブジェクト上のメソッドを呼び出します。複数の
オブジェクト参照が 1 つの CORBA オブジェクトを表すことはできますが、1 つのオブジェクト参照が複
数の CORBA オブジェクトを表すことはできません。
CORBA サーバはオブジェクトを実装し、オブジェクト参照を生成します。生成されたオブジェクト参
照は、さまざまな方法で使用することができます。オブジェクト参照は、Naming Service のデータベース
内に文字列化して保管し、パラメータとしてほかのメソッドに渡すことができます。
NonStop DOM は、CORBA 仕様の定義に従って、相互運用可能なオブジェクト参照 (IOR) を生成および
変換します。NonStop DOM の IOR をほかの ORB 実装が変換したり、ほかの ORB が生成した IOR を
NonStop DOM が変換したりすることもできます。
3.5.1 オブジェクト参照の取得
CORBA オブジェクト上のメソッドを呼び出すには、そのオブジェクトの参照が必要です。オブジェク
ト参照の基本的な取得方法は次の 2 つです。
□ 文字列化されたオブジェクト参照を取得し、利用可能な形式に変換する。
□ メソッド呼出しの戻り値または出力パラメータとして取得する。
オブジェクト参照から文字列を生成することができます。これは、
「文字列によるオブジェクト参照」と
呼ばれます。反対に、文字列によるオブジェクト参照からオブジェクト参照を生成することもできます。
文字列によるオブジェクト参照は文字列形式なので、ファイル内に保存することができます。
メソッド呼出しからオブジェクト参照を受け取る一般的な方法は次のとおりです。
□ Naming Service による名前の解決。Naming Service は、オブジェクト参照に識別可能な名前をバインド
するのに使用されます。クライアントはこの名前を使って、オブジェクト参照を取り込むことができま
す。
□「factory」を使ってオブジェクトのインスタンスを作成する。factory とは、ほかのオブジェクトを作成
するオブジェクトのことです。
□ すでにオブジェクト参照を持つオブジェクト上でメソッドを呼び出す。このメソッドによってオブジェ
クト参照が返され、呼出し元でこの参照を使用することができます。
3-60
140418J
第 3 章 NonStop DOM アプリケーションの開発
文字列化オブジェクト参照の使用
オブジェクト参照は明確に定められたものではなく、ORB ごとに異なる場合があるため、オブジェクト
参照そのものを、オブジェクトを参照する値として永続的なストレージに保管したり、呼出し以外の手段
で通信に使ったりするのは便利な方法ではありません。問題は 2 つあります。オブジェクト参照を、クラ
イアントがほかの媒体に保管できるような値に変換すること、そしてその値を後で正しいオブジェクト参
照に戻すことです。
オブジェクト参照の保管と取込みのため、ORB には次のインタフェース関数が用意されています。
□
object_to_string
□
string_to_object
NonStop DOM プログラム ( 通常サーバ ) では、次のように object_to_string( ) が使用されま
す。
char* refStr = orb->object_to_string(CORBAObject);
<CORBAObject> 変数の部分にオブジェクト参照が入っています。この結果、ファイルなどに書き込む
ことができる文字列化オブジェクト参照が返されます。呼出しプログラムは、不要になった文字列メモリ
を解放するために CORBA::string_free を使用する必要があります。
NonStop DOM プログラム ( 通常クライアント ) では、次のように string_to_object( ) が使用
されます。
CORBA::Object_var CORBAObject =
CORBA::string_to_object(refStr);
<refStr> 変数の部分に文字列化オブジェクト参照が入っています。この結果、CORBA オブジェクト参
照が返されます。
返されたオブジェクト参照の使用
このセクションには、次の 2 つのサブトピックスが含まれています。
□ メソッドによって生成されたオブジェクト参照
□ Naming Service によって生成されたオブジェクト参照
メソッドによって生成されたオブジェクト参照
メソッド呼出しの結果としてオブジェクト参照を取得することができます。IDL 仕様ではメソッドシグ
ニチャは、out、inout、または
return の値としてオブジェクトを指定します。オブジェクトの型
は、インタフェース名か、または単に Object とします。
オブジェクト参照を取得したら、それを使ってオブジェクト上のメソッドを呼び出すことができます。
140418J
3-61
第 3 章 NonStop DOM アプリケーションの開発
Naming Service によって生成されたオブジェクト参照
NonStop DOM Naming Service を使って、オブジェクト参照を取得することができます。Naming Service
の resolve(
) メソッドに名前を与えることによって、保管されているオブジェクト参照が取り込まれ
ます。Naming Service は、どのような型のオブジェクト参照でも保管できますので、通常クライアントプ
ログラムがオブジェクト参照を使用するには、事前に限定する必要があります。限定について詳しくは、
「オブジェクト参照の拡大と限定」を参照してください。
3.5.2 オブジェクト参照の操作
このセクションでは、次の操作について説明しています。
□ オブジェクト参照の複製
□ nil オブジェクト参照の取得
□ nil オブジェクト参照の確認
□ オブジェクト参照の解放
□ 同値のオブジェクト参照の確認
□ オブジェクトが存在していることの確認
□ オブジェクト参照型の確認
オブジェクト参照の複製
アプリケーションで
_duplicate( ) メソッドを使用して、オブジェクト参照をコピーすることが
できます。このメソッドは通常、オブジェクト参照の保持者が、オブジェクト参照を使用できる状態のま
ま、リクエスタにオブジェクト参照を供給したい場合に使用されます。たとえば、オブジェクトのメソッ
ド が オ ブ ジ ェ ク ト 参 照 の 戻 り 値 を 生 成 す る 場 合、その オ ブ ジ ェ ク ト 参 照 を 後 で 使 用 し た い と き は
_duplicate( ) を使用します。
CORBA::Object_ptr Account2 = CORBA::Object::_duplicate(<Account>);
_duplicate( ) に有効なオブジェクト参照を与えると、同じオブジェクトへの参照が返されます。
与えたオブジェクト参照が nil の場合は、_duplicate( ) メソッドによって nil オブジェクト参照が
返されます。この呼出しで返されたオブジェクトは、CORBA::release( ) を使って解放するか、ま
たは CORBA::Object_var に割り当てて自動的に破棄する必要があります。
備考 : オブジェクト実装は、複製の作成に関与しません。実装からは、特定のリクエストで使用されたオブジェク
ト参照がオリジナルであるか複製であるかは認識されません。
nil オブジェクト参照の取得
nil( ) メソッドを使用して、nil オブジェクト参照を取得することができます。
A_ptr aPtr = A::_nil( );
このメソッドによって、Object_ptr 型の NULL 値が返されます。
3-62
140418J
第 3 章 NonStop DOM アプリケーションの開発
nil オブジェクト参照の確認
与えられたオブジェクト参照が nil かどうか調べるには、CORBA::is_nil(
) 静的メソッドを使用
します。与えられたオブジェクト参照が nil の場合は TRUE、そうでない場合は FALSE が返されます。オ
ブジェクト実装は、nil 確認には関与しません。
if (CORBA::is_nil(aPtr))
return;
オブジェクト参照の解放
プログラムでオブジェクト参照が必要なくなった場合は、解放操作を実行してストレージを再利用する
ことができます。オブジェクト実装はこの操作には関与せず、オブジェクト自身も、そのオブジェクトへ
のほかの参照も、この操作によって影響を受けません。使用例は次のとおりです。
CORBA::release(Account);
同値のオブジェクト参照の確認
2 つのオブジェクト参照が同じオブジェクトを示しているかどうか調べるには、_is_equivalent( )
メソッドを使用します。与えられたオブジェクト参照が、メソッドの起動元と同じオブジェクトを示して
いる場合は、TRUE が返されます。
CORBA::Object_ptr account2 = CORBA::Object::_duplicate(account1);
CORBA::Boolean b = account1->_is_equivalent(account2);
この 例で は、_duplicate(
) に よっ てオ ブジ ェク ト参 照の コピ ーが 作成 され てい るの で、
_is_equivalent( ) の戻り値は TRUE です。
オブジェクトが存在していることの確認
オブジェクトが明示的に削除された場合や、非永続オブジェクトの元のサーバが再起動された場合は、
オブジェクト参照によって示されたオブジェクトが不在になっています。オブジェクトが存在しているか
どうか調べるには、_non_existent(
) メソッドを使用します。オブジェクトが存在しないことが
ORB によって確認された場合は、TRUE が返されます。(CORBA::OBJECT_NOT_EXIST 例外は上
げられません。) 確認されなかった場合は、FALSE が返されます。
if (aPtr->_non_existent())
return;
オブジェクト参照型の確認
オブジェクト参照が特定のクラスのインスタンスであるかどうか調べるには、_is_a(
) メソッドを
使用します。このメソッドによって、そのオブジェクトが、logical_type_id パラメータで指定し
た Repository 型のインスタンスであるかどうかを調べることができます。これにより、ORB の有効範囲内
で、オブジェクト参照の型保証が維持されます。オブジェクトが、指定した型のインスタンスである場合、
140418J
3-63
第 3 章 NonStop DOM アプリケーションの開発
または指定した型が、そのオブジェクトの型の祖先クラスである場合 TRUE が返されます。
CORBA::Boolean ab = account1->_is_a("Account");
3.5.3 オブジェクト参照の拡大と限定
IDL インタフェース定義の、次のアウトラインをごらんください。
interface Account {
// . . . . .
};
interface Savings: Account {
// . . . .
};
interface Checking: Account {
// . . . .
};
ここでは、Savings と
Checking の両方のインタフェースが、Account インタフェースから継
承されています。IDL コンパイラによって、これらに対応する、Account、Savings、Checking
という名前の C++ クラスが生成されます。継承関係は維持されますので、Saving オブジェクトは
Account オブジェクトでもあり、同様に Checking オブジェクトは Account オブジェクトでもあ
ります。与えられた Account オブジェクトは、Saving オブジェクトである可能性もありますし、そ
うでない可能性もあります。以後のセクションで、これらのクラスを使用します。
オブジェクト参照の拡大
通常のオブジェクト指向システムと同様、Savings オブジェクトへの参照を持っていれば、それを
Account 型の参照に代入することができます。導出されたインタフェースから基本インタフェースへ移
動することを、CORBA では「拡大する」と言います (C++ では「アップキャスト」と言います )。
たとえば、次のオブジェクトの場合、次のような代入を実行できます。
Savings_ptr pSavings = [a valid savings object];
Checking_ptr pChecking = [a valid checking object];
Account_ptr pAccount;
CORBA::Object_ptr pObject;
pAccount = pSavings;
pObject = pChecking;
オブジェクト参照の限定
CORBA では、基本インタフェースから導出インタフェースへ移動することを、
「限定する」と言います
(C++ では「ダウンキャスト」と言います )。基本インタフェース参照を持っていれば、それを導出インタ
フェースへの参照に代入することができます。ただしこれは、基本参照が実際に導出インタフェースのイ
ンスタンスを参照している場合です。この条件が満たされているかどうかを静的に決定する手段はありま
せんので、代入の安全性を確認するには、実行時にテストする必要があります。
3-64
140418J
第 3 章 NonStop DOM アプリケーションの開発
次の例は、限定の成功例と失敗例です。
pSavings = Savings::_narrow(pAccount);
if (!CORBA::_is_nil(pSavings))
{ /* pAccount did reference a Savings object */ }
else
{ /* the narrow failed */ }
このような代入を行った場合、<pAccount> が Savings オブジェクトを持っているので、_narrow(
)
は正しく実行されます。
pSavings = Savings::_narrow(pObject);
if (!CORBA::_is_nil(pSavings))
{ /* pObject did reference a Savings */ }
else { /* the narrow failed */ )
この場合、<pObject> にもともと Checking オブジェクト参照が代入されているので、_narrow(
)
によって nil が返されます。
_narrow( ) への呼出しが成功すると、与えられたオブジェクトに新しいオブジェクト参照が返され
) メソッドから返されたオブジェクト参照を解
ます。オブジェクトが不要になった場合は、_narrow(
放する必要があります。
渡されたパラメータが、正しいインタフェースまたは導出インタフェースのオブジェクトへの参照でな
い場合は、静的関数である _narrow(
) から、nil オブジェクト参照が返されます。_narrow( ) メ
ソッドが例外を上げる場合もありますので、コードに例外ハンドラを含めておく必要があります。
3.6 スレッド化
サブトピックス
□ スレッド化の概要
□ クライアントアプリケーションのスレッド化
□ サーバ実装のスレッド化
□ NonStop DOM ポータブルスレッド化インタフェース
3.6.1 スレッド化の概要
マルチスレッド化というプログラミングファシリティによって、プログラミングの共同作業が可能にな
ります。スレッドとは小さなプロセスのことで、同じアドレススペース内で複数が共存することができま
す。各スレッドは、専用の CPU レジスタとスタックを持っています。スレッドどうしで、処理命令スペー
スが共有されます。プロセス内にマルチスレッドがあるということは、複数の同時実行点があるというこ
とです。NonStop DOM ORB では内部的にスレッド化が使用されていますが、NonStop DOM アプリケー
ションのプログラマがこのことを認識している必要はありません。しかし NonStop DOM アプリケーショ
ンのプログラミング時に、明示的にスレッド化を使用することもできます。
140418J
3-65
第 3 章 NonStop DOM アプリケーションの開発
スレッドの主な目的は、並列処理を利用することでプロセスのスループットを増やすことです。マルチ
スレッド環境での実装において特に優れたアプリケーションもあります。分散 NonStop DOM アプリケー
ションでは、クライアントとサーバのどちらか一方、または両方でスレッドを使用することができます。
次のような場合にスレッド化が便利です。
□ 応答の遅いオブジェクトまたはプロセスと相互動作する場合
□ すぐに応答しない可能性のあるユーザと相互動作する場合
□ 遅いデバイスと相互動作する場合
3.6.2 クライアントアプリケーションのスレッド化
NonStop DOM クライアントプログラムでスレッド化を使用する典型的な例は、1 つまたは複数のオブ
ジェクトに対して同時に複数のリクエストを送る場合です。スレッド化を使用しないと、メソッドリクエ
ストは同時に行われます。この場合、クライアントがオブジェクトに対してメソッドリクエストを送った
後、応答が返されるまでの間、ほかのプロセスを実行できません。クライアントアプリケーションがマル
チスレッドを作成すると、各スレッドが別々にメソッドリクエストを送ることができ、未処理のリクエス
トを同時に複数保持することができます。
プログラム例
$NSD_ROOT/samples/bank/feed に、マルチスレッド化された NonStop DOM
クライアントプログラムの例があります。
備考 : スレッド化でなく、動的呼出しインタフェースを使用して、非同期リクエストを送ることもできます。状況
によっては、こちらのほうが良い場合があります。ただし、動的呼出しインタフェースを使用すると、通常、
プログラミングがより複雑になります。
3.6.3 サーバ実装のスレッド化
デフォルト POA スレッド化ポリシーを使用する場合は、スレッドプログラミングは必要ありません。追
加リクエスト処理の必要性に応じて、POA が追加スレッドを生成します。POA はまず、サーバ内のオブ
ジェクトに対するリクエストの処理のため、スレッドを 1 つ作成します。未処理のリクエストが完了する
前に別のリクエストが届くと、POA が別のスレッドを生成して新しいリクエストを処理します。このため
には、元のリクエストを処理しているスレッドがブロックされるか、またはプロセッサの制御を明示的に
解放する必要があります。スレッドがプロセッサの制御を解放しないと、POA スレッドを実行して新しい
スレッドを生成することができません。
状況によっては、サーバに新しいスレッドを生成させるほうが良い場合があります。このようなスレッ
ドは、POA が作成したスレッドと共存できます。
マルチスレッド化サーバを使用する場合は、次の点に注意してください。
□ スレッドから、プロセスをブロックする呼出しを行わない。このような呼出しを行うと、呼出しが実行
されている間プロセス全体がブロックされてしまうため、マルチスレッド化プロセスの意味がありませ
ん。Tandem の NonStop SQL/MP 製品はスレッドをサポートしていないため、SQL 呼出しはすべてプ
ロセスをブロックします。
□ リモートオブジェクトのファイル I/O やメソッドリクエストは、スレッドをブロックする呼出しです。
このような呼出しは呼出しスレッドをブロックしますが、プロセス全体をブロックすることはありませ
3-66
140418J
第 3 章 NonStop DOM アプリケーションの開発
ん。よく設計されたマルチスレッド化プログラムでは、スレッドをブロックする呼出しが使用されます
が、プロセスをブロックする呼出しは使用されません。
□ NonStop DOM では、いくつかの Guardian 呼出し用に「ジャケット」が提供されています。ジャケット
によって、プロセスをブロックする呼出しが、スレッドをブロックする呼出しに変換されます。ジャ
ケットは、NonStop TS/MP および NonStop TM/MP のいくつかの呼出しで使用できます。ジャケット
について詳しくは、『NonStop DCE Application Programming Guide』を参照してください。
3.6.4 NonStop DOM ポータブルスレッド化インタフェース
NonStop DOM では、スレッド用に、オブジェクト指向の、移植可能なアプリケーションプログラミン
グインタフェース (API) が提供されています。このプログラミングインタフェースを使用すると、次のよ
うなスレッド操作を実行できます。
□ スレッドを作成する。
□ スレッドの優先順位を変更する。
□ プロセッサの制御を解放する。
□ ほかのスレッドの完了を待機する。
□ スレッドをキャンセルする。
□ スレッド固有のデータを操作する。
また、
「ミューテックス」と「条件変数」という、2 つの同時制御メカニズムも提供されています。ミュー
テックスについては、次のような操作を実行できます。
□ ミューテックスを作成する。
□ ミューテックスをロックする。
□ ミューテックスのロックを解除する。
□ ミューテックスをテストする。
条件変数については、次のような操作を実行できます。
□ 条件変数を作成する。
□ 条件変数を待機する。
□ 条件変数が使用可能かどうか知らせる。
□ 条件変数が使用可能かどうかブロードキャストする。
これらのクラスのヘッダファイルは
vthread.h です。NonStop DOM のスレッド化インタフェース
について詳しくは、『第 4 部 Nonstop™ JTS/OTS ユーザーズ・ガイド』を参照してください。
OSS 環境では、DCE Threads パッケージに基いた API が提供されています。これは NonStop DOM SRL
に含まれていますので、スレッド化アプリケーションプログラムを別のスレッドライブラリとリンクしな
い でく ださ い。スレ ッド API の 使用 方法 につ いて 詳し くは、Tandem の『NonStop DCE Application
Programming Guide』を参照してください。おすすめできませんが、特定のプラットフォームに含まれるス
レッド化実装を使用することも可能です。たとえば、DCE Treads スレッド化インタフェースを直接使用す
ることもできます。
140418J
3-67
第 3 章 NonStop DOM アプリケーションの開発
備考 : DCE 製品がインストールされている場合は、DCE で提供されているライブラリを使用しないでください。
NonStop DOM SRL ではスレッド API と、サポートされるジャケットルーチンが提供されています。
3-68
140418J
第 4 章 インスツルメンテーション用アプリケーション
第 4 章 インスツルメンテーション用アプリケーション
4.1 エラーログファシリティ
サブトピックス
□ エラーログファシリティの設計
□ エラーログ情報
□ エラーログの有効化
□ エラーログファシリティの呼出し
□ エラーログの例
□ エラーログファシリティインタフェース
NonStop DOM 「エラーログファシリティ」は、OSS 環境で実行され、EMS (Event Management Server)
を使ってログ情報をレポートします。
エラーログファシリティは、一つのオブジェクトと、NonStop DOM 例外および例外条件を EMS コレク
タに書き込むための 一つの API で構成されます。ログファイルに記録されたデータを使って、NonStop
DOM アプリケーションの実行中に発生した問題を追跡および修正することができます。
エラーログファシリティでは、エラーログの詳細はユーザの目から隠されています。ユーザは、エラー
ログファイルの形式や、エラーログの作成、オープン、クローズに関与する必要はありません。
4.1.1 エラーログファシリティの設計
エラーログファシリティは、NSDOM_Error_Log オブジェクト内に実装されています。このオブジェ
クトは、例外と例外条件の記録のためのメソッドを提供しています。NSDOM_Error_Log 内のメソッ
ドを呼び出すと、ログメッセージが作成され、メッセージを EMS コレクタに書き込むために必要な操作が
実行されます。
エラーログファシリティは、ユーザが供給するデータと呼出し中に NSDOM_Error_Log が取得する
データに基いて、ログメッセージを構成します。
備考 : エラーログは、NonStop DOM によって内部的にも使用されます。ユーザがエラーログに書き込んだメッ
セージに、NonStop DOM によって生成されるメッセージが挿入されます。
ログエントリが生成されると、エラーログファシリティによって、ユーザが指定した EMS コレクタに
エラーメッセージが書き込まれます。コレクタは、NonStop DOM 構成データベース内で、log_file
キー値を使って指定します。
EMS コレクタに書込みを行うには、まず EMA コレクタを開始する必要があります。EMA コレクタの
開始と実行について詳しくは、
「エラーログの有効化」と『Event Management Service (EMS) Manual』を参
140418J
3-69
第 4 章 インスツルメンテーション用アプリケーション
照してください。
4.1.2 エラーログ情報
ログメッセージは、次の表 3-5 の情報で構成されています。
表 3-5 エラーログのデータフィールド
フィールドの説明
フィールド名
例外が記録された日付と時間
フィールド名なし
エントリのエラー番号
フィールド名なし
例外のテキスト記述
フィールド名なし
例外の重大度
Severity
エラーを記録したコンポーネントの名前
Component
エラーを記録したプロセスの名前
PName
エラーを記録したプロセスの ID
PId
エラーを記録したスレッドの ID
TId
例外の型
ExcptType
例外の名前
ExcptName
エラーを記録したソースファイルの名前
File
エラーを記録したソースファイルの行番号
Line
これらの情報のほとんどは、呼出しが実行されたときにエラーログファシリティによって作成されます
が、いくつかの情報はユーザが供給する必要があります。
ユーザが供給する情報
エラーログファシリティを使って実行時の例外を記録するには、エラーログ API への呼出しに次の情報
を含める必要があります。
□ エラー条件を表す一意のエラー番号
( 既定のアプリケーションエラー番号は 7001 ∼ 7100 です )
□ ユーザ指定のエラーテキスト
□
CORBA::Environment オブジェクトへのポインタ ( オプション )
□ エラーが発生したソースファイルの名前
□ エラーが発生したソースファイルの行番号
3-70
140418J
第 4 章 インスツルメンテーション用アプリケーション
システムが供給する情報
エラーログファシリティへの呼出しが実行されると、NSDOM_Error_Log によって、構成データベー
スからいくつかの情報がコンパイルされます。NSDOM_Error_Log が供給するのは、生成されるログ
メッセージごとの、日付、時間、プロセス名、プロセス ID、スレッド ID、コンポーネント ID、例外名、
例外の説明、およびエラー番号です。
4.1.3 エラーログの有効化
EMS コレクタが使用されていることは、ユーザからは見えません。エラーログファシリティは、
NSDOM_Error_Log 呼出しの処理中に、このファシリティをバックグラウンドでシームレスに使用し
ます。ただし、ログファシリティへの呼出しを実行する前に、指定された EMS コレクタをユーザが開始す
る必要があります。EMS コレクタは、構成データベース内で、log_file キー値によって指定されてい
ます。
NonStop DOM でエラーログを有効化するには、TACL プロンプトで次の OSS コマンドを入力して、EMS
ディストリビュータを開始します。
> ADD DEFINE =_EMS_TEMPLATES, FILE $SYSTEM.ZDOMSD20.newnres
> EMSACOLL /NAME $ xxx , NOWAIT/ BLOCKING OFF
備考 : NonStop DOM の SDK (Software Development Kit) バージョンをインストールしている場合は、ファイル
は、 ZDOMSD20 サブディレクトリにインストールされています。NonStop DOM のランタイムバージョ
ンを使用している場合は、NonStop DOM のファイルは、 ZDOMRT20 サブディレクトリにあります。
$ xxx は、データベース構成ファイル ( デフォルトでは default.db) 内の log_file エントリ
に指定されたコレクタのプロセス名です。
EMS コレクタの開始について詳しくは、『Event Management Service (EMS) Manual』を参照してくださ
い。
4.1.4 エラーログファシリティの呼出し
エラーログファシリティへの呼出しはそれぞれ、「重大度レベル」を与える必要があります。重大度は、
Error、Warning、Informational の 3 種類です。
□「Error」
システム内でエラーが発生したことを示します。問題を修正するためのユーザアク
ションが必要な場合があります ( 構成エラーなど )。
□「Warning」
将来問題を起こす可能性のあるイベントが発生したことを示します ( データベース
ファイルの使用率が 90% になったなど )。
□「Informational」 メッセージは、エラーや警告ではありません。インスツルメンテーションに使用でき
ます。
例外メッセージを記録するための呼出しが実行されると、エラーログファシリティは、呼出し元に返る
前に、データをログファイルに書き込む必要があります。
エラーログファシリティ自身は、例外を上げたりエラーを返したりすることはありません。エラーログ
140418J
3-71
第 4 章 インスツルメンテーション用アプリケーション
ファシリティがエラーログファイルに書き込めない場合は、標準出力ファイル (<stdout>) に書き込みます。
実行時の例外を記録するには、NonStop DOM アプリケーションのエラー処理ルーチン内でエラーログ
ファシリティを呼び出します。
コードへのエラーログメッセージ追加作業を支援するため、NonStop DOM では、例外の重大度レベル
ごとに 1 つずつ既定マクロが用意されています。これらのマクロを使用するには、各エラーログ呼出しご
とに次の情報を供給する必要があります。
□ エラー条件を表す一意のエラー番号
□ ユーザ指定のエラーテキスト
□
CORBA::Environment オブジェクトへのポインタ ( オプション )
既定マクロを使用すると、エラーが発生したソースファイル名と行番号は、自動的に呼出しに追加され
ます。
既定マクロ
エラーログプロセスの単純化のため、NonStop DOM では、次のエラーログマクロを提供しています。
例 1. エラーログマクロ
/* Log message where severity = ERROR */
NSDOM_LOG_ERR ( ErrorNum , ErrorText ,
Environment );
/* Log message where severity = WARNING */
NSDOM_LOG_WARN ( ErrorNum , WarningText ,
Environment );
/* Log message where severity = INFORMATIONAL */
NSDOM_LOG_INFO ( ErrorNum , InfoText , Environment );
/* Set component id */
NSDOM_LOG_SET_COMPONENT_NAME ( ComponentName );
これらのマクロの使用方法については、「エラーログの例」を参照してください。
コンポーネント名
NonStop DOM が、エラーメッセージを記録するプロセスを識別できるよう、各 NonStop DOM コンポー
ネントには一意の名前が割り当てられている必要があります。コンポーネント名は、エラーメッセージが
記録される前に、各プロセスに 1 度ずつ割り当てます。ユーザがコンポーネント名を設定していない場合
は、エラーログファシリティによって、Application というデフォルト値がコンポーネント名として
割り当てられます。
コンポーネント ID 初期化のため、NonStop DOM では次のマクロが提供されています。
NSDOM_LOG_SET_COMPONENT_NAME (<ComponentName>);
このマクロを使用するときは、ユーザが <ComponentName> の部分を供給する必要があります。次の表
は、NonStop DOM コンポーネントが使用する既定名です。
3-72
140418J
第 4 章 インスツルメンテーション用アプリケーション
表 3-6 コンポーネント名
既定 NonStop DOM コンポーネント名
CommServer
LSD
InterfaceRepository
EventService
NameService
ConfigManagement
OTS
エラー番号
NonStop DOM 環境で発生する問題は、エラー番号によって識別されます。0 ∼ 6,999 までのエラー番号
は NonStop DOM によって予約されていますが、7,001 ∼ 7,100 までの番号を使って、ユーザ定義エラー番
号を追加することができます。
エラー番号の追加について詳しくは、
『Event Management Service (EMS) Manual』を参照してください。
各エラー番号は、次の情報に関連付けられます。
□ 名前
□ エラーの短い説明
□ 問題解決のためにユーザが取り得るアクション
4.1.5 エラーログの例
次 の コ ー ド は、既 定 マ ク ロ を 使 っ た エ ラ ー の 記 録 例 で す。こ の 例 で は、ま ず
NSDOM_LOG_SET_COMPONENT_NAME( ) マクロを使ってコンポーネント名を設定しています。次
) 既定マクロを呼び出し、エラーの重大度を
に、エラー処理サブルーチン内で、NSDOM_LOG_ERR(
持つメッセージを記録しています。
例 2. マクロを使ったエラーの記録
#include errorlog.h
main ( )
{
CORBA::Environment
lv_env;
// set the component name (done once per component)
NSDOM_LOG_SET_COMPONENT_NAME( "Bank Server" );
...
// log an error
140418J
3-73
第 4 章 インスツルメンテーション用アプリケーション
NSDOM_LOG_ERR ( 7003,
"Error writing to CustDB", lv_env);
...
}
4.1.6 エラーログファシリティインタフェース
エラーログファシリティを使用する際に、実際の API の NSDOM_Error_Log 呼出しについて理解し
ている必要はありません。用意されているエラーログマクロを使用して、マクロに API メソッドを呼び出
させてください。しかし、エラーログファシリティの動作について理解していると便利な場合もあります。
エラーログファシリティへの公開インタフェースセクションは、記録したメッセージの重大度 (Error、
Warning、または Informational) に基いています。これらの重大度は、NSDOM_Error_Log クラスで定
義されるメソッドに反映されています。次の例を参照してください。
例 3. NSDOM_Error_Log 公開メソッド
//C++ NSDOM_Error_Log Class
class NSDOM_Error_Log
{
public:
static void set_component_name (char *ppComponentName);
static void log_error_msg (char *ppSourceFileName, // name of
the src file
long ppSourceLineNum, // line number of
src file
long pvErrNumber,
// error number
char *ppErrorText, //error msg text
CORBA::Environment &prEnv);
static void log_warning_msg (char *ppSourceFileName, //name of
the src file
long ppSourceLineNum, // line number of
src file
long pvErrNumber,
// error number
char *ppWarningText, //warning text
CORBA::Environment &prEnv);
static void log_info_msg (char *ppSourceFileName, // name of the
src file
long ppSourceLineNum, // line number of
src file
long pvErrNumber,
// error number
char *ppInfoText,
//info msg text
CORBA::Environment &prEnv);
};
3-74
140418J
第 4 章 インスツルメンテーション用アプリケーション
メッセージのログ
エラーメッセージの記録は、3 つの
NSDOM_Error_Log メソッド呼出しでサポートされています。
次のメソッドがそれぞれ、Error、Warning、および Informational メッセージのサポートを提供しています。
□
NSDOM_Error_Log::log_error_msg( )
□
NSDOM_Error_Log::log_warning_msg( )
□
NSDOM_Error_Log::log_info_msg( )
これらの NSDOM_Error_Log メソッドのどれかを呼び出すと、エラーログファシリティが次の動作
を実行します。
1. システムコールを使用して、日付、時間、プロセス名、プロセス ID、およびスレッド ID を取得する。
2. CORBA::Environment オブジェクトから例外情報を取得する。
3. ユーザが供給した情報と、システムが収集した情報を使って、メッセージを作成する。
4. EMS メッセージを発行する。これもログファイルに記録されます。
これらに加えて、NSDOM_Error_Log には、次のメソッドも含まれています。これは、コンポーネ
ント名設定のサポートを追加するメソッドです。
NSDOM_Error_Log::set_component_name( )
4.2 トレースファシリティ
サブトピックス
□ トレースファシリティの設計
□ トレース情報
□ トレースファシリティの呼出し
□ トレース例
□ トレースファシリティインタフェース
NonStop DOM トレースファシリティは、トレースメッセージを ASCII ファイルに書き込むオブジェク
ト API で構成されます。トレースファシリティは、NonStop DOM アプリケーションでインスツルメンテー
ションを実装するのに使用します。NonStop DOM アプリケーションやコンポーネントの特定の部分にト
レース文を追加して、プログラムコードのトラブルシュートに利用することができます。
4.2.1 トレースファシリティの設計
トレースファシリティは、NSDOM_Trace と呼ばれる単一のオブジェクトによって構成されます。こ
のオブジェクトは、トレースメッセージを指定されたトレースファイルに書き出すためのメソッドをいく
つか提供しています。トレースファシリティの使用を単純化するため、NonStop DOM には、トレースマク
ロが用意されています。
140418J
3-75
第 4 章 インスツルメンテーション用アプリケーション
トレースマクロも NSDOM_Trace メソッド自体も、トレースメッセージ書込みの詳細はユーザの目か
ら隠されています。ユーザは、トレースファイルの形式や、トレースファイルのオープン、クローズ、お
よびプラットフォーム固有の問題に関与する必要はありません。
トレースファシリティが呼び出されると、ユーザが供給するデータと呼出し中にシステムが取得する
データに基いてメッセージが構成されます。その後トレースファシリティは、指定された ASCII トレース
ファイルにメッセージを書き出します。
トレースファシリティは、1 つのトレースファイルに複数のプロセスがトレース情報を書き込めるよう
に設計されています。
トレースファイルの指定
トレースファシリティが書き込むファイルは、構成ファイルで指定します。デフォルトでは、トレース
ファシリティは、<stdout> に書き込みます。ORB_init(
) が呼び出される前にトレースメッセー
ジが生成された場合も、トレースファシリティは <stdout> に書き込みます。
4.2.2 トレース情報
トレースメッセージが生成されると、トレースファシリティが次の情報をトレースファイルに書き込み
ます。
□ トレースメッセージの日付と時間
□ トレースメッセージを生成したプロセスの名前と ID
□ スレッド ID
□ ユーザが供給したトレースデータ
これらの情報のほとんどはシステムによって供給されますが、特定のトレースメッセージはユーザが供
給する必要があります。このメッセージによって、ユーザは、コードのどの部分でトレースメッセージが
生成されたかがわかります。
4.2.3 トレースファシリティの呼出し
トレースメッセージを生成するには、ユーザが、既定トレースマクロか、または NSDOM_Trace オブ
ジェクトで定義された log_trace(
) メソッドを呼び出します。呼出しには、ユーザが供給するパラ
メータ値が必要です。トレースファシリティはその後、トレースメッセージを作成し、メッセージを ASCII
トレースファイルに書き込むために必要な操作を実行します。
トレースファイル情報と、トレースファシリティが使用するその他の構成データは、NonStop DOM 構
成ファイル内で指定されている必要があります。構成データの取込みには、NonStop DOM 2.0 CDF
(Configuration Data Facility) が使用されます。トレース情報は、構成データベース内で ORB エンティティ
に指定されたファイルに書かれています。
3-76
140418J
第 4 章 インスツルメンテーション用アプリケーション
既定トレースマクロ
アプリケーションコードへのトレース文追加作業を単純化するため、次のマクロが用意されています。
例 1. トレースファシリティマクロ
/* log trace message */
NSDOM_trace ( const char *pp_data,
short pp_data_len,
CORBA::Enfironment &pr_env );
/* printf style trace output */
NSDOM_tracef ( const char *pp_format, ...);
このマクロによってトレースファイルが開かれ、トレースメッセージが書き込まれます。このマクロを
使用すると、直接 NSDOM_Trace オブジェクトに呼出しを行う必要はありません。
備考 : トレースファイルを明示的に閉じるには、NSDOM_Trace::close_trace_file( ) を呼び出
す必要があります。このメソッドを呼び出さなかった場合は、現在のプロセス終了時に、トレースファシリ
ティによってトレースファイルが閉じられます。
4.2.4 トレース例
次の例は、既定トレースマクロを使ってコードにトレースメッセージを追加する方法を示しています。
アプリケーションプロセスが NSDOM_TRACE(
) への呼出しを検出すると、トレースファシリティがデ
フォルトの ASCII トレースファイルにメッセージを書き込みます。
例 2. トレースメッセージの作成
#include "nsdorb/trace.h"
main( )
{
CORBA::Environment lv_env;
char lv_trace_buf[100];
...
/*perform trace operation */
strcpy(lv_trace_buf, "User-routine while loop");
NSDOM_trace ( lv_trace_buf, strlen(lv_trace_buf ), lv_env);
...
/* using the printf-style trace macro */
NSDOM_tracef ("%s %d", S1, 25);
...
}
140418J
3-77
第 4 章 インスツルメンテーション用アプリケーション
4.2.5 トレースファシリティインタフェース
トレースファシリティを使用する際に、実際の API の
NSDOM_Trace 呼出しについて理解している
必要はありません。用意されているトレースマクロを使用して、マクロに API メソッドを呼び出させてく
ださい。しかし、トレースファシリティの動作について理解していると便利な場合もあります。
NSDOM_Trace の公開セクションには、4 つのメソッドがあります。このうち 3 つは、実際のトレー
スメッセージの作成に使用されます。4 番目のメソッドは、特定の、ユーザ定義トレースファイルの作成
に使用できます ( デフォルトでは、トレースファシリティは、システム構成の際に指定されたファイルに
トレースメッセージを書き込みます )。
例 3. NSDOM_Trace 公開メソッド
//C++ NSDOM_Trace Class
class NSDOM_Trace
{
public:
static void set_trace_file_name(char *pp_trace_fname,
CORBA::Environment &pr_env);
static void open_trace_file (CORBA::Environment &pr_env);
static void close_trace_file (CORBA::Environment &pr_env);
static void log_trace (char *pp_trace_data,
short pv_trace_data_len,
CORBA::Environment &pr_env);
};
NSDOM_Trace メソッドの解説
NSDOM_Trace::log_trace( ) メソッドは、トレースメッセージをトレースファイルに書き込
みます。また、open_trace_file( ) メソッドの明示的な呼出しによってトレースファイルの作成
とオープンがまだ実行されていない場合は、このメソッドが、その作業を実行します。( このメソッドの呼
出し前に open_trace_file(
) を呼び出す必要はありません )。
NSDOM_Trace::open_trace_file( ) メソッドは、log_trace( ) メソッドの呼出し前
にトレースファイルを作成して開くために使用します。
NSDOM_Trace::close_trace_file( ) を使って、開いているトレースファイルを明示的に
閉じることができます。NSDOM_Trace は、現在のプロセスが終了するまで、トレースファイルを閉じ
ません。
NSDOM_Trace::set_trace_file_name( ) を使って、ユーザ定義のトレースファイル名を
指定することができます。このメソッドによって、ユーザは、構成データベースで指定されたデフォルト
のトレースファイルでなく、独自のファイルを指定することができます。ユーザ指定のトレースファイル
を 作成 する には、o p e n _ t r a c e_ fil e( ) ま たは l og_ tra ce( ) を呼 び出 す前 に、
NSDOM_Trace::set_trace_file_name( ) メソッドを呼出してください。
3-78
140418J
第 5 章 NonStop DOM アプリケーションの構築
第 5 章 NonStop DOM アプリケーションの構築
5.1 OSS 開発環境
サブトピックス
□ OSS を通じた Guardian コマンドとファイルの利用
□ OSS 環境変数と env.sh ファイル
□ OSS 開発およびデバッグツール
OSS (Open System Services) は、UNIX や Tandem NonStop Kernel に似たインタフェースです。OSS 環
境は、Guardian 環境と共存することもでき、また Guardian に代わる独立したインタフェースも提供しま
す。OSS は、オープンコンピューティング業界標準、特に POSIX 仕様に準拠しています。
UNIX と違い、OSS はオペレーティングシステムではありません。Tandem NonStop Kernel は、OSS と
Guardian 両方のファイルシステムのオペレーティングシステムです。
OSS は、次の主要コンポーネントで構成されています。
OSS ファイルシステムは、UNIX に似た階層構造を持ち、ディレクトリ、サブ
ディレクトリ、およびファイルで構成されています。OSS ファイルシステムは、フラット Guardian ファ
イルシステムを使用します。
□ ファイルシステム
□ コマンドインタプリタ (OSS シェル )
OSS シェル (osh) は、OSS のユーザインタフェースです。
UNIX Korn シェルを使用します。
□ ユーザコマンドおよびユーティリティ
□ API( アプリケーションプログラミングインタフェース )
□ C++ ランタイムライブラリ
OSS のほとんどのコマンドは、UNIX のコマンドに直接対応していますが、いくつかのコマンドとユー
ティリティは、OSS 固有のものです。OSS では状況に応じて、NonStop Kernel 機能へのアクセスを提供す
るため、UNIX のコマンドを拡張しています。
OSS コマンドとユーティリティのオンライン情報を入手するには、OSS の man コマンド (「manual」の
短縮形 ) を使用します。たとえば、gtacl コマンドの詳細を調べるには、次のように入力します。
man gtacl
デフォルトでは、OSS プロセスは、名前なしの Guardian プロセスとして実行されます。しかし OSS の
run コマンドを使って、OSS プロセスを、名前付きの Guardian プロセスとして実行することもできます。
140418J
3-79
第 5 章 NonStop DOM アプリケーションの構築
5.1.1 OSS を通じた Guardian コマンドとファイルの利用
OSS の gtacl コマンドを使って、osh から Guardian コマンドを実行することができます。次の例は、
gtacl を使った、Guardian の fileinfo コマンドと status コマンドの実行方法を示しています。
gtacl -c fileinfo
gtacl -c ‘status $ztc0’
また、標準名前規則を使って、osh から Guardian ファイルを使用することもできます。OSS ファイルシ
ステム内では、
「/G」は Guardian ファイルシステムを意味します。次の例は、OSS の ls コマンドを使っ
て、Guardian の $data1.nsdom サブボリュームの内容をリストする方法を示しています。
ls /G/data1/nsdom
OSS の run コマンドを使って、プロセスを Tandem 属性で実行することができます。たとえば、次の構
文を使って、名前付きプロセスを実行することができます。
run -name=Guardian-process-name program-name
5.1.2 OSS 環境変数と env.sh ファイル
シェルには通常、環境変数があり、設定したり表示したりすることができます。シェルから開始された
プロセスは、OSS API を使って環境変数にアクセスすることができます。たとえば、NonStop DOM プロ
セスとユーティリティは、システムを構成したり、コンポーネントを開発したり、アプリケーションを実
行したりするときに、環境変数を使用します。NonStop DOM が使用する環境変数は、env.sh ファイル
内に保管され、構成手順の 1 つとして osh 環境にロードされます。
NonStop DOM アプリケーションの構築に関する、env.sh 内の変数のサブセットは次のとおりです。
export NSD_ROOT=/usr/tandem/nsdoms
export MY_ROOT=$NSD_ROOT
add_define =_SRL_01 class=map file=$NSD_SRL_SUBVOL.NSDSRL
export NSDOM_CFG_DBM=$MY_SUBVOL.NSDCFGDB
export PATH=$PATH:$NSD_ROOT/bin:$COMP_ROOT/usr/lib:$JAVA_HOME/
bin
備考 : NonStop DOM の SDK (Software Development Kit) バージョンをインストールしている場合は、ファイル
は、 ZDOMSD20 サブディレクトリにインストールされています。NonStop DOM のランタイムバージョ
ンを使用している場合は、NonStop DOM のファイルは、 ZDOMRT20 サブディレクトリにあります。
NSD_ROOT は、NonStop DOM ファイルが常駐するルートディレクトリを指します。このマニュアル
内では、NSD_ROOT 内にあるディレクトリ名を参照している箇所がいくつかあります。この場合、
NSD_ROOT と書かれている箇所を、各自の NSD_ROOT 変数の設定に置き換えてお読みください。
add_define は、OSS から NonStop DOM SRL へポイントする Guardian の定義を設定します。実行
ファイルが実行される際に、Guardian はこの定義を使って、実行ファイルを SRL に関連付けます。
NSDOM_CFG_DBM は、構成データベースの位置を指定します。
PATH は、osh プロンプトでコマンドが入力された際に検索する、ディレクトリの順序を指定します。
NonStop DOM のインストールと構成については、
『第 2 部 NonStop™ DOM 管理者ガイド』に詳しく記
3-80
140418J
第 5 章 NonStop DOM アプリケーションの構築
載されています。
5.1.3 OSS 開発およびデバッグツール
アプリケーション開発には、次の OSS コマンドおよびユーティリティを使用します。
make
このユーティリティを使って、複数の相互依存モジュールで構成されるアプリケーションを構築および
保守します。デフォルトで 「Makefile 又は makefile」という名前の付けられたファイルを使って、
プログラムモジュール間の依存性を記述します。その後、ほかのモジュールに依存されているモジュール
を修正すると、make ユーティリティが、依存しているモジュールの再コンパイルを自動的に開始します。
NonStop DOM のプログラム例では、makefile を使って、アプリケーションの構築と構成のすべての手順を
実行しています。実行している手順は、IDL コンパイラの実行と、アプリケーションプログラムのコンパ
イルおよびリンクです。
c89
このユーティリティは、C++ コンパイラのフロントエンドです。make ファイルの中から c89 を呼び出
すことができます。
nld
このユーティリティは、ネイティブ (TNS/R) リンカです。1 つまたは複数の TNS/R ネイティブオブジェ
クトファイルをリンクして、実行可能または再リンク可能なネイティブオブジェクトファイルを生成しま
す。nld ユーティリティは、Guardian 環境からでも OSS 環境からでも実行できます。c89 は自動的に nld
ユーティリティを呼び出すため、アプリケーション実行ファイルの作成時は、ほとんどの場合、明示的に
nld を使用する必要はありません。
noft
noft ユーティリティは、ネイティブオブジェクトファイルから情報を読み込み、表示します。たとえば、
オブジェクトファイル内の SRL 参照や未解決の参照をリストするのに使用できます。NonStop DOM プロ
グラムの開発とデバッグにはとても便利なユーティリティです。noft は、Guardian 環境でも OSS 環境でも
使用できます。
vi
このユーティリティは、OSS ファイルを作成および更新するための OSS エディタです。
inspect
OSS には、ネイティブのデバッガがありません。NonStop DOM アプリケーションプログラムをデバッ
グするには、Guardian の INSPECT デバッガを使用する必要があります。osh プロンプトから INSPECT
セッションを開始するには、次の要領で run コマンドを実行します。
run -debug program-name
140418J
3-81
第 5 章 NonStop DOM アプリケーションの構築
5.2 NonStop DOM アプリケーションコンポーネントの構築
サブトピックス
□ Makefiles
□ プログラム例
プログラム構築手順の概要は次のとおりです。
1. OSS シェル環境に env.sh ファイルがロードされていることを確認します。NonStop DOM のインス
トール時にプロファイルに env.sh を追加した場合は、osh セッションを開始すると自動的に
env.sh ファイルがロードされます。
2. すべての IDL ファイルに対して NonStop DOM IDL コンパイラを実行して、言語固有のヘッダファイ
ルと実装スタブファイルを作成します。たとえば、C++ を使用してオブジェクトメソッドを実装するに
は、次のコマンドを実行します。
java nsdidl.Main -language C++ *.idl
3. コンパイラが生成したファイルを修正しないでください。IDL コンパイラが生成したヘッダを含むヘッ
ダファイルを自分で作成してください。IDL コンパイラが生成したヘッダで宣言されている純仮想関数
を実装してください。
4. 任意の言語でクライアントプログラムを作成します。オブジェクトが実装された言語と違う言語でクラ
イアントを作成することもできます。クライアントプログラムには、プログラムが使用するオブジェク
トの、言語固有のヘッダファイルが含まれている必要があります。
5. c89 を使ってすべてのソースコードファイルをコンパイルし、.o ファイルを生成します。
6. .o ファイルを NonStop DOM ランタイム SRL とリンクして、クライアントおよびサーバの実行可能
ファイルを構築します。
5.2.1 Makefiles
NonStop DOM のプログラム例では、make ファイルを使ってアプリケーション構築の手順を実行してい
ます。make ファイルはプログラムの依存性を記述します。その記述によって、make コマンドを実行する
だけで、アプリケーションのすべてのコンポーネントが構築されます。たとえば、
「bank」アプリケーショ
ン例を構築するには、次のように入力します。
make bank
5.2.2 プログラム例
NonStop DOM 製品には、このセクションで前述した「bank」のようなプログラム例が多数含まれてい
ます。プログラム例のソースコードはすべて、$NSD_ROOT/samples ディレクトリに入っています。
例は、簡単なものから複雑なものまであり、さまざまな NonStop DOM 機能の使用方法を示しています。た
とえば、Naming Service と Event Service の使用方法、ステートフルオブジェクトとステートレスオブジェ
クトの使用方法、NonStop SQL/MP データベースへのアプリケーションデータの保管方法、マルチスレッ
ド化アプリケーションの作成方法などです。各プログラム例のディレクトリには README ファイルが含
まれており、プログラム例の構築、構成、および実行方法が記載されています。
プログラム例は、C++ で書かれています。
3-82
140418J
第 6 章 NonStop DOM アプリケーションの実行
第 6 章 NonStop DOM アプリケーションの実行
6.1 アプリケーションコンポーネントのトラブルシューティング
サブトピックス
□ NonStop DOM のエラーメッセージログ
□ トレース
□ デバッグ SRL(Shared Runtime Library) の有効化
NonStop DOM アプリケーションまたはコンポーネントをトラブルシュートする際は、次のソースから
の情報を参考にします。
□ NonStop DOM ランタイムの環境から上げられ、クライアントプログラムに報告されたシステム例外
□ オブジェクトクラスから上げられ、クライアントプログラムに報告されたその他の例外
□ 指定されたログファイルにテキスト形式で記録されたか、または標準出力デバイスに表示された、ラン
タイムのエラー。通常、ログファイルには、NonStop DOM ランタイムによって検出された、予期でき
ないエラー状態に関する情報が記録されます。
□ NonStop DOM が使用する、ほかの Tandem 製品からのイベントメッセージ。NonStop TS/MP、NonStop
TM/MP、NonStop TCP/IP などです。
□ 構成データベース内のエントリまたは環境変数設定に制御される、NonStop DOM トレース
分散オブジェクトアプリケーション内でエラーの位置を特定ことが難しいのは、次の 3 つの理由により
ます。
□ アプリケーション内のフロー制御は、多数のクラス内を渡ってきます。エラーが発生したクラスを簡単
に特定するためには、アプリケーション例外にクラスを識別する情報を含ませるよう設計することで
す。NonStop DOM のトレースファシリティでも、エラーの発生したクラスを特定することができます。
□ アプリケーションが、リモートコンポーネントやリモート ORB と通信するような場合は、すべてのソー
スからのエラー情報を考え合わせて相互運用性の問題を特定するのは難しいことです。すべての ORB
が CORBA 準拠であることを確認し、相互運用性と準拠に関する情報を含め、各 ORB のマニュアルを
すべて取得してください。複数のベンダが供給するクラスライブラリやフレームワークをアプリケー
ションで使用している場合は、それらのコンポーネントのマニュアルも必要です。
□ NonStop DOM を正しく実行するためには、NonStop DOM、NonStop DOM が使用するほかの Tandem
製品、および対応するリモートシステムコンポーネントが正しく構成されている必要があります。たと
えば、TCP/IP 構成のエラーによって、NonStop DOM の構成やアプリケーションの実行に悪影響が出る
場合があります。
Tandem システムでは、各種製品のイベントメッセージと構成ファイルを使って、構成の問題を特定す
ることができます。TCP/IP を含むいくつかの製品では、トレースもサポートしています。場合によっては、
オペレータが、ほかのリモートシステムのオペレータと話し合って、構成の問題を特定する必要があります。
140418J
3-83
第 6 章 NonStop DOM アプリケーションの実行
6.1.1 NonStop DOM のエラーメッセージログ
NonStop DOM が、予期できない状況を検出すると、Tandem の EMS (Event Management Service) を使っ
て記録されます。問題解決の第一歩は、まず EMS メッセージを調べることです。ログに記録された情報か
ら、簡単に問題の原因を特定できることもよくあります。
EMS についての情報と使用方法については、『EMS FastStart Manual』、『EMS Manual』、および『EMS
Reference Summary』を参照してください。
デフォルトでは、NonStop DOM の EMS メッセージは、システムコレクタ $0 に送られます。別のコレ
クタを指定するには、新しいコレクタを開始し、env.sh ファイルの MY_COLLECTOR 変数を新しいコレ
クタ名に設定します。
別の NonStop DOM コレクタの開始
NonStop DOM の別のコレクタを開始するには、TACL プロンプトで次のコマンドを入力します。
> ADD DEFINE =_EMS_TEMPLATES, FILE $SYSTEM.ZDOMSD20.newnres
> EMSACOLL /NAME $ xxx , NOWAIT/ BLOCKING OFF
変数 $xxx は、env.sh ファイルの MY_COLLECTOR 変数に設定するコレクタのプロセス名です。
備考 : NonStop DOM の SDK (Software Development Kit) バージョンをインストールしている場合は、ファイル
は、 ZDOMSD20 サブディレクトリにインストールされています。NonStop DOM のランタイムバージョ
ンを使用している場合は、NonStop DOM のファイルは、 ZDOMRT20 サブディレクトリにあります。
NonStop DOM EMS メッセージの表示
NonStop DOM の EMS メッセージを表示するには、TACL プロンプトで次のコマンドを入力します。
> ADD DEFINE =_EMS_TEMPLATES, FILE $SYSTEM.ZDOMSD20.newnres
> EMSDIST TYPE PRINTING, COLLECTOR $xxx
変数 $xxx は、env.sh ファイルの MY_COLLECTOR 変数に設定したコレクタのプロセス名です。
EMS メッセージの検査
EMS ログのエントリ例を見てみましょう。
98-03-17 09:05:40 ¥KT22.3,330
TANDEM.NSDOM.D44
001617
GIOP Proxy profiles exhausted.
Severity:
Error, Component:
Application, PName:
¥KT22.$:3:330, PId:
1037303857, TId: 1,
File: proxy.cpp, Line: 531
最初に、イベントの日付と時間が表示されています。ログには、さまざまなプロセスからの多くのメッ
セージが含まれる可能性があるため、特定の範囲の時間に記録された EMS メッセージを検査するとよいで
しょう。2 行目には、エラーメッセージのテキストがあります。ここでは「GIOP
3-84
Proxy profiles
140418J
第 6 章 NonStop DOM アプリケーションの実行
exhausted」と表示されています。この情報が、問題解決のヒントになります。
6.1.2 トレース
分散アプリケーションでは通常、複数のプロセス間で相互動作が行われます。これらの動的相互動作の
状況がつかめると、問題の解決に役立ちます。NonStop DOM のトレースファシリティは、この目的のため
に提供されています。
トレースファシリティを使って、問題の発生箇所を特定の相互動作に特定できます。たとえば、クライ
アントがオブジェクトにリクエストを送信したが返信がない、という場合は、オブジェクトをホストして
いるサーバ上で、限定した範囲で検査を行うと問題を特定しやすくなります。NonStop DOM では、さまざ
まな内部コンポーネントにトレースを実行できます。トレースの出力は大きくなることがあるため、トレー
スを有効化する際は慎重に行ってください。
トレースの有効化
NonStop DOM のトレースは、ORB コンポーネント (Comm Server および LSD)、Naming Service、Event
Service、クライアントプログラム、およびサーバプログラムに対して実行できます。トレースを有効化す
るには、プロセスの開始前に、構成データベースを修正するか、または環境変数を設定します。トレース
を無効化するには、修正内容を元に戻してからプロセスを再開します。
トレースの有効化と無効化には 2 つの方法があります。1 つ目は、トレース環境変数を設定することで
す。これらは標準の OSS 環境変数です。変数を設定するには、代入文と、通常 EXPORT 修正子を組み合
わせて使用します。
例:
export NSDOM_CFG_TRACE_CS=TRUE
環境変数を解除するには、unset 文を使用します。例 :
unset NSDOM_CFG_TRACE_CS
もう 1 つの方法は、構成データベース内で値を設定することです。default@trace エンティティ
には、各種トレース設定の名前と値が含まれています。値が TRUE なら、トレースフラグ設定に影響を受
け る NonStop DOM コン ポー ネン トの トレ ース が有 効化 され てい ます。(Naming Service の場 合は、
NS@name_service_settings エンティティでトレースの設定を行います。)
トレースのカテゴリ
NonStop DOM では、複数のコンポーネントでトレースを実行できます。一般に、より小さなコンポー
ネントセットでトレースを有効化するほうが、問題の範囲を限定できます。これ以降のセクションでは、
推奨されるトレース設定を紹介します。次の表には、使用できるトレース設定の一覧が記載されています。
1 列目は環境変数名、2 列目は対応するデータベースキー、3 列目はトレース出力内容の概要です。
表 3-7 トレースオプション
環境変数
140418J
データベース名
説明
NSDOM_CFG_TRACE_CS
comm_server
Comm Server の活動
NSDOM_CFG_TRACE_ES
event_svc
Event Service の活動
3-85
第 6 章 NonStop DOM アプリケーションの実行
環境変数
データベース名
説明
なし
trace
(NS@name_service_se
ttings 内 )
Naming Service の活動
NSDOM_CFG_TRACE_IR
ir
インタフェースレポジトリ
の活動
NSDOM_CFG_TRACE_GCFEH
event_context_free
Pathway プロトコルの ORB
下位レベルイベント処理
NSDOM_CFG_TRACE_GFSEH
event_file_system
Guardian ファイルシステム
プロトコルの ORB 下位レベ
ルイベント処理
NSDOM_CFG_TRACE_SOCKEH
NSDOM_CFG_TRACE_SOCKEH_DETAIL
event_socket
TCP/IP プロトコルの ORB
下位レベルイベント処理
NSDOM_CFG_TRACE_EVENT_CORE
event_core
ORB 下位レベルイベント処
理
NSDOM_CFG_TRACE_GIOP_FW
orb_giop_connections
ORB GIOP プロトコルレイ
ヤ
NSDOM_CFG_TRACE_ORB
orb_request_queue
ORB リクエスト処理
NSDOM_CFG_TRACE_POA
poa
POA (Portable Object
Adapter) の活動
NSDOM_CFG_TRACE_PROXY
NSDOM_CFG_TRACE_PROXY_DETAIL
orb_proxy
ORB プロキシ処理 : メソッ
ド送信と、メソッド呼出し
の結果
NSDOM_CFG_TRACE_THREADS
threads
NonStop DOM スレッドフ
レームワーク
NSDOM_CFG_TRACE_TIMER
event_time
NonStop DOM タイマーオブ
ジェクト
NSDOM_CFG_TRACE_DETAIL
「詳細」トレースの設定
NonStop DOM プロセスのトレース設定
NonStop DOM プロセスのいくつかは、nsdstart スクリプトによって起動されます。このスクリプ
トには、トレースフラグ設定が含まれていますが、無効化されています。1 つまたは複数のシステムプロ
セスに対してトレースを有効化したい場合は、nsdstart を実行する前に、必要な行を有効化してくだ
さい。詳細は、
『第 2 部 NonStop™ DOM 管理者ガイド』の nsdstart に関する章を参照してください。
次のような行が含まれています。
[ set server env NSDOM_CFG_TRACE_ORB=TRUE
有効化するには、[ を削除します。
3-86
140418J
第 6 章 NonStop DOM アプリケーションの実行
次の表は、各システムプロセスに実行できる便利なトレース設定と、トレースログファイルのデフォル
ト名の一覧です。
NonStop DOM プロセス
トレース設定
ログファイル名
Comm Server
NSDOM_CFG_TRACE_CS
NSDOM_CFG_TRACE_SOCKEH
NSDOM_CFG_TRACE_GFSEH
NSDOM_CFG_TRACE_GCFEH
cs.out
Location Service Demon
NSDOM_CFG_TRACE_ORB
NSDOM_CFG_TRACE_GIOP_FW
NSDOM_CFG_TRACE_SOCKEH
lsd.out
Event Service
NSDOM_CFG_TRACE_ES
es.out
Name Service
TRACE
ns.out
アプリケーションプロセスのトレース設定
NonStop DOM のクライアントプロセスまたはサーバプロセスのトレースを有効化するには、プロセス
の実行前に、1 つまたは複数の環境変数を設定します。クライアントプロセスの場合は、まず
NSDOM_CFG_TRACE_PROXY を TRUE に設定するとよいでしょう。より詳細な情報が必要な場合は、
クライアントが使用するプロトコルに応じて、1 つまたは複数のプロトコルトレース変数を有効にします。
サーバプロセスの場合は、まず NSDOM_CFG_TRACE_POA を TRUE に設定するとよいでしょう。よ
り詳細な情報が必要な場合は、NSDOM_CFG_TRACE_ORB を有効にするか、または、サーバが使用す
るプロトコルに応じて、1 つまたは複数のプロトコルトレース変数を有効にします。
6.1.3 デバッグ SRL(Shared Runtime Library) の有効化
NonStop DOM には、デバッグバージョンの SRL (Shared Runtime Library) が含まれています。名前は
NSDGSRL です。デバッグバージョンの SRL の使用目的は多々ありますが、その 1 つは、ヒープコラプ
ションの問題とアプリケーションメモリリークの問題を追跡することです。
デバッグバージョンの SRL を有効化するには、etc/env.sh の次の行を修正します。
add_define=_SRL_01 class=map file=$G_NSDSRL
この行では、NonStop DOM が使用する SRL のバージョンが指定されています。この行の _SRL_01 を
NSDGSRL に変更してください。デバッグが終了したら、元に戻してください。
デバッグバージョンの SRL (NSDGSRL) は、次の 2 つのメソッドを提供しています。
□ グローバル ::operator
□
new( ) は、次の動作を実行します。
heap_check( ) を呼び出す。
□ メモリを割り当てる。
140418J
□
0xcc に新しく割り当てられたすべてのメモリを初期化する。
□
heap_check( ) を呼び出す。
3-87
第 6 章 NonStop DOM アプリケーションの実行
□ グローバル ::operator
delete( ) は、次の動作を実行します。
□
heap_check( ) を呼び出す。
□
0xdd への割当てを解除されたすべてのメモリを初期化する。
□ メモリの割当てを解除する。
□
heap_check( ) を呼び出す。
これらのバージョンの new(
) と delete( ) を使用すると、次の効果があります。
□ ヒープメモリコラプションがあった場合は、heap_check(
) への呼出しがあることによって、早
期に検出されます。これは、ヒープデータ構造の整合性を検証する、Tandem C ランタイム機能です。
□ 削除されたメモリをプログラムが使用しようとした場合は、早期にエラーが発生します。これは、メモ
リの以前の内容が、ビットパターンで置きかえられるためです。
□ 解放されているメモリをプログラムが解放しようとした場合は、エラーが発生します。
これらのアクションによって大きな負荷がかかるため、アプリケーションプログラムの性能が大幅に落
ちることがあります。デバッグ SRL は、実際の業務環境では使用しないでください。
3-88
140418J
第 7 章 NonStop DOM オブジェクトラッパ
第 7 章 NonStop DOM オブジェクトラッパ
7.1 NonStop DOM 2.0 ブリッジ例
7.1.1 はじめに
このセクションでは、会計業務の例を使って、NonStop DOM 2.0 ブリッジについて説明しています。こ
NonStop TS/MP( 支払勘定システム ) が提供している ISO8583 を使ってクライアントおよびサー
の例では、
バと通信を行うシステムがあることを前提としています。また、CORBA システムがあり、IIOP で使用す
る Account サービスおよびクライアントが存在していることも前提としています。次の図は、これらのシ
ステムをブリッジするのに必要な各部分を示しています。
図 3-3 NonStop DOM 2.0 ブリッジ例
続く 2 つのセクションでは、次の内容について説明しています。
□ CORBA クライアントと支払勘定サーバブリッジの接続
□ 支払勘定クライアントと CORBA サーバブリッジの接続
これは、NonStop DOM オブジェクトラッパの使用方法を示す現実的な例です。
140418J
3-89
第 7 章 NonStop DOM オブジェクトラッパ
7.2 CORBA クライアントサーバから支払い勘定サーバへのブリッジ
サブトピックス
□ サーバラッパ
□ メインの処理
□ Factory::Create の実装
□ Worker インタフェースの実装
□ Worker::do_pathsend I の実装
□ イベントコア
□ Worker::handle_event の実装
7.2.1 サーバラッパ
この部分は、Account Service と支払勘定クライアントの役割を果たします。この部分が、メソッド呼出
しを支払勘定リクエストに変換し、支払勘定の返信を待機して、その結果を使ってもとのメソッドを完了
します。この部分は、サーバラッパと呼ばれます。
図 3-4 システムコンテキスト - サーバラッパ
このサーバラッパは、Guardian ファイルシステムと TCP/CS サーバプロトコルで構成されています。
Factory に PERSISTENT_LIFESPAN が設定されているので、サーバラッパは、サーバプールとして構
成されます。
サーバラッパは、NonStop DOM Naming Service を使用して、Factory の参照を
Server_Wrapper
という名前にバインドします。
クライアントは、Server_Wrapper 名前 / 参照を解決するよう、ネーミングサービスに要求します。
その後、結果を
3-90
Account_Service::Factory に限定し、Create メソッドを呼び出します。クラ
140418J
第 7 章 NonStop DOM オブジェクトラッパ
イアントは、結果として得た Account_Service::Account 参照に対して、Inquiry、Credit、およ
び Debit メソッドを実行します。
Naming Service も Account Service も use_comm_server に構成されているため、それらの IOR 内
の IIOP プロファイルには、LSD アドレスが含まれ、Service へのその後のトラフィックに最良の CS を選
択することができます。このバージョンの NonStop DOM 2.0 では、この機能をサポートせず、値を返しま
せん。
図 3-5 サーバラッパの内部プロセスアーキテクチャ
このラッパの内部アーキテクチャは、基本的にどの NonStop DOM 2.0 プロセスとも同じです。NSDEvent
部分は、NonStop Kernel プラットフォームとの相互動作を規格化するために使用されます。NSDORB 部分
は NSDEvent 部分を使って GIOP メッセージのやり取りを行い、POA (Portable Object Adapters) のリクエ
ストをキューに並べます。POA は、IDL コンパイラによって生成されたスタブを使って、factory と worker
のメソッドを送ります。
サーバラッパと、純粋な CORBA アプリケーションの違いは、Worker によって示されます。Worker の
メソッドは、同じ方法で送られますが、メソッド実装には、NSDEvent コンポーネントを直接使った、ラッ
プされたシステムとの通信が関係します。
140418J
3-91
第 7 章 NonStop DOM オブジェクトラッパ
図 3-6 クラス階層
すべての CORBA サーバがそうであるように、IDL インタフェースは、IDL コンパイラによって生成さ
れた POA クラスからの導出によって実装されます。実装クラスはその後、インタフェースで定義された
C++ メソッドを置き換えます。Factory はこれの単純な例です。
POA クラ スか らの 継承 に加 えて、Worker は、Fw_Event_Handler クラ スか らも 継承 し、
handle_event メソッドを置き換えます。Worker は SERVERCLASS_SEND_ 操作の完了を待機す
る間に使用される条件変数を持っています。Worker は、変換関数を使ってメソッドパラメータと ISO8583
メッセージ間の変換を行います。最後に、Worker は自身のメソッドを使って
SERVERCLASS_SEND_
を実行し、完了を待って、結果を解釈します。
7.2.2 メインの処理
サーバラッパの主要機能は、基本的にどの NonStop 2.0 サーバの主要機能とも同じです。ORB を初期化
し、POA を構築し、常駐オブジェクトインスタンス ( この場合は Factory) を生成します。サーバラッパは、
Naming Service を使って Server_Wrapper という名前を Factory にバインドします。その後、ORB を
実行し、リモートメソッド呼出しを待機します。
7.2.3 Factory::Create の実装
create メソッドは、Worker のインスタンスを作成し、ルート POA とともに有効化し、その結果、重
複インスタンスを返します。
3-92
140418J
第 7 章 NonStop DOM オブジェクトラッパ
7.2.4 Worker インタフェースの実装
Account インタフェースから継承される 3 つのメソッドは、同じ基本形式をもっており、すべてのサー
バラッパメソッドは、多少は同じ形式を持っています。これらのメソッドによって、CORBA メソッド呼
出しと、ラップされるシステムのプロトコル間がブリッジされます。
図 3-7 サーバラッパメソッド
7.2.5 Worker::do_pathsend の実装
do_pathsend は、nowaited SERVERCLASS_SEND_ を送り、完了を待ちます。Fw_MD パ
ラメータには、送信されるデータ ( この場合は ISO8583 リクエストメッセージ ) が含まれており、関連す
る応答データ (ISO8583 返信メッセージ ) があれば、そのデータの保持に使用されます。
Fw_Message と FwMD ( メッセージセグメント記述子とも呼ばれます ) は一緒に働いて、隣接する
メッセージデータの柔軟な抽象化 ( コード化 ) を行います。Fw_Md はとても大きくなる場合があり、ま
た、Message 内で複数が連接される場合もあります。この例では、データの流れが小さいため、単一のデ
フォルトサイズの MD で足りています。
Fw_MD パラメータのメソッドは、いくつかの SERVERCLASS_SEND_ パラメータの導出に使用され
ます。
SERVERCLASS_SEND_ パラメータ
MD メソッド
message-buffer
get_ip_base( )
request-length
get_iv_data_bytes( )
maximum-reply-length
get_iv_size( )
NonStop TS/MP では、クライアントプロセスと Blinkmon /Bin its CPU との間の通信に、単一のファイル
番号を使用します。この情報は、NSDEFw_GCF (Guardian Context Free) 内のスタティックパブリックデー
タナンバの cv_file_number が使用されます。
140418J
3-93
第 7 章 NonStop DOM オブジェクトラッパ
NonStop TS/MP 呼出しで使用されているタグは、NSDEFw_GFS (Guardian File System) 内のスタティッ
クパブリックメソッドの generate_unique_tag から取得されます。このメソッドは、プロセス固
有のファイルシステムタグを提供します。このタグは、すべての呼出しで再利用することができます。
NonStop TS/MP 操作が正しく送られた場合、その完了を追跡するために Fw_Event を具体化すること
ができます。Worker がイベントハンドラとして供給され、完了とともに呼び出されます。ファイル番号は
NonStop TS/MP 共用ファイル番号で、タグはファイル番号の修飾子です。作成されたイベントは、イベン
ト自身によって NSDEvent コアに登録されます。
Worker はその後、条件変数を使って NonStop TS/MP 操作の完了を待機します。これによりメソッドス
レッドがブロックされ、ほかのスレッドが実行できるようになります。NonStop TS/MP が完了すると、
Worker の条件変数が handle_event メソッドによって合図されます。イベントは、ファイルエラーや
受信バイト数など、完了作業に関連した情報を運びます。情報は解釈され、エラーがあった場合は適切な
例外が生成されます。エラーが検出されなかった場合は、イベントの完了データに基いて MD が更新され
ます。
7.2.6 イベントコア
NSDEvent コアには、低い優先度で実行されるイベントスレッドが別にあります。プロセス内でほかの
作業が保留中になっていないときに、イベントスレッドが COMMON_COMPLETION_ への呼出しを行い
ます。NonStop TS/MP 操作が完了すると、関連するイベントのファイル番号とタグが合致し、イベントコ
アが、イベントスレッド上のイベントハンドラへの呼出しを行います。
7.2.7 Worker::handle_event の実装
このメソッドは、Worker の条件変数上のシグナルを呼び出します。これにより、イベントスレッドが一
連の過程を実行した後、メソッドスレッドが続行できます。
7.3 クライアント支払勘定から CORBA サーバブリッジ
サブトピックス
□ クライアントラッパ
□ メインの処理
□ Factory::wait の実装
□ Factory::connect_in の実装
□ Worker::accept の実装
□ Worker::handle_event の実装
□ Worker::handle_writeread の実装
□ Worker::handle_close の実装
□ Worker::find_server の実装
□ thread_function の実装
3-94
140418J
第 7 章 NonStop DOM オブジェクトラッパ
7.3.1 クライアントラッパ
この部分は、Account Service クライアントと支払勘定サーバの役割を果たします。この部分が、支払勘
定リクエストを CORBA メソッド呼出しに変換し、メソッドの結果を使って支払勘定返信を送ります。こ
の部分は、クライアントラッパと呼ばれます。
図 3-8 システムコンテキスト - クライアントラッパ
サーバは、Account_Service 名を factory 参照にバインドするよう Naming Service に要求します。
Naming Service は use_comm_server に構成されているため、IOR 内の IIOP プロファイルには LSD
アドレスが含まれ、サービスへのその後のトラフィックに最良の CS を選択することができます。このバー
ジョンの NonStop DOM 2.0 では、この機能はサポートせず、値は返しません。
このクライアントラッパは NonStop TS/MP サーバクラスとして実行されます。プロセスは、Guardian
ファイルシステムと TCP クライアントプロトコルを使用するよう構成されています。
クライアントラッパプロセスは、NonStop DOM Naming Service を使用して、Account_Service
という名前を解決し、サーバの Factory 参照にします。そして結果を Account_Service::Factory
に限定し、Create メソッドを呼び出します。その後支払勘定リクエストを待機し、対応する Inquiry、Credit、
および Debit メソッドを Account_Service::Account 参照に対して実行します。
支払勘定クライアントは、支払勘定サーバの場合と同じように、NonStop TS/MP を使ってクライアント
ラッパと通信します。
140418J
3-95
第 7 章 NonStop DOM オブジェクトラッパ
図 3-9 クライアントラッパの内部プロセスアーキテクチャ
クライアントラッパの内部アーキテクチャは、GFS (Guardian File System) サーバと CORBA クライアン
トの複合体です。Factory は、NSDEvent 部分を使って、$receive 上で LINKMON プロセスからの OPEN
メッセージを待機します。OPEN を受信すると、その GFS 接続のため、Factory が Worker を作成します。
Worker は NSDEvent 部分を使って、LINKMON からの WRITEREAD および CLOSE メッセージを待機
します。WRITEREAD イベントが受信されると、Worker は、イベントを引数として渡してスレッドを起
動し、スレッドを送信して (Worker がその後の結合に無関係であることを示しています )、その後返しま
す。これは、受信された各 WRITEREAD イベントに対して、それらを完了するために 1 つずつスレッド
が起動されることを意味します。
1 つのクライアントラッパプロセス内にある複数のスレッドは、1 つのプロセスを共有します。実行され
る最初のスレッドは NSDORB 部分を使って、サーバ名を Factory 参照に解決するよう Naming Service に
要求し、その結果を使って Account 参照を作成します。
スレッドはその後イベントの Fw_MD を解釈して ISO8583 リクエストメッセージに変換し、Account 参
照上で対応するメソッドを呼び出します。メソッドの結果は ISO8583 応答メッセージの生成に使用されま
す。応答はイベント
Fw_MD に書き込まれ、イベントの返答メソッドが起動されます。これがスレッドの
作業の終わりで、thread_function が完了します。
3-96
140418J
第 7 章 NonStop DOM オブジェクトラッパ
図 3-10 クラスの説明
Client_Wrapper::Factory は、Guardian File System リス ナイ ベン トハ ンド ラユ ーザ
(NSDEFw_GFS::Listener_EH_User) です。これが、null サブデバイス用にリスナイベントハン
ドラ を構築します ( つまり、LINKMON がプロセスを開始します )。OPEN メッセージが $RECEIVE に届
くと、イベントハンドラが connect_in メソッドを起動します。Worker デストラクタがシグナルを呼
び出します。
Client_Wrapper::Worker は NSDEFw_GFS::Server_Event_Handler です。これは
File System 接続のために、Factory によって作成されます。cv_worker カウンタがコンストラクタに
よって増加され、その後減少してデストラクタに検査されます。Worker は、接続に関与する WRITEREAD
NSDEFw_Receive_Handler に登録します。各 WRITEREAD イベント
に 対し て、Worker は thread_function を 起動 しま す。thread_function は 変換 関数 と
Account_Service::Account_client を使用します。CLOSE イベントを受信すると、Worker
および CLOSE イベントを
は自動的に消去します。
7.3.2 メインの処理
クライアントラッパの主要機能は、ORB を初期化し、Client_Wrapper::Factory を作成し、
factory の wait メソッドを呼び出すことです。最後の CLOSE メッセージを LINKMON から受け取ると、
wait メソッドが完了し、プロセスが終了します。
140418J
3-97
第 7 章 NonStop DOM オブジェクトラッパ
7.3.3 Factory::wait の実装
wait メソッドは、その条件変数上で待機します。
7.3.4 Factory::connect_in の実装
connect_in メソッドは、Worker のインスタンスを作成し、接続を受諾するよう指示します。
7.3.5 Worker::accept の実装
accept メソッドは、キーパラメータを使って関連する I/O や CLOSE イベントを Receive_
Handler を用い登録します。
7.3.6 Worker::handle_event の実装
handle_event メソッドは、自身も $RECEIVE に関係する GFS Client イベントハンドラである
R ec e i v e _ H a n d l e r か ら呼 び出 され ます。W o r k e r が ha ndl e_w rit ere ad 実 装と
handle_close 実装のどちらを呼び出すかを決定します。
7.3.7 Worker::handle_writeread の実装
handle_writeread メソ ッド は handle_event か ら呼 び出 され ます。こ のメ ソッ ドは
writeread の処理のために thread_function を起動し、その後 Fw_Thread::detach を使って
スレッドを解放します。
7.3.8 Worker::handle_close の実装
handle_close メソッドは handle_event から呼び出され、delete this を呼び出します。
7.3.9 Worker::find_server の実装
find_server メソッドは thread_function から呼び出されます。このメソッドは Naming
Service を使って Account_Service の名前を解決します。
結果は
Account_Service::Account に限定され、cp_account に配置されます。
7.3.10 thread_function の実装
thread 関数は handle_writeread 実装から起動されます。この関数は次の動作を実行します。
□ 必要に応じて find_server を呼び出す。
□ 書込みデータを解釈して ISO8583 リクエストメッセージに変換する。
□ 適切な Account_Service メソッドを呼び出す。
□ メソッドの完了に基いて、ISO8583 応答を構築する。
□ イベントに返答する。
3-98
140418J
第 8 章 Event Service
第 8 章 Event Service
8.1 Event Service の概要
サブトピックス
□ OMG 標準
□ イベント通信
□ コンシューマとサプライヤ
□ Event Service と any データ型
□ イベントチャネルの作成と配置
通常、CORBA ベースのクライアントとサーバは、直接相互動作します。つまり、クライアントからの
リクエストは、サーバに直接送られ、サーバからクライアントへも直接応答が返されます。しかしこのよ
うな相互動作では、クライアントとサーバが同時に使用可能な状態になっている必要があるため、ときと
して柔軟性を欠きます。また、クライアントは、通信する相手のサーバを明示的に選択する必要がありま
す。このような制限をやわらげるには、別の形式の相互動作が必要になります。
NonStop DOM の Event Service は、クライアントとサーバの通信を緩和するための機構を提供していま
す。この機構は、次のような要件のアプリケーションの場合に便利です。
□ データを供給するオブジェクトと、データを消費するオブジェクトが、異なるレートで動作する。
□ サプライヤとコンシューマが、互いの ID を認知している必要がない。
□ 複数のサプライヤから、1 つまたは複数のコンシューマにデータを供給する必要がある。
□ 複数のコンシューマが、1 つまたは複数のサプライヤからデータを受け取ることができる。
このタイプのアプリケーションの 1 例として、監視用のファシリティが挙げられます。センサー監視機
能を提供するオブジェクトは、警告条件が発生したときに、イベントチャネルを使って信号を送ることが
できます。イベントチャネルのコンシューマとしては、修正作業を行う 1 つまたは複数のパーティに通知
を送るオブジェクトなどがあります。
8.1.1 OMG 標準
NonStop の Event Service は、OMG Event Service 仕様の実装です。このバージョンでは、型付けされて
いないイベントだけが使用できます。
8.1.2 イベント通信
NonStop DOM の Event Service は、1 つまたは複数のイベントチャネルを提供しており、緩和された通
信に使用することができます。イベントチャネルのユーザは、コンシューマとしての役割またはサプライ
ヤとしての役割を持ちます。イベントチャネルは、コンシューマとサプライヤの間の仲介として動作しま
す。次の図はその概念を示しています。
140418J
3-99
第 8 章 Event Service
図 3-11 サプライヤ、イベントチャネル、コンシューマの関係
サプライヤはイベントデータを作成し、コンシューマはイベントデータを処理します。サプライヤは、
標準 CORBA リクエストを使って、イベントデータをイベントチャネルに送ります。イベントチャネルも、
標準 CORBA リクエストを使って、イベントデータをコンシューマに送ります。これらのリクエストは、
SII (Static Invocation Interface) または DII (Dynamic Invocation Interfaces) を使って作成することができます。
イベント通信には、プッシュモデルとプルモデルの 2 つの方法があります。プッシュモデルでは、サプ
ライヤがイベントを作成し、供給するイベントがあるときにイベントをイベントチャネルに送ります。コ
ンシューマは、データがあれば受け取ります。プルモデルでは、コンシューマ側の都合でデータがリクエ
ストされ、要求に応じてサプライヤがイベントデータを作成します。サプライヤとコンシューマには、
「プッ
シュサプライヤ」、
「プッシュコンシューマ」、「プルサプライヤ」、「プルコンシューマ」という、4 つの役
割があります。アプリケーションでどの役割が使用されるかは、データ転送を開始するオブジェクトによっ
て異なります。これらの役割は、1 つのアプリケーションのコンポーネントごとに、どのような組み合わ
せでも使用できます。
イベントチャネルが仲介者として動作するため、サプライヤは、コンシューマ側でどの通信モデルが使
用されるかは認知していません。また、コンシューマも、サプライヤ側でどの通信モデルが使用されるか
は認知していません。このため、プッシュサプライヤがプルコンシューマにデータを供給したり、プルサ
プライヤがプッシュコンシューマにデータを供給したりすることができます。
コンシューマとサプライヤは、イベントチャネルを通じて間接的に相互動作します。コンシューマから
はイベントチャネルはイベントサプライヤとして認識され、サプライヤからはイベントチャネルはイベン
トコンシューマとして認識されます。イベントチャネルはコンシューマとサプライヤに対して「プロキシ」
オブジェクトを供給します。これらのプロキシオブジェクトは、コンシューマとサプライヤが直接相互動
作しているかのようなインタフェースを提供します。図 3-12 はこの概念を示しています。
3-100
140418J
第 8 章 Event Service
図 3-12 サプライヤ、コンシューマ、プロキシの関係
8.1.3 コンシューマとサプライヤ
このセクションでは、次のコンシューマとサプライヤの組み合わせについて説明します。
□ プッシュサプライヤとプッシュコンシューマ
□ プッシュサプライヤとプルコンシューマ
□ プルサプライヤとプルコンシューマ
□ プルサプライヤとプッシュコンシューマ
□ 複数のサプライヤと複数のコンシューマの組み合わせ
プッシュサプライヤとプッシュコンシューマ
プッシュサプライヤとプッシュコンシューマの組み合わせを図 3-13 に示します。
140418J
3-101
第 8 章 Event Service
図 3-13 プッシュサプライヤとプッシュコンシューマ
ここでは、プッシュサプライヤがイベントチャネル内でプロキシプッシュコンシューマと相互動作して
います。いくつかのプッシュコンシューマが登録されており、それぞれに対してプロキシプッシュサプラ
イヤがあります。プッシュサプライヤがイベントをプッシュすると、プロキシプッシュコンシューマがそ
れを受け取ります。イベントチャネルによって、各プロキシプッシュサプライヤがイベントを認識して、
対応するプッシュコンシューマに正しく供給します。この図から、1 つのサプライヤが、イベントチャネ
ルを通じて、複数のコンシューマと通信するようすがおわかりいただけるでしょう。
この組み合わせは、相互動作が 1 方向に行われるため、最も理解しやすいモデルです。この組み合わせ
は、Event Service を必要とする多くのアプリケーションで使用されます。
プッシュサプライヤとプルコンシューマ
プッシュサプライヤとプルコンシューマの組み合わせを図 3-14 に示します。
3-102
140418J
第 8 章 Event Service
図 3-14 プッシュサプライヤとプルコンシューマ
ここでは、プッシュサプライヤがイベントチャネル内でプロキシプッシュコンシューマと相互動作して
います。2 つのプルコンシューマが登録されており、それぞれに対してプロキシプルサプライヤがありま
す。プッシュサプライヤがイベントをプッシュすると、プロキシプッシュコンシューマがそれを受け取り
ます。イベントチャネルは、プルコンシューマからリクエスト ( プル ) があるまで、イベントを保管しま
す。イベントがないときにプルコンシューマがイベントをリクエストした場合は、イベントが届くまで待
機する必要があります。
プルサプライヤとプルコンシューマ
プルサプライヤとプルコンシューマの組み合わせを図 3-15 に示します。
140418J
3-103
第 8 章 Event Service
図 3-15 プルサプライヤとプルコンシューマ
ここでは、プルコンシューマがイベントチャネル内でプロキシプルサプライヤと相互動作しています。2
つのプルコンシューマが登録されており、それぞれに対してプロキシプルサプライヤがあります。プルコ
ンシューマがイベントを必要としたとき、プロキシプルサプライヤに「プル」リクエストを送ります。イ
ベントチャネルは、イベントが要求されたことをプルサプライヤに知らせます。プルサプライヤがイベン
トを供給すると、それがプロキシプルサプライヤに転送され、最初のプルリクエストに応えます。
プルサプライヤとプッシュコンシューマ
プルサプライヤとプッシュコンシューマの組み合わせを図 3-16 に示します。
3-104
140418J
第 8 章 Event Service
図 3-16 プルサプライヤとプッシュコンシューマ
ここでは、プルサプライヤがイベントチャネル内でプロキシプルコンシューマと相互動作しています。2
つのプッシュコンシューマが登録されており、それぞれに対してプロキシプッシュサプライヤがあります。
この組み合わせはあまり一般的ではありません。この場合は、プルサプライヤもプッシュコンシューマも
相互動作を開始しません。イベントチャネルが開始します。プロキシプルコンシューマは、プルサプライ
ヤに定期的にプルリクエストを行います。イベントが発生したときに、プロキシプッシュサプライヤがそ
れをプッシュコンシューマにプッシュします。
複数のサプライヤと複数のコンシューマの組み合わせ
複数のサプライヤと複数のコンシューマの組み合わせも考えられます。プッシュサプライヤ、プルサプ
ライヤ、プッシュコンシューマ、プルコンシューマのどんな組み合わせも可能です。次の図は、これら 4
者が 1 つずつ存在する組み合わせの例です。
140418J
3-105
第 8 章 Event Service
図 3-17 複数のサプライヤと複数のコンシューマの組み合わせ
ここではさまざまな相互動作が考えられます。プッシュサプライヤは、イベントを持っているときにい
つでも供給することができます。供給されたイベントは、すぐにプッシュコンシューマにプッシュされま
す。プルコンシューマは必要に応じてイベントをリクエストすることができます。たとえばプッシュサプ
ライヤ側でイベントが供給できれば、プルリクエストは満たされます。供給できない場合は、プルサプラ
イヤに対してプルリクエストが送られます。プルサプライヤがイベントを供給すると、プルリクエストが
満たされ、プッシュコンシューマにもプッシュされます。
複数のプルサプライヤがある場合にプルリクエストが 1 つ送られると、すべてのプルサプライヤがリク
エストを受け取ります。最初にイベントを供給したサプライヤがもとのプルリクエストを満たします。そ
の後供給されたほかのイベントは、必要になるまで保管されます。
3-106
140418J
第 8 章 Event Service
8.1.4 Event Service と any データ型
サプライヤからイベントチャネルに送られるイベントデータと、イベントチャネルからコンシューマに
送られるイベントデータは、any データ型にカプセル化されています。このデータ型に保管される情報は、
必要に応じて、単純にも複雑にもできます。名前が示すように、any データ型は、どのような型のデータ
「CORBA::Any」を参照してください。
でも表すことができます。any データ型の使用については、
サプライヤとコンシューマは、イベントデータに保管された情報の内容について決定する必要がありま
す。イベントチャネルは、サプライヤとコンシューマの間でデータを渡すだけで、データの解釈や変換は
行いません。
8.1.5 イベントチャネルの作成と配置
サプライヤやコンシューマがイベントチャネルを使用するには、まずイベントチャネルが作成されてい
る必要があります。このセクションでは、イベントチャネルの作成に使用される NonStop DOM の Event
Channel Factory ファシリティと、その使用方法について説明します。また、Name Service を使ってイベン
トチャネルオブジェクト参照を保管したり取り込んだりする方法についても説明します。
Event Channel Factory
NonStop DOM は、イベントチャネル作成のための factory インタフェースを提供しています。次に示す
このインタフェースは、CosEventChannelAdmin.idl ファイル内にあります。
例 1. Naming Service のルートコンテキスト取得
interface EventChannelFactory
{
EventChannel create();
};
イベントチャネルアプリケーションを作成するには、EventChannelFactory オブジェクト上の
create( ) メソッドを呼び出します。EventChannel オブジェクトが新しく作成され、create(
) から返されます。
NonStop DOM Event Channel の factory オブジェクトの取得
通常、NonStop DOM Event Channel の factory オブジェクトは、Naming Service から取得します。後述
するように、この factory オブジェクトは、NonStop DOM の構成中に Naming Service に保管されます。
factory オブジェクト参照は、次のようにして Naming Service から取り込まれます。
まず、NonStop DOM Naming Service のルートネームコンテキストを取り込みます。
例 2. Naming Service のルートコンテキストの取得
CORBA::Object_var CORBAObject;
CosNaming::NamingContext_var RootNameContext;
CORBAObject = orb->
resolve_initial_references("NameService");
RootNameContext =
140418J
3-107
第 8 章 Event Service
CosNaming::NamingContext::_narrow(CORBAObject);
次に、factory オブジェクトが取り込まれます。factory オブジェクト参照の取得には、Naming Service の
resolve( ) メソッドが使用されます。factory オブジェクトは、EventService ネーミングコンテ
キスト内に保管されています。識別子は NSDOM ES で、種類は EventChannelFactory です。
例 3. Event Channel Factory の検索
CosNaming::Name name;
name.length(2);
name[0].id
= "EventService";
name[0].kind = "";
name[1].id
= "NSDOM ES";
name[1].kind = "EventChannelFactory";
CORBAObject = RootNameContext->resolve(name);
最後に、factory オブジェクト参照は正しい型のオブジェクトに限定される必要があります。これは、
resolve( ) が汎用 CORBA オブジェクトを返すためです。汎用オブジェクトは、factory オブジェク
トにキャストしないと使用できません。
例 4. オブジェクト参照を、Event Channel factory オブジェクトに限定する
CosEventChannelAdmin::EventChannelFactory_var Factory;
Factory = CosEventChannelAdmin::EventChannelFactory::
_narrow( CORBAObject );
Event Channel の作成
Event Channel factory オブジェクトが使用可能になった後は、簡単に新しいイベントチャネルを作成す
ることができます。
例 5. Event Channel factory の使用、Event Channel の作成
CosEventChannelAdmin::EventChannel_var EventChannel;
EventChannel = Factory->create();
Event Channel の保管
複数のサプライヤとコンシューマが共用するイベントチャネルは、1 度作成するだけです。イベントチャ
ネルの作成者は、その後、そのイベントチャネルを使用する必要のあるほかのプロセスに対して、イベン
トチャネルの存在を知らせる必要があります。イベントチャネルオブジェクト参照の保管には、Naming
Service が理想的な場所です。次にその方法を示します。
例 6. Naming Context の検索
name.length(1);
name[0].id
= "Application Event Channels";
name[0].kind = "";
3-108
140418J
第 8 章 Event Service
CosNaming::NamingContext_var EventChannelsContext;
CORBAObject = RootNameContext->resolve(name);
EventChannelsContext =
CosNaming::NamingContext::_narrow(CORBAObject);
// Enter name for newly created event channel into
// Naming Service so other users of the channel can find it.
name.length(1);
name[0].id
= "commonEventChannel";
name[0].kind = "EventChannel";
EventChannelsContext->rebind(name, EventChannel);
ここでは、Application
Event Channels というネーミングコンテキストがすでにあると仮
) メソッドを使って見つけます。こ
定しています。このコンテキストは、Naming Service の resolve(
のネーミングコンテキストを使用して、新しく作成されたイベントチャネルをコンテキスト内にバインド
します。名前は commonEventChannel で、種類は EventChannel です。同じ名前でネーミング
コンテキストにバインドされていた既存のイベントチャネルは、rebind(
) メソッドを使って取り外し
ます。
Event Channel の取込み
イベントチャネルオブジェクト参照がいったん Naming Service に保管されれば、アプリケーションプロ
グラムはそれを取り込んで使用することができます。次に示すように、オブジェクト参照の取込み方法は、
保管方法と同様です。
例 7. Event Channel の検索
name.length(2);
name[0].id
= "Application Event Channels";
name[0].kind = "";
name[1].id
= "commonEventChannel";
name[1].kind = "EventChannel";
CORBAObject = RootNameContext->resolve(name);
// Narrow object reference to an Event Channel object
EventChannel = CosEventChannelAdmin::EventChannel::
_narrow( CORBAObject );
イベントチャネルオブジェクト参照を取り込んだら、すぐに使用することができます。後のセクション
で、アプリケーションがどのようにイベントチャネルを使用するか説明します。
使用時の注意点
ここまでのセクションでは、イベントチャネル factory を見つけ、イベントチャネルを作成し、以前作成
したイベントチャネルを見つけるためのコードを紹介してきました。アプリケーション環境のコンテキス
トでは、これらの動作は、1 つまたは複数のプロセッサによって実行されます。
アプリケーション環境では、前述のように特定のプログラムがイベントチャネルを作成し、合意した名
前を使って Naming Service に登録します。サプライヤおよびコンシューマとして動作するほかのプロセス
はその後 Naming Service に問い合せて、イベントチャネルオブジェクトを取得します。これは、イベント
140418J
3-109
第 8 章 Event Service
チャネルの作成と使用を管理する方法の 1 つです。
イベントチャネルの作成と使用を管理するには、別の方法もあります。たとえば、特定のサプライヤオブ
ジェクトがイベントチャネルを作成することができます。ほかのコンシューマオブジェクトおよびサプライ
ヤオブジェクトはその後、作成されたチャネルを使用します。また、イベントチャネルオブジェクト参照は、
Naming Service に保管される必要はありません。たとえば、イベントチャネルの作成者が、
object_to_string を使用してオブジェクト参照を外部形式に変換し、ファイルに書き込む、などと
いうことが可能です。ほかのアプリケーションはファイルを読み込んで、string_to_object を
使って内部形式に変換し、使用することができます。
イベントチャネルオブジェクトは、非永続オブジェクトです。作成後、そのオブジェクトをホストする
Event Service プロセスが動作中である限り有効です。プロセスがダウンまたはリスタートされると、イベ
ントチャネルオブジェクトも無効になり、再度作成する必要があります。
イベントチャネルオブジェクト参照が Naming Service に保管される場合に、問題が発生する可能性があ
ります。イベントチャネルオブジェクトが無効になると、Naming Service 内のオブジェクト参照も失効し
ます。失効したオブジェクト参照をサプライヤまたはコンシューマが使用しようとすると、エラーが発生
します。このような状況を防ぐようにアプリケーション環境を構成してください。1 つの方法は、アプリ
ケーション環境の起動シーケンスによって、イベントチャネルオブジェクト参照の再作成を確実にするこ
とです。もう 1 つの方法は、サプライヤまたはコンシューマが失効したオブジェクト参照を認識し、再作
成するための手順をとるようにすることです。
複数のイベントチャネル
これまでの例では、単一のイベントチャネルのケースを紹介してきました。しかし実際のアプリケーショ
ンでは、複数のイベントチャネルを必要とする場合があります。複数のイベントチャネルを使用するのは
次のような場合です。
□ 同じ一群のサプライヤとコンシューマの間で、異なるタイプのイベントを通信する場合
□ 別の一群のサプライヤとコンシューマがイベントを通信する場合
□ 追加機能を提供する場合
□ フィルタなどのために、イベントチャネルを段階的に実行する場合
複数のイベントチャネルは、単一のイベントチャネルと同じように動作します。単一のプロセスが複数
のイベントチャネルを使用する場合もあります。NonStop DOM Event Service の構成によって、factory は、
同じプロセス内で、既存のイベントチャネルとして新しいイベントチャネルを作成するか、または新しい
プロセス内に作成することができます。
また、複数の Event Service サーバプールを構成することによって、複数の異なる Event Service factory
が作成されます。これにより、Event Service が集中的に使用されることによって生じる処理の負荷を柔軟
に分散することができます。
3-110
140418J
第 8 章 Event Service
Event Service の構成オプション
イベントチャネル factory 自体は、通常 Event Service プロセス起動中に作成されます。Event Service の
デフォルト構成によって、Event Channel factory オブジェクトが NonStop DOM Naming Service に登録され
ます。登録時の ID は NSDOM
ES、種類は EventChannelFactory です。この factory オブジェク
トは NonStop DOM ルートネーミングコンテキスト内の EventService ネーミングコンテキスト内に
バインドされます。イベントチャネルオブジェクトと違い、イベントチャネル factory オブジェクトは永続
オブジェクトです。つまり、Event Service がリスタートされても有効なままです。
NonStop DOM Event Service は、起動時に、イベントチャネル factory でなく、イベントチャネルを作成
するように構成することもできます。単一のイベントチャネルしか必要ない場合には、この構成が適切で
しょう。このように構成する利点は、イベントチャネルサプライヤとコンシューマが、イベントチャネル
を作成する必要なく、すぐにイベントチャネルを使用できることです。この構成が指定された場合は、イ
NSDOM ES という ID と EventChannel という種類で、Naming
Service に登録されます。このイベントチャネルオブジェクトは、NonStop DOM ルートネーミングコンテ
ベントチャネルオブジェクトは
キスト内の EventService ネーミングコンテキスト内にバインドされます。
Event Service の初期構成の変更方法について詳しくは、
『第 2 部 NonStop™ DOM 管理者ガイド』を参照
してください。
8.2 Event Service の使用
サブトピックス
□ プッシュコンシューマの実装
□ プルコンシューマの実装
□ プッシュサプライヤの実装
□ プルサプライヤの実装
イベントチャネルがいったん作成されれば、それを使用することができます。イベントチャネルを使用
するプロセスの役割によって、準備とプロセスの手順は異なります。このセクションでは、イベントの送
信や受信の前に必要な準備と、イベントプロセスの動作について概説します。
8.2.1 プッシュコンシューマの実装
プッシュコンシューマは PushConsumer インタフェースを実装しており、イベントチャネルからメ
ソ ッド 呼出 しを 受け 取る こと がで きま す。PushConsumer イ ンタ フェ ース は、CosEvent
Comm.idl ファイル内で指定されています。PushConsumer から導出されるクラスは、push( )
および disconnect_push_consumer( ) メソッドの実装を提供します。プッシュコンシューマ
プロセスは、PushConsumer オブジェクトをホストするサーバントを実装します。
準備
実行時に、次の動作が行われます。
1. 使用するイベントチャネルオブジェクトを見つけます。
2. オ ブ ジ ェ ク ト 上 の f o r _ c o n s u m e r s (
140418J
) 操 作 を 呼 び 出 し ま す 。こ の 操 作 に よ っ
3-111
第 8 章 Event Service
て 、 ConsumerAdmin オブジェクトが返されます。
3. こ こ で は プ ッ シ ュ モ デ ル を 使 用 し て い る た め 、C o n s u m e r A d m i n オ ブ ジ ェ ク ト 上
の o b t a i n _ p u s h _ s u p p l i e r ( ) 操 作 を 呼 び 出 し ま す 。こ の 操 作 に よ っ て
ProxyPushSupplier オブジェクトが返されます。
4. ProxyPushSupplier オブジェクトを使用して、connect_push_consumer( ) 操作を呼
Pu s h Co n s u me r イ ン タ フ ェ ー ス で あ る
PushConsumer オブジェクトが、引数として使用されます。
び 出 し ま す 。こ の 操 作 で は 、以 前 作 成 し た
プロセス
1. push( )
新しいイベントが使用可能になると、イベントチャネルがこのメソッドを呼び出します。
2. disconnect_push_consumer( )
イベントチャネルが接続解除する必要があるときに、こ
のメソッドを起動します。プロセスは、正しいシャットダウンのための手順を実行することができます。
8.2.2 プルコンシューマの実装
プルコンシューマは、PullConsumer インタフェースを実装することも、単にイベントチャネルクラ
イアントとして動作することもできます。PullConsumer インタフェースを実装している場合は、
disconnect_pull_consumer( ) メソッド呼出しを受け取ることができます。PullConsumer
インタフェースは CosEventComm.idl ファイル内で指定されています。PullConsumer から導
出されるクラスは、disconnect_pull_consumer( ) メソッドの実装を提供します。プルコン
シューマプロセスは、PullConsumer オブジェクトをホストするサーバントを実装します。
プ ル コ ン シ ュ ー マ が ク ラ イ ア ン ト と し て だ け 動 作 す る 場 合 は、イ ベ ン ト チ ャ ネ ル か ら
disconnect_pull_consumer( ) リクエストを受け取ることはできません。しかし、イベント
チャネルからイベントをプルすることはできます。
準備
実行時に、次の動作が行われます。
1. 使用するイベントチャネルオブジェクトを見つけます。
2. オ ブジ ェク ト上 の f o r _ c o nsumers(
) 操 作を 呼び 出し ます 。こ の操 作に よっ て、
ConsumerAdmin オブジェクトが返されます。
3. こ こ で は プ ル モ デ ル を 使 用 し て い る た め 、 C o n s u m e r A d m i n オ ブ ジ ェ ク ト 上 の
obtain_pull_supplier( ) 操作 を呼 び出 しま す。この 操作 によ って ProxyPull
Supplier オブジェクトが返されます。
4. ProxyPullSupplier オブジェクトを使用して、connect_pull_consumer( ) 操作を呼
び出します。この操作では、PullConsumer オブジェクトが引数として使用されます。イベント
チャ ネルがプルコンシューマを切断する必 要がある際に通知を受け取るには、後述す るように
P ull Cons ume r イ ン タ フ ェ ー ス を 供 給 す る 必 要 が あ り ま す。通 知 が 必 要 な い 場 合 は、
connect_pull_consumer( ) メソッドの引数として NULL を渡します。
プロセス
1. 新しいイベントが必要になったときに、ProxyPullSupplier の pull( ) メソッドを呼び出し
3-112
140418J
第 8 章 Event Service
ます。pull(
) メソッドは、新しいイベントが使用可能な場合にのみ返されます。
2. イ ベ ン ト を 取 得 し た い と き、ま た は イ ベ ン ト が 使 用 可 能 か ど う か 調 べ た い と き は、
ProxyPullSupplier の try_pull( ) メソッドを呼び出します。try_pull( ) メソッド
は、イベントが使用可能かどうかの答えを返します。イベントが使用可能な場合は、try_pull( )
はイベントも返します。
3. P u l l C o n s u m e r イ ン タ フ ェ ー ス が 実 装 さ れ て い る 場 合 は 、 イ ベ ン ト チ ャ ネ ル が
disconnect_pull_consumer( ) メソッドを呼び出すことができます。このメソッドが呼び
出された後は、プルコンシューマは、プルリクエストや try_pull( ) リクエストを送ることがで
きません。
8.2.3 プッシュサプライヤの実装
プッシュサプライヤは、PushSupplier インタフェースを実装することも、単にイベントチャネル
クライアントとして動作することもできます。PushSupplier インタフェースを実装している場合は、
d i s c o n n e c t _ p u s h _ s u p p l i e r ( ) メ ソ ッ ド 呼 出 し を 受 け 取 る こ と が で き ま す。
PushSupplier イン タフ ェー スは、CosEventComm.idl ファ イル 内で 指定 され てい ます。
PushSupplier から導出されるクラスは、disconnect_pull_consumer( ) メソッドの実装
を提供します。プッシュサプライヤプロセスは、PushSupplier オブジェクトをホストするサーバン
トを実装します。
プ ッ シ ュ サ プ ラ イ ヤ が ク ラ イ ア ン ト と し て だ け 動 作 す る 場 合 は、イ ベ ン ト チ ャ ネ ル か ら
disconnect_push_supplier( ) リクエストを受け取ることはできません。しかし、イベント
チャネルにイベントをプッシュすることはできます。
準備
実行時に、次の動作が行われます。
1. 使用するイベントチャネルオブジェクトを見つけます。
2. オ ブジ ェク ト上 の f o r _ suppliers(
) 操 作を 呼び 出し ます 。こ の操 作に よっ て、
SupplierAdmin オブジェクトが返されます。
3. こ こ で は プ ッ シ ュ モ デ ル を 使 用 し て い る た め 、 S u p p l i e r A d m i n オ ブ ジ ェ ク ト 上 の
o b t a i n _ p u s h _ c o n s u m e r ( ) 操 作 を 呼 び 出 し ま す。こ の 操 作 に よ っ て
ProxyPushConsumer オブジェクトが返されます。
4. ProxyPushConsumer オブジェクトを使用して、connect_push_supplier( ) 操作を呼
び出します。この操作では、PushSupplier オブジェクトが引数として使用されます。イベント
チ ャ ネ ル が サ プ ラ イ ヤ を 切 断 す る 必 要 が あ る 際 に 通 知 を 受 け 取 る に は、後 述 す る よ う に
PushSupplier インタフェースを供給する必要があります。通知が必要ない場合は、connect_
push_supplier( ) の引数として NULL を渡します。
プロセス
1. イベントをプッシュするには、まず any 変数内でイベントを構築します。any 変数は、イベントチャネ
ルに送信する任意のデータ構造を記述することができます。その後、ProxyPushConsumer 上で
プッシュ操作を呼び出します。
140418J
3-113
第 8 章 Event Service
2. P u s h C o n s u m e r イ ン タ フ ェ ー ス が 実 装 さ れ て い る 場 合 は 、 イ ベ ン ト チ ャ ネ ル が
disconnect_push_supplier( ) メソッドを呼び出すことができます。このメソッドが呼び
出された後は、プッシュサプライヤはイベントチャネルにイベントをプッシュすることができません。
8.2.4 プルサプライヤの実装
プルサプライヤは PullSupplier インタフェースを実装しており、イベントチャネルからメソッド
呼出しを受け取ることができます。PullSupplier インタフェースは、CosEventComm.idl ファ
イル内で指定されています。PullSupplier から導出されるクラスは、pull(
)、try_pull( )、
disconnect_pull_supplier( ) メソッドの実装を提供します。プルサプライヤプロセ
スは、PullSupplier オブジェクトをホストするサーバントを実装します。
および
準備
実行時に、次の動作が行われます。
1. 使用するイベントチャネルオブジェクトを見つけます。
2. オブジェクト上の for_suppliers(
Admin オブジェクトが返されます。
) 操作を呼び出します。この操作によって、Supplier
3. ここではプルモデルを使用しているため、SupplierAdmin オブジェクト上の obtain_pull_
consumer( ) 操作を呼び出します。この操作によって ProxyPullConsumer オブジェクトが
返されます。
4. ProxyPullConsumer オブジェクトを使用して、connect_pull_supplier( ) 操作を呼
P ull Sup pli er
PullSupplier オブジェクトが引数として使用されます。
び 出し ます。こ の操 作で は、以前 作成 した
イン タフ ェー スで ある
プロセス
1. pull( )。イベントが必要になると、イベントチャネルがこのメソッドを呼び出します。any 変数内
にイベントを構築する必要があります。イベントは、pull(
) メソッドの値として返されます。
try_pull( ) リクエストが届くと、try_pull( ) メソッドはイベントを供給するか、または
使用可能なイベントがないことを知らせます。
2. try_pull( )。イベントチャネルは、イベントが使用可能かどうか調べたいときにこのメソッドを
呼び出します。イベントが使用可能な場合は、try_pull( ) メソッドの値として返され、has_event
変数が真に設定されています。使用可能なイベントがない場合は、has_event 変数が偽に設定され、
try_pull( ) メソッドから、空の any 変数が返されます。
3. disconnect_pull_supplier( )。イベントチャネルは、プルサプライヤがその後プルリク
エストや try_pull( ) リクエストを受け取らないことを示すために、このメソッドを呼び出しま
す。
3-114
140418J
第 8 章 Event Service
8.3 Event Service 使用法の例
サブトピックス
□ プッシュサプライヤ
□ プッシュコンシューマ
□ 追加管理インタフェース
この例では、Event Service 機能のサブセットが紹介されています。ここでは、
「プッシュサプライヤ」と
「プッシュコンシューマ」を構築します。
「プッシュサプライヤ」はイベントを作成し、自分の都合でイベ
ントチャネルに供給します。イベントチャネルがサプライヤからイベントを受け取ると、そのイベントを
「プッシュコンシューマ」に供給 ( プッシュ ) します。
8.3.1 プッシュサプライヤ
PushSupplier プログラムは、イベントチャネルにイベントを供給する役割を持ちます。この例で
は、「イベント」は、ユーザが入力した単純な数字です。一般に、
「イベント」とは、アプリケーションの
設計者が決めた任意のデータです。説明のため、ここでは単純化してあります。PushSupplier プロ
グラムは、Event Service のクライアントとして実装されています。このプログラムはプッシュサプライヤ
インタフェースを実装していませんので、イベントチャネルは disconnect_push_supplier(
)
メソッドを呼び出すことはできません。また、エラー検査も最小限しか行っていません。この例のもとと
なる NonStop DOM のプログラム例では、より詳細なエラー検査が行われます。実際にアプリケーション
を作成する場合は、問題の発生を防ぐため、詳細にエラー検査を行ってください。プッシュサプライヤプ
ログラムは、クライアントプログラムの通常の方法で開始されます。最初の手順は、ORB を初期化し、ルー
トネーミングコンテキストのオブジェクト参照を取得することです。
例 1. ORB の初期化とオブジェクト参照の取得
int main(int argc, char *argv[])
{
// Initialize the ORB
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
// Get root context for Naming Service
CORBAObject = orb->
resolve_initial_references("NameService");
RootNameContext =
CosNaming::NamingContext::_narrow(CORBAObject);
Naming Service 内でイベントチャネルが検索されます。
次に、
ここでは、
別のプログラム (RegisterChannel)
がすでにチャネルを作成し、Naming Service 内に配置したと仮定しています。
例 2. イベントチャネルの検索
name.length(2);
name[0].id = "NSDOM-Samples";
name[0].kind = "";
140418J
3-115
第 8 章 Event Service
name[1].id = "SampleEventChannel";
name[1].kind = "EventChannel";
CORBAObject = RootNameContext->resolve(name);
// Narrow object reference to an Event Channel object
EventChannel = CosEventChannelAdmin::EventChannel::
_narrow( CORBAObject );
イベントチャネルを使って、SupplierAdmin オブジェクトを取得します。
例 3. SupplierAdmin オブジェクトの取得
CosEventChannelAdmin::SupplierAdmin_var SupplierAdminObj;
SupplierAdminObj = EventChannel->for_suppliers();
SupplierAdmin オブジェクトはその後 ProsxyPushConsumer の取得に使われます。
例 4. ProxyPushConsumer オブジェクトの取得
CosEventChannelAdmin::ProxyPushConsumer_var
ProxyPushConsumer;
ProxyPushConsumer = SupplierAdminObj->
obtain_push_consumer();
ProxyPushConsumer オブジェクトを使って、イベントのサプライヤとして登録します。
例 5. イベントサプライヤとしての登録
CosEventComm::PushSupplier_ptr PushSupplier=NULL;
ProxyPushConsumer->connect_push_supplier(PushSupplier);
ここで、イベントを供給する準備ができました。次のループは、ユーザからの数字入力を要求します。
ユーザが数字を入力すると、any 変数にパッケージ化されます。any 変数はその後、イベントとしてプッ
シュされます。この動作は、空行が入力されるまで続きます。
例 6. ユーザ入力の要求
CORBA::Long aLong;
CORBA::Any anyLong;
const unsigned int lineSize = 1024;
char buffer[lineSize];
cout << "Enter number to be pushed to event channel"
<< endl;
cout << "> " << flush;
while (cin.getline(buffer, lineSize))
{
if (strlen(buffer) == 0) break;
3-116
140418J
第 8 章 Event Service
aLong = strtol(buffer, NULL, 10);
anyLong <<= aLong;
ProxyPushConsumer->push(anyLong);
cout << "> " << flush;
}
最後に、接続を解除することを ProxyPushConsumer に伝えます。
例 7. 接続解除
ProxyPushConsumer->disconnect_push_consumer();
return 0;
}
8.3.2 プッシュコンシューマ
PushConsumer プログラムは、イベントチャネルを通じて PushSupplier が作成したイベント
を 消 費 す る 役 割 を 持 ち ま す。こ の 例 で は、
「イ ベ ン ト」は、ユ ー ザ が 入 力 し た 単 純 な 数 字 で す。
PushConsumer プログラムは、単にそのイベントを表示します。
PushConsumer は、CosEventComm.idl で定義された PushConsumer インタフェースを
実装します。
例 8. PushConsumer インタフェースの実装
interface PushConsumer {
void push (in any data) raises(Disconnected);
void disconnect_push_consumer();
};
IDL コンパイラは、スケルトンサーバ側のヘッダファイルと実装を作成します。PushConsumer プ
ログラムは、メソッドの具体的な実装を提供する必要があります。最初の手順は実装ヘッダファイルを提
供することです。
例 9. ヘッダファイルの実装
#include <CosEventComm_server.h>
class PushConsumer_impl: public
POA_CosEventComm_PushConsumer
{
public:
PushConsumer_impl() {}
~PushConsumer_impl() {}
void push(const CORBA::Any& data,
CORBA::Environment &pr_env);
void disconnect_push_consumer(
CORBA::Environment &pr_env);
140418J
3-117
第 8 章 Event Service
};
ここでは、IDL コンパイラによって作成された実装ヘッダファイルを含むところから開始しています。
PushConsumer_impl クラスが定義されています。このクラスは、サーバ実装の基本クラス
定 義 を 含 む POA_CosEventComm_PushConsumer か ら継 承 し て い ま す。
PushConsumer_impl クラス内では、実装する必要のある 2 つのメソッドが宣言されています。
push( ) と disconnect_push_consumer( ) です。
その後
次に、PushConsumer の C++ 実装に目を向けてみましょう。push(
) メソッドの実装を例 10 に
示します。
例 10. push( ) メソッドの実装
void PushConsumer_impl::push(const CORBA::Any& data,
CORBA::Environment &pr_env)
{
cout << "Invoked PushConsumer_impl::push, ";
// Display the "any" data
if ((data.type())->kind() == CORBA::tk_long)
{
CORBA::Long aLong;
if (data >>= aLong); else aLong = 0;
cout << "Long value=" << aLong << endl;
}
else
cout << "Unknown any data received" << endl;
}
「プッシュ」リクエストが届くと、push(
) メソッドが標準出力で情報を表示します。any データ変数
にカプセル化された値が抽出され、表示されます。簡単のため、disconnect_push_consumer(
) メソッドの実装は、単にそれが呼び出されたことを示します。実際の実装では、PushConsumer を
正しくシャットダウンするための動作を実行することができます。
例 11. disconnect_push_consumer( ) メソッドの実装
void PushConsumer_impl::disconnect_push_consumer
(CORBA::Environment &pr_env)
{
cout << "PushConsumer_impl::disconnect_push_consumer "
"was called." << endl;
}
PushConsumer 実装のメインプログラムは、リクエスト処理の環境を設定します。最初の手順は、
ORB を初期化し、ルート POA のオブジェクト参照を取得することです。
例 12. ORB の初期化とオブジェクト参照の取得
int main(int argc, char *argv[])
{
// Initialize the ORB
CORBA::ORB_ptr orb = CORBA::ORB_init(argc, argv);
3-118
140418J
第 8 章 Event Service
// Get object reference for POA Manager
CORBAObject = orb->resolve_initial_references("RootPOA");
RootPOA = PortableServer::POA::_narrow(CORBAObject);
PushConsumer_impl オブジェクトのインスタンスが作成されます。これは、イベントチャネルか
ら届くリクエストを処理するオブジェクトです。POA は、このオブジェクトを有効化するよう指示されま
す。有効化された後は、オブジェクトがリクエストを処理することができます。
例 13. リクエストの処理
PushConsumer_impl *PushConsumer = new PushConsumer_impl;
PortableServer::ObjectId_ptr oid =
RootPOA->activate_object(PushConsumer);
delete oid;
次 に 、 N a m i n g S e r v i c e 内 で イ ベ ン ト チ ャ ネ ル が 検 索 さ れ ま す。 こ こ で は、 別 の プ ロ グ ラ ム
(RegisterChannel) がすでにチャネルを作成し、Naming Service 内に配置したと仮定しています。
例 14. Naming Service 内でのイベントチャネルの検索
// Get root context for Naming Service
CORBAObject = orb->
resolve_initial_references("NameService");
RootNameContext =
CosNaming::NamingContext::_narrow(CORBAObject);
// Find the Event Channel
name.length(2);
name[0].id = "NSDOM-Samples";
name[0].kind = "";
name[1].id = "SampleEventChannel";
name[1].kind = "EventChannel";
CORBAObject = RootNameContext->resolve(name);
// Narrow object reference to an Event Channel object
EventChannel = CosEventChannelAdmin::EventChannel::
_narrow( CORBAObject );
イベントチャネルを使って、ConsumerAdmin オブジェクトを取得します。
例 15. ConsumerAdmin オブジェクトの取得
CosEventChannelAdmin::ConsumerAdmin_var ConsumerAdminObj;
ConsumerAdminObj = EventChannel->for_consumers();
次に ProxyPushSupplier の取得のために ConsumerAdmin が使用されます。
例 16. ProxyPushSupplier 取得のためのオブジェクト使用
140418J
3-119
第 8 章 Event Service
CosEventChannelAdmin::ProxyPushSupplier_var
ProxyPushSupplier;
ProxyPushSupplier = ConsumerAdminObj->
obtain_push_supplier();
ProxyPushSupplier オブジェクトを使って、イベントのコンシューマとして登録します。
例 17. イベントコンシューマとしての登録
ProxyPushSupplier->connect_push_consumer(PushConsumer);
ここ では、以 前作 成さ れ た PushConsumer オ ブジ ェク トが、引 数と して 供給 され てい ます。
P us h C o n s u m e r オブ ジェ クト 参照 を Pr oxy Pus hSup pli er に 供給 する こと によ り、
PushConsumer オブジェクト上のメソッドを呼び出せるようになります。
最後の手順は、POA を有効化し、リクエスト処理を開始できるようにすることです。
例 18. リクエスト処理の開始
RootPOA->the_POAManager()->activate();
orb->run();
8.3.3 追加管理インタフェース
NonStop DOM Event Service は、イベントチャネルの管理用にいくつかのインタフェースを提供してい
ます。次の宣言は CosEventChannelAdmin.idl ファイル内にあります。
例 19. CosEventChannelAdmin.idl 内の宣言
interface EventChannel
{
struct EventChannelStats
{
unsigned long PushConsumers;
unsigned long PushSuppliers;
unsigned long PullConsumers;
unsigned long PullSuppliers;
unsigned long IdlePullSuppliers;
unsigned long StoredEvents;
unsigned long TotalEvents;
};
struct EventChannelPolicies
{
unsigned long PullDelay;
unsigned long OldEventThreshold;
};
void get_statistics(out EventChannelStats
Statistics);
void set_trace(in boolean OnOff);
void get_policies(out EventChannelPolicies Policies);
void set_policies(in EventChannelPolicies Policies);
};
3-120
140418J
第 8 章 Event Service
イベントチャネルオブジェクト上のさまざまなメソッドを起動することにより、管理プログラムが、プ
ロセスのポリシーに影響を与えたり、イベントチャネルの現在の状態に関する統計を取得することができ
ます。
140418J
3-121
第 9 章 マイナーコード
第 9 章マイナーコード
9.1 General Minor Codes
9.1.1 一般マイナーコード値
500 - MINOR_BAD_ENUM_RANGE
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。マーシャル化された列挙
値が、列挙型の正しい値でない場合に発生します。
501 - MINOR_SEQ_CONSTRUCTOR
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンスコンストラク
タが、シーケンス要素のメモリ取得に失敗しました。
502 - MINOR_SEQ_COPY_CONSTRUCTOR
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンスコピーコンス
トラクタが、シーケンス要素のメモリ取得に失敗しました。
503 - MINOR_SEQ_BOUND
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。このマイナーコードは、登
録されたシーケンスが有限シーケンスに宣言された範囲よりも長い場合に生成されます。
504 - MINOR_SEQ_BUFFER
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンスの length(
)
メソッドが、シーケンス要素のメモリ取得に失敗しました。
505 - MINOR_SEQ_INDEX
こ の マ イ ナ ー コ ー ド は、 BAD_PARAM シ ス テ ム 例 外 に 関 連 し て 発 生 し ま す。シ ー ケ ン ス の
operator( ) メソッドが、存在しない要素を返すよう要求されました。
506 - MINOR_SEQ_ASSIGNMENT
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンス割当て演算子
が、シーケンス要素のメモリ取得に失敗しました。
140418J
3-123
第 9 章 マイナーコード
508 - MINOR_SEQ_MARSHAL
このマイナーコードは、MARSHAL システム例外に関連して発生します。このマイナーコードは、マー
シャル化されたシーケンスの復元中に、シーケンス範囲より長いものが検出されたことを示します。
このような状況が発生するのは、次のような場合です。
□ マーシャル化した側に、IDL 宣言の矛盾がある場合
□ マーシャル化されたシーケンスが正しくなかった場合
□ シーケンスが壊れている場合
509 - MINOR_SEQ_DEMARSHAL
このマイナーコードは、MARSHAL システム例外に関連して発生します。このマイナーコードは、シス
テムが、マーシャル化されたシーケンスを復元したとき必要なメモリを割り当てられなかったことを示し
ます。プログラムで使用可能なメモリ ( ヒープ ) がなかったか、またはシーケンスサイズが正しくありませ
ん。ORB が、壊れたバッファか、または予期しない方式でマーシャル化されたバッファを復元しようとし
た場合に発生します。
510 - MINOR_STR_SEQ_CONSTRUCTOR
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンスコンストラク
タが、文字列シーケンスのためのメモリ取得に失敗しました。
511 - MINOR_STR_SEQ_INDEX
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。operator(
) メソッ
ドが、存在しない文字列シーケンスを返すよう要求されました。
512 - MINOR_STR_SEQ_ASSIGNMENT
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンス割当て演算子
が、文字列シーケンスのためのメモリ取得に失敗しました。
513 - MINOR_OBJ_SEQ_CONSTRUCTOR
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンスコンストラク
タが、オブジェクト参照シーケンスのためのメモリ取得に失敗しました。
514 - MINOR_OBJ_SEQ_INDEX
こ の マ イ ナ ー コ ー ド は、 BAD_PARAM シ ス テ ム 例 外 に 関 連 し て 発 生 し ま す。シ ー ケ ン ス の
operator( ) メソッドが、存在しないオブジェクト参照のシーケンスを返すよう要求されました。
515 - MINOR_OBJ_SEQ_ASSIGNMENT
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。シーケンス割当て演算子
が、オブジェクト参照シーケンスのためのメモリ取得に失敗しました。
3-124
140418J
第 9 章 マイナーコード
516 - MINOR_STR_DUP
このマイナーコードは、NO_MEMORY システム例外に関連して発生します。メモリが取得できないた
め、文字列シーケンスのメソッドが、文字列シーケンス要素の複製に失敗しました。
517 - MINOR_STR_NULL
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。ユーザが、NULL 文字列
ポインタをマーシャル化させようとしました。ヌル文字列ポインタは許可されません。空の文字列を表す
ときは、ヌル文字への有効なポインタ (「\0」) を使用する必要があります。
518 - MINOR_ARRAY_INDEX
この マイ ナー コー ドは、B A D_ PAR AM
シス テム 例外 に関 連し て発 生し ます。こ の例 外は、
_forany::operator[] メソッド内で範囲を超えるインデックスが指定されたときに、上げられま
す。
519 - MINOR_GET_ARRAY_NULL_PTR
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。配列の out パラメータと
してヌルポインタが渡されました。ポインタは、配列のすべての要素を保持するのに十分な大きさの連続
メモリブロックへの有効なポインタである必要があります。メモリ割当ての失敗が検出されなかった場合
に、このような状況が発生します。
521 - MINOR_ILLEGAL_DISCRIMINANT
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。ユニオンのマーシャル形
式からの復元中に、ユニオンの識別値が正しくないことが分かりました。
522 - MINOR_ILLEGAL_DISCR_SET
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。この例外は、ユニオンの
_d( ) メソッド内で上げられ、ユーザがユニオンの識別値を不正な値に設定しようとしたことを示しま
す。リクエストされた動作は実行されません。
523 - MINOR_BAD_STRUCT_VAR
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。_var クラスが、自身を
マーシャル化するよう要求されましたが、ipVar メンバーが初期化されていません。マーシャル化の前
に、_var が有効な構造に初期化される必要があります。
524 - MINOR_BAD_UNION_VAR
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。_var クラスが、自身を
マーシャル化するよう要求されましたが、ipVar メンバーが初期化されていません。マーシャル化の前
に、_var が有効なユニオンに初期化される必要があります。
140418J
3-125
第 9 章 マイナーコード
525 - MINOR_BAD_SEQ_VAR
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。_var クラスが、自身を
マーシャル化するよう要求されましたが、ipVar メンバーが初期化されていません。マーシャル化の前
に、_var が有効なシーケンスに初期化される必要があります。
526 - MINOR_UNKNOWN_EXCEPTION
このマイナーコードは、MARSHAL システム例外に関連して発生します。reply(
) 操作が、予期し
ない (IDL メソッドの RAISES 句にリストされていない ) ユーザエラーを返しました。不明な例外は、型
情報が不明なため、マーシャル形式からの復元ができません。
527 - MINOR_BAD_REPLY_STATUS
このマイナーコードは、MARSHAL システム例外に関連して発生します。GIOP メッセージの応答状況
フィールドが正しくありません。メッセージが壊れているか、または不正に書式設定されました。
528 - MINOR_NO_PROXY
このマイナーコードは、INTERNAL システム例外に関連して発生します。オブジェクトのすべてのプ
ロキシが試行され、拒否された場合に、ORB がこの例外を上げます。オブジェクト参照のマーシャル化が
試行されましたが、参照が正しく初期化されておらず、マーシャル化されたプロキシ情報がありません。
オブジェクト参照が正しく取得されなかった可能性があります。
たとえば、CORBA::Object::_factory(
) への呼出しによって得られた参照をユーザがマー
シャル化しようとしたときなどにこの例外が発生します。この使用法はサポートされておらず、また実行
する必要もありません。
備考 : 各プロキシは、プロファイルのリストです。オブジェクトはプロキシのスタックを持っています。GIOP 位
置の転送応答を受信すると、プロキシがスタック上でプッシュされます。プロキシのプロファイルが使い尽
くされると、プロキシがスタックから外されます。
529 - MINOR_DUPLICATE_REQUEST_ID
このマイナーコードは、INTERNAL システム例外に関連して発生します。GIOP Request メッセージ
ヘッダに含まれているリクエスト ID が、未解決の GIOP Request メッセージに以前割り当てられた ID で
あることを、リクエスト送信試行中に ORB が検出しました。リクエスト ID がユーザによって壊された可
能性があります。また、よくあることではありませんが、前のリクエストが未解決の間に、リクエスト ID
値 (long データ型 ) がラップアラウンドされたことも考えられます。
530 - MINOR_ROOT_NC_NOT_FOUND
このマイナーコードは、NonStop DOM 構成データベース内にエラーがあることを示しています。
org.omg.CORBA.ORG.resolve_initial_references( ) への呼出しによって、構成
データベースで参照されている RootNamingContextIORFile が正しく開きませんでした。
3-126
140418J
第 9 章 マイナーコード
531 - MINOR_INVALID_NAME
この マイ ナー コー ドは、I N V_ OBJ REF シス テム 例外 に関 連し て発 生し ます。_ <cl ass >
ServantRef.class を開こうとしましたが、これは、開いたり、検索したりできません。IDL が生
成したすべてのクラスが、$CLASSPATH 変数内で参照されていることを確認してください。
532 - MINOR_NULL
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。入力パラメータに
NULL
入力値があると発生します。すべての入力パラメータに有効な入力を行ってから、再度呼び出してくださ
い。
533 - MINOR_NOT_IOR
この マイ ナー コー ドは、I NV_OBJREF 例 外に 関連 して 発生 しま す。この マイ ナ ーコ ード は、
ORB::string_to_object( ) が、正しい IOR を表さない、無効な文字列を検出したことを示し
ています。
このような状況が発生するのは、次のような場合です。
□ 文字列が「IOR:」で始まっていない場合
□ 文字列に、正しく符号化された文字が含まれていない場合
□ ORB が、復号化された文字列を配列解除できない場合
534 - MINOR_NO_IMPLEMENTATION_REPOSITORY
こ の マ イ ナ ー コ ー ド は 、 N O_IMPLEMENT シ ス テ ム 例 外 に 関 連 し て 発 生 し ま す。 こ れ は
CORBA::Object::_get_implementation( ) によって返され、この関数が実装されていな
いことを示します。
9.2 POA Minor Codes
9.2.1 POA マイナーコード値
POA 管理下で操作からシステム例外が上げられると、POA が例外とともにマイナーコードを提供し、シ
ステム例外の詳細を理解するための、より厳密なコンテキストを知らせます。
600 - MINOR_BAD_OBJECT_ID
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。
POA::activate_object_with_id( ) から上げられるこのマイナーコードは、POA に与えら
れたオブジェクト ID が、呼出し (this( ) POA) を実行する POA によって生成されたものではないこ
とを示します。
備考 : サーバがリスタートされると、そのサーバ上の LifespanPolicy::PERSISTENT ポリシーを持
つどの POA も、すべてのオブジェクト ID を認識する必要がなく、実際に認識しません。
140418J
3-127
第 9 章 マイナーコード
601 - MINOR_BAD_SERVANT_MANAGER
この マイ ナー コー ドは、B A D _ PAR AM
シ ステ ム例 外に 関連 して 発生 しま す。POA ::se t
_servant_manager( ) から上げられるこのマイナーコードは、set_servant_manager( )
への呼出し内で POA に与えられたサーバントマネージャの型が正しくないことを示しています。たとえ
ば、RETAIN ポリシーを持つ POA は、PortableServer::ServantActivator 型に限定で
き るサ ーバ ント マネ ージ ャが 必要 です し、NON_RETAIN の P O A は
PortableServer
::ServantLocator が必要です。
602 - MINOR_NO_SERVANT_ACTIVATOR
このマイナーコードは、OBJ_ADAPTER システム例外に関連して発生します。このマイナーコードは、
リクエストの処理に必要なサーバントアクティベータが使用可能でないことを示しています。この状況は、
RETAIN ポリシーと USE_SERVANT_MANAGER ポリシーを持つ POA にリクエストが来たが、それを
処理するサーバントが存在していないときに発生します。この場合は、サーバントマネージャが必要です。
set_servant_manager( ) への呼出しによって事前に設定されている必要があります。
603 - MINOR_NO_SERVANT_LOCATOR
この マイ ナー コー ドは、OBJ_ADAPTER シ ステ ム例 外に 関連 して 発生 しま す。これ は、前記 で
NON_RETAIN の POA に対して詳細に記述されている MINOR_NO_SERVANT_ACTIVATOR マイ
ナーコードと同様です。到着するリクエストがサーバントの検索に必要とするサーバントロケータが、設
定されていません。違いは、このマイナーコードはすべてのリクエストに対して生成されることです。そ
れは、USE_SERVANT_MANAGER ポリシーを持つ
NON_RETAIN POA は、どのリクエストの処理に
もサーバントロケータを必要とするからです。
604 - MINOR_NOT_IN_AOM
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、到着
するリクエストが POA のアクティブオブジェクトマップ内にサーバントを見つけられなかったことを示
しています。これは、POA が RETAIN ポリシーと USE_ACTIVE_OBJECT_MAP_ONLY ポリシーを
持っていることを表しています。
605 - MINOR_NO_ADAPTER
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、到着
するリクエスト内で指定された POA が見つからないことを示しています (POA は、オブジェクトアダプタ
として、より汎用的に参照されることもあります )。このコードは、OBJ_ADAPTER システム例外に関
連して発生することもあります。この場合は、ローカルリクエストが、関連付けられた POA を見つけられ
なかったことを示しています。これは、サーバントへの参照がローカルで生成されて、POA がその後破壊
され、自動的に再作成されない場合に発生します。
3-128
140418J
第 9 章 マイナーコード
606 - MINOR_WRONG_STATE
このマイナーコードは、TRANSIENT または
OBJ_ADAPTER システム例外に関連して発生します。
どちらの場合も、このマイナーコードは、POA マネージャが、リクエストを処理するための正しい状態 (
有効な状態 ) にないことを示しています。状態が Discarding になっている場合は、TRANSIENT 例外が
生成されます。それ以外の場合は、状態が Inactive になっているため、OBJ_ADAPTER 例外が上げられ
ます。状態が Holding の場合は、例外は上げられず、POA マネージャがほかの状態に変更されるまで、リ
クエストが遅延 ( 保留 ) されます。
607 - MINOR_WRONG_PROCESS
このマイナーコードは、INV_OBJECT システム例外に関連して発生します。これは、リクエストが
サーバに配信されたが、IOR が別のサーバを指していることを示します。IOR が壊れていることが考えら
れます。ローカルリクエストに応えて生成された場合 ( クライアントとサーバが同じプロセスにある場合 )
は、このマイナーコードは、NonStop DOM ランタイムの内部エラーを意味しますので、Tandem の担当者
に詳細を連絡してください。
608 - MINOR_WRONG_POLICY
このマイナーコードは、OBJECT_NOT_EXIST または OBJ_ADAPTER システム例外に関連して発
生します。OBJECT_NOT_EXIST の場合は、IOR が壊れているか失効していることを示します。クラ
イアントリクエストが存在しない POA を指したが、POA の現在のポリシーが、IOR 内で与えられている
ものと一致しません。これは不正です。OBJECT_NOT_EXIST 例外が返され、古い IOR で以前参照さ
れたオブジェクトがすでになくなっていることを示します。OBJ_ADAPTER 例外の場合は、POA が、
create_reference_with_id( ) を呼び出すなどしてオブジェクト参照を作成するよう要求さ
れ、POA が Lifespan ポリシーとして PERSISTENT を持っているが、サーバプロセスのための ORB プ
ロファイルが設定されていないことを示しています。これを修復するには、正しい -ORBprofile <
value > コマンドを使ってサーバを再実行してください。
609 - MINOR_NO_OBJECT_ID
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、初期
化されていないオブジェクトを使ってローカルリクエストが作成されたときに生成されます。正しいオブ
ジェクト参照には、オブジェクト ID が含まれます。MINOR_NO_OBJECT_ID コードが発生したとい
うことは、オブジェクト ID がないことを示しています。アプリケーションが正しくオブジェクト参照を取
得したことを確認してください。
610 - MINOR_NO_DEFAULT_SERVANT
このマイナーコードは、OBJ_ADAPTER システム例外に関連して発生します。これは、デフォルト
サーバントを必要とするリクエストが到着したが、デフォルトサーバントが設定されていないことを示し
ています。POA の RequestProcessing ポリシーは USE_DEFAULT_SERVANT で、リクエスト
のためのサーバントが見つかりません。
140418J
3-129
第 9 章 マイナーコード
611 - MINOR_NONE_GIVEN
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、サー
バントマネージャが呼び出されたが、マネージャが NULL を返し、例外を返しておらず、ロケータがサー
バントを返していないことを示します。サーバントマネージャは、サーバントが見つからない特定の理由
を示す例外を返すはずなので、これは、アプリケーションエラーと考えられます。
612 - MINOR_NO_SUCH_OPERATION
このマイナーコードは、BAD_OPERATION システム例外に関連して発生します。これは、リクエスト
処理のプロセス中に、リクエスト内にある操作名が、サーバントによって処理されるものでないことを示
しています。これは通常、リクエストを処理するサーバントの型が、クライアントのターゲットオブジェ
クトと一致しないことを意味します。これは不正です。この状況は、アプリケーションサーバントマネー
ジャが、リクエストに不正なサーバントを返した場合に発生します。または、リクエストを送るクライア
ントが NonStop DOM ORB でなく、クライアントが、現在 NonStop DOM がサポートしていない CORBA
オブジェクト上のメソッドを呼び出そうとした場合にも発生します。POA のトレースをオンにして
(NSDOM_CFG_TRACE_POA 環境変数 )、問題のある操作の名前を調べてください。
613 - MINOR_POA_DESTROYED
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。POA 上の呼出
しに応えて発生した場合は、呼出しが行われた POA が壊れていることを示しています。アプリケーション
は POA 参照を解放する必要があります。同じ POA 上でのその後の操作は不正です。壊れた POA と同じ
プロパティ ( 同じ名前、ポリシー、およびペアレント ) を持つ POA を再作成することによって、アプリ
ケーション内で操作を続行することができます。
614 - MINOR_BAD_VALUE
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。これは、不正データのた
め、PortableServer::ObjectId_to_string(
) または string_to_ObjectId( )
) への入力には、ヌル文字を
への呼出しが失敗したことを示しています。ObjectId_to_string(
含めることはできません。ObjectId パラメータにヌルが含まれていると、オブジェクト識別子として
は不正ではありませんが、文字列で表せないため、string_to_ObjectId(
) 操作がこの例外を上
げます。
615 - MINOR_TOO_MANY_POLICIES
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。これは、ユーザが呼び出
した PortableServer::create_POA(
) のポリシーセット内に、ポリシーメンバーが多すぎる
ことを示しています。各ポリシーは、リスト内で 1 回または 0 回しか存在できません。
3-130
140418J
第 9 章 マイナーコード
9.3 Marshal マイナーコード
9.3.1 Marshal マイナーコード値
700 - MINOR_LOCALITY_CONSTRAINED
このマイナーコードは、MARSHAL システム例外に関連して発生します。これは、ユーザが、POA オ
ブジェクトのような、場所が制約されたオブジェクトをマーシャル化しようとしたことを示しています。
このようなオブジェクトは、単一のプロセス内だけで存在するように定義されており、ほかのプロセスか
らはアクセス不可能なため、クライアントには返されません。
701 - MINOR_NO_OBJECT_KEY
このマイナーコードは、MARSHAL システム例外に関連して発生します。これは、ユーザが、オブジェ
クトキーを与えられていないオブジェクトをマーシャル化しようとしたことを示しています。オブジェク
トキーが与えられていないのは、通常、POA によって有効化されていないためです。
702 - MINOR_INVALID_IOR
このマイナーコードは、MARSHAL システム例外に関連して発生します。これは、GIOP メッセージ結
果またはパラメータ内で受け取られた IOR が、無効であることを示しています。
703 - MINOR_INVALID_LENGTH
このマイナーコードは、MARSHAL システム例外に関連して発生します。これは、マーシャル形式から
復元された値が長すぎることを示しています。バッファが壊れているか、または送信者がマーシャル化し
たものが、マーシャル形式から復元されるものとは違っています。
9.4 COMM_FAILURE Minor Codes
9.4.1 COMM_FAILURE マイナーコード
1000 - MINOR_BROKEN_CONNECTION
このマイナーコードは、COMM_FAILURE システム例外に関連して発生します。このコードは、クラ
イアントがサーバからリクエストへの応答を待機している間に通信エラーが発生した場合に、クライアン
ト内で上げられます。接続が再確立されれば、リクエストが再試行されます。
1001 - MINOR_TARGET_UNREACHABLE
このマイナーコードは、COMM_FAILURE システム例外に関連して発生します。リモートオブジェク
ト参照のプロファイルが使い尽くされたときに、ORB がこの例外を上げます。プロファイルが使い尽くさ
れるとは、参照内のすべてのプロファイルが試行され、失敗したという意味です。
140418J
3-131
第 9 章 マイナーコード
推奨される解決策
□ 参照 (IOR) が有効であることを確認してください。
□ クライアント構成に、参照と共通のプロファイルが 1 つまたは複数あることを確認してください。
□ サーバが実行中であることを確認してください。
□ サーバが、1 つまたは複数のプロファイルで構成されていることを確認してください。
□ サーバの ORB が使用可能であることを確認してください。
□ IOR プロファイルの少なくとも 1 つが、
アクセス可能なアドレスを持っていることを確認してください。
□ 参照を解放して、新しい参照を取得してください。
1003 - MINOR_INITIALIZATION
このマイナーコードは、COMM_FAILURE システム例外に関連して発生します。これは、サーバの
G I O P プ ロ ト コ ル コ ン ポ ー ネ ン ト の 初 期 化 に 失 敗 し た こ と を 示 し て い ま す 。プ ロ ト コ ル に は、
tcp_server、gfs_server、および tsmp_server があり、それぞれに原因が異なります。
□
tcp_server
●
direct tcp server のプロファイルが tcp_process 句を持っていて、そのプロセスに自身を関連付
けるための ORB 呼出しが失敗した場合は、ORB が認識している tcp プロセス名を特定するイベン
トが生成されます。tcp プロセス名が正しいことと、そのプロセスが有効であることを確認してくだ
さい。( たとえば、直接の tcp サーバに、use_comm_server = not true プロファイルが
含まれている場合があります。)
●
tcp サーバの ORB が、構成データベース内の情報から LSD のアドレスを構築できなかった場合は、
ORB が何をエラーとして認識したかを特定するイベントが生成されます。イベントに含まれる情報
を使って、LSD の問題を解決してください。
●
direct tcp server のプロファイルに host_name 句または port_number 句がない場合は、不足
している句を特定するイベントが生成されます。
●
direct tcp server が、転送プロバイダ (tcp プロセス ) にソケットリッスンを配置できなかった場合は、
リッスンのどの手順が失敗したかを特定するイベントが生成されます。
●
direct tcp server が、構成データベース内にある、自身の <profile>@actual_tcp_address
エンティティを作成または更新できなかった場合は、どの手順が失敗したかを特定するイベントが
生成されます。
□
gfs_server (GUARDIAN File System)
●
プロセス名なしで
gfs_server が実行されている場合は、このエラーを知らせるイベントが生
成されます。
□
tsmp_server
●
tsmp_server のプロファイルに、pathmon 句または server_class 句がない場合は、不
足している句を特定するイベントが生成されます。
3-132
140418J
第 9 章 マイナーコード
9.5 LSD マイナーコード
9.5.1 LSD マイナーコード値
1102 - MINOR_NO_DIRECT_HOST
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、LSD
が、構成された tcp サーバの直接アドレスを構成データベース内で検索しようとして失敗したことを示し
ています。
1103 - MINOR_NO_DIRECT_PORT
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、LSD
が、構成された tcp サーバのポート番号を構成データベース内で検索しようとして失敗したことを示して
います。
1104 - MINOR_NO_CS_CONFIG
ターゲットサーバが、use_comm_server に構成されていて、LSD が csmap@load_table エ
ンティティ内にエントリを見つけられない場合に、LSD がこの例外を上げます。このエンティティは、実
行時に Comm Server によって作成および更新されます。
推奨される解決策
□ Comm Server が実行中であることを確認してください。
□ Comm Server と LSD が同じ構成データベースを使用していることを確認してください。
□ 構成データベースが正しく保護されていることを確認してください。
1105 - NO_CS_HOST_NAME
LSD が、使用する Comm Server を見つけたが、構成データベース内に Comm Server の host_name
を見つけられなかった場合に、この例外が上げられます。これは通常、Comm Server が正しく構成されて
いないことを示しています。
次は、Comm Server 構成レコード ( エンティティ ) の例です。
cfgmgt> entity ZC01@comm_server
port_number
5220
host_name
oss2.tandem.com
actual_ip_address
204.160.16.36
この問題を修正するには、まず、Comm Server の構成設定が正しいかどうか検証してください。次に、
Comm Server が正しく初期化され、実行しており、リクエストを受信できる状態になっていることを確認
します。問題が見つかったら、構成を修正して、Comm Server サーバクラスをリスタートしてください。
これは、PATHCOM セッションで実行するか、または nsdstop を使ってシステムを停止し、構成設定
を修正してから nsdstart を使ってシステムをリスタートしてください。
140418J
3-133
第 9 章 マイナーコード
1106 - NO_CS_PORT_NUMBER
NO_CS_HOST_NAME と似ていますが、このマイナーコードは、LSD が、使用する Comm
Server を見つけたが、Comm Server の port_number を見つけられなかった場合に発生します。
前記の
この問題を修正するには、まず、Comm Server の構成設定が正しいかどうか検証してください。次に、
Comm Server が正しく初期化され、実行しており、リクエストを受信できる状態になっていることを確認
します。問題が見つかったら、構成を修正して、Comm Server サーバクラスをリスタートしてください。
これは、PATHCOM セッションで実行するか、または nsdstop を使ってシステムを停止し、構成設定
を修正してから nsdstart を使ってシステムをリスタートしてください。
1107 - MINOR_NO_PP_CONN
このマイナーコードは、INTERNAL システム例外に関連して発生します。これは、LSD が必要とする、
comm サーバ接続を表すデータ構造が存在していないことを示しています。
1108 - MINOR_NO_CLIENT_ADDRESS
このマイナーコードは、INTERNAL システム例外に関連して発生します。これは、
csmap@map_table にリストされているクライアントが無効であることを示しています。
1109 - MINOR_NOT_NSDOM_OBJECT_KEY
このマイナーコードは、OBJECT_NOT_EXIST システム例外に関連して発生します。これは、LSD
が、NonStop DOM によってホストされていないオブジェクトの位置を検索するよう要求されたことを示し
ています。これは無効な操作です。
9.6 CS マイナーコード
9.6.1 CS マイナーコード値
1200 - MINOR_NO_SERVER_AGENT
Comm Server がターゲットサーバに接続できないときに、この例外を上げます。オブジェクトキーには、
使 用可能な アドレスが 含まれま す。ターゲッ トサーバ が実行中 で、gfs_server および tsmp_
server の両方またはどちらか一方を使って構成されていることを確認してください。
1201 - MINOR_CANT_RELAY_REQUEST
Comm Server が、ターゲットサーバにリクエストを配信できません。ターゲットサーバが実行中である
ことを確認してください。
1202 - MINOR_SERVER_DISCONNECTED
Comm Server からサーバへの接続が失敗しました。ターゲットサーバが異常終了していないことを確認
してください。
3-134
140418J
第 9 章 マイナーコード
9.7 データ変換マイナーコード
9.7.1 データ変換マイナーコード値
1500 - MINOR_UNDERFLOW
このマイナーコードは、MARSHAL システム例外に関連して発生します。IEEE 浮動小数点値または
Tandem 固有の浮動小数点値が小さすぎて、ほかの形式で表せませんでした。
1501 - MINOR_OVERFLOW
このマイナーコードは、MARSHAL システム例外に関連して発生します。IEEE 浮動小数点値または
Tandem 固有の浮動小数点値が大きすぎて、ほかの形式で表せませんでした。
1502 - MINOR_NOT_A_NUMBER
このマイナーコードは、MARSHAL システム例外に関連して発生します。浮動小数点値が、
「NAN」値
で定義されたような実数を表していませんでした。
9.8 Context マイナーコード
9.8.1 Context マイナーコード値
1600 - MINOR_NOT_STRING
こ の マ イ ナ ー コ ー ド は 、 B AD_CONTEXT シ ス テ ム 例 外 に 関 連 し て 発 生 し ま す。 こ れ は、
CORBA::Context( ) メソッドへの呼出しが文字列を期待していたが、ANY パラメータの kind
フィールドが文字列を表していなかったことを示しています。
1601 - MINOR_NO_MATCH
このマイナーコードは、BAD_CONTEXT システム例外に関連して発生します。CORBA::Context(
)
メソッドへの呼出しが、一致検索を要求されたが、何も見つかりませんでした。
1602 - MINOR_NO_SUCH_START_SCOPE
このマイナーコードは、BAD_CONTEXT システム例外に関連して発生します。CORBA::Context(
)
メソッドへの呼出しが、ユーザからリクエストされた「start scope」を見つけられませんでした。
1603 - MINOR_NO_PROPERTY_GIVEN
このマイナーコードは、BAD_CONTEXT システム例外に関連して発生します。CORBA::Context(
)
メソッドへの呼出しが、ヌルプロパティ文字列を与えられました。
140418J
3-135
第 9 章 マイナーコード
9.9 OTS マイナーコード
9.9.1 OTS マイナーコード値
1700 - MINOR_NO_TS_SENDER
このマイナーコードは、INTERNAL システム例外に関連して発生します。クライアントの役割を持つ
アプリケーションが、Current(
) を使ってトランザクションを開始することができ、その後トランザ
クションオブジェクトにリクエストを送信しようとしました。ORB は GIOP Request メッセージに対応す
るサービスコンテキストを生成する OTS アプリケーションランタイムコンポーネントを見つけることが
できませんでした。
アプリケーションが、一度は OTS ランタイムコンポーネントの使用に成功しているため、アプリケー
ションまたは ORB でメモリが壊れていることが考えられます。クライアントアプリケーションでメモリ破
壊の問題が起きていないか調べてください。問題が見つからない場合は、Compaq のサポートに連絡して
ください。
1701 - MINOR_NO_TS_RECEIVER
このマイナーコードは、INTERNAL システム例外に関連して発生します。原因の 1 つとしては、サー
バの役割内でのプロセスが、トランザクションオブジェクトに向けられたリクエストを受け取ったが、ORB
が、サービスコンテキストを処理する OTS ランタイムコンポーネントを見つけられなかったことが考えら
れます。サーバからクライアントへ、例外が返されます。
この場合は、プロセスが OTS ランタイムライブラリ (nsdots.o) に正しくリンクされていないか、ま
たはアプリケーションか ORB でメモリ破壊の問題が発生していることが考えられます。
実行ファイルにリンクされた一連のオブジェクトファイルを調べて、アプリケーションの Makefile に
nsdots.o が含まれていることを確認してください。その後、アプリケーションにメモリ破壊のバグが
ないかどうか確認してください。問題が見つからない場合は、Compaq のサポートに連絡してください。
考えられる状況のもう 1 つは、サーバの役割内でのプロセスが、トランザクションオブジェクトに向け
られたリクエストを受け取り、サーバがリクエストを処理して返した場合です。この場合、ORB が GIOP
Reply メッセージに対応するサービスコンテキストを生成する OTS ランタイムコンポーネントを見つける
ことができませんでした。サーバからクライアントへ、例外が返されます。
この場合は、アプリケーションのメソッド実装内にメモリ破壊の問題があることが考えられます。メソッ
ド実装にメモリ破壊の問題がないかどうか調べてください。
1703 - MINOR_BAD_TS_CTX
このマイナーコードは、INVALID_TRANSACTION システム例外に関連して発生します。サーバの
役割内でのプロセスが受け取った GIOP Request メッセージに含まれるトランザクションサービスコンテ
キストを、OTS ランタイムコンポーネントがマーシャル形式から復元できませんでした。これは通常、サー
ビスコンテキストが不正に書式設定されていることが原因です。また、サービスコンテキストをマーシャ
ル形式から復元する OTS ランタイムコンポーネントが、有効だが予期しない構造を検出したか、または移
動中に構造が壊れたことも考えられます。
サービスコンテキストを生成する OTS ランタイムコンポーネントのサポート先に連絡してください。ま
た、コンポーネント不良の報告として、Compaq のサポートにも連絡してください。
3-136
140418J
第 9 章 マイナーコード
9.10 Interface Repository Minor Codes
9.10.1 インタフェースレポジトリマイナーコード値
1800 - MINOR_IR_INIT
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、インタフェース
レポジトリデータベースの初期化に失敗したことを意味します。この問題の原因は、データベースファイ
ルが不足していること、データベースファイルの読み書き許可が無効であること、またはデータベースファ
イルが壊れていることなどが考えられます。
1801 - MINOR_INVALID_IR_OBJECT
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、間違ったインタ
フ ェ ー ス 定 義 オ ブ ジ ェ ク ト 上 で メ ソ ッ ド が 呼 び 出 さ れ た こ と を 示 し て い ま す。た と え ば、
CORBA::Repository オブジェクト上で destroy( ) が呼び出されたような場合です。
1802 - MINOR_INVALID_DEFKIND
この マイ ナー コー ドは、INTF_REPOS シ ステ ム例 外に 関連 して 発生 しま す。こ れは、不 正な
CORBA::DefinitionKind 値がインタフェース定義操作に渡されたことを示しています。
1803 - MINOR_DUPLICATE_REPOID
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、Container
オブジェクトに Contained オブジェクトを挿入するよう試行されたが、Container には、一致した
RepositoryId を持つ Contained オブジェクトがすでに存在していたことを示しています。
1804 - MINOR_DUPLICATE_NAME
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、Container
オブジェクトに Contained オブジェクトが挿入されたが、Container オブジェクトには、一致した
Name を持つ Contained オブジェクトがすでに存在していたことを示しています。
1805 - MINOR_IRDB_WRITE_ERROR
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、インタフェース
定義オブジェクトが IR データベースに直列化される際に、エラーが発生したことを示しています。
1806 - MINOR_IRDB_READ_ERROR
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、インタフェース
定義オブジェクトが IR データベースから読込み中にエラーが発生したことを示しています。
1899 - MINOR_NO_SUCH_IR_OBJECT
このマイナーコードは、INTF_REPOS システム例外に関連して発生します。これは、インタフェース
定義オブジェクトが IR データベース内に見つからないことを示しています。
140418J
3-137
第 9 章 マイナーコード
9.11 DSI マイナーコード
9.11.1 DSI マイナーコード値
通常、DSI マイナーコードを通じて報告される例外は、サーバ側のエラーを意味します。このようなエ
ラーを修復するには、ユーザ DSI コードを修正する必要があります。
1900 - MINOR_SET_RESULT_BEFORE_ARGS
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクトの set_result(
呼び出されます。arguments(
) 操作は、arguments( ) 操作後に 1 度
) が呼び出される前に set_result( ) が呼び出されると、この
マイナーコードが発生します。
1901 - MINOR_SET_RESULT_TWICE
こ の マ イ ナ ー コ ー ド は 、 B A D _INV_ORDER シ ス テ ム 例 外 に 関 連 し て 発 生 し ま す 。前 記 の
MINOR_SET_RESULT_BEFORE_ARGS と似ていますが、このマイナーコードは、set_result( )
が呼び出された後にもう一度 set_result( ) が呼び出されると発生します。
1902 - MINOR_SET_RESULT_AFTER_EX
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクトの set_result(
) 操作は、arguments( ) 操作後に 1 度
呼 び出 され ます。し かし、s e t _ exc epti on( ) へ の呼 出し によ って 例外 が上 げら れる と、
set_result( ) を 呼び 出す こと はで きま せん。set_exception( ) が 呼び 出さ れた 後に
set_result( ) が呼び出されると、このマイナーコードが生成されます。
1903 - MINOR_CTX_BEFORE_ARGS
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクトの
ctx( ) 操作が呼び出される場合は、arguments ( ) 操
) の前に ctx( ) が呼び出されると、このマイ
作の後に呼び出される必要があります。arguments(
ナーコードが生成されます。
1904 - MINOR_CTX_TWICE
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクトの
ctx( ) 操作が呼び出される場合は、arguments ( ) 操
) の後に ctx( ) が 2 回呼び出され
作の後に 1 度だけ呼び出される必要があります。arguments(
ると、このマイナーコードが生成されます。
3-138
140418J
第 9 章 マイナーコード
1905 - MINOR_CTX_AFTER_SET_RESULT
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクトの ctx(
) 操作が呼び出される場合は、arguments ( ) 操
) への呼出しが実行される前に呼び出される必要があります。
set_result( ) が呼び出された後に ctx( ) が呼び出されると、このマイナーコードが生成されま
作が呼び出された後、set_result(
す。
1906 - MINOR_CTX_AFTER_EX
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクトの ctx(
) 操作が呼び出される場合は、arguments ( ) 操
作が呼び出された後、set_exception(
す。set_exception(
) への呼出しが実行される前に呼び出される必要がありま
) が呼び出された後に ctx( ) が呼び出されると、このマイナーコードが
生成されます。
1907 - MINOR_OUT_PARAM_NOT_SUPPLIED
このマイナーコードは、MARSHAL システム例外に関連して発生します。通常の DSI の状況では、
ServerRequest 擬似オブジェクトの ctx( ) 操作が呼び出される場合は、arguments( ) 操作が呼び
出 され た後、s e t _ r e s u l t (
) への 呼出 しが 実行 され る前 に呼 び出 され る必 要が あり ます。
set_result( ) が呼び出されたとき、ユーザは、arguments( ) への呼出しによって以前返され
たすべての出力引数を供給する必要があります。set_result( ) への呼出しに、arguments( )
への呼出しによって返されたすべての出力パラメータが含まれていないと、このマイナーコードが生成さ
れます。
また、このマイナーコードは、操作の IDL がコンテキスト式を含む際に、ctx(
) を呼び出さずに
set_result( ) を呼び出した場合にも生成されます。
1908 - MINOR_NOT_AN_EXCEPTION
このマイナーコードは、BAD_PARAM システム例外に関連して発生します。通常の DSI 処理では、ユー
ザは、set_exception(
) を呼び出すことにより、例外がクライアントに返されるべきであると指
) に渡される Any には、呼び出された操作の IDL 定義の
示することができます。set_exception(
raises( ) 式で指定されているように、システム例外またはユーザ定義例外が含まれている必要があり
ます。有効な例外を持たない Any が渡されると、このマイナーコードが生成されます。
1909 - MINOR_ARGS_TWICE
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。arguments(
)
) が呼び出された場合に、同じ ServerRequest 上で再度 arguments( )
を呼び出すと、このマイナーコードが生成されます。set_exception( ) を呼び出した場合は、
arguments( ) を呼び出す必要がないことに注意してください。
または set_exception(
140418J
3-139
第 9 章 マイナーコード
1910 - MINOR_ARGS_AFTER_EX
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクト上の arguments(
) 操作は、1 度だけ呼び出される必要があり
) への呼出しによって例外処理が行われた後に arguments( )
を呼び出すことはできません。set_exception( ) への呼出しが行われた後に arguments( )
ます。しかし、set_exception(
が呼び出されると、このマイナーコードが生成されます。
1911 - MINOR_ARGS_NOT_CALLED
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ServerRequest 擬似オブジェクト上の arguments(
) 操作は、1 度呼び出される必要があります
( クライアントが set_exception( ) 操作への呼出しを行わなかった場合 )。この呼出しは、operation
signature にパラメータが含まれていない場合でも実行される必要があります。arguments( ) が呼び
出されないと、このマイナーコードが生成されます。
1912 - MINOR_SET_EX_TWICE
このマイナーコードは、BAD_INV_ORDER システム例外に関連して発生します。通常の DSI の状況
では、ユーザは、set_exception(
) を呼び出すことにより、例外がクライアントに返されるべき
であると指示することができます。単一の DSI メソッド呼出し中に set_exception( ) 操作が複数
回呼び出されると、このマイナーコードが発生します。
3-140
140418J
第 10 章 NonStop DOM システムエラーメッセージ
第 10 章 NonStop DOM システムエラーメッセージ
10.1 NonStop DOM エラーメッセージ
サブトピックス
□ Event Framework メッセージ ( エラー番号 1100 ∼ 1199)
□ データベースエラーメッセージ ( エラー番号 1200 ∼ 1299)
□ トレースエラーメッセージ ( エラー番号 1400 ∼ 1499)
□ ORB エラーメッセージ ( エラー番号 1600 ∼ 1699)
□ Comm Server エラーメッセージ ( エラー番号 2000 ∼ 2099)
□ インタフェースレポジトリエラー ( エラー番号 2200 ∼ 2299)
□ Event Service エラーメッセージ ( エラー番号 2600 ∼ 2699)
□ Naming Service エラーメッセージ ( エラー番号 2800 ∼ 2899)
このセクションでは、NonStop DOM システムコンポーネントが生成するエラーメッセージをリストし
てあります。エラーは番号順に並べてあり、
「ユーザアクション」の項にエラーの原因と修正方法を示しま
した。これらのメッセージを表示するには、NonStop DOM とともに構成された EMS テンプレートファイ
ルが必要です。
10.1.1 Event Framework メッセージ
1100 - Event FrameWork error
ユーザアクション : このエラーが発生するのは、Event FrameWork 内で、通常と違うイベントが発生し
た場合です。エラーを説明するための詳細なテキストが表示されます。
10.1.2 データベースエラーメッセージ
1202 - Attempted delete of non-existent record
ユーザアクション : アクションは必要ありません。このメッセージが表示されることはありません。こ
のエラーは、存在していないレコードをユーザが削除しようとした場合に、それを知らせるために作成さ
れました。
1203 - Get of first record failed
ユーザアクション : NonStop DOM が、データベース内の最初のレコードを読み取れなかった場合に、こ
のメッセージが表示されます。データベースが壊れていることが考えられます。
140418J
3-141
第 10 章 NonStop DOM システムエラーメッセージ
1204 - Attempt to get next record failed: Key <xyz> Failed
ユーザアクション : 次のレコードにアクセスにしようとして、I/O エラーが発生しました。これはオペ
レーティングシステムのエラーが原因です。このメッセージが表示された場合は、コンパックの担当者に
連絡してください。
1206 - Attempt update failed: Key <xyz> Failed
ユーザアクション : 次のレコードにアクセスしようとして、I/O エラーが発生しました。これはオペレー
ティングシステムのエラーが原因です。このメッセージが表示された場合は、コンパックの担当者に連絡
してください。
1209 - Failed to create database: FILE_CREATE <name>
ユーザアクション : データベースの作成に失敗しました。考えられる原因は、ファイルシステムが一杯
であること、ファイルの更新に必要な権利をユーザが持っていないこと、またはデータベースファイル名
のスペルが間違っていることなどです。
1210 - Failed to open database: Cannot open database file <name> . Aborting.
ユーザアクション : <name> という名前のデータベースを開く試みが 5 回行われ、
すべて失敗しました。
名前、権利、およびファイルコードを確認してください。ファイルコードの型は 426 である必要があります。
1212 - Attempted delete of database failed: Delete for database failed: <name>
ユーザアクション : リクエストされたデータベースを削除できません。データベースの権利や、現在開
かれている数を確認してください。
10.1.3 トレースエラーメッセージ
1401 - Unable to open Trace file: Trace File = <name>
ユーザアクション : トレースファイルを開くプロセスが、トレースファイルへのアクセス権を持ってい
ることを確認してください。
1402 - Unable to open Trace file: Trace File = <name>
ユーザアクション : プロセスが、トレースファイルの書込み権を持っていることを確認してください。
1403 - Unable to read from Trace file: Trace File = <name>
ユーザアクション : プロセスが、トレースファイルの読込み権を持っていることを確認してください。
1404 - Unable to create Trace file: Trace File = <name>
ユーザアクション : プロセスが、トレースファイルの作成権を持っていることを確認してください。
3-142
140418J
第 10 章 NonStop DOM システムエラーメッセージ
1405 - Unable to lock Trace file record: Trace File = <name>
ユーザアクション : プロセスが、トレースファイルの書込み権を持っていることを確認してください。
1406 - Unable to unlock Trace file record: Trace File = <name>
ユーザアクション : レコードが、ほかのプロセスによってロックされています。
1407 - Trace file is corrupted. Write on Trace file failed: Trace File = <name>
ユーザアクション : トレースファイルを削除してください。新しいトレースファイルが作成されます。
10.1.4 ORB エラーメッセージ
1601 - Configuration error. No tcp host name for LSD <name>
ユ ー ザ ア ク シ ョ ン : こ の エ ラ ー は 、t c p _ s e r v e r の 初 期 化 中 に 、構 成 デ ー タ ベ ー ス か ら
lsd1@actual_tcp_address{host_name} キ ーを 取り 込め なか った 場合 に発 生し ます。サ ーバ が正 しい
NSDOM_CFG_DBM 環境を持っているかどうか検証してください。検証するには、構成データベースに、
有効な lsd1@actual_tcp_address エンティティが含まれていることを確認します。このエンティティは、構
成スクリプト実行中に作成されます。
1602 - Configuration error. No tcp port number for LSD <name> .
ユーザアクション : これは 1601 と似ていますが、address キーではなく、port_number キーを取り込めな
かったときに発生します。
1603 - Configuration error. No host name for profile <name>
ユーザアクション : このエラーは、直接の tcp_server 初期化中に、構成データベースから <profile>@ORB
{host_name}
キーを取り込めなかった場合に発生します。サーバが正しい NSDOM_CFG_DBM 環境を
持っているかどうか検証してください。検証するには、サーバが、USE_COMM_SERVER とは異なり、直
接の tcp_server として構成されていて、構成データベースに有効な <profile>@ORB{host_name} キーと値
が含まれていることを確認します。
1604 -Configuration error. No port number for profile <name>
ユーザアクション : これは 1603 と似ていますが、address キーではなく、port_number キーを取り込めな
かったときに発生します。
1605 - Configuration error. Failed to delete actual address for profile <name>
ユー ザア クシ ョン : この エラ ーは、直 接の tcp_server 初期 化中 に、プロ セス が、以前 作成 され た
<profile>@actual_tcp_address エンティティの削除に失敗した場合に発生します。サーバプロセスが、構成
データベースへの書込み権を持っていることを確認してください。
140418J
3-143
第 10 章 NonStop DOM システムエラーメッセージ
1606 - Configuration error. Failed to update address for profile <name>
ユーザアクション : このエラーは、直接の tcp_server 初期化中に、プロセスが、@actual_tcp_address エ
ンティティの書込みに失敗した場合に発生します。サーバプロセスが、構成データベースへの書込み権を
持っていることを確認してください。
1607 - GIOP Client context not found
ユーザアクション : このエラーは、GIOP 応答メッセージの処理中に、対応するリクエストに関連付けら
れたコンテキストが見つからない場合に発生します。このエラーは、重大な問題があることを示していま
す。GIOP_FW と PROXY のトレースを取得し、コンパックの担当者に連絡してください。
1608 - GIOP Client message error
ユーザアクション : このエラーは、クライアント側での受信メッセージの処理中に、それが有効な GIOP
メッセージでなかった場合に発生します。サーバが有効な GIOP メッセージを送信していることを確認し
てください。
1609 - GIOP Client invalid message type
ユーザアクション : このエラーは、クライアント側での受信メッセージの処理中に、そのタイプが GIOP
Reply メッセージでなかった場合に発生します。サーバが GIOP Request に応えて GIOP Reply メッセージ
を送信していることを確認してください。
1610 - GIOP Server message error
ユーザアクション : このエラーは、サーバ側での受信メッセージの処理中に、そのタイプが GIOP Reply
メッセージでなかった場合に発生します。クライアントが有効な GIOP メッセージを送信していることを
確認してください。
1611 - No load_table entries
ユーザアクション : このエラーは、LSD が、クライアントアドレスと関連付けるために、最もビジーで
ない Comm Server を選択しようとした際に、構成データベース内に csmap@load_table エントリがなかっ
た場合に発生します。Comm Server プールが正しく開始されたことと、Comm Server プールプロセス名が
正しいことを確認してください (default.db を参照 )。
1612 - User exception received but not expected. Not declared in IDL.
ユーザアクション : このエラーは、認識できないユーザ例外のマーシャル形式の復元中に発生します。す
べての例外が、生成された *_client.h ファイルと .cpp ファイル内で宣言されていることを確認してくださ
い。
1613 - Expected null for object key <name>
ユーザアクション : このエラーは、POA がオブジェクト参照を作成する際に、プロキシのオブジェクト
キーがヌルでない場合に生成されます。
3-144
140418J
第 10 章 NonStop DOM システムエラーメッセージ
1614 - GIOP Proxy marshalling 0 profiles
ユーザアクション : このエラーは、object_to_string の一部として、または、出力パラメータや結果の応
答データ生成のために、オブジェクト参照をマーシャル化している際に、有効になっているプロトコルが
ない場合に発生します。構成データベース内に、プロセスで使用されたプロファイルが存在していること
を確認してください。構成されたプロファイルに、少なくとも 1 つのサーバプロトコル (tcp_server、
tsmp_server、fs_server など ) が含まれていることを確認してください。
1615 - GIOP Proxy demarshal - 0 profiles!
ユーザアクション : このエラーは、string_to_object、マーシャル形式復元パラメータ、または戻り値の一
部として、オブジェクト参照をマーシャル形式から復元している際、参照にプロファイルが含まれていな
い場合に発生します。参照を生成したアプリケーションが、有効なプロファイルとともに実行されている
ことを確認してください。参照を生成したアプリケーションに、少なくとも 1 つのサーバプロトコル
(tcp_server、tsmp_server、fs_server など ) が構成されていることを確認してください。
1618 - Object key error. Bad system name <name>
ユーザアクション : このエラーは、fs または tsmp プロファイルのマーシャル形式からの復元中に、シス
テム名が長すぎる場合に発生します。showior を使用して、参照が有効なシステム名を持っていることを確
認してください。ファイルシステムプロファイル、または構成された pathmon 値にシステム名が含まれな
い tsmp プロファイルの場合は、名前が自動的に生成されています。Tandem の担当者に連絡してください。
1619 - Object key error. Bad pathmon name <name>
ユーザアクション : このエラーは、tsmp プロファイルのマーシャル形式からの復元中に、pathmon 名が
長すぎる場合に発生します。参照されたアプリケーションの <profile>@ORB{pathmon} 値が正しいかどう
か確認してください。
1620 - Object key error. Bad server class name <name>
ユーザアクション : このエラーは、tsmp プロファイルのマーシャル形式からの復元中に、サーバクラス
名が長すぎる場合に発生します。参照されたアプリケーションの <profile>@ORB{server_class} 値が正し
いかどうか確認してください。
1621 - Configuration error. No pathmon for profile <name>
ユーザアクション : このエラーは、tsmp_server の初期化中に、<profile>@ORB{pathmon} キー値が見つ
からない場合に発生します。構成データベース内の <profile>@ORB が正しいことを確認してください。
1622 - Configuration error. No server class for profile <name>
ユーザアクション : このエラーは、tsmp_server の初期化中に、<profile>@ORB{server_class} キーまた
は値が見つからない場合に発生します。構成データベース内の <profile>@ORB が正しいことを確認してく
ださい。
140418J
3-145
第 10 章 NonStop DOM システムエラーメッセージ
1623 - Object key error. Bad process name <name>
ユーザアクション : このエラーは、ファイルシステムプロファイルのマーシャル形式からの復元中に、プ
ロセス名が長すぎる場合に発生します。このフィールドは NSDOM によって生成されます。このエラーは、
重大な問題があることを示しています。ior をキャプチャして、Tandem の担当者に連絡してください。
1624 - Oject key error. Bad subdev name <name>
ユーザアクション : このエラーは、ファイルシステムプロファイルのマーシャル形式からの復元中に、
subdevice フィールドが長すぎる場合に発生します。このフィールドは NSDOM によって生成されます。こ
のエラーは、重大な問題があることを示しています。ior を取って、Tandem の担当者に連絡してください。
1630 - demarshalled invalid policy list length
demarshalled invalid string length
demarshalled invalid encap length
demarshalled invalid repository id length
demarshalled invalid operation length
demarshalled invalid principal length
demarshalled invalid sequence length
ユーザアクション : このエラーは、マーシャル形式から復元された値が長すぎる場合に発生します。デー
タが壊れていないことを確認してください。
10.1.5 Comm Server エラーメッセージ
2001 - Configuration error. CommServer <name> has no host name
ユ ー ザ ア ク シ ョ ン : こ の エ ラ ー は、 C o m m S e r v e r が 、構 成 デ ー タ ベ ー ス 内 で < c s name>
@comm_server{host_name} キーを見つけられない場合に発生します。Comm Server サーバプール (nsdstart
Comm
スクリプトを参照 ) が正しい NSDOM_CFG_DBM env を持っていることを確認してください。また、
Server サーバプール (nsdstart を参照 ) 名と構成データベース名が正しいことを確認してください。
2002 - Configuration error. CommServer <name> has no port number
ユ ー ザ ア ク シ ョ ン : こ の エ ラ ー は、 C o m m S e r v e r が 、構 成 デ ー タ ベ ー ス 内 で < c s name>
@comm_server{port_number} キー を見 つけ られ ない 場合 に発 生し ます。Comm Server サー バプ ール
(nsdstart スクリプトを参照 ) が正しい NSDOM_CFG_DBM env を持っていることを確認してください。ま
た、Comm Server サーバプール(nsdstart を参照) 名と構成データベース名が正しいことを確認してください。
2003 - Configuration error. Failed to set tcp_process
ユーザアクション : このエラーは、Comm Server がトランスポート名の指定に失敗した場合に発生しま
す。<cs name>@comm_server{tcp_process} が正しく構成されていることを確認してください。
3-146
140418J
第 10 章 NonStop DOM システムエラーメッセージ
2004 - NID <interposed id> Server Reply : ctx not found <address>
ユーザアクション : このエラーは、Comm Server が応答メッセージをリレーしているときに発生します。
介在するリクエスト ID(New ID) が、以前リレーされたリクエスト用に保持されているコンテキストにマッ
プしません。
2005 - Object key error. Bad system name
ユーザアクション : このエラーは、Comm Server がリクエストをリレーしているときに発生します。tsmp
リレープロファイルに、大きすぎるシステム名が含まれています。<server>@ORB{pathmon} の値が正し
いことを確認してください。値にシステム名が含まれていない場合は、生成されたものが間違っています。
IOR を取って、コンパックの担当者に連絡してください。
2006 - Object key error. Bad pathmon name
ユーザアクション : このエラーは 2005 と似ていますが、これは pathmon プロセス名に関するエラーで
す。<server>@ORB{pathmon} の値が正しいことを確認してください。
2007 - Object key error. Bad server class name
ユーザアクション : このエラーは 2005 と似ていますが、これは server_class 値に関するエラーです。
2008 - Internal error. Address not found
ユーザアクション : このエラーは、tsmp サーバエージェントの 解体（tear-down）中に発生します。エー
ジェントテーブルが一貫していません。Tandem の担当者に連絡してください。
2009 - Object key error. Bad system name
ユーザアクション : このエラーは、ファイルシステムがリクエストをリレーしているときに発生します。
tsmp リレープロファイルに、大きすぎるシステム名が含まれています。このフィールドは生成されます。
IOR を取って、コンパックの担当者に連絡してください。
2010 - Object key error. Bad process name
ユーザアクション : このエラーは、プロセス名がリクエストをリレーしているときに発生します。tsmp
リレープロファイルに、大きすぎるシステム名が含まれています。このフィールドは生成されます。IOR
を取って、コンパックの担当者に連絡してください。
2011 - Object key error. Bad subdev name
ユーザアクション : このエラーは、サブデバイス名がリクエストをリレーしているときに発生します。
tsmp リレープロファイルに、大きすぎるシステム名が含まれています。このフィールドは生成されます。
IOR を取って、コンパックの担当者に連絡してください。
2012 - Internal error. Address not found
ユーザアクション : これはファイルシステムエラーです。コンパックの担当者に連絡してください。
140418J
3-147
第 10 章 NonStop DOM システムエラーメッセージ
2013 - Initialization error. CommServer <cs_name> listen failed
ユーザアクション : このメッセージは、Comm Server が、自身が構成されたアドレス上で待機できない
場合に生成されます。Configuration Tool を使って、Comm Server 構成を検査してください。failure
completion 状況では、Comm Server は自動的に停止します。Pathway が Comm Server のリスタート
を試みるため、Comm Server は、非永続 TCP または構成データベースの問題を回避できます。
10.1.6 インタフェースレポジトリエラー
2201 - Cannot find the Contained object within current Container <name>
ユーザアクション : IR データベースを Contained オブジェクトで更新してください。
2202 - Cannot delete IR object from the IR database. IR object <name>
ユーザアクション : IR データベースが読み書き権を持っていることと、Repository オブジェクトが更新
モードで作成されたことを確認してください。
2203: Cannot create IR object <name>
ユーザアクション : IR データベースが読み書き権を持っていることを確認してください。
2204 Cannot write IR object
ユーザアクション : IR データベースが読み書き権を持っていることを確認してください。
2205: Cannot insert key/value for IR object
ユーザアクション : IR データベースが読み書き権を持っていることを確認してください。
2206: Cannot read IR object from the IR database. IR object <name>
ユーザアクション : IR データベースが読込み権を持っていることを確認してください。
2207: IR object type is invalid for the operation
ユーザアクション : IR オブジェクトが、操作を呼び出すための適切な型のオブジェクトであることを確
認してください。
2208 Cannot initialize IR database
ユーザアクション : 読込みモードでは、IR データベースが存在し、読込み権を持っていることを確認し
てください。更新モードでは、使用者が、データベースの作成権と書込み権を持っていることを確認して
ください。
3-148
140418J
第 10 章 NonStop DOM システムエラーメッセージ
2209: Invalid Container for the Contained object
ユーザアクション : Contained オブジェクトが正しい Container オブジェクトに挿入されることを確認し
てください。
2210: Cannot find IR object in the IR database. IR object <name>
ユーザアクション : なし
2211: Later version of the IR object already exists. IR object <name>
ユーザアクション : なし
10.1.7 Event Service エラーメッセージ
2601 - push_to_consumer got system exception when tried to ’push’ <exception#>
ユーザアクション : Event Service が、プッシュコンシューマを提供したアプリケーションと正しく相互
動作できませんでした。プッシュコンシューマは、イベントを受け取りませんでした。イベントサービス
は、プッシュコンシューマとの相互動作の試行を停止します。プッシュコンシューマを提供したアプリケー
ション内で予期できないエラーが発生していないことを確認してください。プッシュコンシューマが正し
く消滅すれば、アクションは特に必要ありません。最も推奨されるのは、終了する前に、イベントチャネ
ルから正しく接続解除できるように、プッシュコンシューマを再処理することです。プッシュコンシュー
マプロセスが失敗した場合は、リスタートして、イベントチャネルに登録してください。
2602 - pull_to_supplier got system exception when tried to ’pull’ or ’try_pull’ <exception#>
ユーザアクション : Event Service が、プルサプライヤを提供したアプリケーションと正しく相互動作で
きませんでした。イベントサービスコンシューマは、期待したイベントを取得していない可能性がありま
す。「comm failure」例外が上げられた場合は、イベントサービスは、害を与えているプルサプライヤとの
相互動作の試行を停止します。プルサプライヤを提供したアプリケーション内で予期できないエラーが発
生していないことを確認してください。プルサプライヤが正しく消滅すれば、アクションは特に必要あり
ません。そうでなければ、comm エラーが発生した場合は、プルサプライヤをリスタートしてイベントチャ
ネルに登録する必要があります。comm エラー以外の例外が発生した場合は、イベントチャネルは、プル
サプライヤとの相互動作を試行し続けます。さらにエラーが発生した場合は、プルサプライヤをリスター
トしてください。
2603 - pull_from_supplier got user exception when tried to ’pull’ or ’try_pull’ <exception#>
ユーザアクション : このエラーは、情報提供の目的で記録されます。Event Service には影響しません。
「Disconnected」
プルサプライヤを提供したアプリケーションは、pull または try_pull リクエストに対して、
以外のユーザ例外を生成すべきではありません。
「Disconnected」以外のユーザ例外を生成しないよう、ア
プリケーションを作成しなおしてください。
2604 - GetEvent encountered inconsistency in saved events
ユーザアクション : コンシューマからリクエストされたイベントが使用可能でない可能性があります。イ
ベントチャネルは、特定のイベントを配信できませんが、それに続くイベントは認識および配信すること
140418J
3-149
第 10 章 NonStop DOM システムエラーメッセージ
ができます。
2605 - release_proxy could not find object to be released
ユーザアクション : イベントチャネルが、内部一貫性の問題を検出しましたが、自動的に修復しました。
この問題が頻繁に発生する場合は、Tandem サポートに連絡してください。
2606 - EventService could not obtain Root Name Context
ユーザアクション : Event Service オブジェクト参照が、Naming Service 内にありません。このエラーが
修正されないと、アプリケーションプログラムが、Naming Service 内で Event Service オブジェクト参照を
問い合せることができません。Naming Service の構成が正しいことと、Naming Service が動作可能である
ことを確認してください。また、Naming Service のルートネームコンテキストが、構成データベース内に
あることを確認してください。Naming Service のエラーを修正した後、Event Service をリスタートしてく
ださい。
10.1.8 Naming Service エラーメッセージ
2801 - Could not execute resolve_initial_references successfully
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2802 - Cannot get Naming Database name from configuration database
ユーザアクション : NS@name_service_settings エンティティ内に DatabaseName 値を設定してください。
2803 - Could not create POA [NamingContextPOA’ | ’BindingIteratorPOA’]
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2804 - Could not delete record from Naming database
ユーザアクション : ネーミングコンテキストオブジェクト上で destroy メソッドを呼び出そうとして、
ネーミングデータベースからネーミングコンテキストレコードを削除できませんでした。ネーミングデー
タベースが壊れている可能性があります。ネーミングデータベースを破棄して、再構成してください。
2805 - Could not initialize Naming database <name>
ユーザアクション : データベースが壊れている可能性があります。データベースを破棄して、初期化ス
クリプトを再実行してください。
2806 - Could not create Naming Service reference
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2807 - Could not create Naming Service stringified reference
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
3-150
140418J
第 10 章 NonStop DOM システムエラーメッセージ
2808 - Cannot save Name Service IOR in config database
ユーザアクション : 構成データベースファイルが存在していることと、ユーザが必要なアクセス権を持っ
ていることを確認してください。
2809 - Could not convert string IOR to object
ユーザアクション : 名前を解決しようとしましたが、ORB の string_to_object メソッドを使って文字列化
オブジェクト参照をオブジェクトに変換できませんでした。これは、オブジェクト参照が失効したことを
示しています。rebind メソッドを呼び出して、名前を有効な新しいオブジェクト参照にバインドしてくだ
さい。
2810 - Cannot set Servant Manager
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2811 - Could not activate POA
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2812 - Could not narrow to PortableServer::POA
ユーザアクション : ネーミングコンテキスト上で list メソッドを呼び出そうとしましたが、ORB の
resolve_initial_references("RootPOA") メソッドから返されたオブジェクトを PortableServer::POA に正しく
限定できません。これは内部エラーです。
2815 - Could not insert record into naming database
ユーザアクション : 新しいコンテキスト作成の試行中にこのエラーが生成された場合は、このメッセー
ジによって、「NEW_CONTEXT」のバインディングネームコンポーネント ID も報告されます。ネーミン
グデータベースファイルが存在していることと、ユーザが書込み権を持っていることを確認してください。
2817 - Could not narrow to CosNaming::NamingContext
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2819 - Could not get timestamp from NamingContext
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2821 - Could not create CosNaming::NamingContext
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2822 - Could not find POA [’NamingContextPOA’ | ’BindingIteratorPOA’]
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
140418J
3-151
第 10 章 NonStop DOM システムエラーメッセージ
2823 - Could not create reference with ID
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2824 - Could not get record from naming database
Could not find CosNaming::NamingContext start record in database.
ユーザアクション : ネーミングデータベースファイルが存在していることと、ユーザが読込み権を持っ
ていることを確認してください。ほかのメッセージが表示されない場合は、ターゲットネーミングコンテ
キストオブジェクトが存在していないことを意味します。内部エラーが発生している可能性があります。
2825 - Could not initialize Naming database. <name> already exists
ユーザアクション : ネーミングデータベースが存在していると、ns_init プログラムを実行できません。
ネーミングデータベースを破棄して、ns_init を再実行してください。
2829 - Cannot set key cursor in CosNaming::BindingIterator
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2830 - Cannot set alternate key in CosNaming::BindingIterator
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2831 - Could not activate CosNaming::BindingIterator
ユーザアクション : 内部エラーです。コンパックの担当者に連絡してください。
2836 - Cannot unbind <name>
ユーザアクション : ネーミングデータベースファイルが存在していることと、ユーザが書込み権を持っ
ていることを確認してください。
3-152
140418J
付 録
付 録
相互運用オブジェクトの参照
サブトピックス
□ オブジェクト参照の作成
□ オブジェクト参照の内容
□ オブジェクトキー
□ 設定した TCP アドレスと実際の TCP アドレス
□ サーバプール上のオブジェクトに対する IOR
この付録では、
「IOR」(Interoperable Object References) の作成と、IOR に含まれる情報を理解するため
の技術詳細について解説します。
IOR の概要
分散オブジェクト上のメソッドを起動するため、NonStop DOM クライアントでは、OMG 文書『Universal
Networked Objects』で定義されている IOR が使用されます。IOR はサーバによって作成され、クライアン
トに対しては透過的です。オブジェクトのオブジェクト参照型は、クラス設計によって異なります。クラ
ス設計には、エンティティオブジェクトを、データベースレコードのような外部エンティティにリンクす
る方法などが含まれます。
オブジェクト参照はクライアントに渡され、その内容はクライアントから認識されます。しかし、オブ
ジェクト参照に含まれるオブジェクトキー情報は、クライアントからは認識されず、サーバによって使用
されます。
クライアントは、分散オブジェクトを、ローカルオブジェクトと同様に取り扱うことができます。クラ
イアントは、IOR の内容に関与する必要はありませんが、IOR の検索方法と、使用後に IOR を解放する方
法を知っている必要があります。
IOR には、NonStop DOM が、メソッド呼出し側 ( クライアントプロセス ) とメソッド実装側 ( サーバプ
ロセス内で実行されるオブジェクト ) との通信を可能にするための、プロトコル固有の情報が含まれてい
ます。デフォルトでは、NonStop DOM が、サーバプロセスに代わって自動的にオブジェクト参照を生成し
ます。サーバプロセスが、複数のプロトコル (Pathway とファイルシステムなど ) を使用するように構成さ
れている場合は、オブジェクト参照には、それぞれのプロトコルに固有の情報が含まれます。プロトコル
固有の情報には、次の内容が含まれます。
□ 特定のプロトコルを使用した場合の、サーバプロセスの検索方法
□ サーバプロセス内での、ターゲットオブジェクトインスタンスの検索方法
140418J
3-153
付 録 オブジェクト参照の作成
NonStop DOM は、次の 3 つの時点でサーバ IOR を生成します。
1. アプリケーションが CORBA::object_to_string() を呼び出したときに、明示的に生成
これは通常、IOR がクライアントに「手動で配信」される必要がある場合です。たとえば、システムの
最初のテスト中に、Name Service 相互動作の複雑性を排除したい場合などがこれにあたります。
2. オブジェクトが、out パラメータまたは操作の結果として返されるときに、黙示的に生成
Name Service の resolve( ) 操作などがこの例です。
3. オブジェクトが、in パラメータとして操作に渡されるときに、黙示的に生成
samples/bank/server/bank_main.cpp 内で、Name Service の rebind( ) 操作が呼
び出されるときなどがこの例です。
オブジェクト参照の内容
NonStop DOM IOR の内容は、サーバントの POA ポリシー、cfgmgt を使って有効化されたサーバプロト
コル、およびサーバプロセスの実際の配備によって異なります。cfgmgt について詳しくは、
『第 2 部
NonStop™ DOM 管理者ガイド』の「Configuration Tool の使用」を参照してください。
NonStop DOM IOR は、CORBA IOR 規則に準拠します (『CORBA v2.1, section 10.6.2』を参照 )。ただ
し、NonStop DOM は、IOP::TAG_MULTIPLE_COMPONENTS を認識しません。
NonStop DOM は、次の 3 つのプロファイルタグを認識します。
□
IOP::TAG_INTERNET_IOP (0)
□
NSDOM_GFS_IOP::Profile_Tag
□
NSDOM_GCF_IOP::Profile_Tag
これら 3 つのプロファイルはすべて、バージョン、アドレス、およびオブジェクトキーフィールドを含
みます。サーバで複数のプロトコルが有効になっている場合は、IOR 内に複数のプロファイルが存在しま
す。複数のプロファイルは、次のように、クライアントの要求度に準じて並べられます。
1. NSDOM_GCF_IOP::Profile_Tag
2. NSDOM_GFS_IOP::Profile_Tag
3. IOP::TAG_INTERNET_IOP
サーバが、Comm Server を使用するように構成されている (tcp_server true,
use_comm_
server) 場合は、tsmp_server と fs_server の両方またはどちらか一方が存在している必要が
あります。そうでないと、Comm Server がターゲットサーバにリクエストをリレーできません。
3-154
140418J
付 録
オブジェクトキー
IOP::TAG_INTERNET_IOP Addresses
NSDOM_GFS_IOP::Profile_Tag Addresses
NSDOM_GCF_IOP::Profile_Tag Addresses
オブジェクトキーは、3 種類のプロトコルすべてに対して共通です。オブジェクトキーは、NonStop DOM
の外部では無効です。おおまかに言えば、オブジェクトキーには、サーバのプロファイル、レポジトリ ID、
POA ポリシーマスク、および (tcp_server true, use_comm_server true) が含まれます。オブジェ
クトキーは、Comm Server が個々のリクエストをターゲットサーバにリレーするのに使用するアドレス指
定を含む、一連の「Relay プロファイル」です ( つまり、各リクエストには IOR は含まれず、オブジェク
トキーが、個々のリクエスト内でサーバによって供給される唯一のデータです )。
IOP::TAG_INTERNET_IOP Addresses
サーバ ( 後述の「備考」を参照 ) が、IIOP を有効化するように構成されている (tcp_server true) 場
合は、そのサーバ内のオブジェクト用に生成された IOR に、このプロファイルが追加されます。NonStop
DOM は、CORBA で定義された (『CORBA v2.1, section 12.7.2』を参照 ) IIOP プロファイルをサポートし
ています。ただし、NonStop DOM は IIOP::ProfileBody_1_1 はサポートしていません。ここで
ポイントとなるのは、host、port、および object_key フィールドの内容です。
host および port フィールドには、ドット付き 10 進記法での IP アドレスと、待機されるポートが含
まれます。IP アドレスとポートは、サーバ構成とサーバント POA の Lifecycle ポリシーに依存します。
サーバが use_comm_server で構成されているか、またはサーバントの POA の Lifecycle ポリシー
が Persistent に設定されている場合は、これらのフィールドには、LSD の実際のホスト名とポート番号が
含まれます (「設定した TCP アドレスと実際の TCP アドレス」を参照 )。その結果、そのようなサーバへ
『第 2 部 NonStop™ DOM 管理者ガ
の接続を試ると、まず LSD に接続されます。LSD の動作については、
イド』の「NonStop DOM アーキテクチャ」を参照してください。
サーバが、
「直接の」TCP サーバとして構成されて (use_comm_server でなく tcp_server が
真 ) いて、サーバントの POA の Lifecycle ポリシーが Transient に設定されている場合は、host および port
フィールドには、サーバの実際の TCP ホスト名とポート番号が含まれます (「設定した TCP アドレスと実
際の TCP アドレス」を参照 )。クライアントがそのようなサーバにコンタクトしようとすると、LSD を介
さず、サーバに直接接続されます。
NSDOM_GFS_IOP::Profile_Tag Addresses
サーバ ( 後述の「備考」を参照 ) が、Guardian File System 上で GIOP を有効化するように構成されてい
る (fs_server true) 場合は、プロファイルアドレスは、完全に記述された Guardian プロセス名に設定されま
す。NonStop DOM クライアントは、FILE_OPEN_ を使って、#NSDOMFS 「サブデバイス」で修飾された
プロセス名に接続します。
140418J
3-155
付 録 NSDOM_GCF_IOP::Profile_Tag Addresses
サーバが、TS/MP 上で GIOP を有効化するように構成されている (tsmp_server true、サーバが非
永続オブジェクトもサポートする場合は、fs_server も true で構成。< pathmon-process-name >,
server_class < server-class >) 場合は、プロファイルアドレスには <pathmon-process-name> と <server-class>
も含まれます。NonStop DOM クライアントは、IOR のオブジェクトキーが NonStop DOM によって生成さ
れ、POA の Lifecycle ポリシーが Persistent の場合に、このプロファイルを使用します。
備考 : ここでは、敢えて「サーバ」の意味をあいまいにしてあります。サーバプールとして配備された場合、
「サー
バ」はプール内のすべてのプロセスを意味します。そうでない場合は、
「サーバ」は単一のプロセスを意味し
ます。
設定した TCP アドレスと実際の TCP アドレス
「直接の」tcp サーバを構成する際は、host_name フィールドは、ドット付き 10 進記法でなく、名前
形式で入力することができます。さらに、ホスト名は複数の TCP プロセスにマップできるため、ホスト名
は多義にしておくことができます。この多義性は、tcp_process フィールドを使って解決されます。
また、次のように、port_number フィールドを 0 に設定して、TCP がポートを選択できるようにし
ておくこともできます。
例 1. 構成データベースレコード
cfgmgt> entity xyz_service@ORB
tcp_server true
tcp_process $ztc1
host_name
oss2.tandem.com
port_number 0
NonStop DOM の IOP::TAG_INTERNET_IOP プロファイルを構築する際、すべてのクライアント
に対して DNS/ ホストファイル構成をエクスポートしなくて済むように、プロファイルのホストフィール
ドは、ドット付き 10 進記法にする必要があります。また、ポートフィールドが 0 に設定されている場合
は、ポートフィールドには、TCP が選択した実際のポート番号が入っている必要があります。
これは、サーバによって実行されます。サーバは、ソケットのリッスンを正しく実行することで、実際
の TCP アドレスを構成データベースに書き込みます ( リッスンは、CORBA::ORB::ORB_init(
) メソッ
ド呼出し中に行われます )。直接の TCP サーバが実行されるたびに、actual_tcp_address エン
テ ィテ ィが 生成 され ます。こ のレ コー ドは、構 成デ ータ ベー ス内 で <pr ofi le> @ac tual _
tcp_address として表示され ます。前記の構成例に続いて、xyz サーバを実行した後 ( および
ORB_init( ) メソッドを呼び出した後 )、cfgmgt を使ってこのレコードを表示することができます。
例 2. 構成データベースレコード
cfgmgt> entity xyz_service@actual_tcp_address
host_name
204.160.16.38
port_number 1342
xyz サーバが実行されるたびに、新しい xyz_service@actual_tcp_address エンティティ
port_number を選択するため、
が表示されます。host_name は変更されませんが、TCP が xyz の
3-156
140418J
付 録
このフィールドは、毎回新しい値になります。
サーバプール上のオブジェクトに対する IOR(Interoperatable Object References)
このサブトピックでは、2 種類のサーバプールオブジェクトについて解説します。ステートレスオブジェ
クトとステートフルオブジェクトです。
□ サーバプール内のステートレスオブジェクトの IOR
□ サーバプール内のステートフルオブジェクトの IOR
サーバプール内のステートレスオブジェクトの IOR
ステートレスリクエスト ( ステートレスオブジェクトのメソッド呼出し ) は、サーバプール内の、空い
ているどのサーバプロセスにでも送ることができます。
次のリストは、NonStop DOM がステートレスオブジェクトのオブジェクト参照を作成および使用する
方法です。この場合は、サーバプールに関しては、クライアントはローカルでもリモートでもかまいませ
ん。クライアントがリモートの場合は、クライアントに代わって、Comm Server プロセスが、サーバプー
ルとのリンクを取得します。
□ クライアントプログラムがステートレスオブジェクト上のメソッドを呼び出す際、NonStop DOM が、
参照内の NonStop TS/MP プロトコル固有の情報を使って、クライアントと、サーバプール内で最もビ
ジーでないサーバプロセス ( ターゲットプロセス ) との間の、
新規 NonStop TS/MP リンクを確立します。
□ NonStop DOM が、クライアントからターゲットプロセスへのメソッドリクエストを送り、ターゲット
プロセスからの応答をクライアントに返します。
□ 応答を送ったあと、NonStop DOM が、クライアントとターゲットプロセス間の NonStop TS/MP リン
クを解除します。
この動作は、CORBA の、「リクエストごとのプロセス」に似ています。NonStop DOM が、各リクエス
トの処理のたびに新しい NonStop TS/MP リンクを確立するため、リクエストの際にロードバランシングが
発生します。
サーバプール内のステートフルオブジェクトの IOR
ステートフルリクエスト ( ステートフルオブジェクトのメソッド呼出し ) は、常に、オブジェクトが作
成されたプロセスに送られる必要があります。このため、NonStop DOM はステートフルオブジェクトの参
照を生成します。
次のリストは、NonStop DOM がステートフルオブジェクトのオブジェクト参照を作成および使用する
方法です。サーバプールに関しては、クライアントはローカルでもリモートでもかまいません。クライア
ントがローカルの場合は、クライアントに代わって、Comm Server プロセスが、サーバプールとのリンク
を取得します。
□ クライアントプログラムが、サーバプール内でステートフルオブジェクトの作成をリクエストする際、
NonStop DOM がサーバプール内でサーバプロセスを一意に識別する参照を生成し、返します。
□ クライアントプログラムがステートフルオブジェクト上のメソッドを呼び出すと、NonStop DOM が
サーバプール内のサーバプロセスを使用します。
140418J
3-157
付 録 □ NonStop DOM が、クライアントからターゲットプロセスへのメソッドリクエストを送り、ターゲット
プロセスからの応答をクライアントに返します。
ステートフルオブジェクトがいったん作成されると、すべてのメソッド呼出しは同じサーバプロセスに
送られます ( サーバプール内で最もビジーでないサーバプロセスに送られるのではありません )。ただし、
ステートフルオブジェクトを作成するためのメソッドリクエストは、通常、ステートレスオブジェクト
(factory) に渡されるため、サーバプール内で最もビジーでないサーバに送られます。この方法では、ステー
トフルオブジェクトが複数のプロセスに配分されるため、サーバプール全体でのロードバランスが一定に
保たれます。
ステートフルオブジェクトをホストするサーバプールの NonStop TS/MP 構成変数 (DELETEDELAY や
MAXLINKS など ) の設定については、
『第 2 部 NonStop™ DOM 管理者ガイド』の「NonStop TS/MP Process
Management」を参照してください。
3-158
140418J
索 引
索 引
（英数字）
A
Adapter Activator
Adapter Activator Association
unknown_adapter 操作 3-57
概要 3-56
3-59
C
COMM_FAILURE Minor Codes
3-131
CORBA
クライアントサーバから支払い勘定サーバへのブリッジ
3-90
CORBAServices
Event Service
3-99
E
Event Service
OMG 標準 3-99
イベントチャンネルの作成と配置
イベント通信
3-107
3-99
3-99
概要
コンシューマとサプライヤ
3-101
3-111
3-115
使用
例
F
factory
Factory::connect_in 3-98
Factory::Create の実装 3-92
Factory::wait 3-98
G
Guardian コマンドとファイル、OSS を通じた利用 3-80
I
Interface Repository Minor Codes 3-137
IOR(Interoperatable Object References)
オブジェクトキー 3-155
サーバプール 3-157
作成
3-154
設定した TCP アドレスと実際の TCP アドレス
内容
3-156
3-154
M
makefiles
3-82
N
NonStop DOM
140418J
3-159
索 引 アプリケーション開発、概要 3-21
アプリケーションコンポーネントの構築 3-82
アプリケーション設計 3-16
オブジェクトクラスの設計 3-17
O
ORB(Object Request Broker)、初期化 3-23
OSS
開発およびデバッグツール 3-81
環境開発 3-79
環境変数と env.sh ファイル
3-80
P
POA (Portable Object Adapter)
Adapter Activator 3-56
Servant Managers 3-46
State Policy
3-45
作成 3-37
参照の作成 3-45
ポリシーオブジェクト 3-39
マイナーコード 3-127
Postinvoke( ) 3-46
preinvoke( ) 3-46
S
Servant Managers
Default Servant 3-48
Servant Activator 3-49
Servant Locator 3-48
Servant Managers 3-46
SRL (Shared Runtime Library)、デバッグバージョンの有効化 3-87
T
thread_function
3-98
U
unknown_adapter( )
3-57
W
Worker
Worker::accept 3-98
Worker::do_pathsend の実装 3-93
Worker::find_server 3-98
Worker::handle_close 3-98
Worker::handle_event 3-98
Worker::handle_writeread 3-98
Worker インタフェースの実装 3-93
3-160
140418J
索 引
（五十音順）
あ
アプリケーション開発、概要 3-21
アプリケーションコンポーネント
NonStop DOM の構築 3-82
トラブルシューティング 3-83
アプリケーションの設計
NonStop DOM
3-16
3-13
分散オブジェクト
い
イベントコア 3-94
イベントチャネル、作成と配置
3-107
え
永続オブジェクトと非永続オブジェクト
永続オブジェクト 3-53
永続オブジェクトアプリケーションの要件
3-54
3-55
永続オブジェクトの POA サーバ実装例の概要
システム ID を持つ永続オブジェクト
非永続オブジェクト
3-55
3-52
3-84
3-69
インタフェース 3-74
情報 3-70
設計 3-69
呼出し 3-71
例 3-73
エラーメッセージログ
エラーログファシリティ
お
オブジェクト参照
解放 3-28
拡大と限定
3-64
3-25
3-24, 3-60
操作 3-62
オブジェクトラッパ 3-89
限定
取得
か
環境変数と env.sh ファイル
環境、OSS 開発
3-80
3-79
く
クライアント
ORB の初期化 3-23
3-23
オブジェクト参照の限定 3-25
アプリケーション開発
オブジェクト参照の取得
サーバブリッジ
3-94
使用不能なシステムコール
140418J
3-24, 3-60
3-28
3-161
索 引 スレッド化 3-66
メインの処理 3-97
メソッドの呼出し 3-26
例外処理 3-26
3-95
クライアントラッパ
さ
サーバ
アプリケーション開発 3-29
オブジェクト実装の作成 3-30
実装ヘッダファイルの作成 3-29
スレッド化 3-66
メインの処理 3-92
ユーザ例外の作成 3-31
ラッパ 3-90
参照
作成 3-45
相互運用オブジェクト 3-153
し
システムコール、使用不能 3-28
す
ストック例
MakeFile 3-4
NonStop DOM 上での実行 3-5
インタフェース実装 3-3
インタフェース定義 3-2
クライアントアプリケーションプログラム 3-3
ストックオブジェクト 3-2
ほかの ORBS 上での実行 3-6
3-66
概要 3-65
クライアントアプリケーション 3-66
サーバの実装 3-66
スレッド化
ポータブルスレッド化インタフェース 3-67
せ
設計
NonStop DOM アプリケーション 3-16
オブジェクトクラス 3-17
分散オブジェクトアプリケーション 3-13
て
デバッグ
エラーログファシリティ 3-69
デバッグ SRL(Shared Runtime Library) の有効化
3-87
と
トラブルシューティング、アプリケーションコンポーネント 3-83
トレースファシリティ
3-162
3-75
140418J
索 引
3-75
設計
3-76
トレース情報
トレースファシリティインタフェース
トレースファシリティの呼出し
例
3-78
3-76
3-77
3-85
トレース手続き
ひ
非永続オブジェクト 3-52
ふ
ブリッジ例 3-89
分散オブジェクトアプリケーションの設計
3-13
へ
ヘッダファイル、実装の作成 3-29
ほ
ポリシーオブジェクト 3-39
ま
マイナーコード
COMM Failure Minor Codes 3-131
Interface Repository Minor Codes 3-137
ORB Minor Codes 3-123
POA Minor Codes 3-127
め
メインの処理
クライアント 3-97
3-92
サーバ
メソッド
呼出し 3-26
ら
ラッパ
オブジェクト 3-89
クライアント
3-95
3-90
サーバ
れ
例
Event Service の使用法 3-115
unknown_adapter の実装 3-58
エラーログファシリティ 3-73
ストック
3-1
トレースファシリティ
ブリッジ
3-77
3-89
ほかの ORBS 上での実行 3-6
例外
処理 3-26
ユーザの作成
140418J
3-31
3-163
索 引 レガシーラッパ
3-164
3-89
140418J
第4部
NonStop™ JTS/OTS
ユーザーズ・ガイド
概要
NonStop™ JTS (Java Transaction Service) および NonStop™ OTS (Object
Transaction Service) は、既存の NonStop™ JORB/MP および NonStop™ DOM/
MP システムのインストールにアドオンする CORBA® サービスです。このマ
ニュアルでは、NonStop™ Kernel システム上での、JTS と OTS のインストー
ルと構成、および JTS と OTS を使ったプログラミングについて解説していま
す。
製品バージョン
NonStop™ JTS/OTS バージョン 1.0
リリース ID
Independent Product
マニュアル番号
142999J
発行日
2000 年 2 月
Document History
Edition
Part Number Product Version Earliest Supported Release Published
First
Second
Third
Fourth
127557
131054
138003
134268
D40
D41
D41
D42
November 1996
January 1997
October 1997
November 1997
New editions incorporate any updates issued since the previous edition.
A plus sign(+) after a release ID indicates that this manual describes function added to the
base release, either by an interim product modification(IPM) or by a new product version on
a .99 site update tape(SUT).
140418J
-1
目 次 目 次
第1章
NonStop JTS/OTS のインストール
1.1 NonStop JTS/OTS とは ........................................................................................................... 4-1
1.2 インストールの概要 ............................................................................................................... 4-1
1.2.1 SOFTDOC ファイル .................................................................................................... 4-2
1.3 NonStop JTS/OTS システム要件............................................................................................ 4-2
1.4 Software pax ファイルのコピー ............................................................................................. 4-2
1.4.1 FTP を使用した pax ファイルのコピー...................................................................... 4-2
1.5 ソフトウェアの解凍 ............................................................................................................... 4-4
1.6 NonStop JTS/OTS ファイル ................................................................................................... 4-5
第2章
NonStop OTS の構成と管理
2.1 NonStop OTS トランザクションマネージャの構成 ............................................................. 4-7
2.2 OTSTM サーバプールの管理 ................................................................................................. 4-8
2.2.1 OTSTM サーバプールの停止 ...................................................................................... 4-8
2.2.2 OTSTM サーバプールの再開 ...................................................................................... 4-8
2.2.3 OTSTM サーバプールの削除 ...................................................................................... 4-8
2.3 Transaction サービストレースの有効化 ................................................................................ 4-9
2.3.1 NonStop OTS アプリケーションのトレース ............................................................. 4-9
2.3.2 OTSTM サーバプールのトレース .............................................................................. 4-9
2.3.3 トレース出力 ................................................................................................................ 4-9
2.4 銀行のサンプル ..................................................................................................................... 4-10
第3章
NonStop JTS/OTS の概要
3.1 Transaction サービス ............................................................................................................ 4-11
3.2 トランザクションについて .................................................................................................. 4-11
3.2.1 仕様 ............................................................................................................................. 4-12
3.3 トランザクションの ACID 属性 .......................................................................................... 4-12
3.4 トランザクションオブジェクト (Transactional Objects).................................................... 4-13
3.4.1 トランザクションクライアント (Transactional Clients).......................................... 4-13
i
140418J
目 次
3.5 NonStop OTS Transaction Manager (OTSTM) .....................................................................4-13
3.6 2 相コミットプロセス ...........................................................................................................4-13
3.6.1 動作確認機能 ...............................................................................................................4-14
3.7 リソース管理機能 ..................................................................................................................4-14
3.8 トランザクションコンテキスト ...........................................................................................4-14
3.8.1 トランザクションコンテキストの伝播 .....................................................................4-15
3.9 トランザクションの制御 ......................................................................................................4-15
3.10 アプリケーションの移植性...................................................................................................4-15
第4章
NonStop OTS Clients の実装
4.1 Transaction サービス処理へのアクセス ...............................................................................4-17
4.1.1 IDL 内でトランザクションオブジェクトを定義する ..............................................4-18
4.1.2 アプリケーション IDL ファイルをコンパイルする .................................................4-18
4.1.3 クライアントヘッダファイルを含める .....................................................................4-18
4.1.4 nsdots.o ファイルをバインドする .............................................................................4-19
4.2 NonStop OTS クライアントの作成 ......................................................................................4-19
4.3 現在のオブジェクトへのアクセス .......................................................................................4-20
4.3.1 現在のオブジェクトを限定する ................................................................................4-20
4.4 トランザクションの開始 ......................................................................................................4-21
4.5 トランザクションオブジェクトへのリクエスト送信 .........................................................4-21
4.6 トランザクションの終了 ......................................................................................................4-22
4.7 設計時の注意点 ......................................................................................................................4-23
第5章
NonStop OTS サーバの実装
5.1 NonStop OTS サーバの作成 ..................................................................................................4-25
5.1.1 クライアントからリクエストを受け取る .................................................................4-26
5.2 アプリケーションサーバから Current へのアクセス ..........................................................4-27
5.3 Synchronization インタフェースの使用 ...............................................................................4-28
5.4 Synchronization オブジェクトの作成 ...................................................................................4-28
5.4.1 ステートフルオブジェクトとステートレスオブジェクト ......................................4-29
第6章
Transaction サービスインタフェース
6.1 Current インタフェース ........................................................................................................4-31
140418J
ii
目 次 6.1.1 Current::begin()........................................................................................................... 4-32
6.1.2 Current::commit() ....................................................................................................... 4-32
6.1.3 Current::rollback()....................................................................................................... 4-32
6.1.4 Current::rollback_only() ............................................................................................. 4-32
6.1.5 Current::get_status().................................................................................................... 4-33
6.1.6 Current::get_transaction_name()................................................................................. 4-33
6.1.7 Current::set_timeout() ................................................................................................. 4-33
6.1.8 Current::get_control() ................................................................................................. 4-33
6.1.9 Current::suspend()....................................................................................................... 4-33
6.1.10 Current::resume() ........................................................................................................ 4-33
6.2 TransactionalObject インタフェース ................................................................................... 4-34
6.3 Synchronization インタフェース .......................................................................................... 4-34
6.3.1 Synchronization::before_completion() ....................................................................... 4-34
6.3.2 Synchronization::after_completion() .......................................................................... 4-34
6.4 Coordinator インタフェース................................................................................................. 4-35
6.4.1 Coordinator::get_status()............................................................................................. 4-35
6.4.2 Coordinator::register_resource() ................................................................................. 4-36
6.4.3 Coordinator::register_synchronization() ..................................................................... 4-36
6.4.4 Coordinator::rollback_only() ...................................................................................... 4-37
6.4.5 Coordinator::get_transaction_name() ......................................................................... 4-37
6.4.6 Coordinator::get_txcontext()....................................................................................... 4-37
6.4.7 Coordinator::is_same_transaction() ............................................................................ 4-37
6.5 Resource インタフェース ..................................................................................................... 4-37
6.5.1 Resource::prepare() ..................................................................................................... 4-38
6.5.2 Resource::rollback() .................................................................................................... 4-38
6.5.3 Resource::commit()..................................................................................................... 4-38
6.5.4 Resource::commit_one_phase() .................................................................................. 4-38
6.5.5 Resource::forget() ....................................................................................................... 4-39
6.6 Control インタフェース ........................................................................................................ 4-39
6.6.1 Control::get_terminator() ............................................................................................ 4-39
6.6.2 Control::get_coordinator() .......................................................................................... 4-39
6.7 RecoveryCoordinator インタフェース ................................................................................. 4-39
6.7.1 RecoveryCoordinator::replay_completion() ............................................................... 4-39
iii
140418J
目 次
6.8 Transaction サービスインタフェースの概要 .......................................................................4-40
第7章
CosTransactions モジュール
表
140418J
表 4-1
NonStop JTS/OTS pax ファイル .......................................................................................4-2
表 4-2
NonStop JTS/OTS ファイルの詳細 .................................................................................4-5
表 4-3
Synchronization インタフェース処理 ............................................................................4-28
表 4-4
Get_status の戻り値 .................................................................................................4-35
表 4-5
CosTransaction モジュールインタフェースの概要.......................................................4-40
iv
第 1 章 NonStop JTS/OTS のインストール
第 1 章 NonStop JTS/OTS のインストール
サブトピックス
□ NonStop JTS/OTS とは
□ インストールの概要
□ NonStop JTS/OTS システム要件
□ ソフトウェア pax ファイルのコピー
□ ソフトウェアの解凍
□ NonStop JTS/OTS ファイル
1.1 NonStop JTS/OTS とは
「NonStop JTS (Java Transaction Service)/OTS (Object Transaction Service) 」とは、次の 2 つの Transaction
サービス製品を提供するソフトウェアパッケージです。
□「NonStop OTS」は NonStop DOM/MP 2.0 とともに使用します。
□「NonStop JTS」は NonStop JORB/MP 1.0 とともに使用します。
「NonStop OTS」は Object Management Group[tm] (OMG) で定義された「 Transaction Service Specification」
[formal/97-12-17] の実装です。「NonStop JTS」は Sun Micro Systems, Inc. によって定義された Java[tm]
Transaction API の実装です。
NonStop JTS/OTS は、既存の「NonStop DOM 2.0」または 「NonStop JORB 1.0」の上に直接インストー
ルされます。ソフトウェアパッケージに含まれる『第 1 部 NonStop™ DOM 入門ガイド』と『第 2 部
NonStop™ DOM 管理者ガイド』をお読みになり、製品のインストールや構成の手順をあらかじめご理解の
上、NonStop JTS/OTS をインストールしてください。
1.2 インストールの概要
ここでは、NonStop OTS および NonStop JTS のインストール手順について説明します。この 2 つの製品
は両方同時にインストールされますが、その際、NonStop DOM 2.0 または NonStop JORB 1.0 のどちらか
がインストールされている必要があります。
NonStop JTS/OTS ソフトウェアをインストールするには、次の手順が必要です。
1. ソフトウェア pax ファイルを適切な NonStop Kernel システムにコピーする。
2. ソフトウェアを解凍する。
製品 CD-ROM には、NonStop OTS と NonStop JTS の両方が 1 つの pax ファイルで供給されています。
OSS (Open System Services) pax ユーティリティを使用して、NonStop JTS/OTS ソフトウェアファイルを
OSS システム上に解凍およびインストールします。
140418J
4-1
第 1 章 NonStop JTS/OTS のインストール
ソフトウェアをインストールした後、
「NonStop OTS の構成と管理」の解説にしたがって正しく構成す
る必要があります。構成の手順は次の 2 つです。
1. OTS サーバの構成
2. Java JVM (Java Virtual Machine) 用の NonStop サーバの再構築
1.2.1 SOFTDOC ファイル
製品 CD-ROM に含まれる SOFTDOC ファイルには、製品に関する最新情報が記載されています。この
ファイルをお読みになってから、インストールを実行してください。
1.3 NonStop JTS/OTS システム要件
NonStop JTS/OTS は、NonStop DOM/MP 2.0 および NonStop JORB/MP 1.0 ソフトウェア用のアドオン
製品です。NonStop DOM/MP 2.0 および NonStop JORB/MP 1.0 は Tandem 製品です。各製品の『第 1 部
NonStop™ DOM 入門ガイド』を参考にして、これらの製品の両方またはどちらか一方をインストールして
から、NonStop JTS/OTS をインストールしてください。
NonStop JTS/OTS の最低リリース要件は D46 または G06 です。また、最新バージョンの NonStop TM/
MP (T8607D46 IPM ACA) がインストールされている必要があります。
1.4 Software pax ファイルのコピー
NonStop JTS/OTS 1.0 製品 CD-ROM には、サポートされるオペレーティングシステムごとに、2 種類の
版のソフトウェアが用意されています。それぞれの版は、表 4-1 のとおり、別々の pax ファイルに含まれ
ています。
表 4-1 NonStop JTS/OTS pax ファイル
プラットフォーム
CD 内でのディレクトリと pax ファイル名
D46
D46\T0313PAX
G06
G06\T0313PAX
「pax ファイル」とは、製品ソフトウェアを構成するテキストファイルとバイナリファイルを含む圧縮
ファイルです。適切な pax ファイルを NonStop Kernel システムにコピーしてからソフトウェアを解凍およ
びインストールしてください。
1.4.1 FTP を使用した pax ファイルのコピー
「FTP」はコンピュータ間のファイル転送手段として現在広く使われている便利な方法です。FTP を使用
するには、NonStop JTS/OTS CD がマウントされたコンピュータ上で FTP クライアントアプリケーション
を実行します。転送先 Tandem システム上では Tandem の FTP サーバ製品を実行している必要があります。
次の手順は、製品 CD-ROM がマウントされたシステム上でコマンドライン FTP クライアントが実行さ
れていることを前提としています。GUI ( グラフィックユーザインタフェース ) を備えた FTP アプリケー
ションを使用している場合は、手順内に書かれているコマンドは無視して、FTP ツールのグラフィカルコ
4-2
140418J
第 1 章 NonStop JTS/OTS のインストール
マンドを使用してください。
pax ファイルをコピーするには、次の手順を実行します。
1. 製品 CD-ROM がマウントされたシステム上でコマンドプロンプトウィンドウを開き、FTP クライアン
トアプリケーションを起動します。
> ftp
次の FTP プロンプトが表示されます。
ftp>
2. 転送先の Tandem システムに接続します。
ftp> open <tandem system host name> | <IP address>
ログイン名とパスワードが要求されます。
3. Tandem システムの正しいログイン名とパスワードを入力します。Tandem システムにログインした後、
そのログイン ID が $SYSTEM ボリュームに書き込み権を持っていることを確認してください。
4. ディレクトリ指定に OSS 構文を使用するため、API を oss に設定します。
ftp> quote oss
5. FTP ツール内で /G/SYSTEM/ZDOMOT20 ディレクトリに移動し、リモート (Tandem) システムを
設定します。
ftp> cd /G/SYSTEM/ZDOMOT20
6. 表 1 を参考にして、ローカルシステム上の CD の適切な製品ディレクトリに移動します。たとえば、CD
が D: ドライブにあり、G06 Tandem システムにインストールする場合は、次のコマンドを実行します。
ftp> lcd D:\G06
7. FTP 転送モードをバイナリに設定します。
ftp> binary
8. NonStop JTS/OTS pax ファイルを転送します。
ftp> put T0313PAX
9. FTP クライアントを終了します。
ftp> quit
140418J
4-3
第 1 章 NonStop JTS/OTS のインストール
1.5 ソフトウェアの解凍
NonStop JTS/OTS pax ファイルを OSS システムにコピーした後、OSS pax ユーティリティを使用して、
NonStop JTS/OTS ファイルを解凍し、ソフトウェアをインストールします。
デフォルトでは、NonStop JTS/OTS は、NonStop DOM および NonStop JORB パッケージと同じデフォ
ルトファイルディレクトリにインストールされます。このため、これらのパッケージをそれぞれのデフォ
ルトファイルディレクトリにインストールした場合は、NonStop JTS/OTS も自動的にそれぞれのデフォル
トファイルディレクトリにインストールされます。しかし、NonStop DOM 2.0 または NonStop JORB 1.0
をインストールするときに別のディレクトリを指定した場合は、NonStop JTS/OTS を解凍およびインス
トールするときに同じディレクトリを指定する必要があります。
NonStop JTS/OTS を解凍するには、次の手順を実行します。
1. TACL プロンプトで次のコマンドを入力し、OSS シェルを起動します。
> osh
2. NonStop DOM 2.0 または NonStop JORB 1.0 がインストールされていることを確認します。デフォルト
では、これらの製品のファイルは
/usr/tandem/nsdoms ディレクトリツリー内にあります。別
のディレクトリにインストールした場合は、指定したディレクトリ内にあります。
システムに NonStop DOM または NonStop JORB がインストールされていない場合は、各製品の『第 1
部 NonStop™ DOM 入門ガイド』を参照して、NonStop DOM 2.0 または NonStop JORB 1.0 をインス
トールしてください。
3. 現在のユーザが NonStop DOM の /usr ディレクトリに書き込み権を持っていることを確認します。
4. 次の OSS コマンドを入力します。pax ユーティリティが実行され、NonStop JTS/OTS ファイルがデフォ
ルトディレクトリ内に解凍されます。
> pax -rvf /G/SYSTEM/ZDOMOT20/T0313PAX
別のディレクトリを指定するには、pax プログラムの
-s オプションを使用します。-s オプションを
使用すると、NonStop OTS と NonStop JTS 両方のファイルの解凍先ディレクトリを指定することがで
きます。
> pax -rvf /G/SYSTEM/ZDOMOT20/T0313PAX
[-s:/usr/tandem/nsdoms:<custom-nsdom-directory>:]
[-s:/usr/tandem/java:<custom-java-directory>:]
<custom-nsdom-directory> は、NonStop DOM 2.0 OSS のインストール
ディレクトリを指定するための変数で、<custom-java-directory> は、NonStop Server for
このコマンド内の
Java のインストールディレクトリを指定するための変数です。
備考 : システムに前バージョンの NonStop JTS/OTS がインストールされている場合は、新しい製品をインストー
ルすると、前のファイルが上書きされます。必要な NonStop OTS ファイルをバックアップしてから新しい
製品をインストールすることをおすすめします。
4-4
140418J
第 1 章 NonStop JTS/OTS のインストール
1.6 NonStop JTS/OTS ファイル
pax コマンドを使用して NonStop JTS/OTS ファイルを解凍すると、表 4-2 の表に示した各ディレクトリ
にファイルが解凍されます。この表は、$NSD_ROOT 環境変数が NonStop DOM セットアップのルート
ディレクトリに設定されていて、$JAVA_HOME 環境変数が NonStop Server for Java のインストールの
ルートディレクトリに設定されていることを前提としています。
表 4-2 NonStop JTS/OTS ファイルの詳細
ディレクトリ
内
容
$NSD_ROOT/
NonStop JTS/OTS readme ファイルを追加します。
$NSD_ROOT/bin/
シェルスクリプトと実行可能ファイルを追加します。
$NSD_ROOT/lib/
OTS ライブラリとバックアップ JTS ライブラリファイル
を更新します。
$NSD_ROOT/lib_env/
OTS ライブラリの環境形式を追加します。
$JAVA_HOME/oss/nssjava/
JTS が有効にされた JORB の再構築のために jts.jar ファ
イルとライブラリファイルを追加します。
$NSD_ROOT/samples
NonStop OTS サンプルファイルの最上位ディレクトリ
$NSD_ROOT/javasamples
NonStop JTS サンプルファイルの最上位ディレクトリ
NonStop JTS/OTS をインストールした後、システムを構成する必要があります。システムの構成につい
て詳しくは、「NonStop OTS の構成と管理」を参照してください。
140418J
4-5
第 2 章 NonStop OTS の構成と管理
第 2 章 NonStop OTS の構成と管理
サブトピックス
□ NonStop OTS トランザクションマネージャの構成
□ OTSTM サーバプールの管理
□ Transaction サービストレースの有効化
□ 銀行のサンプル
NonStop OTS ソフトウェアパッケージを解凍すると、「NonStop OTS トランザクションマネージャ」
(OTSTM) が既存の NonStop DOM システム上にインストールされます。OTSTM はサーバプロセスのひと
つで、トランザクションを処理する前に構成および開始しておく必要があります。
OTSTM は、インストール済みの NonStop DOM の構成に追加するサーバプロセスです。OTSTM は、
NonStop DOM システム内でほかのサーバプールを実行しているのと同じ PATHMON プロセス内で実行す
るサーバプールとして構成します。OTSTM サーバプロセスをいったん実行した後は、NonStop DOM シス
テム内のほかのサーバプールと同じように管理することができます。
備考 : NonStop OTS トランザクションマネージャを構成するには、NonStop DOM システムが起動し、実行され
ている必要があります。NonStop DOM のインストールと実行について詳しくは、
『第 1 部 NonStop™ DOM
入門ガイド』を参照してください。
2.1 NonStop OTS トランザクションマネージャの構成
OTSTM の構成とは、既存の NonStop DOM 構成データベースに OTSTM サーバプール設定を追加する
ことです。サーバプールの構成には、NonStop JTS/OTS パッケージに含まれる otsconfigure スクリ
プトファイルを使用します。NonStop JTS/OTS をインストールすると、このスクリプトファイルが NonStop
DOM の bin/ ディレクトリにコピーされます。
OTSTM を構成するには次の手順を実行します。
1. NonStop DOM システムの環境変数が設定済みで、NonStop DOM PATHMON プロセスが実行中である
ことを確認します。
2. OSS プロンプトで otsconfigure スクリプトを実行します。
> otsconfigure
otsconfigure スクリプトによって、NSotsTM@ORB エンティティが NonStop DOM 構成データ
ベースに追加されます。同様に、OTSTM サーバプールが既存の NonStop DOM PATHMON プロセスに追
加されます。エンティティの追加後、スクリプトによってサーバプールが初期化され開始されます。
OTSTM サーバは、OTS factory の IOR を、com.cpq.nsdom.NSotsTM という名前を使ってネー
ミングサービスデータベースに登録します。OTSTM サーバはまた、そのストリング化された IOR を
NonStop DOM ルートファイルである tm.ior に書き込みます。
140418J
4-7
第 2 章 NonStop OTS の構成と管理
2.2 OTSTM サーバプールの管理
NonStop DOM PATHMON プロセス内で実行されているほかのサーバプールと同様、OTSTM サーバ
プールを管理するときも、PATHCOM インタフェースを使用します。このプロセスについての詳細は『第
2 部 NonStop™ DOM 管理者ガイド』の「PATHCOM インターフェイスを使用して Nonstop TS/MP プロセ
スを維持するには」を参照してください。このプロセスの利用を支援するため、NonStop JTS/OTS には、
次のスクリプトが用意されています。これにより、NonStop OTS サーバプールの管理が簡単になります。
□
otsstop
□
otsstart
□
otsunconfigure
これらの各スクリプトは、生成された出力をすべて NonStop DOM の log/ ディレクトリにある
otscom.log ファイルに転送します。
2.2.1 OTSTM サーバプールの停止
OTSTM サーバプールを一時的にシャットダウンするには、NonStop DOM の bin/ サブディレクトリ
otsstop スクリプトを実行します。このスクリプトによって、OTSTM サーバを実行している
にある
サーバプールがフリーズおよび停止されます。
備考 :
otsstop を実行後、$zNO プロセスがしばらく PENDING 状態になることがありますが、これは異常で
はありません。
2.2.2 OTSTM サーバプールの再開
一時的に停止した OTSTM サーバプールを再開するには、otsstart スクリプトを実行します。これ
により、OTSTM サーバを実行しているサーバプールのフリーズが解除され、再開されます。
2.2.3 OTSTM サーバプールの削除
NonStop DOM システム構成から OTSTM サーバプールを削除するには、次の手順を実行します。
1. 前述の otsstop スクリプトを実行します。
2. otsunconfigure スクリプトを実行します。これで OTSTM サーバプールが削除されます。
unconfigure が完了される前に、$zN0 プロセスが PENDING 状態から外れる必要があります。
4-8
140418J
第 2 章 NonStop OTS の構成と管理
2.3 Transaction サービストレースの有効化
Transaction サービストレースは、アプリケーションレベルまたは OTSTM サーバプールレベルで有効化
することができます。
2.3.1 NonStop OTS アプリケーションのトレース
NonStop OTS アプリケーションのトレースを有効にするには、次の OSS (Open System Services) エクス
ポートコマンドを使用して、NSDOM_CFG_TRACE_OTS 環境変数を設定します。
export NSDOM_CFG_TRACE_OTS = TRUE
環境変数を解除するには、次のコマンドを実行します。
unset NSDOM_CFG_TRACE_OTS = TRUE
2.3.2 OTSTM サーバプールのトレース
OTSTM サー バプ ール のト レ ース を有 効に する には、NonStop DOM PATHMON プ ロセ ス内 で
NSDOM_CFG_TRACE_OTS 変数を TRUE に設定します。この変数を設定するには、まず NonStop
PATHMON プロセスをターゲットとして、PATHCOM を実行します。PATHCOM 内に入ったら、次のコ
マンドを実行して変数を設定します。
alter otstm, env NSDOM_CFG_TRACE_OTS = 1
2.3.3 トレース出力
アプリケーションまたは OTSTM サーバプールでトレースを有効にすると、トレースが
$NS_ROOT/
log/ots.out ファイルに出力されます。
トレースについての詳細は、
『第 3 部 NonStop™ DOM プログラマーズ・ガイド』を参照してください。
140418J
4-9
第 2 章 NonStop OTS の構成と管理
2.4 銀行のサンプル
NonStop JTS/OTS のインストールと構成が終了した後、サンプルプログラムを実行して、Transaction
サービスをテストすることができます。NonStop JTS/OTS をインストールすると、NonStop DOM の
samples/ ディレクトリに、NonStop OTS サンプルが 2 つインストールされます。
sa m p l e s / o t s _ b a n k _ e nv/ ディ レク トリ 内の ファ イル は環 境ベ ース の例 外を 使用 し、
samples/ots_bank/ ディレクトリ内のファイルは、C++ 言語の try および catch キーワードに
基づく例外を使用してクライアントアプリケーションとサーバアプリケーションを実装します。
NonStop DOM とともに供給される銀行のサンプルに基づく OTS サンプルは、NonStop OTS を利用した
ト ラ ン ザ ク シ ョ ン の 作 成 方 法 の デ モ ン ス ト レ ー シ ョ ン を 行 い ま す。サ ン プ ル は、
CosTransactions::TransactionalObject から導出されたサーバオブジェクトを実装しま
す。銀行口座と相互に通信するサーバオブジェクトは、クライアントアプリケーション内で実装された
ots_client オブジェクトから操作されます。
NonStop OTS を使ったアプリケーションの構築例として、これらのディレクトリのファイルを参照して
ください。
4-10
140418J
第 3 章 NonStop JTS/OTS の概要
第 3 章 NonStop JTS/OTS の概要
サブトピックス
□ Transaction サービス
□ トランザクションについて
□ トランザクションの ACID 属性
□ トランザクションオブジェクト (Transactional Objects)
□ NonStop OTS トランザクションマネージャ (OTSTM)
□ 2 相コミットプロセス
□ リソース管理機能
□ トランザクションコンテキスト
□ トランザクションの制御
□ アプリケーションの移植性
3.1 Transaction サービス
「NonStop JTS/OTS」とは、次の 2 つの Transaction サービス製品を含むソフトウェアパッケージです。
□「NonStop OTS」は NonStop DOM/MP 2.0 とともに使用します。
□「NonStop JTS」は NonStop JORB/MP 1.0 とともに使用します。
これらの Transaction サービス製品によって分散オブジェクト間のトランザクション処理がサポートさ
れ、既存の CORBA 準拠システム内の相互運用トランザクション処理に対応して、CORBA モデルを拡張
します。
NonStop JTS/OTS に用意されている Transaction サービスの概要と、それらが Tandem NonStop
ここでは、
Kernel 環境でどのようにサポートされているかについて解説します。
3.2 トランザクションについて
「トランザクション」という言葉は、クライアントが 1 つまたは複数のオブジェクトに変更を加えること
ができる「作業の単位」という意味を持っています。トランザクション処理の最後では、トランザクショ
ン中に行われた変更をコミットするかまたはロールバックするかの決定が行われます。これは、トランザ
クションに関連したすべての作業の結果に基づいて、関係者全員で行う決定です。
トランザクションを「コミットする」とは、トランザクション中に行われた変更をすべて保持すること
です。トランザクションを「ロールバック」( 又はアボート ) するとは、トランザクション中に行われた変
更をすべて破棄し、トランザクションにかかわるオブジェクトの状態を、トランザクション開始前と同じ
140418J
4-11
第 3 章 NonStop JTS/OTS の概要
状態に保持することです。トランザクション処理中にエラーが発生した場合も、トランザクションがロー
ルバックされます。
トランザクション処理によって、アプリケーションのアクセス先データに対する複数の変更を処理する
ことができます。
3.2.1 仕様
OMG Transaction Service Specification [formal/97-12-17] には、OMG の IDL ( インタフェース定義言語 )
で定義されているオブジェクトと演算を持つ
CosTransactions モジュールについて書かれていま
す。CosTransactions で定義された演算は、X/Open のトランザクション処理モデルと同調するよう
に設計されました。これらの Transaction サービスインタフェースを使用することにより、分散オブジェク
トが、異種の CORBA 準拠システム間で相互動作することができ、またトランザクション処理を実行でき
ます。
Sun Micro Systems, Inc. の『Java Transaction API』の中で、JTS (Java Transaction Service) およびそのイ
ンタフェースが定義されています。JTS は OMG Transaction Service Specification に基づいて設計されまし
た。JTS で定義されているインタフェースは、OMG の IDL 言語で表現することができ、これによって Java
クライアントおよびサーバが、複数の CORBA 準拠のシステムにわたってトランザクションを制御するこ
とができます。
3.3 トランザクションの ACID 属性
トランザクションとは、
「ACID 属性」を持つ作業単位のことで、トランザクション処理と同義語です。
1 つまたは複数のシステム上に分散されたトランザクション内では、トランザクション制御に関する下位
レベルの詳細の実行に、通常「トランザクションマネージャ」が使用されます。次に示す ACID 属性によ
り、トランザクションマネージャが行うトランザクション処理の安全性と信頼性が確保されます。
□「Atomic」( 原子性 ): トランザクション内で行われた変更のすべてをコミットするか、またはすべてを
ロールバックするとき、そのトランザクションは「原子性」を持っているといいます。トランザクショ
ンは「オールオアナッシング」である必要があります。
□「Consistent」( 一貫性 ): トランザクションは、システムの特定の一貫性を持つ状態から別の一貫性を持
つ状態へと移る必要があります。そうすることで、トランザクションは、システムの不変の属性を維持
する必要があります。
□「Isolated」( 隔離性 ): トランザクションによって実行される「作業単位」は、作業実行中にシステムに
アクセスするほかのエンティティからは隠されている必要があります。また、トランザクション中の状
態は、ほかのトランザクションや、トランザクションが実行されているデータにアクセスしているほか
のオブジェクトからは見えないようにする必要があります。トランザクションは、同時に実行されてい
ても、逐次的に実行されているように見えます。
□「Durable」( 持続性 ): 完了しコミットされたトランザクションの結果はすべて、持続的に保持される必
要があります。
これにより、トランザクションは、システムの特定の一貫性をもつ状態から別の一貫性を持つ状態へと
移動する、逐次的操作となります。
4-12
140418J
第 3 章 NonStop JTS/OTS の概要
3.4 トランザクションオブジェクト (Transactional Objects)
OMG Transaction Service Specification では、トランザクションの範囲内で呼び出されることによって動
作が影響を受けるオブジェクトを、
「トランザクションオブジェクト」と定義しています。トランザクショ
ンオブジェクトは通常、トランザクションの範囲内で作成されたリクエストによって変更される可能性が
ある永続データを含むか、または間接的に参照します。
3.4.1 トランザクションクライアント (Transactional Clients)
クライアントは、トランザクションオブジェクトおよび非トランザクションオブジェクトを組み合わせ
たリクエストを作成することができます。ただし、トランザクションの範囲内でリクエストを作成したク
ライアントアプリケーションは、トランザクションクライアントと呼ばれます。
3.5 NonStop OTS Transaction Manager (OTSTM)
NonStop JTS/OTS アプリケーションを作成する際に最も考えるべきことは、トランザクションの範囲内
で作成されるリクエストを発行し処理するクライアントとサーバです。トランザクション処理の下位レベ
ルの詳細は、NonStop OTS トランザクションマネージャ (OTSTM) によって透過的に処理されます。
OTSTM は、NonStop DOM または NonStop JORB システムでほかのシステムプロセスを実行する
PATHMON プロセスのもとで実行されるよう、インストールおよび構成されたサーバプールプロセスで
す。OTSTM によって、トランザクション処理の間、トランザクションの ACID 属性が保たれていること
が保証されます。OTSTM は NonStop TM/MP とともに働き、2 相のコミットプロトコルを制御することに
よって、トランザクションの終了処理中、すべてのトランザクションデータの完全性を維持します。
OTSTM は、Transaction サービスで定義されたインタフェースに大きく依存します。NonStop OTS では、
これらのインタフェースは、nsdots.o オブジェクトファイル内に実装されています。NonStop JTS で
は、インタフェースは、Java が有効化された JVM の構築に使用する jts.jar ファイルに含まれていま
す。
3.6 2 相コミットプロセス
OTSTM では、2 相コミットプロセスによって、トランザクション処理に関連付けられた ACID 属性を
各トランザクションが保持していることを保証します。
2 相コミットについて説明する前に、まずロールバック処理について説明します。
トランザクションが終了する際、トランザクションのすべての関連処理は、コミットまたはロールバッ
クする必要があります。トランザクションの処理中に、関連処理がロールバックの必要性を検出した場合、
ロールバックが指示されます。OTSTM はそのトランザクションスレッドの関連処理全てに対してロール
バック呼び出しを起動することで、このリクエストを処理します。
トランザクションをコミットする処理もロールバックと同じように行われますが、コミットする場合は
2 つの手順で実行されます。
第 1 段階は、トランザクションの範囲内で作業を行うために起動されたすべてのオブジェクトが、呼び
出しから返されたときに実行されます。この時点では、すべてのトランザクション関連処理が、トランザ
クションの更新を表示させるか、またはトランザクション作業の自分の分担部分を取り消せるステートを
確立します。未処理のトランザクション操作がすべて返された時、クライアントが commit() を起動し
140418J
4-13
第 3 章 NonStop JTS/OTS の概要
ま す。この リクエ スト の処理 のた め、OTSTM は、ト ラン ザク ション のす べての 関連 処理に 対し て
prepare() を実行します。
prepare() によって、各関連処理に、トランザクションの変更を保持してコミットしてよいかどう
かが尋ねられます。ここで、トランザクションの各関連処理は、トランザクションの最終結果をコミット
するかロールバックするかを「決定」します。
この第 1 段階で得た応答に基づいて、コミットプロトコルの第 2 段階が開始されます。すべてのトラン
ザクション関連処理がコミットを選択した場合、OTSTM によって、各関連処理に対して
commit() が
呼び出され、トランザクションが終了されます。この呼び出しの後、トランザクション内で行われたすべ
ての変更が保持されます。
しかし、関連処理が 1 つでもコミットを選択しなかった場合、トランザクションのすべての関連処理に
対して rollback() が起動されます。これにより、トランザクション処理内で行われたすべての変更が
破棄されます。
3.6.1 動作確認機能
OTSTM に実装された「トランザクション動作確認機能」により、トランザクションの完全性がさらに
維持されます。動作確認機能により、トランザクションがコミットされる前に、すべてのクライアント側
のトランザクション操作が正しく完了したことが確認されます。Transaction サービスではこの機能によっ
て、トランザクションに関与するすべてのトランザクションオブジェクトが、それぞれのトランザクショ
ンリクエストの処理を終えてはじめて、コミットが成立することが保証されます。
3.7 リソース管理機能
Transaction Service Specification には「リソース管理機能」が記述されています。これは、トランザク
ションに関与するデータベースのことです。NonStop JTS/OTS では、NonStop SQL/MP および Enscribe の
2 つのリソース管理機能がサポートされます。これらのリソース管理機能によって、トランザクションの
コミットに必要なすべての変更が保持されます。
これらのリソース管理機能と OTSTM 間の相互通信のため、「NonStop トランザクションマネージャ /
MP」(NonStop TM/MP) が使用されます。
備考 : NonStop TM/MP の動作については、NonStop TM/MP のソフトウェアパッケージに含まれる一連のマニュ
アルに詳しく記載されています。NonStop TM/MP の使用方法および異常事態からの復元方法については、
これらのマニュアルを参照してください。
3.8 トランザクションコンテキスト
クライアント / サーバ環境では、通常、クライアントが begin() を起動した時にトランザクションが
開始されます。クライアントのリクエストは、リクエストの処理能力を持つサーバオブジェクトに送られ
ます。トランザクションに関連するすべてのリクエストが返された後、クライアント ( トランザクション
を開始した ) はトランザクション完了のリクエストを実行できます。
クライアントがトランザクションを開始すると、クライアントスレッドに関連付けられたトランザク
ションコンテキストが生成されます。トランザクションコンテキストは、特定のスレッドに関連付けられ
たトランザクション情報です。トランザクションに関係するオブジェクトは、このトランザクションコン
4-14
140418J
第 3 章 NonStop JTS/OTS の概要
テキストによって、トランザクションの持続中、トランザクションスレッドとの継続性を保持します。
3.8.1 トランザクションコンテキストの伝播
トランザクションの「伝播」とは、クライアントのトランザクションコンテキストと、トランザクショ
ンオブジェクトによって実行される操作とを関連付ける動作のことです。Transaction Service Specification
では、黙示的と明示的の 2 種類の伝播が定義されています。NonStop JTS/OTS では現在、黙示的伝播だけ
がサポートされています。
「黙示的伝播」では、リクエストに関連付けられたトランザクションコンテキストは、ORB によってリ
クエストとともに自動的に伝播されます。リクエストを処理するサーバは、クライアントのトランザクショ
ンを「共有」します。この場合、トランザクションコンテキストはクライアントからの直接の介在なしに、
黙示的に送信されます。
「明示的伝播」では、トランザクションコンテキストは、クライアントからオブ
ジェクトサーバに、パラメータとして直接送られます。
3.9 トランザクションの制御
OMG Transaction Service Specification には、トランザクション制御の 2 つのモデルについて詳細に記載
されています。
□「間接的なコンテキスト管理」では、トランザクションコンテキストと、制御のアプリケーションスレッ
ドの関連付けに、Current オブジェクトが使用されます。
□「直接的なコンテキスト管理」では、トランザクションの制御に、ほかのオブジェクトとともに
Control オブジェクトが使用されます。
NonStop JTS/OTS アプリケーションでは通常、間接的コンテキスト管理が使用され、クライアントは
CosTransactions::Current() インタフェースを使用してトランザクションを作成および制御
します。しかし、アプリケーションは、Control オブジェクトにアクセスすることによって、トランザ
クションを直接管理することもできます。たとえば、保留中のトランザクションを再開するような場合で
す。
NonStop JTS/OTS では、特別なトランザクションコンテキストに関するリクエスト作成のために、直接
的なコンテキスト管理もサポートされていますが、このトランザクション制御方法はおすすめできません。
3.10 アプリケーションの移植性
異種の CORBA 準拠 Transaction サービス間でアプリケーションを移植可能にするためには、アプリケー
ションに「フラットトランザクションモデル」が実装されている必要があります。フラットモデルでは、
Transaction サービスがすべてのトランザクションを最上位トランザクションとして扱う必要があります。
チャイルドトランザクションや「ネストされた」トランザクションを持つことはできません。フラットト
ランザクションモデルによって、NonStop JTS/OTS サーバオブジェクトは、異種の OTS から起動されたト
ランザクションに関係することができます。
備考 : Transaction Service Specification には、フラットトランザクションおよびネストされたトランザクション
の両方が記載されており、ネストされたトランザクションはオプション機能とされています。移植性を最大
にするため、NonStop OTS ではフラットトランザクションだけをサポートしています。
140418J
4-15
第 4 章 NonStop OTS Clients の実装
第 4 章 NonStop OTS Clients の実装
サブトピックス
□ Transaction サービス処理へのアクセス
□ NonStop OTS クライアントの作成
□ 現在のオブジェクトへのアクセス
□ トランザクションの開始
□ トランザクションオブジェクトへのリクエスト送信
□ トランザクションの終了
□ 設計時の注意点
OMG Transaction Service Specification には、アプリケーション内でトランザクション機能を実装する際
に使用するインタフェースを備えた、CosTransactions モジュールについて書かれています。
CosTransactions モジュールでは、OMG インタフェース定義言語 (IDL) でインタフェースが定義さ
れます。これらのインタフェースは、ほかのオブジェクトの IDL 定義への継承が可能で、これによってト
ランザクション機能を備えることができます。
ここでは、NonStop Kernel システム上で実行されている CORBA 準拠のクライアントでの、トランザク
ションの開始、処理、および終了方法について説明します。
ここで使用されているプログラミングインタフェースについては、「Transaction サービスインタフェー
ス」を参照してください。
4.1 Transaction サービス処理へのアクセス
NonStop JTS/OTS でのプログラミング作業には、トランザクションを開始および終了するクライアント
アプリケーションの作成と、クライアントが作成したトランザクションリクエストを処理するサーバオブ
ジェクトの作成が含まれます。
アプリケーションにトランザクション作業能力を持たせるには、次の手順を実行します。
1. アプリケーション IDL ファイル内でトランザクションオブジェクトを定義する。
□ アプリケーション IDL ファイル内に CosTransactions.idl モジュールを含める。
□ IDL ファイルの各トランザクションオブジェクトごとに、
CosTransactions::TransactionalObject からの継承を行う。
2. アプリケーション IDL ファイルをコンパイルする。
3. 適切なクライアントヘッダファイルをアプリケーションモジュールに含める。
4. アプリケーションオブジェクトとオブジェクトファイル nsdots.o をバインドする。
140418J
4-17
第 4 章 NonStop OTS Clients の実装
4.1.1 IDL 内でトランザクションオブジェクトを定義する
トランザクションオブジェクト作成の最初の手順は、アプリケーション IDL ファイル内で、オブジェク
トをトランザクションオブジェクトとして定義することです。
次の IDL コードは、アプリケーションインタフェースを定義する IDL ファイルに、CosTransactions.idl
Account イン タフ ェー スが
CosTransactions::TransactionalObject からどのように継承されてトランザクションオ
フ ァイ ルを 含め る方 法を 示し てい ます。ま た、アプ リケ ーシ ョン の
ブジェクトとなっているかも示しています。
//
account.idl
#include "CosTransactions.idl"
interface Account : CosTransactions::TransactionalObject
{
// Some IDL interfaces for the Account object
short do_credit ( in long value);
short do_debit ( in long value);
// The rest of your application IDL
}
4.1.2 アプリケーション IDL ファイルをコンパイルする
適切なトランザクション宣言をアプリケーション IDL ファイルに追加した後、ファイルをコンパイルし
て、アプリケーションスタブとスケルトンを生成することができます。C++ マッピングを指定すると、IDL
コンパイラによって次のファイルが生成されます。<IDL_name> は IDL モジュール名または IDL イン
タフェース名です。
□
<IDL_name>_client.h
□
<IDL_name>_client.cpp
□
<IDL_name>_server.h
□
<IDL_name>_server.cpp
たとえば、前述の小さな IDL ファイルを使用した場合、<IDL_name> は「account」となります。
4.1.3 クライアントヘッダファイルを含める
トランザクションオブジェクトに対するリクエストの作成元である各ソースコードファイルに、
CosTransactions_client.h および <IDL_name>_client.h の 2 つのヘッダファイルを
含める必要があります。
たとえば、前述の IDL を使用する場合なら、アプリケーションソースファイルに account_client.h
を含めます。CosTransactions_client.h も含める必要がありますが、これは手動で行う必要は
ありません。CosTransactions.idl が IDL ファイル内に含められた時に、IDL コンパイラによっ
て自動的に account_client.h に CosTransactions_client.h が含められます。
次のクライアントソースコード例では、account.idl ファイル内で定義されたトランザクションオ
ブジェクトにプロトタイプを供給するヘッダファイル
4-18
account_client.h が含められるようすを示
140418J
第 4 章 NonStop OTS Clients の実装
しています。
#include
#include
#include
#include
<iostream.h>
<stdlib.h>
"naming_client.h"
"account_client.h"
// Transactional object’s header
この例では、#include 指令に、含めるファイルの相対パス情報が指定されていません。これは、
makefile アプリケーションが、PATH 環境変数を使って、適切なシステムディレクトリをポイントするこ
とを前提としているためです。
4.1.4 nsdots.o ファイルをバインドする
NonStop OTS では、Transaction サービスインタフェースと処理はオブジェクトファイル nsdots.o 内
で実装されます。アプリケーションで Transaction サービス処理を使用可能にするには、アプリケーション
と nsdots.o をリンクします。最も簡単な方法は、クライアントおよびサーバモジュールの構築に使用
する makefile を修正して、nsdots.o をアプリケーションクライアントとサーバにリンクすることです。
次の例では、makefile によってクライアントのオブジェクトファイルが構築されるようすを示していま
す。
include
OBJs =
../macros.mk
client.o account_client.o
$(NSD_LIB)/nsdots.o
NonStop JTS/OTS をデフォルトディレクトリにインストールした場合は、nsdots.o オブジェクト
ファイルは /usr/tandem/nsdoms/bin にあります。
4.2 NonStop OTS クライアントの作成
通常、トランザクションの開始と終了は、アプリケーションのクライアント側で実行します。この場合、
クライアントがトランザクションを開始し、トランザクションオブジェクトに対するリクエストを作成し、
トランザクションを終了します。
トランザクションオブジェクトに対してリクエストが作成されると、クライアントのトランザクション
コンテキストが黙示的にターゲットオブジェクトに送られます。この詳細は NonStop OTS コンポーネント
によって透過的に処理されるため、アプリケーションのプログラマが介在する必要はありません。
通常、トランザクションオブジェクトに対してリクエストを起動するには、次の手順を実行します。
1. 現在のオブジェクトにアクセスする。
2. トランザクションを開始する。
3. トランザクションオブジェクトにリクエストを送信する。
4. トランザクションを終了する ( コミットまたはロールバック )。
140418J
4-19
第 4 章 NonStop OTS Clients の実装
4.3 現在のオブジェクトへのアクセス
CosTransactions::Current オブジェクトは、クライアントがクライアントプロセスとトラ
ンザクションコンテキストの関連付けを黙示的に管理するための処理を行います。
CosTransactions::Current オブジェクト内の処理は、トランザクションの開始、保留、情報
取得、および終了に使用されます。
CosTransactions::Current オブジェクトは擬似オブジェクトです。クライアントがこのオブ
ジェクトを使用するには、まずオブジェクト参照を取得する必要があります。最初に、呼び出しのパラメ ー
"TransactionCurrent" を使って resolve_initial_reference()
を呼び出し、CosTransactions::Current にアクセスします。この呼び出しによって、CORBA
タとして文字列値
オブジェクト参照が返されます。次にコード例を示します。
// Get a CORBA object reference
CORBA::Object_ptr ots_corba_obj = NULL;
try
{
ots_corba_obj =
ORB->resolve_initial_reference("TransactionCurrent");
}
catch ( CORBA::Exception, &exception )
{
cout << "resolve_initial_reference(\"TransactionCurrent\")
failed" << endl;
return;
}
catch (...)
{
cout << "resolve_initial_reference(\"TransactionCurrent\")
failed" << endl;
return;
}
4.3.1 現在のオブジェクトを限定する
CORBA オブジェクト参照を取得したら、次に参照を限定して、使用可能な CosTransactions::Current
オブジェクト参照を取得します。次にコード例を示します。
// Narrow the CORBA object reference to CosTransactions::Current
CosTransactions::Current_ptr ots_current =
CosTransactions::Current::_narrow( ots_corba_obj );
if ( ots_current == NULL ) {
cout << "CosTransactions::Current::_narrow failed." << endl;
return;
}
4-20
140418J
第 4 章 NonStop OTS Clients の実装
4.4 トランザクションの開始
CosTransactions::Current::begin() 処理を呼び出すことにより、クライアントがトラ
ンザクションを開始します。Current::begin() への呼び出しが正しく返されると、トランザクショ
ンコンテキストがクライアントのスレッドに関連付けられます。その後、クライアントはトランザクショ
ンオブジェクトに対してリクエストを作成することができ、クライアントのトランザクションコンテキス
トがターゲットサーバに黙示的に伝播されます。
次のコードはトランザクションの開始例です。
// Begin a transaction
try
{
ots_current->begin( );
}
catch ( CORBA::Exception, &exception )
{
cout << "OTS Current::begin failed" << endl;
return;
}
catch ( ... )
{
cout << "OTS Current::begin failed" << endl;
return;
}
4.5 トランザクションオブジェクトへのリクエスト送信
CosTransactions::Current::begin() の処理に際して、NonStop OTS はクライアントス
レッドに関連付けられるトランザクションコンテキストを生成します。その後クライアントはトランザク
ションの範囲内でリクエストを開始することができます。
次のコード例は、クライアントがトランザクションオブジェクト上で処理を開始して、特定の金額で掛
売りするようすを示しています。
// Credit an account
// Get reference to account object
// ...
//process a credit transaction
try
{
account_obj->do_credit(2000000);
}
catch ( CORBA::Exception, &exception )
{
cout << "account_obj->do_credit failed" << endl;
return;
}
catch ( ... )
{
cout << "account_obj->do_credit failed" << endl;
return;
}
140418J
4-21
第 4 章 NonStop OTS Clients の実装
4.6 トランザクションの終了
クライアントは、1 つのトランザクションコンテキストに関連して、いくつでもリクエストを作成する
ことができます。トランザクションコンテキストに関連付けられたリクエストがすべてクライアントに返
された時、クライアントは、トランザクションを終了することができます。クライアントがトランザクショ
ンを終了すると、そのトランザクションに関してデータベースに加えられたすべての変更内容がコミット
またはロールバックされます。
次のコード例は、クライアント側でトランザクションをコミットするようすを示しています。
// Commit a transaction
try
{
ots_current->commit(false);
}
catch ( CORBA::Exception, &exception )
{
cout << "OTS Current::commit failed" << endl;
return;
}
catch ( ... )
{
cout << "OTS Current::commit failed" << endl;
return;
}
commit() 処理実行中にシステム例外エラーが発生した場合は、クライアントは
CosTransactions::Current::rollback() を呼び出してトランザクションをアボートする
必要があります。
備考 :
CosTransactions::Current::commit() は、ブールパラメータを使用して、ヒューリス
ティックな決定がレポートされるべきかどうか示します。NonStop JTS/OTS でプログラミングを行う場合
は、ヒューリスティックな決定はサポートされていないため、値「false」を送る必要があります。
次のコード例は、クライアント側でトランザクションをロールバックするようすを示しています。
// Rollback a transaction
try
{
ots_current->rollback();
}
catch ( CORBA::Exception, &exception )
{
cout << "OTS Current::rollback failed" << endl;
return;
}
catch ( ... )
{
cout << "OTS Current::rollback failed" << endl;
return;
}
4-22
140418J
第 4 章 NonStop OTS Clients の実装
4.7 設計時の注意点
クライアント / サーバ環境でプログラミングする場合は、アプリケーションの実装に 「3 階層分散アプ
リケーションモデル」を使うことがよくあります。3 つの階層はすべて、1 つのシステム上でホストされる
単一のアプリケーション内で実装することもできますし、複数の異なるシステム上に分散したクライアン
トおよびサーバとして存在することもできます。このように 3 階層モデルは概念的な性質を持っています
が、このモデルの概念は、アプリケーションモジュールのさまざまな役割を区別するのに便利です。
3 階層分散アプリケーションモデルでは、第 1 階層は通常、アプリケーションユーザインタフェースを
表します。たとえば、32 ビット Windows™ プラットフォーム上で実行されるアプリケーションのような、
表層の GUI プログラムです。このモデルでは、第 1 階層のオブジェクトが、第 2 階層のオブジェクトと相
互に通信します。
第 2 階層には、アプリケーションの実際のビジネスロジックを実装するビジネスオブジェクトが含まれ
ます。これらの第 2 階層オブジェクトは、第 3 階層のオブジェクトと相互に通信します。第 3 階層のオブ
ジェクトは通常、データベースオブジェクトです。
NonStop JTS/OTS でプログラミングする際は、3 階層クライアント / サーバモデルを使ってアプリケー
ションを設計すると便利です。このモデルを使用する場合、第 1 階層オブジェクト ( ユーザインタフェー
ス ) は、第 2 階層オブジェクトへの呼び出しを実行することによって作業のリクエストを作成します。
たとえば、第 2 階層を、Tandem NonStop Kernel システム上でホストされる NonStop DOM または
NonStop JORB アプリケーションサーバにします。そうすると、第 2 階層は、トランザクションを開始し、
トランザクション関連の作業を実行し ( または第 3 階層のオブジェクトに作業を行うよう要求し )、トラン
ザクションを終了することにより、トランザクションを一括して管理します。
第 3 階層は、トランザクションコンテキストを必要とするデータベース操作を実行する、データベース
オブジェクトをホストします。たとえば、第 3 階層オブジェクトを、NonStop DOM または NonStop JORB
アプリケーションサーバにします。NonStop JTS/OTS データベースオブジェクトは、オブジェクト指向ア
クセスを可能にする CORBA ラッパに実装された NonStop SQL/MP データベースまたは Enscribe データ
ベースにアクセスします。
クライアントやサーバは、単にアプリケーションの役割であるため、1 つのトランザクションの処理中
に、1 つのアプリケーションオブジェクトがクライアントとサーバの両方の役割を果たすことも可能です。
第 2 階層上で実行されているビジネスオブジェクトは、トランザクションリクエストを受信するとサーバ
になります。このオブジェクトはその後、第 3 階層のデータベースオブジェクトに呼び出しを行う際、ク
ライアントになります。
トランザクションが完了すると、第 2 階層オブジェクトは、第 1 階層のユーザインタフェースに結果を
返します。
140418J
4-23
第 5 章 NonStop OTS サーバの実装
第 5 章 NonStop OTS サーバの実装
サブトピックス
□ NonStop OTS サーバの作成
□ アプリケーションサーバから Current へのアクセス
□ Synchronization インタフェースの使用
NonStop OTS トランザクションサーバの作成とは、主にサーバオブジェクトを修正してトランザクショ
ンオブジェクトにすることです。そのためには、サーバオブジェクトの IDL 定義内の
CosTransactions::TransactionalObject インタフェースを継承します。
NonStop OTS クライアント / サーバアプリケーションの実装の際、通常のケースでは、トランザクショ
ンに関するリクエストをすべてクライアント内に置きます。この場合は、クライアントがトランザクショ
ンを起動し、トランザクション関連作業をリクエストし、トランザクションを終了します。トランザクショ
ンの範囲内でリクエストが作成されると、トランザクションオブジェクトは、トランザクションコンテキ
ストを含むリクエストを受け取ります。トランザクションの範囲内で作成されたリクエストを処理するた
めには、サーバオブジェクトがトランザクションオブジェクトである必要があります。サーバ側では、
NonStop OTS が下位レベルのトランザクション詳細を処理します。
別のケースでは、トランザクションコンテキストに関連付けられた作業の実行のため、トランザクショ
ンオブジェクトが新しいリクエストを起動しなければならない場合があります。この場合は、トランザク
ションオブジェクトがほかのサーバオブジェクトにリクエストを送る際、クライアントとしての役割に変
わります。多くの場合、新しいリクエストはリモートトランザクションオブジェクトに対して送られます。
さらに別のケースでは、Synchronization インタフェースの操作を使って、トランザクションサー
バに機能を追加することができます。この場合は、トランザクションの終了前後に、サーバが NonStop OTS
からの作業リクエストを受け取ることができます。
ここでは、これらのトランザクションサーバの実装方法すべてについて説明します。ここで使用されて
いるプログラミングインタフェースについては、
「Transaction サービスインタフェース」を参照してくださ
い。
5.1 NonStop OTS サーバの作成
NonStop JTS/OTS トランザクションに関与するには、アプリケーションオブジェクトがトランザクショ
ンオブジェクトである必要があります。それにより、トランザクションの範囲内で起動されたリクエスト
の処理が可能になります。
アプリケーションサーバオブジェクトからトランザクションオブジェクトを作成するには、オブジェク
トが
CosTransactions::TransactionalObject インタフェースを継承する必要がありま
す。このようなオブジェクトによって、トランザクションの範囲内で起動されたリクエストの処理能力を
持つサーバオブジェクトが作成されます。
140418J
4-25
第 5 章 NonStop OTS サーバの実装
次の IDL コードは、CosTransactions::TransactionalObject インタフェースの継承を
示しています。Account オブジェクトがトランザクションオブジェクトにされています。
//
account.idl
#include "CosTransactions.idl"
interface Account : CosTransactions::TransactionalObject
{
// Some IDL interfaces for the Account object
short do_credit ( in long value);
short do_debit ( in long value);
// The rest of your application IDL
}
TransactionalObject インタフェースには操作がありません。これは NonStop DOM ORB への
フラグとして働き、トランザクションの範囲内でサーバオブジェクトが起動される必要があることを表し
ます。このフラグはまた、サーバオブジェクトでは、トランザクションコンテキストがリクエストととも
に黙示的に伝播される必要があることも示しています。
NonStop OTS では、トランザクションに関与するために、サーバオブジェクトにほかの変更を加える必
要はありません。トランザクションオブジェクトにされた後、そのオブジェクトはトランザクションコン
テキストを含むリクエストを受け取ることができます。クライアントがトランザクションの範囲内で操作
を実行すると、NonStop OTS は呼び出し元のトランザクションコンテキストを、呼び出し先オブジェクト
に黙示的に送ります。
備考 : トランザクションオブジェクト作成のため、現在は TransactionalObject インタフェースを継承する必要が
あります。しかし OMG は、この作業を実行するために POA ポリシーを使用しなければならないような決
定をする可能性があります。その場合は、追加のトランザクション POA ポリシーを提供するサーバコード
を実装する必要があります。
5.1.1 クライアントからリクエストを受け取る
トランザクションオブジェクトは、非トランザクションオブジェクトと同じように、クライアントのリ
クエストを受け取り、処理します。トランザクションオブジェクトは、トランザクションコンテキストを
含むリクエストを処理しますが、トランザクションコンテキストに関連する下位レベルのサーバアクショ
ンは、アプリケーションのプログラマが作成するサーバコードからは完全に隠れています。ほとんどの場
合、トランザクションの下位レベルの詳細は NonStop OTS に処理させます。
4-26
140418J
第 5 章 NonStop OTS サーバの実装
5.2 アプリケーションサーバから Current へのアクセス
CosTransactions::Current オブジェクトへアクセスしなけれ
ばならない場合があります。トランザクションオブジェクトは、Current を使用して、現在のトランザ
アプリケーションサーバから
クションコンテキストのステータスを取得したり、新しいトランザクションを開始したりします。たとえ
ば、Current::suspend() を使うと、クライアントのトランザクションコンテキストを保留するこ
とができ、Current::begin() を使うと、別のオブジェクト上にリクエストを起動して、新しいト
ランザクションを開始することができます。新しいリクエストによって新しいトランザクションコンテキ
ストが作成され、新規リクエストを処理するサーバに黙示的に伝播されます。
CosTransactions::Current にアクセスするときは、クライアントオ
"TransactionCurrent" を パラ メー タと して 使用 して、
resolve_initial_reference() を呼び出します。サーバオブジェクトもクライアントオブジェ
サーバオブジェクトが
ブ ジェ クト と同 じよ うに、文 字列
クトと同じように、呼び出しから返されたオブジェクト参照を限定する必要があります。次のコードはこ
の手順の実行例です。
// Get a CORBA object reference
CORBA::Object_ptr ots_corba_obj = NULL;
try
{
ots_corba_obj =
ORB->resolve_initial_reference("TransactionCurrent");
}
catch ( CORBA::Exception, &exception )
{
cout << "resolve_initial_reference(\"TransactionCurrent\")
failed" << endl;
return;
}
catch (...)
{
cout << "resolve_initial_reference(\"TransactionCurrent\")
failed" << endl;
return;
}
// Narrow the CORBA object reference to CosTransactions::Current
CosTransactions::Current_ptr ots_current =
CosTransactions::Current::_narrow( ots_corba_obj );
if ( ots_current == NULL ) {
cout << "CosTransactions::Current::_narrow failed." << endl;
return;
}
CosTransactions::Current インタフェース内で操作を実行するためには、トランザクション
オ ブ ジ ェ ク ト の ア プ リ ケ ー シ ョ ン ソ ー ス モ ジ ュ ー ル に、ク ラ イ ア ン ト ヘ ッ ダ フ ァ イ ル
CosTransactions_client.h が含まれている必要があります。次のコード例を参照してくださ
い。
140418J
4-27
第 5 章 NonStop OTS サーバの実装
#include <iostream.h>
#include <stdlib.h>
#include "CosTransactions_client.h"
client header
// Transactional
5.3 Synchronization インタフェースの使用
トランザクションオブジェクトにより多くの機能と制御を与えるため、CosTransactions::
Synchronization インタフェースを使用することができます。これにより、トランザクションによっ
て作成された修正がコミットされる前に、呼び出しの受け取りや処理を実行させることができます。また
必要に応じて、Synchronization インタフェースを使用して、トランザクションの終了後にも、ト
ランザクションオブジェクトに呼び出しの受け取りや処理を実行させることができます。
このような機能を提供するため、Synchronization インタフェースは、次の 2 つの操作を提供し
ています。
表 4-3 Synchronization インタフェース処理
処 理
before_compeltion()
説
明
commit() の処理前に、NonStop JTS/OTS トランザクションマ
ネージャによって呼び出されます。
after_compeltion()
トランザクションの終了後に、NonStop JTS/OTS トランザクション
マネージャによって呼び出されます。
5.4 Synchronization オブジェクトの作成
Synchronization オブジェクトを作成するには、トランザクションオブジェクトの IDL 定義の
CosTransactions::Synchronization インタフェースを継承します。
CosTransactions::Synchronization イ ン タ フ ェ ー ス は 、 そ の 定 義 内 で
Cos T r a n s a c t i o n s : : T ransactionalObject から 継承 され てい ます。つ まり、
Synchronization オブ ジェ クト は、TransactionalObject であ ると いう こと です。
Synchronization インタフェースから継承されるオブジェクトは、TransactionalObject
インタフェースの属性も継承しています。このため、Synchronization オブジェクトサーバ作成の際に、
Synchronization イ ン タ フ ェ ー ス と CosTransactions::TransactionalObject
インタフェースの両方から継承する必要はありません。
次の IDL コードは、Synchronization オブジェクトの作成例を示しています。
//
account.idl
#include "CosTransactions.idl"
interface Account : CosTransactions::Synchronization
{
// Some IDL interfaces for the Account object
4-28
140418J
第 5 章 NonStop OTS サーバの実装
short do_credit ( in long value);
short do_debit ( in long value);
// The rest of your application IDL
}
5.4.1 ステートフルオブジェクトとステートレスオブジェクト
CosTransactions::TransactionalObject インタフェースだけを継承するオブジェクト
サーバは、ステートレスオブジェクトです。この場合、オブジェクトはステートを持っていません。つま
り、そのオブジェクトがアクセスする重要なデータはすべて、ディスク上に保持されるか、または別のオ
ブジェクト内に保管されます。ステートレスオブジェクトでは、トランザクション内での変更はすべて、
発生と同時にディスクに書き戻されます。( トランザクションの変更をディスクに保存することは、コミッ
トすることとは違います。コミットは、NonStop OTS トランザクションマネージャによって処理されます。)
ステートフルオブジェクトとは、変更されたデータをメモリ内に保持しているオブジェクトのことです。
オブジェクトは、オブジェクト自身についての情報を含む「ステート」を持っています。I/O を減らすた
め、一連の特定の処理が実行された後にだけ、変更済みデータを保持したい場合などは、ステートフルオ
ブジェクトを作成します。
Synchronization オブジェクトを使用して、ステートフルオブジェクトを実装することができま
す。実装するには、トランザクションがコミットプロセスを開始する前に、before_completion()
を使って変更をディスクに書き込みます。これでステートがフラッシュされます。
140418J
4-29
第 6 章 Transaction サービスインタフェース
第 6 章 Transaction サービスインタフェース
サブトピックス
□ Current インタフェース
□ TransactionalObject インタフェース
□ Synchronization インタフェース
□ Coordinator インタフェース
□ Resource インタフェース
□ Control インタフェース
□ RecoveryCoordinator インタフェース
□ Transaction サービスインタフェースの概要
OMG Transaction Service Specification には、CosTransactions モジュールのインタフェースが 10 種類も
定義されています。これらすべてのインタフェースの概要はこのトピックの末尾に記載されていますが、
NonStop JTS/OTS を使用したクライアントとサーバの実装でキーとなるのは、そのうちのいくつかです。
NonStop JTS/OTS トランザクションオブジェクトの実装に使用する主要な CosTransaction イン
タフェースについて以下に詳しく解説します。
6.1 Current インタフェース
トランザクションクライアントにとって、もっとも触れる機会の多いのが、Current インタフェース
です。このインタフェースによって、クライアントが、トランザクションを開始および終了し、また現在
処理中のトランザクションのステータスを取得することができます。Current インタフェース内の操作
を使用することで、クライアントは、トランザクションを開始、管理、終了することができます。
Current インタフェースは、黙示的に伝播されたトランザクションとともに働くよう設計されてお
り、次の操作をサポートします。
□ begin()
□ commit()
□ rollback()
□ rollback_only()
□ get_status()
□ get_transaction_name()
140418J
4-31
第 6 章 Transaction サービスインタフェース
□ set_timeout()
□ get_control()
□ suspend()
□ resume()
6.1.1 Current::begin()
begin() は、新しいトランザクションを作成します。トランザクションが作成されると、クライアン
トスレッドのトランザクションコンテキストが、新しいトランザクションへの関連付けを含むよう変更さ
れます。
NonStop JTS/OTS では、ネストされたトランザクションはサポートされないため、クライアントは、そ
のクライアントに関連付けられたトランザクションがほかに存在しないときだけ
begin() を呼び出す
ことができます。トランザクションは常に「最上位」トランザクションである必要があります。begin()
を呼び出したときに、クライアントスレッドに関連付けられたトランザクションがすでに存在すると、
begin() によって SubtransactionsUnavailable 例外エラーが返されます。
6.1.2 Current::commit()
トランザクションに関連するリクエストがすべて正しく返された後、クライアントは commit() を呼
び出してトランザクションの変更を永続的にすることができます。
トランザクションがコミットされると、そのトランザクションに関連付けられたトランザクションコン
テキストは null になります。
クライアントスレッドにトランザクションが関連付けられていない状態で commit() を実行すると、
NoTransaction 例外エラーが返されます。また、クライアントスレッドがトランザクションをコミッ
トする権利を持っていない場合に commit() を実行すると、NO_PERMISSION 標準例外エラーが返
されます。
6.1.3 Current::rollback()
トランザクションに関連するリクエストが 1 つでも正しく返されなかった場合は、クライアントは
rollback() を呼び出して、トランザクションの変更を取り消すことができます。トランザクションが
ロールバックされると、関連付けられたトランザクションコンテキストは null になります。
commit() と同様、クライアントスレッドにトランザクションが関連付けられていない状態で
rollback() を実行すると、NoTransaction 例外エラーが返されます。クライアントスレッドが
トランザ ク シ ョ ン を ロ ー ル バ ッ ク す る 権 利 を 持 っ て い な い 場 合 に rollback() を実行する
と、NO_PERMISSION 標準例外エラーが返されます。
6.1.4 Current::rollback_only()
rollback_only() を使用すると、たとえ commit() が呼び出されてもトランザクションの変更
が永続的にされないよう、フラグを設定することができます。これは、データベースに変更を加えないで、
トランザクション処理を監視したい場合に便利です。
4-32
140418J
第 6 章 Transaction サービスインタフェース
クライアントスレッドにトランザクションが関連付けられていない状態で
rollback_only() を
実行すると、NoTransaction 例外エラーが返されます。
6.1.5 Current::get_status()
get_status() を実行すると、現在のトランザクションのステータスが返されます。ステータスに
ついて詳しくは表 4-4 を参照してください。クライアントスレッドにトランザクションが関連付けられて
いない状態で get_status() を実行すると、StatusNoTransaction という値が返されます。
6.1.6 Current::get_transaction_name()
get_transaction_name() を実行すると、現在のクライアントトランザクションを記述した、
印刷可能な文字列が返されます。これはデバッグに使用します。クライアントスレッドにトランザクショ
ンが関連付けられていない状態で get_transaction_name() を実行すると、空の文字列が返され
ます。
6.1.7 Current::set_timeout()
set_timeout() を使用すると、begin() で開始されたトランザクションがコミットされない場
合に、自動的にロールバックされるまでの待機時間を、秒で定義することができます。これは、トランザ
クションスレッド管理に使用する重要な操作です。
この操作によって送られるパラメータは、タイムアウトを秒で表す状態変数を設定します。パラメータ
値がゼロの場合は、タイムアウトが設定されません。
6.1.8 Current::get_control()
get_control() を実行すると、クライアントの現在のトランザクションコンテキストに関連付けら
れた Control オブジェクトへの参照が返されます。このオブジェクト参照はその後、このコンテキスト
の再確立のため、resume() に送られます。
クライアントが現在トランザクションを処理していない場合は、null オブジェクト参照が返されます。
6.1.9 Current::suspend()
Current::suspend() を実行すると、現在のトランザクションスレッドの処理が一時停止されま
す。Current::resume() で再開されます。
これは、現在の Control オブジェクトへの参照が返されるという点で get_control() と似てい
ます。しかし、返された参照がクライアントによって保持され、その後の resume() への呼び出しに送
られるという点で異なっています。
クライアントが現在トランザクションを処理していない場合は null オブジェクト参照が返されます。
6.1.10 Current::resume()
resume() では、Control オブジェクトへの参照がパラメータとして使用されます。オブジェクト
参照が、現在の実行環境で有効なトランザクションを表している場合は、クライアントスレッドは、前の
トランザクションに代わって、そのトランザクションと関連付けられます。トランザクションが存在しな
い状態で
140418J
resume() を実行すると、InvalidControl 例外エラーが返されます。resume() に
4-33
第 6 章 Transaction サービスインタフェース
null オブジェクト参照を送ると、クライアントスレッドは、どのトランザクションとの関連付けも失いま
す。
6.2 TransactionalObject インタフェース
TransactionalObject は、トランザクションサーバのために提供されているインタフェースで
す。TransactionalObject から継承されているオブジェクトが呼び出されると、呼び出しを行っ
たクライアントのトランザクションコンテキストが、ターゲットサーバに黙示的に伝播されます。その後
ターゲットサーバは
Current オブジェクト上で get_control() を呼び出し、トランザクション
コンテキストを表すオブジェクトを取得することができます。この場合、ターゲットサーバはクライアン
トとして動作します。
TransactionalObject イ ン タ フ ェ ー ス に は 、 操 作 が 含 ま れ ず 、 ま た 定 義 も さ れ て い ま
せ ん 。 TransactionalObject は、そのオブジェクトが、トランザクションの範囲内で作業を処理
できることを示すための、単なるマーカです。
6.3 Synchronization インタフェース
Synchronization インタフェースを使用して、オブジェクトが 2 相コミットを行う前後に実行さ
れ る、トランザ クショ ンオブ ジェクト 内での 処理を 実装する ことが できま す。これは、before_
completion() および after_completion() の 2 つの操作を使って行います。
6.3.1 Synchronization::before_completion()
が
before_completion() は、2 相コミットプロトコルが開始される前、つまり Coordinator
prepare() への呼び出しを行う前に使用されます。この操作を使用して、トランザクション終了前
の特定の処理を実行します。
6.3.2 Synchronization::after_completion()
af t e r _ c o m p e l t i o n ( ) は、すべ ての コミ ット また はロ ール バッ クの 応答 が、関連 する
Coordinator オブジェクトによって受け取られた後に使用されます。この呼び出しを行うには、
get_status() への呼び出しによって取得したトランザクションの現在のステータスを、入力パラ
メータとして使用する必要があります。この操作を使用して、トランザクション完了後の特定の処理を実
行します。
4-34
140418J
第 6 章 Transaction サービスインタフェース
6.4 Coordinator インタフェース
Coordinator インタフェースで提供される操作によって、トランザクションサーバがトランザク
ションを管理することができます。
Transaction Service Specification では、Coordinator インタフェースの操作が多数紹介されています
が、そのうちのいくつかは、ネストされたトランザクションに関するものです。NonStop JTS/OTS ではネ
ストされたトランザクションはサポートしていません。NonStop JTS/OTS でサポートされる次の操作につ
いて、以下に詳しく解説します。
□ get_status()
□ register_resource()
□ register_synchronization()
□ rollback_only()
□ get_transaction_name()
□ get_txcontext()
□ is_same_transaction()
6.4.1 Coordinator::get_status()
get_status() を実行すると、ターゲットオブジェクトに関連付けられたトランザクションのス
テータスが返されます。返される値は、次の表のとおりです。
表 4-4 Get_status の戻り値
ステータス
StatusActive
説
明
トランザクションが動作中です。開始されており、Coordinator は
まだ prepare() または rollback() 呼び出しを行ってい
ません。
StatusMarkedRollback
トランザクションがロールバックに設定されています。たとえば、
rollback_only() が実行された後の状態です。
StatusPrepared
トランザクションが準備中です。下位レベルがすべて
VoteCommit を実行しました。この状態にあるターゲットトラ
ンザクションは、次の処理に関する上位の命令を待機しています。
StatusCommitted
トランザクションのコミットプロセスが完了しました。この場合、
ヒューリステックが存在しています。そうでなければ、トランザ
クションが破棄され、StatusNoTransaction が返されて
いるはずです。
140418J
4-35
第 6 章 Transaction サービスインタフェース
ステータス
説
明
StatusRolledBack
トランザクションの結果がロールバックされました。この場合、
ヒューリステックが存在しています。なぜなら、トランザクショ
ンは通常、ロールバック後に破棄され、ステータスが
StatusNoTransaction に変わっているはずだからです。
StatusUnknown
トランザクションがターゲットオブジェクトに関連付けられてい
ますが、Transaction サービスが現在のステータスを特定できませ
ん。これは一時的な状態であり、別の呼び出しによって別のス
テータスが返されます。
StatusNoTransaction
ターゲットオブジェクトに関連付けられたトランザクションがあ
りません。トランザクションがすでに完了しているか、またはト
ランザクションが開始されていません。
StatusPreparing
トランザクションが準備処理中です。リソースの応答を待機して
いることが考えられます。
StatusCommitting
トランザクションがコミット処理中です。リソースの応答を待機
していることが考えられます。
StatusRollingBack
トランザクションがロールバック処理中です。リソースの応答を
待機していることが考えられます。
6.4.2 Coordinator::register_resource()
register_resource() を使用して、Resource オブジェクトを、トランザクションの関連処
理として登録します。トランザクションが終了する際、Resource オブジェクトは、コミットまたはロー
ルバックするようリクエストされます。
この操作では RecoveryCoordinator オブジェクトが返されます。これは、回復が必要となった
際に、関連する Resource オブジェクトによって使用されます。
トランザクションが準備された後にこの操作を呼び出すと、Inactive 例外エラーが返されます。ま
た、トランザクションが rollback_only に設定されている場合は、TRANSACTION_ROLLEDBACK
標準例外エラーが返されます。
6.4.3 Coordinator::register_synchronization()
register_synchronization() を実行すると、指定された Synchronization オブジェ
クトが Coordinator オブジェクトとともに登録されます。それにより、登録したリソース上で
Coordinator が prepare() を呼び出す前に、必要な処理を実行するよう、Synchronization
オブジェクトに要求されます。詳しくは、「Synchronization インタフェース」を参照してください。
この操作により、次の例外エラーが返されることがあります。
□ トランザクションが準備されている場合は、Inactive 例外が返されます。
□
Coordinator が Synchronization をサポートしていない場合は、
SynchronizationUnavailable 例外が返されます。
□ トランザクションが rollback_only に設定されている場合は、TRANSACTION_ROLLEDBACK が返
される場合があります。
4-36
140418J
第 6 章 Transaction サービスインタフェース
6.4.4 Coordinator::rollback_only()
rollback_only() を使用して、トランザクションを強制的にロールバックするよう設定できます。
トランザクションが準備された後にこの操作を実行すると、Inactive 例外エラーが返されます。
6.4.5 Coordinator::get_transaction_name()
get_transaction_name() を実行すると、ターゲットオブジェクトに関連するトランザクショ
ンを記述した、印刷可能な文字列が返されます。これはデバッグに使用します。
6.4.6 Coordinator::get_txcontext()
get_txcontext() を呼び出すと、PropagationContext オブジェクトが返されます。これ
はトランザクションの相互動作性のために使用します。返されたオブジェクトは、現在のトランザクショ
ンを表しており、これは、特定の Transaction サービスドメインから別の Transaction サービスドメインに
エクスポートすることができます。
6.4.7 Coordinator::is_same_transaction()
is_same_transaction() は、Coordinator オブジェクトを入力パラメータとして使用しま
す。ターゲットオブジェクトとパラメータオブジェクトが同じトランザクションを参照している場合だけ、
true が返されます。
6.5 Resource インタフェース
Resource インタフェースには、Coordinator オブジェクトとともに登録された各 Resource オブ
ジェクト上で呼び出される操作が定義されています。Coordinator は Resource インタフェースを
使用して、登録されたリソースに対して要求されるトランザクション結果を知らせ、コミットまたはロー
ルバックの決定を収集し、最終的なトランザクションコマンドを配信します。Coordinator は、1 つ
のトランザクションと黙示的に関連付けられていますが、複数の独立した Resource オブジェクトをサ
ポートすることができます。
トランザクションを完了させるには、トランザクション Coordinator とともに登録された各リソー
スが、2 相コミットプロトコル処理を通過する必要があります。エラーが発生した場合は、エラーの修復
後に再開される必要があります。このため、リソースは、コミットまたはロールバックの重複したリクエ
ストを受信でき、また矛盾せずに応答できるよう準備されている必要があります。
Resource インタフェースには、次の 5 つの操作が定義されています。
□ prepare()
□ rollback()
□ commit()
□ commit_one_phase()
□ forget()
140418J
4-37
第 6 章 Transaction サービスインタフェース
6.5.1 Resource::prepare()
prepare() によって、関連付けられたリソース上で 2 相コミットプロトコルが開始されます。リソー
スは呼び出しに応答して、Vote を返します。返される値は、次の enum のどれか 1 つです。
□
VoteCommit
□
VoteRollback
□
VoteReadOnly
これらの応答によって、Resource オブジェクトがトランザクションの結果をコミットできるかどう
か記述されます。
関連するトランザクションデータがすべてリソースによって永続的にできる場合、VoteCommit が返
されます。2 相コミットプロトコルに対応するため、ほかのリソースが VoteRollback を返した場合
に備えて、リソースは、トランザクションによって作成された変更をすべてロールバックするようにも準
備されている必要があります。また、VoteCommit は、リソースがトランザクションを準備したことも
示しています。
リソースはいつでも VoteRollback を返すことができます。ただし、それによってトランザクショ
ン全体が無効にされ、関連する各リソースはロールバックを実行する必要があります。リソースが
VoteRollback を返した後は、トランザクションに関する記録はすべて消去することができます。
リソースに関連付けられた永続データがトランザクションによって変更されていない場合は、トランザ
クションは VoteReadOnly を返すことができます。この応答を受け取った後、Transaction サービスは、
このリソース上で何も操作を実行する必要はありません。またリソースは、トランザクションに関する記
録をすべて消去することができます。
6.5.2 Resource::rollback()
2 相コミットの 第 2 段階は、トランザクションに関連する変更をコミットするかまたはロールバックす
るかの決定です。Coordinator によって
rollback() が呼び出されると、リソースは、永続デー
タに加えた変更をすべて取り消す必要があります。リソースは、前回コミットされていても、ロールバッ
クするように準備されている必要があります。Resource オブジェクトによってこの呼び出しが処理さ
れた後、Resource は削除してもかまいません。
6.5.3 Resource::commit()
commit() への呼び出しは、トランザクションが正しく完了したことを示します。この場合、リソー
スは、トランザクションの結果を永続的にする必要があります。この呼び出しの処理後、Resource オ
ブジェクトは削除してもかまいません。
rollback() と違い、prepare() が呼び出される前に commit() 呼び出しを受け取った場合
は、リソース側が例外エラーを返す必要があります。
6.5.4 Resource::commit_one_phase()
commit_one_phase() は、Coordinator オブジェクトが、prepare() の呼び出しをせず
に 1 つの段階でトランザクションをコミットしたい場合に備えて用意されています。可能な限り、関連付
けられたリソースはすべてのトランザクションの変更をコミットする必要があります。不可能な場合は、
TRANSACTION_ROLLEDBACK 標準例外エラーを返す必要があります。
4-38
140418J
第 6 章 Transaction サービスインタフェース
6.5.5 Resource::forget()
forget() は、最終結果に関連する操作であり、NonStop JTS/OTS ではサポートされていません。
6.6 Control インタフェース
Control インタフェースによって、トランザクションコンテキストをプログラム的に管理することが
できます。
このインタフェースには、get_terminator と get_coordinator の 2 つの操作があります。
これらを使用して、トランザクションの Coordinator オブジェクトと Terminator オブジェクト
を取得することができます。
6.6.1 Control::get_terminator()
get_terminator() を実行すると、Terminator インタフェースをサポートするオブジェクト
が返されます。このオブジェクトは、Control に関連するトランザクションをロールバックまたはコ
ミットするのに使用されます。
リクエストされた
Terminator オブジェクトを Control が提供できない場合は、Unavailable
例外エラーが返されます。
6.6.2 Control::get_coordinator()
get_coordinator() を実行すると、Coordinator インタフェースをサポートするオブジェ
クトが返されます。このオブジェクトは、Control に関連するトランザクションのリソースを登録する
のに使用されます。
リク エス トさ れた
C o o r d i nat or オ ブジ ェク トを Con tro l が提 供で きな い場 合は、
Unavailable 例外エラーが返されます。
6.7 RecoveryCoordinator インタフェース
RecoveryCoordinator インタフェースは、回復可能なオブジェクトが回復プロセスを実行する
際に使用されます。
このインタフェースを使用する回復可能なオブジェクトは、register_resource() 呼び出しに
よって取得したオブジェクト参照を持っています。このオブジェクト参照は、ある 1 つのリソースの登録
リクエストに黙示的に関連付けられています。回復可能なオブジェクトは、その 1 つのリソースによって
だけ使用可能です。
このインタフェースの操作は 1 つだけで、replay_completion() です。
6.7.1 RecoveryCoordinator::replay_completion()
replay_completion() は、関連するリソースが準備された後はいつでも呼び出すことができま
す。これは非ブロック操作であり、Coordinator オブジェクトに対して、リソース上でコミットまた
はロールバックが完了されていないという情報を提供します。このような情報は、特定のエラーが発生し
140418J
4-39
第 6 章 Transaction サービスインタフェース
た場合に必要となります。呼び出しが行われると、Resource オブジェクトが送られ、トランザクショ
ンの現在のステータスが返されます。
リソースが準備されていない状態で replay_completion() が呼び出されると、NotPrepared
例外エラーが返されます。
6.8 Transaction サービスインタフェースの概要
表 4-5 に、OMG で定義されている CosTransaction.idl モジュールのインタフェースすべてについて簡単
にまとめてあります。これらのインタフェースについて詳しくは、
『OMG Transaction Service Specification』
文書を参照してください。
表 4-5 CosTransaction モジュールインタフェースの概要
インタフェース
Current
説
明
Current は、クライアントアプリケーションで最も重要なインタ
フェースです。クライアントは、このインタフェースを使用して、
トランザクションを開始および終了します。Current には、
begin()、status()、commit()、rollback() などの
操作があります。Current は擬似インタフェースであり、本当の
トランザクションインタフェースに間接的にアクセスする方法とし
て使用されます。詳細は以下を参照してください。
TransactionalObject
TransactionalObject には操作がありません。このインタ
フェースは、黙示的に伝播されるトランザクションコンテキストを
含むリクエストをトランザクションオブジェクトが受け付けられ
る、ということを示すために使用されます。
Synchronization
Synchronization インタフェースによって、トランザクショ
ンサーバ内の機能を実装することができます。このインタフェース
を使用すると、関連するトランザクションの終了前後に、トランザ
クションサーバが作業を処理することができます。
TransactionFactory
TransactionFactory インタフェースによって、トランザク
ションの開始者がトランザクションを作成することができます。こ
のインタフェースには、create() と recreate() の 2 つの
操作があり、このどちらもが Control オブジェクトを返します。
Control
Control インタフェースは、トランザクションへのハンドルのよ
うなものです。これはラッパインタフェースであり、OTS のほかの
関連処理、特に Terminator および Coordinator インタ
フェースにアクセスするために使用されます。
Coordinator
Coordinator インタフェースは、トランザクションプロセスの
さまざまな関連処理のアクションを調整する仕組みを提供します。
4-40
140418J
第 6 章 Transaction サービスインタフェース
インタフェース
Resource
説
明
Resource インタフェースは、2 相コミットプロトコルを使って
トランザクションを完了するために、OTS によって使用されます。
また、リソースが 1 つしかない場合は、1 相コミットのための特定
の操作を提供します。このインタフェースを使って、非 CORBA 関
連処理をラップし、トランザクションを実行できるよう、CORBA
ドメイン内で使用可能にすることができます。
Terminator
Terminator インタフェースは、トランザクションを
commit() または rollback() するための操作を提供します。
RecoveryCoordinator
RecoveryCoordinator インタフェースは、エラーが発生し
た際、OTS ベースのシステムの回復を調整するために、回復可能な
オブジェクトによって使用されます。
SubtransactionAware
Resource
SubtransactionAwareResource インタフェースは、ネ
ストされたトランザクションモデル内で、特殊なコールバックリ
ソースオブジェクトを登録するのに使用されます。NonStop JTS/
OTS はネストされたトランザクションをサポートしていないため、
このインタフェースはサポートされていません。
Transaction Service Specification では、こ の表 にある CosTransactions モジ ュー ル以外 にも、
CosTSPortability というモジュールも定義しています。これは、トランザクションの管理に使用
されます。
CosTSPortability モジュールのインタフェースは、sender() および receiver() の 2 つ
です。これらは管理インタフェースであり、内部 ORB と OTS との通信や同期に使用されます。このイン
タフェースはまた、ORB と OTS の間の、構造上の重要な区切りを提供します。
140418J
4-41
第 7 章 CosTransactions モジュール
第 7 章 CosTransactions モジュール
OMG で定義された CosTransactions.IDL モジュール
#include <Corba.idl>
module CosTransactions {
// DATATYPES
enum Status {
StatusActive,
StatusMarkedRollback,
StatusPrepared,
StatusCommitted,
StatusRolledBack,
StatusUnknown,
StatusNoTransaction,
StatusPreparing,
StatusCommitting,
StatusRollingBack
};
enum Vote {
VoteCommit,
VoteRollback,
VoteReadOnly
};
// Structure definitions
struct otid_t {
long formatID; /*format identifier. 0 is OSI TP */
long bqual_length;
sequence <octet> tid;
};
struct TransIdentity {
Coordinator coord;
Terminator term;
otid_t otid;
};
struct PropagationContext {
unsigned long timeout;
TransIdentity current;
sequence <TransIdentity> parents;
any implementation_specific_data;
};
// Forward references for interfaces defined later in module
interface Current;
interface TransactionFactory;
interface Control;
interface Terminator;
interface Coordinator;
interface RecoveryCoordinator;
interface Resource;
interface Synchronization;
interface SubtransactionAwareResource;
140418J
4-43
第 7 章 CosTransactions モジュール
interface TransactionalObject;
// Heuristic exceptions
exception HeuristicRollback {};
exception HeuristicCommit {};
exception HeuristicMixed {};
exception HeuristicHazard {};
// Other transaction-specific exceptions
exception SubtransactionsUnavailable {};
exception NotSubtransaction {};
exception Inactive {};
exception NotPrepared {};
exception NoTransaction {};
exception InvalidControl {};
exception Unavailable {};
exception SynchronizationUnavailable {};
// Current transaction
interface Current : CORBA::Current {
void begin()
raises(SubtransactionsUnavailable);
void commit(in boolean report_heuristics)
raises(
NoTransaction,
HeuristicMixed,
HeuristicHazard
);
void rollback()
raises(NoTransaction);
void rollback_only()
raises(NoTransaction);
Status get_status();
string get_transaction_name();
void set_timeout(in unsigned long seconds);
Control get_control();
Control suspend();
void resume(in Control which)
raises(InvalidControl);
};
interface TransactionFactory {
Control create(in unsigned long time_out);
Control recreate(in PropagationContext ctx);
};
interface Control {
Terminator get_terminator()
raises(Unavailable);
Coordinator get_coordinator()
raises(Unavailable);
};
interface Terminator {
4-44
140418J
第 7 章 CosTransactions モジュール
void commit(in boolean report_heuristics)
raises(
HeuristicMixed,
HeuristicHazard
);
void rollback();
};
interface Coordinator {
Status get_status();
Status get_parent_status();
Status get_top_level_status();
boolean
boolean
boolean
boolean
boolean
is_same_transaction(in Coordinator tc);
is_related_transaction(in Coordinator tc);
is_ancestor_transaction(in Coordinator tc);
is_descendant_transaction(in Coordinator tc);
is_top_level_transaction();
unsigned long hash_transaction();
unsigned long hash_top_level_tran();
RecoveryCoordinator register_resource(in Resource r)
raises(Inactive);
void register_synchronization (in Synchronization sync)
raises(Inactive, SynchronizationUnavailable);
void register_subtran_aware(in SubtransactionAwareResource r)
raises(Inactive, NotSubtransaction);
void rollback_only()
raises(Inactive);
string get_transaction_name();
Control create_subtransaction()
raises(SubtransactionsUnavailable, Inactive);
PropagationContext get_txcontext ()
raises(Unavailable);
};
interface RecoveryCoordinator {
Status replay_completion(in Resource r)
raises(NotPrepared);
};
interface Resource {
Vote prepare()
raises(
HeuristicMixed,
HeuristicHazard
);
void rollback()
raises(
HeuristicCommit,
140418J
4-45
第 7 章 CosTransactions モジュール
HeuristicMixed,
HeuristicHazard
);
void commit()
raises(
NotPrepared,
HeuristicRollback,
HeuristicMixed,
HeuristicHazard
);
void commit_one_phase()
raises(
HeuristicHazard
);
void forget();
};
interface TransactionalObject {
};
interface Synchronization : TransactionalObject {
void before_completion();
void after_completion(in Status status);
};
interface SubtransactionAwareResource : Resource {
void commit_subtransaction(in Coordinator parent);
void rollback_subtransaction();
};
}; // End of CosTransactions Module
4-46
140418J
索 引
索 引
T
Transaction サービス
CosTransactions モジュール 4-43
NonStop JTS/OTS のインストール 4-1
NonStop JTS/OTS の構成と管理 4-7
NonStop OTS Clients の実装 4-17
NonStop OTS Transaction Manager (OTSTM)
4-13
NonStop OTS サーバの実装 4-25
Transaction サービスインタフェース 4-31
概要 4-11
140418J
4-47
用語解説
用語解説
3 階層アーキテクチャ
Adapter Activator
階層アプリケーションアーキテクチャ (tiered application architecture) を参照。
存在していない子 POA に対して要求を発するときに、ORB が使用するサーバサイド
のオブジェクト。この場合には、Adapter Activator は子 POA を作成します。
AWAITIO(X)
Guardian ファイルシステムコールの 1 つ。これによって、呼び出し側は、待ち無し要
求に対する返答を受け取ることができます。NonStop DOM アプリケーションコン
ポーネントでは、ファイル番号を -1 にしてこのコールを使用しないでください。
Basic Object Adapter (BOA)
オブェクトアダプタを参照。
CLI
Command Line Interface を参照。
Comm Server
リモートクライアントとローカルサーバ間のリンクを管理する NonStop DOM プロセ
ス。構成には複数の Comm Server を含めることが可能であり、多数のクライアント
が同一の Comm Server を使用できます。
Command Line Interface (CLI)
stdlin またはスクリプトファイルから入力ラインを受け取る方法。OSS (Open System
Services) では、これが基本のコマンドラインインタフェースです。
Common Object Request Broker Architecture (CORBA)
標準コンポーネントの定義であり、異機種ネットワーク間でのオブジェクト指向のコ
ンポーネントの対話をサポートするために必要なインタフェースです。CORBA は、
OMG (Object Management Group) によって定義されています。
Common Object Services (COS)
CORBA コンテキストでのアプリケーションに有益なサービスの、一連の OMG 仕様。
COS には Lifecycle Service、Persistence Service、Event Service、そして特に Naming
Service が含まれています。CORBAServices とも呼ばれます。
CORBA
Common Object Request Broker Architecture を参照。
CORBA オブジェクト
CORBA オブジェクトは基本クラスの CORBA::Object から派生します。クライアン
トの要求を受け取る ORB オブジェクトのこと。これは、すべてのクライアントの呼
び出しターゲットとなります。CORBA オブジェクトはその参照で位置がわかるよう
になっています。CORBA オブジェクトが要求を対処する振舞いは、クライアントに
対して完全に透過的です。
CORBAServices
Common Object Services を参照。
COS
Common Object Services を参照。
CSMAP
NonStop DOM データベースであり、このエントリによって構成済みの各クライアン
トが使用する Comm Server が決まります。CS を保持する構成データベースのエン
ティティは、リモートクライアントとクライアント / サーバ間のマッピングをロード
します。
140418J
用語解説 -1
用語解説 Current インフェタース (Current interface)
OTS (Object Transaction Service) で定義されているオブジェクトクラスの １ つ。これ
を使用することによって、OTS クライアントはアプリケーショントランザクションを
制御することができます。たとえば、トランザクションの開始をマークする、トラン
ザクションをコミットする、トランザクションを中断する、トランザクションを元に
戻す ( ロールバックする ) といった処理を Current インタフェースでは定義します。
Distributed Computing Environment (DCE)
OSF (Open Software Foundation) によって定義されているアプリケーションサービス
のセット。分散アプリケーションに適しています。DCE にはタイムサービス、セル
およびグローバルディレクトリサービス、スレッドパッケージ、そしてファイルサー
ビスが含まれます。NonStop DCE は、OSF DCE の機能のすべてではありませんが、
そのいくつかを実装している Tandem 製品です。
Dynamic Invocation Interface (DII)
クライアントが実行時に要求を構築する、要求のスタイル。クライアントは、コンパ
イル時にオブジェクトインタフェース ( 特定の操作を要求するための呼出し手順 ) を
知る必要がありません。
Event Management Service (EMS)
オペレータや運用管理アプリケーションへ Tandem 製品の重要なイベントを通知す
る為に一元化を行なうプロセスとインタフェース。EMS ではフィルタをサポートし
ており、これを使用してユーザは、特定の製品からのメッセージや、特定の内容また
は特性を含んだメッセージを選別することができます。
Enscribe
Tandem Nonstop kernel のディスクプロセスと関連インタフェース。
Event Service
オブジェクト間の非同期通信を実現する、標準のアプリケーションサービス (OMG の
Common Object Service の 1 つ )。
Externalization Service
標準のアプリケーションサービス (OMG の Common Object Service の 1 つ )。「スト
リーム」の抽象概念を使用して、1 つの又は数個のプロセスから別のプロセスまたは
オブジェクト状態情報を移動させます。送り手は、必要となるあらゆる変換操作を実
行して、データをストリームに書き込みます。受取り手は、必要な変換を実行して、
そのローカル環境でデータを処理します。
factory オブジェクト
他のオブジェクトを生成することを目的とするオブジェクト。Naming Service に factory
サービスが含まれており、factory オブジェクトの登録が可能です。
HOSTS ファイル
IP アドレスとエイリアスを含んだファイル。IP アドレスとエイリアスは、NonStop
TCP/IP に認識されるシステムを表しています。
IDL コンパイラ
Interface Definition Language (IDL) を参照。
IDL 仕様 (IDL specification)
特定のオブジェクトクラスのインタフェースを定義する、一連の IDL 文。Interface
Definition Language (IDL) もまた参照してください。
IIOP
Internet interORB プロトコル。
Implementation Repository
オブジェクト実装とそれらが常駐しているサーバに関する情報を記録したデータ
ベース。
用語解説 -2
140418J
用語解説
Interface Definition Language (IDL)
OMG が規定した言語であり、オブジェクトクラスの継承関係、データ、およびメソッ
ドシグニチャを定義するのに使用します。IDL はオブジェクトの実装に使用する言語
とは独立しています。IDL コンパイラは、IDL とサポートされている実装言語との間
の CORBA 定義のマッピングに従って、言語固有のヘッダファイルを生成します。
Interface Repository (IR)
オブジェクトインタフェースに関する情報を含んだデータベース。これらの情報は、
オブジェクトおよびオブジェクトがサポートしている各操作の呼出しシーケンスに
よってアクセス可能なデータです。この用語はオブジェクト技術に使われ、呼出し
シーケンスが「メソッドシグニチャ」であることを意味します。
IR 定義の永続格納を提供する、Object Request Broker のコンポーネントのこと。IR
定義は、IR 定義オブジェクトのセットとして Interface Repository で維持されます。
Internet InterORB Protocol (IIOP)
InterORB Protocol (IOP) を参照。
InterORB Protocol (IOP)
分散型システムの間でメッセージを伝送するための規則。Internet InterORB Protocol
(IIOP) は、CORBA によって定義されており、TCP/IP を使用します。
IP アドレス
IPC
TCP/IP プロトコルと結び付くネットワークアドレスの形式。
プロセス間通信。Tandem NonStop システムでは、メッセージベースの IPC 形式を使
用します。
IR
Interface Repository (IR) を参照。
IR ブラウザ (IR browser)
Interface Repository を図表で表わす会話型のツール。
irdump ユーティリティ
NonStop DOM に提供されているプログラム。Interface Repository の内容をリストし
ます。
Lifecycle Service
オブジェクトの作成と削除のための標準アプリケーションサービス。Common Object
Services (COS) も参照してください。
LINKMON プロセス
CPU 内のすべてのリクエスタに対してリンクを獲得する NonStop TS/MP プロセス。
Location Service Daemon (LSD)
クライアントの Comm Server への割り当て、及び直接接続の TCP サーバのアドレス
を調べる常駐の NonStop DOM プロセス。Comm Server も参照してください。
Makefile
実行プログラムを構築するアプリケーションモジュール間の依存性が記述されてい
るファイル。Make ユーティリティ (Tandem OSS およびその他 UNIX や POSIX の実
装で提供されている ) は makefile を解釈して、変更されたモジュール及び関連するモ
ジュールの再コンパイルを実行します。
message factory
NonStop DOM のオブジェクトクラスの 1 つ。アプリケーションはこれを用いて、フ
リーメッセージとメッセージデータセグメントを作成します。
MP (Massively Parallel)
多数の Tandem 製品の名前に含まれている接尾辞。それらの製品のスケーラビリティ
を意味します。
140418J
用語解説 -3
用語解説 Naming Service
標準のアプリケーションサービス (OMG の Common Object Services の 1 つ )。オブ
ジェクト名、識別子、およびその他の情報を格納します。Naming Service の使用で重
要なものの 1 つに、他のオブジェクトの作成に使用する factory オブジェクトの名前
を格納することがあります。
NonStop Distributed Object Manager/Massively Parallel (NonStop DOM)
Tandem システムでオブジェクト指向のアプリケーションとコンポーネントを開発す
る為の製品セット。NonStop DOM は、OMG (Object Management Group) の CORBA
標準をベースにしています。NonStop DOM には、開発環境とランタイム環境の両方
が用意されています。
NonStop DOM
NonStop Distributed Object Manager/Massively Parallel を参照。
NonStop TCP/IP
TCP/IP プロトコルを実装する Tandem 製品。NonStop DOM では、リモートクライア
ントおよびサーバとの通信に NonStop TCP/IP を使用します。
NonStop Transaction Manager/Massively Parallel (NonStop TM/MP)
トランザクションの保護、データベースの一貫性の維持、及び災害などによるデータ
ベース破壊時の回復を行なう製品。
NonStop Transaction Services/Massively Parallel (NonStop TS/MP)
Tandem システムのトランザクション処理 (TP) モニタ。NonStop TS/MP はサーバプー
ルを管理します。この管理機能として、クライアントとサーバ間のリンク確立、サー
バのロードバランシング、要求トラフィックの変化に対応したサーバの作成、削除、
および CPU またはプロセスの障害発生後のサーバ再起動などの処理を行ないます。
Object Management Group (OMG)
Common Object Request Broker Architecture (CORBA) の定義に責任を負うベンダコン
ソーシアム。
Object Request Broker (ORB)
分散オブジェクト環境でクライアントとサーバ間でメッセージを伝送するコンポー
ネント。ORB は、目的のオブジェクトを探したり、ネットワークのなかで要求の伝
送や応答の受信に必要とされる変換を実行するなどのサービスを提供します。マー
シャリング (marshaling) も参照してください。
Object Transaction Service (OTS)
Transaction サービスを参照。
OMG
Object Management Group を参照。
Open System Services (OSS)
NonStop Kernel 上の、POSIX 準拠のオペレーティングシステムインタフェースの
セット。
ORB
Object Request Broker を参照。
osh
Open System Services (OSS) 環境で他のユーティリティを起動することができるユー
ティリティ。UNIX 用語では、この種類のユーティリティをシェルと呼びます。同一
の機能を提供する Guardian インタフェースが TACL です。
OSS
Open System Services を参照。
OTS
Transaction サービス を参照。
用語解説 -4
140418J
用語解説
PATHCOM
TS/MP サーバプールと他の NonStop TS/MP コンポーネントを定義および管理するた
めに使用する、CLI (call level interface) ユーティリティ。
PATHCOM 構成ファイル
PATHMON 環境のプロセスと操作パラメータを定義しているファイル ( 単一の
PATHMON プロセスの制御のもとにあるプロセスの集まり )。
PATHMON
NonStop TS/MP プロセスであり、サーバプロセスの開始・再起動・監視、リクエスタ
とサーバ間のリンクの確立、およびロードバランシングを行なう。PATHMON のイ
ンスタンスによって管理されているプロセスの集まりは、PATHMON 環境と呼ばれ
ています。
Pathsend ファシリティ (Pathsend facility)
リクエスタが要求と返答を NonStop TS/MP サーバプールと交換するために使用する
手順のセット。( メッセージを送信する実際のプロシージャコールの名前は、SERVER
CLASS_SEND のように別の名前にすることができます。) NonStop DOM は、Pathsend
ファシリティを内部的に使用して、NonStop TS/MP サーバプールで実行しているオブ
ジェクトの呼び出しをサポートします。また、クライアントプログラムは、このファ
シリティを明示的に使用して、非 CORBA メッセージを CORBA 準拠でないサーバ
プールに送信することもできます。
Pathway プロトコル
クライアントと
NonStop
TS/MP
サーバプールとの間の通信を行なう場合に、
NonStop DOM が使用するメカニズム。このプロトコルは、NonStop TS/MP Pathsend
ファシリティを使用します。
pax
単一ファイルとしてアーカイブされたファイルの集まりを抽出するユーティリティ。
pax は、OSS (Open Systems Services) を使用する Tandem システムを含む、UNIX お
よび POSIX システム上で利用できます。
POA
Portable Object Adapter (POA) を参照。
POA マネージャ (POA manager) 1 つまたは複数の POA の処理状態を含んだサーバサイドのオブジェクト。開発者は
POA マネージャを使用して、リクエストの処理、キューイング、または破棄を行う
ことができます。また、POA マネージャは POA の起動または停止も実行することが
できます。
Portable Object Adapter (POA)
CORBA 規定のオブジェクトアダプタ ( 以前の CORBA BOA に置き換わるもの )。サー
バに常駐しているオブジェクトと ORB とを接続します。アダプタは、クライアント
とサーバが接続し、情報を交換できるネーム・スペースを提供します。オブジェクト
アダプタ (object adapter) も参照してください。
POSIX
UNIX と同一のオペレーティングシステムインタフェースの標準セット。Tandem
OSS(Open System Services) 製品では、Tandem NonStop Kernel に対して POSIX イン
タフェースを提供しています。
profile ファイル
Open System Services (OSS) の操作パラメータを定義する構成ファイル。
Ptrace
SCF トレース情報のフォーマットされた表示を生成する、ユーティリティプログラム。
QIO
Tandem 製品。この製品は、共有メモリセグメントを使用して、そのクライアントプ
ロセスのパフォーマンスを最適化します。QIO を使用する Tandem 製品の 1 つに、
Tandem LAN Access Method (TLAM) があります。QIO は、Queued Input/Output を表
しています。
140418J
用語解説 -5
用語解説 receiver
メソッド起動の対象となるオブジェクトを指すポインタ。
Root POA
他のすべての POA オブジェクトに関係している ORB によって提供される、POA オ
ブジェクト。
Servant Managers (servant manager)
ORB からの要求によって動作してサーバントを起動・停止させる、POA コンポーネ
ント。Servant Managers は、ORB オブジェクトを適切なサーバントに結び付けます。
このマネージャには、ServantActivator と ServantLocater の 2 種類が用意されていま
す。POA ポリシー ( ルール ) が、使用するマネージャを決定します。
Shared Runtime Library（SRL)
実行時にオペレーティングシステムがプログラムにリンクさせるオブジェクトファ
イル。
Static Invocation Interface (SII)
要求の形式。SII では、クライアントはオブジェクトインタフェース ( 特定の操作を
要求するための呼出しシーケンス ) をコンパイル時に認識していなければなりませ
ん。これと対比されるのが Dynamic Invocation Interface です。
Structured Query Language (SQL)
リレーショナルデータベースを定義および使用する標準技術。NonStop SQL/MP はこ
の標準の Tandem 実装です。
Subsystem Control Facility (SCF)
NonStop System 上のネットワークリソースの構成、監視、制御のための対話型ユー
ティリティ。
Subsystem Programmatic Interface (SPI)
多数の Tandem 製品の管理を自動化する為の統一化されたインタフェース。一般的
に、SPI に基づいた管理プログラミングインタフェースでは、各製品がオペレータに
提供する対話型ユーティリティと同等の機能をアプリケーションプログラムに提供
します。たとえば、NonStop TS/MP は管理プログラミングインタフェースを提供し
ており、これによってアプリケーションは PATHCOM を介して使用できる機能と同
一の機能をアプリケーションプログラムに提供します。
Tandem Information Manager (TIM)
ユーザが Tandem 製品に関する情報を電子的に検索できるようにするプログラム。情
報のソースは、Tandem マニュアル、ソフトウェアドキュメント、その他 CD-ROM ま
たは World Wide Web 上に格納されている文書です。
Tandem LAN Access Method (TLAM)
ローカルエリアネットワークで Tandem NonStop System と他のコンピュータおよび
デバイスとの接続をサポートする、ソフトウェア製品。TLAM がサポートしている通
信プロトコルは、IEEE 802.2 論理リンク制御タイプ 1、Ethernet、IEEE 802.3、およ
び IEEE 802.5 です。
Tandem X.25 Access Method
X25AM を参照。
TCL
Tool Command Language を参照。
用語解説 -6
140418J
用語解説
TCP/IP (Transmission Control Protocol/Internet Protocol)
最も広く普及しているネットワークプロトコルの 1 つであり、インターネット上の通
信のベース。CORBA IIOP プロトコルは、その伝送サービスとして TCP/IP を使用し
ます。TCP/IP を実装する Tandem 製品は、NonStop TCP/IP です。
TIM
Tandem Information Manager (TIM) を参照。
TLAM
Tandem LAN Access Method を参照。
Tool Command Language (TCL)
NonStop DOM で使用される Command Line Interface。TCL は、さまざまなサービス
を提供しており、開発、試験、配布の強力な支援となります。
Transaction サービス (transaction service)
標準アプリケーションサービス (OMG の Common Object Services の 1 つ )。データ
ベースまたは状態リポジトリに対して複数の更新が要求されるときに、データベース
やその他の記憶情報の整合性を確保します。
Tuxedo エンタープライズトランザクション処理システム (Tuxedo enterprise transaction processing system)N o v e l l ,
Inc. のトランザクション処理システム。NonStop Tuxedo システムは、この技術の
Tandem 実装です。
X.25
広域パケット交換ネットワークについての CCITT 勧告。X.25 を実装する Tandem 製
品が X25AM です。
X25AM
X.25 プロトコルを使用して、広域ネットワークで Tandem システムと他のコンピュー
タとデバイスとの間の接続をサポートする Tandem 製品。
アーキテクチャ
機能コンポーネントとそれらの関係に焦点を当てたシステムの概念。
移植 (porting)
異なるシステムまたはプラットフォーム上で実行するために、既存のコンポーネント
を書き換えたり修正すること。
イベント
NonStop DOM では、ある 1 つのオブジェクトが別のオブジェクトに送信する非同期
メッセージを指します。Tandem DSM (Distributed System Management) では、オペ
レータに通知されるサブシステムから Tandem EMS(Event Management Service) への
エラーメッセージ又は重要な事象発生のメッセージ。
イベントハンドラ (event handler)
NSDEVENT アプリケーションプロセスと他のプロセス ( たとえば、レガシークライ
アントやサーバなど ) との間の非同期通信をサポートする、NonStop DOM オブジェ
クト。イベントハンドラはファイルシステム、コンテキスト依存の Pathway、または
TCP/IP プロトコルを使用した接続を管理する際に特定される。
イベントハンドラユーザ (event handler user)
アプリケーションプロセスに代わってイベントハンドラを制御するオブジェクト。
インスタンス
オブジェクトクラスの定義に従う特定のオブジェクト。オブジェクトクラスの定義
は、データ型を含み、クラスに対して定義されている操作をサポートします。たとえ
ば、特定の銀行口座を表すオブジェクトは、一般的に銀行口座を定義しているオブ
ジェクトクラスのインスタンスになります。
140418J
用語解説 -7
用語解説 インストールホスト (install host)
ネットワークシステム内で NonStop DOM を最初にインストールするシステム。この
システムでは、分散型 Naming Service で高水準のエントリを保持します。
インタフェース
データ属性およびメソッドの呼出しシーケンス。オブジェクトクラスがこれをクライ
アントに対してアクセス可能にします。( オブジェクトクラスは、プライベート変数
および関数も定義することができます。)
インタフェースオブジェクト
アプリケーションにおいて要求の発信元のユーザまたはデバイスと対話することを
目的としたオブジェクト。この用語は、ある普及しているオブジェクト指向設計の方
法論 (Jacobson) で使用されています。
永続識別子 (persistent identifier) (PID)
オブジェクトをオブジェクトが表す外部エンティティ ( たとえば、データベースレ
コード ) に関連付けるために使用する値。
演算子 (operator)
計算または論理の操作または関係を表す言語記号。
エンティティオブジェクト (entity object)
外部データを表すオブジェクトのタイプ。データベースのレコードなどの外部データ
や、あるいは外部デバイスも可能です。
オーバーライディング (overriding)
基本クラスのデータ要素またはメソッドを、同一の名前を持つ他のデータ要素または
メソッドに置換すること。たとえば、特定の形式でレポートを作成する report という
メソッドが基本クラスで定義されているとします。サブクラスでそのメソッドをオー
バーライド ( 再定義 ) すると、オブジェクトに対してのサブクラスの「report」要求に
より、異なる形式でレポートが作成されます。
オーバーローディング (overloading)
コンテキストによって異なる動作を実現するために、言語要素を再定義すること。た
とえば、加算演算子 (+) をオーバロードして、テキスト文字列の連結をサポートする
ことができます。
オブジェクト
オブジェクトクラスのインスタンス。書籍のなかには「オブジェクト」をオブジェク
トクラスの意味で使用しているものもあります。
オブジェクト ID
CORBA オブジェクトの識別に使用する値。値は、POA の範囲内で一意でなければな
りません。任意のサーバ上では常に複数の POA オブジェクトが存在する可能性があ
るため、オブジェクト ID がサーバに関して一意であることは保証されません。オブ
ジェクト ID は透過的ではなく、クライアントからは見えません。
オブジェクトアダプタ (object adapter)
サーバに常駐している、CORBA コンポーネント。Object Request Broker とサーバ内
の実行オブジェクトとの間のインタフェースを提供します。CORBA では、POA
(Portable Object Adapter) を定義しています。
オブジェクトクラス
データとデータに対して実行できる操作の集まりを定義するアプリケーションコン
ポーネント。オブジェクトはオブジェクトクラスのインスタンスであり、特定のデー
タを含み、操作の集まりをサポートします。
用語解説 -8
140418J
用語解説
オブジェクトサービス (object services)
Common Object Services を参照。
オブジェクト参照
オブジェクトを正確に識別する値。オブジェクト参照は、他のオブジェクトを識別す
るために再利用されることはありません。
オブジェクト識別サービス (object identity service)
同一オブジェクトクラスのインスタンスを識別するサービス。データ値が同一の場合
であっても識別します。
オブジェクト指向
機能がデータとデータを実行する処理動作を含んだ小モジュールに分割されている、
アプリケーションの特性。
オブジェクトラッパ
CORBA に準拠していない ( つまり、レガシー ) アプリケーションまたはプログラム
インタフェースからのサービスをカプセル化して、そのカプセル化したアプリケー
ションまたはインタフェースを 1 個のオブジェクトとして取り扱うこと。ラッピング
も参照してください。
親クラス (parent class)
他のいくつかのクラス ( サブクラス ) の派生元となるクラス。これによってサブクラ
スは親クラスから特性を継承し、またそれ自体固有の特性も定義します。
階層アプリケーションアーキテクチャ (tiered application architecture)
アプリケーションモデルの 1 つ。機能を 2、3 の主要なオブジェクトカテゴリに分割
して開発・保守の効率を図ります。オブジェクトのカテゴリとしては、インタフェー
スオブジェクト、コントロールオブジェクト、エンティティオブジェクトなどがあり
ます。
カプセル化 (encapsulation)
クライアントによる直接アクセスからサーバのデータ空間を保護する、オブジェクト
技術の特性。これによって確実に、クライアントは、データに対して定義されている
機能だけを起動できます。
可用性
サービスの連続提供。Tandem NonStop システムは高可用性を実現できるように設計
されています。
環境構造体 (environment structure)
例外情報を受け取るためにメソッド起動に含まれる、CORBA 定義の変数。
環境パラメータ
例外情報を受け取るためにメソッド起動に含まれる、CORBA 定義の変数。
環境変数
システムまたは製品固有の構成ファイルの要素。処理コンポーネント、システム特有
の制御または製品操作へのパスを指定するために使われます。たとえば、OSS profile
ファイルの環境変数を使用して、NonStop DOM 構成ファイルの場所を指定します。
キー
ディクショナリに索引を付ける変数。ディクショナリも参照してください。
基本クライアント、リスナ、またはサーバ・イベントハンドラまたはユーザ
(base client, listener, or server event handler or user)
プロトコル固有のイベントハンドラまたはユーザオブジェクトクラスの派生元とな
る、NSDEvent の抽象クラス。
基本クラス (base class)
他のクラス ( サブクラス ) の派生元となるクラス。この結果サブクラスは、基本クラ
スから特性を継承し、またそれ自体の固有の特性も定義します。
140418J
用語解説 -9
用語解説 キャスト
ある型の値を別の型の変数に割り当てること。
クライアント
オブジェクト技術では、オブジェクトの要求を生成するアプリケーションコンポーネ
ントのこと。より一般的には、サーバの要求を生成するアプリケーションコンポーネ
ントを指します。
クライアント / サーバコンピューティング
ユーザに代わって要求を作成するクライアントと、それらの要求を実行するサーバと
に機能を分割したアプリケーションのスタイル。多くの場合、クライアントはワーク
ステーション上で実行し、サーバはより大規模なサーバマシン上で実行しますが、こ
うした分散の形態はクライアント / サーバコンピューティングの特性として必須のも
のではありません。
クライアント・イベントハンドラ (client event handler)
NSDEVENT、NonStop DOM クライアント、およびサーバラッパに対する非同期通信
をサポートするオブジェクトのこと。
クラスデータ (class data)
特定のオブジェクトインスタンスではなく、全体としてオブジェクトクラスに適用さ
れる変数。たとえば、クラスのインスタンスの数を通知する変数など。
クラスライブラリ
関連のあるオブジェクトクラスの集合。ユーザは、クラスライブラリで定義されてい
るオブジェクトの要求を作成します。
継承
特性が基本 ( 親 ) クラスからサブクラスに波及すること。もっと一般的には、データ
型の特性がサブタイプに波及することを意味します。
ゲートウェイ
互換性のないコンポーネント同士の変換機能を提供する、プロセスまたは他のコン
ポーネント。
言語の非依存 (language independence)
クライアントが別の言語で記述されたオブジェクトを使用できる特性。また、別の言
語で記述された親クラスから派生するサブクラスとして定義することも可能です。
言語バインディングまたはマッピング
バインディングを参照。
コミット
コレクションクラス
( トランザクションの ) 完了を宣言します。
他のオブジェクトに対してコンテナを定義するクラスのセット。たとえば、キュー、
スタック、リンクされているリスト、およびディクショナリの構築にコレクションク
ラスを使用できます。
コンストラクタ
オブジェクトクラスのインスタンスを生成するメソッド。オブジェクトクラスで定義
されます。
コントロールオブジェクト (control object)
他のオブジェクトを調整することを目的としているオブジェクトのタイプ。たとえ
ば、記憶データを表すオブジェクトのセットに対してトランザクションを実行する場
合などに使用できます。
用語解説 -10
140418J
用語解説
コンポーネント
クライアント、サーバ、またはクラスライブラリなどのアプリケーション機能の個別ユ
ニットのこと。通常、他のコンポーネントと混合および適合して、1 つまたは複数の異
なるアプリケーションを構築します。( コンポーネントベースのアプリケーション開発
の目的の 1 つが、異なるアプリケーションで同一コンポーネントを使用することです。)
サーバ
オブジェクト技術では、クライアントが起動する 1 つまたは複数のオブジェクトに実
行スペースを提供する ( ホストする ) ことによって、クライアントの要求を満たすア
プリケーションコンポーネントのこと。より一般的には、クライアントの要求にサー
ビスを提供するアプリケーションコンポーネントのこと。サーバプログラムは、サー
バのソースコードです。
サーバ・イベントハンドラ (server event handler)
サーバの非同期通信および NonStop DOM サーバとクライアント間の接続の非同期通
信をサポートする NonStop DOM Event プロセスの事。たとえば、NonStop DOM サー
バやクライアントラッパといった、リスナ・イベントハンドラによって確立する接続
でデータを転送する他の技術を使用するクライアントとの接続で使用します。
サーバクラス (server class)
NonStop TS/MP の用語であり、サーバプールと同義。
サーバプール
同一プログラムを並列して実行するプロセスの集まり。これを使用することで、アプ
リケーションのスループットと耐障害性を向上させます。NonStop DOM アプリケー
ションでは、NonStop Transaction Services/MP (NonStop TS/MP) によって管理されて
いるサーバプールを使用できます。
サーバント (servant)
サーバに常駐しているエンティティ。NonStop のサーバントは、C++ オブジェクトの
インスタンスです。サーバントは、クライアントのサービス要求に応えます。
サービス
システムまたはネットワーク上のアプリケーションが使用できる関連機能のセット。
Common Object Services も参照してください。
再利用 (reuse)
複数のアプリケーションでソフトウェアコンポーネントを使用する原理。たとえば、
汎用目的のオブジェクトクラスからアプリケーション固有のオブジェクトクラスを
派生させたり、既存のクラスライブラリまたはフレームワークを共通のアプリケー
ション機能に対して使用したりすることも再利用です。再利用は、オブジェクト技術
の目的の 1 つです。
サブクラス
他のオブジェクトクラスから特性を継承する、オジェクトクラスのこと。
サブネット (subnet)
NonStop TCP/IP に対して意味を持つ抽象概念。TCP/IP プロセス、1 つまたは複数の
TLAM プロセス、および 1 つまたは複数のインターネット (IP) アドレス間の関係を
定義します。
シーケンス ( 配列、繰り返し )
IDL シーケンスは有限または無限のいずれも可能です。シーケンスは、現在の長さと
最大長とデータの _var 型を持つ C++ クラスにマッピングされます。
識別子
識別子は、アルファベット (a ∼ z、A ∼ Z) および数字 (0 ∼ 9) のシーケンスです。識
別子には下線を含めることができます。識別子はアルファベット文字で開始しなけれ
ばならず、大文字小文字を区別します。長さに制限はありません。
実行単位 (granularity)
オブジェクトの複雑性。オブジェクトを構成している個別的な操作またはデータ項目
が少ないか多いかを示すもの。
140418J
用語解説 -11
用語解説 実装
オブジェクトクラスのデータ定義とメソッド。プログラマは、IDL コンパイラが発行
したスケルトンから実装を生成します。
実装言語 (implementation language)
オブジェクトクラスのソースコードを作成する際に使用するプログラミング言語。
実装バインディング (implementation binding)
バインディングを参照。
使用バインディング (usage binding)
バインディングを参照。
スケーラビリティ
増大する利用量に対応してシステムを拡張できるようにする特性。Tandem システム
においては、主に並列処理によってスケーラビリティが実現されています。
スケルトン (skeleton)
サーバに常駐しているエンティティ。NonStop DOM スケルトンは、サーバントメソッ
ドへのポインタを含んだ C++ の基本クラスです。基本クラスは、IDL コンパイラに
よって生成されます。スケルトンはサーバントをオブジェクトアダプタに接続しま
す。
スケルトンスクリプト (skeleton script)
インストールおよび構成プログラムが使用する最初のスクリプト。デフォルトの
NonStop DOM システムをインストールおよび構成するための情報が記述されていま
す。このスクリプトは unpax 実行後に使用され、ORB 名と $volume.subvolume を決
めます。
ステートフル処理 (stateful processing)
アプリケーションロジックの形式。このロジックでは、クライアントによって取得さ
れたリンクの持続時間中に、同一オブジェクトに向かうメソッド起動のすべてが、同
一サーバントによって処理されなければなりません。そのクラスの他のオブジェクト
へのメソッド起動は、他のプロセスの別のサーバントによって処理できます。ステー
トフ ルオ ブジ ェク ト は、ro o t P O A な どの よう な、Id A ssi gnm ent ポ リシ ーが
TRANSIENT になっている POA によって作成されます。これは、root POA によって
指定されているオブジェクトのデフォルト動作です。
ステートレス処理 (stateless processing)
アプリケーションロジックの形式。このロジックでは、同一オブジェクトに向かうメ
ソッド起動は、サーバプール内の異なるプロセスに存在する異なるサーバントに対し
て要 求す るこ とが 可 能で す。オブ ジェ クト 参照 を生 成す る
POA
に対 して
IdAssignment ポリシーを PERSISTENT とすることによって、また、サーバの NonStop
TS/MP プロトコルを有効化することによって、ステートレス処理が選択されます。こ
れがステートレスと呼ばれる理由は、通常、オブジェクトの状態がディスク ( ゆえに
永続的 ) にあり、サーバントまたはプロセスメモリにはないためです ( ゆえにサーバ
ントはステートレス )。
スレッド
プロセスが一度に複数のタスク ( 仕事 ) を処理する手段。各タスクに対して個別の論
理フロー ( スレッド ) を生成して、実行中のタスク間で行われるスイッチングプロセ
スのメカニズムを提供します。NonStop DOM とそのアプリケーションは、DCE ス
レッドパッケージと同じスレッドパッケージを使用します。スレッドは、同一プロセ
用語解説 -12
140418J
用語解説
スが複数の要求を処理する必要があるという点でサーバプールと異なります。サーバ
プールでは、並列に実行している種々のプロセスが要求を処理できます。サーバプー
ルプロセスをスレッド化することもできます。
セキュリティサービス (security service)
ある特定の操作を適切な識別子 ( 認証 ) を持つユーザに限定する手段として、ユーザ
ID を検証するアプリケーションサービス。
設定値 (setting)
一般的には、パラメータまたは変数の値。NonStop DOM では、構成ファイルで指定
されている値のこと。
相互接続性、相互運用 (interoperability, interoperation)
複数の異機種ハードウェアまたはソフトウェアコンポーネントが、特にネットワーク
間で、一緒に動作する機能。
属性
オブジェクトと値の結合関係。属性 A は、get_A と set_A のように 1 ペアの操作とし
てクライアントに対して明示されます。読込み専用の属性では、get 操作のみ生成し
ます。属性はオブジェクトの特性またはプロパティであり、通常それは単純なデータ
メンバとして、または他のオブジェクトまたはオブジェクトグループとの関連として
実装されます。
ソケット (socket)
TCP/IP プロセスへの論理接続。
ダイナミックリンクライブラリ (DLL)
コンパイル時ではなく実行時に機能をプロセスにロードできるアプリケーション機
能をひとまとめにする方法。アプリケーションの他の部分が実行を続行している間、
それらの機能がアプリケーションで必要とされていないときには、ロードされませ
ん。
チャイルドクラス (child class)
他のクラスから特性を継承するオブジェクトクラスのこと。
抽象クラス (abstract class)
抽象クラスは、そこから派生するあらゆるクラスで定義されなければならない純粋な
仮想機能を含みます。抽象クラスは、その派生クラスのインスタンス以外にインスタ
ンスを持ちません。派生クラスが現実の動作を実行するためにメソッドをオーバーラ
イドする必要がある場合、抽象クラスで定義されるメソッドは抽象メソッドと呼ばれ
ます。
ディクショナリ
索引付きの情報の集まり。RogueWave の STL (Standard Template Library) でコレク
ションクラスとして定義されています。
データ型
値、操作、および引数の分類。通常、動作と表現のどちらにも使用します。
データベースのマッピング (database mapping)
マッピングを参照。
デストラクタ
オブジェクトの破棄に使用するメソッド。通常、オブジェクトに割り当てられている
メモリの解放や、そうでなければ開始された動作の取消しのために用います。
デプリケイト ( 推奨しない )
既存のアプリケーションの上位互換性を実現する機能として利用することが可能か
もしれないが、新規アプリケーションでは使用しないことを推奨する場合に用いる。
「推奨しない」、
「好ましくない」という意味。
140418J
用語解説 -13
用語解説 同時実行 (concurrency)
同時操作のこと。この用語は、並列に実行しているプロセス、同時トランザクション、
同一プロセスにおけるクラスの複数のインスタンス、または同時に同一オブジェクト
( または他のリソース ) を使用する複数のクライアントに適用されます。
同時実行サービス (concurrency service)
複数のクライアントによるオブジェクトへの同時アクセスを管理するアプリケー
ションサービス。この同時アクセスの管理は、主に、読込みと書込みのロッキング要
求をサポートすることによって提供されます。
動的コンテキスト (dynamic context)
メソッド呼出し同士の間で、プロセスのメモリに保持されていなければならない情報
のこと。ディスクに保存されている情報に対する用語。
トランザクション
論理的に関連している一連の操作。トランザクションは、一連の操作のすべてが実行
された場合にのみ完了します。このマニュアルでは、
「ユーザトランザクション」ま
たは「アプリケーショントランザクション」と、
「サービストランザクション」とを
区別しています。前者はアプリケーションコンポーネントによって定義・制御されて
おり、後者は Naming Service などのオブジェクトのサービスによって定義・制御さ
れています。
トランザクション管理 (transaction management)
完全なトランザクション処理を確保するために必要なタスクの集まり。トランザク
ション管理には、トランザクション制御 ( トランザクションがいつ開始して停止する
か、またトランザクションがアボートする時と方法を決定するアプリケーションロ
ジック )、トランザクション保護、およびオーディット ( トランザクションの経過を
ロギングし、要求の追跡と回復をサポート ) が含まれます。NonStop DOM アプリケー
ションでは、OTS (Object Transaction Service) を使用して、トランザクションを制御
します。
トランザクション保護 (transaction protection)
データベースと他の記憶データの整合性を確保する機能。
トレース
トラブルシュートに有効なデータまたはプログラムフローの連続したレコード。
NonStop DOM には、アプリケーション内の制御フローを追跡するファシリティが搭
載されています。
ナローイング (narrowing)
CORBA で使用される用語。基本インタフェースから派生インタフェースに移動する
ときに使われます。C++ では、これをダウンキャスト (down-cast) と呼びます。
肉付けされた (fleshed-out) スクリプト
スケルトン ( たとえば nsdstart や default.db) を編集した後のスクリプト。一度構成さ
れると、肉付けされた (fleshed-out) スクリプトは、既存の NonStop DOM インストー
ルの開始、停止、またはアンインストールに使用することができます。
ネーミングコンテキスト (naming context)
それぞれの名前が一意となっているネームバインディングの集合を含んだオブジェ
クト。ネームの解決は、任意のコンテキストの名前と結び付くオブジェクトを決定す
ることです。
ネームコンポーネント (name component)
名前 -ID 文字列と名前 - 種類の文字列を含む構造。
用語解説 -14
140418J
用語解説
ネームバインディング (name binding)
「名前とオブジェクトのバインディング (name-object binding)」としても知られるも
の。名前とバインディングで構成されるオブジェクトのこと。
ネストトランザクション (nested transactions)
別のトランザクション内で開始・終了するトランザクション。
パーティショニング (partitioning)
複数のファイルおよび記憶媒体にまたがるデータの分散、プロセス間のアプリケー
ションロジックの分散、または、サーバプロセス間のオブジェクトの分散のこと。
バインディング
IDL では、IDL 言語要素とプログラミング言語の対応する言語要素との関係を指しま
す。これには 2 種類のバインディングがあります。すなわち、クライアントが使用す
るための使用バインディングと、オブジェクトの実装で使用する実装バインディング
です。
Naming Service では、名前とその名前が表すオブジェクトとの関係を指します。
ネットワークでは、バインディングは、対話するエンティティ間の論理接続を確立す
ることを意味します。
派生クラス (derived class)
他のクラスから特性を継承するオブジェクトクラスのこと。
ファイルシステム
NonStop Kernel に提供されているインタフェースであり、プロセス間またはプロセス
と外部デバイス間の高レベル通信を提供します。
フレームワーク
関連のあるオブジェクトクラスの集合。クラスライブラリとは技術的に異なり、フ
レームワークがユーザプログラムの要求を作成します。ただし、多くのソフトウェア
ベンダは、「クラスライブラリ」と「フレームワーク」の両方の用語を同じ意味で使
用しています。
プロキシ (proxy)
リモートオブジェクトのローカル参照。プロキシで起動される操作がリモートオブ
ジェクト上で実行されるといった方法で用いられます。
ブロック
他のリクエスタがリソースにアクセスできないようにすること。
「最初の要求が完了
するまで 2 番目の要求はブロックされる」のように使われます。
分散オブジェクトコンピューティング
アプリケーションのスタイルであり、そこではプロセス間またはネットワーク全体に
分散しているオブジェクトベースのコンポーネントが、互いにメッセージベースのイ
ンタフェースを使用して通信します。
並列性 (parallelism)
複数の処理タスクの同時実行を可能にすることによって、パフォーマンスの向上と潜
在 的 に 耐 障 害 性 の 向 上 も 実 現 す る 手 段。ス レ ッ ド と サ ー バ プ ー ル が、並 列 性
(parallelism) を実現するための 2 つのメカニズムです。
ヘッダファイル
C または C++ プログラムに含まれているソースファイルであり、データ定義または
サービスの集合を使用可能します。
ポート番号
複数のローカル宛先を単一のネットワーク (IP) アドレスに結び付けるために使用され
る、アドレス指定のコンポーネント。たとえば、TCP/IP プロセスは 1 つの IP アドレ
スで受信しますが、ポート番号に基づいて種々のローカルプロセスに要求を送り出す
ことができます。
140418J
用語解説 -15
用語解説 ホスト (host)
オブジェクトに対して実行スペースを提供すること。サーバは、1 つまたは複数のオ
ブジェクトクラスのインスタンスをホストすることができます。
ポリシー
ポリシーは、特定の POA に実装されているオブジェクトに対して、その POA 独特の
動作を指定します。たとえば、スレッド化、起動、オブジェクト ID 割当てなどをポ
リシーで決定することができます。他に何も指定されていない場合は、すべての POA
がデフォルトのポリシーを使用します。
ポリモフィズム (polymorphism)
オブジェクト技術の特性。これによってクライアントは種々のオブジェクトに対して
同一の要求を作成することができ、その操作はオブジェクトの各クラスに対応して適
切に実行されます。たとえば、ビデオオブジェクトの表示操作は、テキストファイル
に対する表示操作と同じ動作にはなりません。しかし、クライアントはこの両方を同
じものとして扱います。
マーシャリング (marshaling)
リモートオブジェクトに対する伝送要求のパッケージ化、または、リモートクライア
ントに対する伝送応答のパッケージ化。これは、Object Request Broker によって提供
される機能です。
「demarshaling」は、ローカルオブジェクトとクライアントへの配信
のために受信メッセージを処理することを意味します。
マッピング
IDL 言語要素とプログラミング言語の対応する言語要素との関係、または、オブジェ
クトインスタンスのデータとデータベース内の対応するエンティティとの関係。
マルチ階層アーキテクチャ (multi-tiered architecture)
階層アプリケーションアーキテクチャを参照。
メソッド
オブジェクトに対して定義されている操作。プログラミング言語ではプロシージャま
たは関数として実装されているもの。メソッドの呼出しシーケンスは、メソッドシグ
ニチャと呼ばれます。メソッドへの呼出しは、メソッド起動と呼ばれます。
メッセージ
一般的なオブジェクト技術では、ある 1 つのオブジェクトから他のオブジェクトに渡
される情報を指します。メソッドの起動によって、ターゲットのオブジェクトに向か
うメッセージが生じます。データの物理的な移動が必ずしも生じるとはかぎりません。
NonStop DOM では、イベントハンドラによるプロセス間の転送を目的とするデータ
本体を指します。メッセージオブジェクトは、メッセージデータ (MD) セグメントへ
のポインタのリストで構成されます。実際のデータが、これらのセグメントに含まれ
ています。NonStop DOM メッセージオブジェクトは、アプリケーションがメッセー
ジ処理に必要とするメソッドを含みます。
メッセージデータ (MD) セグメント
メッセージの論理的な細区分のこと。NonStop DOM メッセージオブジェクトは、ア
プリケーションがメッセージに出力すると自動的にセグメントを作成します。あるい
は、アプリケーションがメッセージデータセグメントを明示的に作成し、処理します。
ライフサイクル (lifecycle)
オブジェクトの作成と削除、起動と停止の一連の工程。
ラッピング (wrapping)
コンポーネントに提供されているインタフェースの技術。異なる技術をベースにした
コンポーネントとの相互運用を可能にするもの。たとえば、対話する C++ オブジェ
クトクラスの集合を単一の NonStop DOM クラスのなかにラッピングすることができ
ます。あるいは、レガシーサーバのコードを、サーバの機能に対応するメソッドをサ
ポートしているオブジェクトの実装として使用することができます。
ラッピングに対する推奨アプローチは、メソッド起動と他のメッセージ形式を相互に
用語解説 -16
140418J
用語解説
変換するラッパコンポーネントを開発することです。これによって、オブジェクト指
向のクライアント / サーバとレガシークライアント / サーバの間の対話を実現できま
す。
リスナ・イベントハンドラ (listener event handler)
NonStop DOM サーバとクライアント ( たとえば、NonStop DOM クライアントや
CORBA 準拠でないクライアント ) 間が接続されるのを待つ、NSDEVENT オブジェ
クト。サーバ・イベントハンドラもまた参照してください。
リテラル
オブジェクトでないエンティティを識別する値。
リテラルは次のように分類できます。
・ 整数リテラル : 1 つまたは複数の数字
・ 文字リテラル : 1 つまたは複数の文字
・ 小数点リテラル : 整数、小数点、小数部、e または E、およびオプションの符号付
き整数指数
・ 文字列リテラル : 二重引用符で囲まれた、空または 1 つ以上の文字のシーケンス
リンク
プロセス間の論理接続。NonStop TS/MP では、要求するプロセスとサーバプール内の
サーバとの間の論理接続。
例外
プログラムの操作中に発生する受容できない状態。例外処理コードによって捕捉する
必要があります。ほとんどの例外はエラー状態ですが、例外メカニズムは他の種類の
発生事象にも使用することができます。
レガシークライアント (Legacy client)
CORBA 準拠でないクライアント。
レガシークライアントラッパ (Legacy client wrapper)
レガシーサーバとして動作する NonStop DOM アプリケーション。レガシーシステム
の要求を CORBA メソッドの起動に変換し、CORBA メソッドの完了をレガシーシス
テムの応答に変換します。
レガシーサーバ (legacy server)
CORBA 準拠でないサーバ。
レガシーサーバラッパ (Legacy server wrapper)
サーバとして動作する NonStop DOM アプリケーション。CORBA メソッドの起動を
レガシーサーバの要求に変換し、CORBA メソッドの起動に対して応答を返します。
レガシーシステム (legacy system)
NonStop DOM では、CORBA モデルをベースにしていない既存システムのこと。
ローカル / リモート透過性 (local/remote transparency)
この特性により、クライアントは、使用するオブジェクトがローカルかリモートかを
認識することが不要になります。
ロードバランシング
使用可能なラインまたはプロセス間で、それぞれ、ネットワークトラフィックやアプ
リケーションの作業負荷を分散すること。
ロールバック (roll back)
( トランザクションを ) 元に戻すこと。
ワイディング (widening)
CORBA で使用される用語。派生インタフェースから基本インタフェースに移動する
ときに使われます。C++ では、これをアップキャスト (up-cast) と呼びます。
140418J
用語解説 -17