JP2000235493A - トレーディング装置 - Google Patents
トレーディング装置Info
- Publication number
- JP2000235493A JP2000235493A JP11034765A JP3476599A JP2000235493A JP 2000235493 A JP2000235493 A JP 2000235493A JP 11034765 A JP11034765 A JP 11034765A JP 3476599 A JP3476599 A JP 3476599A JP 2000235493 A JP2000235493 A JP 2000235493A
- Authority
- JP
- Japan
- Prior art keywords
- service type
- information
- trader
- metadata
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
- G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/10—Services
- G06Q50/18—Legal services; Handling legal documents
- G06Q50/188—Electronic negotiation
Abstract
(57)【要約】
【課題】CORBA（コルバ）方式に基づく分散オブジェク
ト指向環境におけるオブジェクトと呼ばれるソフトウェ
ア単位間の動的な通信を援助するトレーディング装置に
関し、サービスタイプ名の衝突を回避し、あるいはトレ
ーダによるクライアントの認証、又はインポート処理の
権限の付与を可能にする。 【解決手段】各クライアント(7)及びトレーダ(1)が、そ
れぞれのオペレーションの文字列型のパラメータを、サ
ービスタイプと該サービスタイプの補助情報であるサー
ビスタイプコンテクストとを含むメタデータで個々に、
或いは一まとめにして記述するメタデータ生成部(75, 1
6)及び該メタデータを全体解釈するメタデータ解釈部(1
5, 76)を有する。また、トレーダへの登録／エクスポー
ト／インポート処理を要求するクライアントが、認証情
報と権限情報とを該メタデータに含めることにより、該
認証情報と該権限情報に基づきトレーダの認証処理部(1
8)で認証処理を行う。
ト指向環境におけるオブジェクトと呼ばれるソフトウェ
ア単位間の動的な通信を援助するトレーディング装置に
関し、サービスタイプ名の衝突を回避し、あるいはトレ
ーダによるクライアントの認証、又はインポート処理の
権限の付与を可能にする。 【解決手段】各クライアント(7)及びトレーダ(1)が、そ
れぞれのオペレーションの文字列型のパラメータを、サ
ービスタイプと該サービスタイプの補助情報であるサー
ビスタイプコンテクストとを含むメタデータで個々に、
或いは一まとめにして記述するメタデータ生成部(75, 1
6)及び該メタデータを全体解釈するメタデータ解釈部(1
5, 76)を有する。また、トレーダへの登録／エクスポー
ト／インポート処理を要求するクライアントが、認証情
報と権限情報とを該メタデータに含めることにより、該
認証情報と該権限情報に基づきトレーダの認証処理部(1
8)で認証処理を行う。
Description
【０００１】
【発明の属する技術分野】本発明はトレーディング装置
に関し、特にCORBA（コルバ）方式に基づく分散オブジ
ェクト指向環境におけるオブジェクトと呼ばれるソフト
ウェア単位間の動的な通信を援助するトレーディング装
置に関するものである。
に関し、特にCORBA（コルバ）方式に基づく分散オブジ
ェクト指向環境におけるオブジェクトと呼ばれるソフト
ウェア単位間の動的な通信を援助するトレーディング装
置に関するものである。
【０００２】CORBA(Common Object Request Broker Arc
hitecture)方式は、分散オブジェクト指向環境の実現の
為にOMG (Object Management Group) により規定された
分散オブジェクト指向環境の標準アーキテクチャであ
る。この規格に従い、分散オブジェクト指向環境の実装
は各ベンダが提供することになる。
hitecture)方式は、分散オブジェクト指向環境の実現の
為にOMG (Object Management Group) により規定された
分散オブジェクト指向環境の標準アーキテクチャであ
る。この規格に従い、分散オブジェクト指向環境の実装
は各ベンダが提供することになる。
【０００３】CORBA方式に準拠した分散オブジェクト指
向環境では、計算機のアーキテクチャやOSの違い、プロ
グラミング言語の違いを気にすることなく、オブジェク
ト間で処理要求をやりとりしオブジェクトの協調により
処理を実現できる。CORBA方式におけるクライアント−
サーバ間の要求／応答はオブジェクトリクエストブロー
カ(ORB)によって仲介される。CORBA方式ではブローカの
他、分散オブジェクト環境で一般に必要とされるネーミ
ングサービスや、トレーダサービス等の機能も定義して
おり、このようなサービスを共通ファシリティとして用
いることによって分散システムの構築は更に効率化でき
る。
向環境では、計算機のアーキテクチャやOSの違い、プロ
グラミング言語の違いを気にすることなく、オブジェク
ト間で処理要求をやりとりしオブジェクトの協調により
処理を実現できる。CORBA方式におけるクライアント−
サーバ間の要求／応答はオブジェクトリクエストブロー
カ(ORB)によって仲介される。CORBA方式ではブローカの
他、分散オブジェクト環境で一般に必要とされるネーミ
ングサービスや、トレーダサービス等の機能も定義して
おり、このようなサービスを共通ファシリティとして用
いることによって分散システムの構築は更に効率化でき
る。
【０００４】CORBA方式では、オブジェクト指向におけ
るオブジェクトに相当する概念をインタフェース、メソ
ッドに相当する概念をオペレーションと呼び、クライア
ントがサーバを呼び出すには、サーバのインタフェース
リファレンス(C＋＋におけるオブジェクトへの参照型)
を獲得する必要がある。
るオブジェクトに相当する概念をインタフェース、メソ
ッドに相当する概念をオペレーションと呼び、クライア
ントがサーバを呼び出すには、サーバのインタフェース
リファレンス(C＋＋におけるオブジェクトへの参照型)
を獲得する必要がある。
【０００５】インタフェースリファレンス中のオペレー
ションを呼ぶと、遠隔に存在するサーバ中の対応するメ
ソッドが自動的に呼び出される。すなわち、CORBA方式
での動作には、呼び出したいサーバのインタフェースリ
ファレンスを手に入れることが先決となる。クライアン
トがインタフェースリファレンスを入手する方法とし
て、CORBAでは上述の如くいくつかの共通ファシリティ
を想定しているが、ネーミングサービスがサーバ名とサ
ーバの実体を１対１対応とするサービス、例えば５０音
別電話帳で相手の電話番号を探すサービスに相当するサ
ービスであるのに対し、トレーダサービスは、イエロー
ページで相手の電話番号を探すサービスに相当したもの
であり、必ずしもサーバ名とサーバの実体とが１対１対
応でなくてもよいトレーディング装置として期待されて
いる。
ションを呼ぶと、遠隔に存在するサーバ中の対応するメ
ソッドが自動的に呼び出される。すなわち、CORBA方式
での動作には、呼び出したいサーバのインタフェースリ
ファレンスを手に入れることが先決となる。クライアン
トがインタフェースリファレンスを入手する方法とし
て、CORBAでは上述の如くいくつかの共通ファシリティ
を想定しているが、ネーミングサービスがサーバ名とサ
ーバの実体を１対１対応とするサービス、例えば５０音
別電話帳で相手の電話番号を探すサービスに相当するサ
ービスであるのに対し、トレーダサービスは、イエロー
ページで相手の電話番号を探すサービスに相当したもの
であり、必ずしもサーバ名とサーバの実体とが１対１対
応でなくてもよいトレーディング装置として期待されて
いる。
【０００６】
【従来の技術】このようなトレーディング装置は図31に
示すブローカORBに相当しており、同図(2)に示す如く複
数のクライアント４，５とトレーダ１とで構成され、下
記に示す如く、(1)サービスタイプの登録処理、及び(2)
サービスのエクスポート処理／インポート処理が実行さ
れる。
示すブローカORBに相当しており、同図(2)に示す如く複
数のクライアント４，５とトレーダ１とで構成され、下
記に示す如く、(1)サービスタイプの登録処理、及び(2)
サービスのエクスポート処理／インポート処理が実行さ
れる。
【０００７】(1)サービスタイプの登録処理（図31(1)参
照） a)サービスタイプの登録を要求するクライアント３（全
てのクライアントが成り得る）が、サービスタイプ名と
そのスーパタイプ名、そしてプロパティ名、型、モード
を定義したプロパティ定義、並びにインタフェース名を
トレーダ１に渡し、新規サービスタイプの登録を要求す
る。
照） a)サービスタイプの登録を要求するクライアント３（全
てのクライアントが成り得る）が、サービスタイプ名と
そのスーパタイプ名、そしてプロパティ名、型、モード
を定義したプロパティ定義、並びにインタフェース名を
トレーダ１に渡し、新規サービスタイプの登録を要求す
る。
【０００８】(2)サービスのエクスポート処理／インポ
ート処理（同図(2)参照） a)エクスポータと称されるサーバクライアント４がサー
ビスタイプ名、プロパティ値と自身のインタフェースリ
ファレンスをトレーダ１に渡し、サービスの登録を要求
する。これを受けたトレーダ１はサービスタイプとサー
バのインタフェースリファレンスの対応を保持する。
ート処理（同図(2)参照） a)エクスポータと称されるサーバクライアント４がサー
ビスタイプ名、プロパティ値と自身のインタフェースリ
ファレンスをトレーダ１に渡し、サービスの登録を要求
する。これを受けたトレーダ１はサービスタイプとサー
バのインタフェースリファレンスの対応を保持する。
【０００９】b)インポータと称されるクライアント５は
トレーダ１に必要なサービスタイプ名と制約式等を渡
し、サービス情報の提供を要求する。トレーダ１はサー
ビスタイプ、制約式の条件等が適合するサービスを選び
出す。 c)トレーダ１は行程b)で選び出されたサービス群の情報
をクライアント５に返す。
トレーダ１に必要なサービスタイプ名と制約式等を渡
し、サービス情報の提供を要求する。トレーダ１はサー
ビスタイプ、制約式の条件等が適合するサービスを選び
出す。 c)トレーダ１は行程b)で選び出されたサービス群の情報
をクライアント５に返す。
【００１０】d)クライアント５はトレーダ１から受け取
ったインタフェースリファレンスを用い、サーバ４のオ
ブジェクトを呼び出す。次に、トレーダ１とそのクライ
アント（符号「７」で総称）との間での処理のやりとり
を図32により説明する。
ったインタフェースリファレンスを用い、サーバ４のオ
ブジェクトを呼び出す。次に、トレーダ１とそのクライ
アント（符号「７」で総称）との間での処理のやりとり
を図32により説明する。
【００１１】トレーダ１は、上記のサービスタイプ管理
処理(1)、サービスエクスポート処理／インポート処理
(2)等の種類毎に、インタフェース１１とそれを実行す
る処理部１２を有する。トレーダ１が保持するサービス
タイプ情報はトレーダ１内のサービスタイプリポジトリ
１３に保持され、サービス情報はトレーダ１内のサービ
スオファリポジトリ１４に保持される。
処理(1)、サービスエクスポート処理／インポート処理
(2)等の種類毎に、インタフェース１１とそれを実行す
る処理部１２を有する。トレーダ１が保持するサービス
タイプ情報はトレーダ１内のサービスタイプリポジトリ
１３に保持され、サービス情報はトレーダ１内のサービ
スオファリポジトリ１４に保持される。
【００１２】トレーダ１はクライアント７からの処理要
求をインタフェース１１中の対応部分で受け取ると、処
理部１２の対応部分に処理を渡す。各処理部はサービス
タイプリポジトリ１３、サービスオファリポジトリ１
４、またトレーダ１外に存在するインタフェースリポジ
トリ６から適宜情報を取り出し処理を行う。処理結果は
インタフェース１１を経てトレーダ１のクライアント７
に返される。
求をインタフェース１１中の対応部分で受け取ると、処
理部１２の対応部分に処理を渡す。各処理部はサービス
タイプリポジトリ１３、サービスオファリポジトリ１
４、またトレーダ１外に存在するインタフェースリポジ
トリ６から適宜情報を取り出し処理を行う。処理結果は
インタフェース１１を経てトレーダ１のクライアント７
に返される。
【００１３】次に、このようなトレーディング装置の内
部動作の詳細を以下に説明する。 (1)サービスタイプ登録処理（図33(1)参照） サービスタイプの新規登録時には、サービスタイプ登録
要求クライアント３がトレーダ１のサービスタイプ登録
インタフェース131を呼ぶ。
部動作の詳細を以下に説明する。 (1)サービスタイプ登録処理（図33(1)参照） サービスタイプの新規登録時には、サービスタイプ登録
要求クライアント３がトレーダ１のサービスタイプ登録
インタフェース131を呼ぶ。
【００１４】このときのサービスタイプ登録のCORBA・I
DL定義の抜粋を以下に示す。 サービスタイプ登録インタフェース131から登録要求を
受けたサービスタイプ登録処理部132は、登録要求中の
スーパタイプ名に対応したスーパタイプ情報をサービス
タイプリポジトリ111から取り出す。またトレーダ１外
部のインタフェースリポジトリ６から登録要求中のサー
ビスのインタフェース定義情報を取り出す。
DL定義の抜粋を以下に示す。 サービスタイプ登録インタフェース131から登録要求を
受けたサービスタイプ登録処理部132は、登録要求中の
スーパタイプ名に対応したスーパタイプ情報をサービス
タイプリポジトリ111から取り出す。またトレーダ１外
部のインタフェースリポジトリ６から登録要求中のサー
ビスのインタフェース定義情報を取り出す。
【００１５】トレーダ１はサービスタイプリポジトリ11
1内でのスーパタイプ−サブタイプ関係と、インタフェ
ースリポジトリ６内でのインタフェース定義の継承関係
の対応を検査し、両者が対応していた場合は正当性を確
認し、新規サービスタイプをサービスタイプリポジトリ
111に格納する。
1内でのスーパタイプ−サブタイプ関係と、インタフェ
ースリポジトリ６内でのインタフェース定義の継承関係
の対応を検査し、両者が対応していた場合は正当性を確
認し、新規サービスタイプをサービスタイプリポジトリ
111に格納する。
【００１６】正常に処理が終了した場合、サービスタイ
プ登録インタフェース131は登録処理にインカネーショ
ン番号を附与し、サービスタイプ登録要求クライアント
３に返す。 (2.1)サービスエクスポート処理（同図(2)参照） サービスのエクスポート処理時には、エクスポータ４が
トレーダ１のエクスポートインタフェース141を呼ぶ。
この時のCORBA・IDL定義の抜粋を以下に示す。
プ登録インタフェース131は登録処理にインカネーショ
ン番号を附与し、サービスタイプ登録要求クライアント
３に返す。 (2.1)サービスエクスポート処理（同図(2)参照） サービスのエクスポート処理時には、エクスポータ４が
トレーダ１のエクスポートインタフェース141を呼ぶ。
この時のCORBA・IDL定義の抜粋を以下に示す。
【００１７】 エクスポートインタフェース141からエクスポート処理
要求を受けたエクスポート処理部142は、要求中で指定
されたサービスタイプ情報をサービスタイプリポジトリ
111から取り出す。パラメータ中のプロパティの型がサ
ービスタイプ定義中のプロパティの型と合致しており、
かつ必須モードのプロパティの値がエクスポート処理要
求中で与えられていれば要求は有効であり、トレーダ１
はサービスをサービスオファリポジトリ112に格納す
る。
要求を受けたエクスポート処理部142は、要求中で指定
されたサービスタイプ情報をサービスタイプリポジトリ
111から取り出す。パラメータ中のプロパティの型がサ
ービスタイプ定義中のプロパティの型と合致しており、
かつ必須モードのプロパティの値がエクスポート処理要
求中で与えられていれば要求は有効であり、トレーダ１
はサービスをサービスオファリポジトリ112に格納す
る。
【００１８】正常に処理が終了した場合、エクスポート
インタフェース141はオファIDをエクスポータ４に返
す。 (2.2)サービスインポート処理（同図(3)参照） サービスのインポート処理時には、インポータ５がトレ
ーダ１のインポートインタフェース151を呼ぶ。この時
のCORBA・IDL定義の抜粋を以下に示す。
インタフェース141はオファIDをエクスポータ４に返
す。 (2.2)サービスインポート処理（同図(3)参照） サービスのインポート処理時には、インポータ５がトレ
ーダ１のインポートインタフェース151を呼ぶ。この時
のCORBA・IDL定義の抜粋を以下に示す。
【００１９】 インポートインタフェース151からインポート処理要求
を受けたインポート処理部152は、要求中で指定された
サービスタイプの情報をサービスタイプリポジトリ111
から取り出した後、以下の手順に従い処理を行う（図34
参照）。
を受けたインポート処理部152は、要求中で指定された
サービスタイプの情報をサービスタイプリポジトリ111
から取り出した後、以下の手順に従い処理を行う（図34
参照）。
【００２０】1)インポート処理要求中で指定されたサー
ビスタイプ名とそのサブタイプのサービスの情報を、サ
ービスオファリポジトリ中112から取り出す。 2)個々のサービスのプロパティ値を元にインポート処理
要求中の制約式を計算し、式の値が真になったサービス
をインポート処理対象として選び出す。
ビスタイプ名とそのサブタイプのサービスの情報を、サ
ービスオファリポジトリ中112から取り出す。 2)個々のサービスのプロパティ値を元にインポート処理
要求中の制約式を計算し、式の値が真になったサービス
をインポート処理対象として選び出す。
【００２１】3)インポート処理要求中のプレファレンス
を元にインポート処理対象のサービスをソートする。 4)インポート処理要求中のポリシイパラメータで指定さ
れた数のサービスをインポータに対して返す。
を元にインポート処理対象のサービスをソートする。 4)インポート処理要求中のポリシイパラメータで指定さ
れた数のサービスをインポータに対して返す。
【００２２】
【発明が解決しようとする課題】分散オブジェクト指向
環境へのトレーディング装置の適用によりクライアント
−サーバ間の柔軟性は増し、システムの設計、実装、運
用は効率化されるが、依然として下記の問題点が挙げら
れる。
環境へのトレーディング装置の適用によりクライアント
−サーバ間の柔軟性は増し、システムの設計、実装、運
用は効率化されるが、依然として下記の問題点が挙げら
れる。
【００２３】[１]サービスタイプ名の衝突 トレーダ内のサービスタイプ名は一意でなくてはならな
い。この為、トレーダにサービスタイプを登録処理しよ
うとした時に名前が衝突する場合がある。例えば通信サ
ービス"Asynchronous Transfer Mode"と金融サービス"A
utomatic Teller Machine"は同じ"ATM" という名前で登
録できず、別名にしなくてはならない。
い。この為、トレーダにサービスタイプを登録処理しよ
うとした時に名前が衝突する場合がある。例えば通信サ
ービス"Asynchronous Transfer Mode"と金融サービス"A
utomatic Teller Machine"は同じ"ATM" という名前で登
録できず、別名にしなくてはならない。
【００２４】またサービスオファをエクスポート処理す
る際に、トレーダはエクスポータがどんな意図で自己の
サービスをそのサービスタイプに分類したのか("ATM"
が"Asynchronous Transfer Mode"を意味するのか"Autom
atic Teller Machine"を意味するのか) は分からない
し、インポート処理時にもインポータが指定して来たサ
ービスタイプ名の意味するところを知ることができな
い。
る際に、トレーダはエクスポータがどんな意図で自己の
サービスをそのサービスタイプに分類したのか("ATM"
が"Asynchronous Transfer Mode"を意味するのか"Autom
atic Teller Machine"を意味するのか) は分からない
し、インポート処理時にもインポータが指定して来たサ
ービスタイプ名の意味するところを知ることができな
い。
【００２５】一方、複数トレーダの協調動作の手段とし
てリンク等がある。リンクが存在すればそれに従ってイ
ンポート処理要求が転送されるが、複数トレーダ間でサ
ービスタイプ及びサービスの意味が整合していなければ
矛盾が生じる。例えばサービスタイプ"ATM" をあるトレ
ーダでは"Asynchronous Transfer Mode"という意味で、
また別のトレーダでは"Automatic Teller Machine"とい
う意味で用いていれば、インポータに意味の異なるサー
ビスが混ざって提供されることになる。
てリンク等がある。リンクが存在すればそれに従ってイ
ンポート処理要求が転送されるが、複数トレーダ間でサ
ービスタイプ及びサービスの意味が整合していなければ
矛盾が生じる。例えばサービスタイプ"ATM" をあるトレ
ーダでは"Asynchronous Transfer Mode"という意味で、
また別のトレーダでは"Automatic Teller Machine"とい
う意味で用いていれば、インポータに意味の異なるサー
ビスが混ざって提供されることになる。
【００２６】[２]トレーダによるクライアントの認証 トレーダは様々なエクスポータのエクスポート処理要求
を受けサービスオファリポジトリを構築する。また様々
なクライアントからサービスタイプ登録要求を受けてサ
ービスタイプリポジトリを構築する。
を受けサービスオファリポジトリを構築する。また様々
なクライアントからサービスタイプ登録要求を受けてサ
ービスタイプリポジトリを構築する。
【００２７】トレーダは分散環境の基盤となるオブジェ
クトであり、トレーダ内の情報が不正に、あるいは不用
意に書き替えられてはならない。この為にはトレーダと
そのクライアントの間のインタフェースに、トレーダの
機能と密接に連動する（ある種のサービスタイプは、あ
るオブジェクトからしか登録できない等）認証手段を組
み込む必要がある。
クトであり、トレーダ内の情報が不正に、あるいは不用
意に書き替えられてはならない。この為にはトレーダと
そのクライアントの間のインタフェースに、トレーダの
機能と密接に連動する（ある種のサービスタイプは、あ
るオブジェクトからしか登録できない等）認証手段を組
み込む必要がある。
【００２８】[３]インポート処理の権限 セキュリティ上の理由等から、エクスポータがサービス
を一部のクライアント（インポータ）からのみ利用可能
にしたい場合が考えられる。このような場合、トレーダ
ではサービスの在処をインポータに通常通り提供し、サ
ーバとクライアントの間で何らかの認証処理を行うこと
もできるが、インポータにサーバの存在を不用意に知ら
せない為には、エクスポート処理時にそのサービスの公
開可能な範囲をトレーダに指定できることが望ましい。
を一部のクライアント（インポータ）からのみ利用可能
にしたい場合が考えられる。このような場合、トレーダ
ではサービスの在処をインポータに通常通り提供し、サ
ーバとクライアントの間で何らかの認証処理を行うこと
もできるが、インポータにサーバの存在を不用意に知ら
せない為には、エクスポート処理時にそのサービスの公
開可能な範囲をトレーダに指定できることが望ましい。
【００２９】しかしながら、現在のトレーディング装置
では、エクスポート処理時にサービスの公開可能な範囲
を指定することも、インポータがインポート処理可能な
サービスを表す権限を示すこともできない。従って本発
明は、サービスタイプ名の衝突を回避し、あるいはトレ
ーダによるクライアントの認証、又はインポート処理の
権限の付与を可能にしたトレーディング装置を実現する
ことを目的とする。
では、エクスポート処理時にサービスの公開可能な範囲
を指定することも、インポータがインポート処理可能な
サービスを表す権限を示すこともできない。従って本発
明は、サービスタイプ名の衝突を回避し、あるいはトレ
ーダによるクライアントの認証、又はインポート処理の
権限の付与を可能にしたトレーディング装置を実現する
ことを目的とする。
【００３０】
【課題を解決するための手段】課題解決のための着眼点 [１]サービスタイプ名の衝突 この課題は、サービスタイプ／サービスオファの内容を
トレーダが認識できる形で、サービスタイプ名やプロパ
ティよりも詳しく示す手段がないことに起因する。トレ
ーダはエクスポート処理／インポート処理時にはサービ
スタイプ名を単なる文字列として一致／不一致の判定を
行うだけであり、サービスタイプ名の持つ意味は判断し
ない。これに対処する為には、サービスタイプの持つ意
味を機械認識可能、かつ拡張可能な形で記述する必要が
ある。
トレーダが認識できる形で、サービスタイプ名やプロパ
ティよりも詳しく示す手段がないことに起因する。トレ
ーダはエクスポート処理／インポート処理時にはサービ
スタイプ名を単なる文字列として一致／不一致の判定を
行うだけであり、サービスタイプ名の持つ意味は判断し
ない。これに対処する為には、サービスタイプの持つ意
味を機械認識可能、かつ拡張可能な形で記述する必要が
ある。
【００３１】[２]トレーダによるクライアントの認証 この課題は、トレーダのクライアントに関する情報（イ
ンポート処理要求者、サービスタイプ登録処理要求者）
を示す手順がないことに起因する。この課題には、トレ
ーダのクライアントが処理要求中に署名情報を添付し、
要求が適正なクライアントから発行されたことを示す為
の機構、またトレーダが署名情報を解読し、権限の情報
と照合する為の機構を備えることで対処できる。
ンポート処理要求者、サービスタイプ登録処理要求者）
を示す手順がないことに起因する。この課題には、トレ
ーダのクライアントが処理要求中に署名情報を添付し、
要求が適正なクライアントから発行されたことを示す為
の機構、またトレーダが署名情報を解読し、権限の情報
と照合する為の機構を備えることで対処できる。
【００３２】[３]インポート処理の権限 この課題も、トレーダのクライアントに関する情報（イ
ンポート処理要求者、サービスタイプ登録処理要求者）
を示す手順がないことに起因する。この課題には、トレ
ーダに対してインポータのアイデンティティを示す機構
を備えることで対処できる。認証を有効に行う為には、
誰何−応答(challenge-response)手順による認証手続き
が必要となる。
ンポート処理要求者、サービスタイプ登録処理要求者）
を示す手順がないことに起因する。この課題には、トレ
ーダに対してインポータのアイデンティティを示す機構
を備えることで対処できる。認証を有効に行う為には、
誰何−応答(challenge-response)手順による認証手続き
が必要となる。
【００３３】上記の着眼点[１]〜[３]を実現する手段に
ついて以下にそれぞれ説明する。 [１]コンテクストに基づくトレーディング処理 請求項１に係る本発明の構成を図１(1)に示す。トレー
ダ１のクライアント７（サービスタイプコンテクスト登
録要求クライアント、サービスタイプ登録要求クライア
ント、エクスポータ、インポータ等）は、処理要求部71
で生成したオペレーションの文字列型のパラメータをメ
タデータ生成部75で、サービスタイプと該サービスタイ
プの補助（包括）情報であるサービスタイプコンテクス
トとを含むメタデータで個々に記述し、インタフェース
72を介してトレーダ１へ送る。
ついて以下にそれぞれ説明する。 [１]コンテクストに基づくトレーディング処理 請求項１に係る本発明の構成を図１(1)に示す。トレー
ダ１のクライアント７（サービスタイプコンテクスト登
録要求クライアント、サービスタイプ登録要求クライア
ント、エクスポータ、インポータ等）は、処理要求部71
で生成したオペレーションの文字列型のパラメータをメ
タデータ生成部75で、サービスタイプと該サービスタイ
プの補助（包括）情報であるサービスタイプコンテクス
トとを含むメタデータで個々に記述し、インタフェース
72を介してトレーダ１へ送る。
【００３４】クライアント７から処理要求を受けるトレ
ーダ１においては、インタフェース11（請求項８）が従
来のトレーダと共通しているが、インタフェース11と処
理部12との間に、受け取った処理要求をメタデータ（デ
ータについて説明するデータ）として解釈し該オペレー
ションの文字列型のパラメータを抽出するメタデータ解
釈部15と、処理部12での処理結果をメタデータに変換す
るメタデータ生成部16が設けられている。
ーダ１においては、インタフェース11（請求項８）が従
来のトレーダと共通しているが、インタフェース11と処
理部12との間に、受け取った処理要求をメタデータ（デ
ータについて説明するデータ）として解釈し該オペレー
ションの文字列型のパラメータを抽出するメタデータ解
釈部15と、処理部12での処理結果をメタデータに変換す
るメタデータ生成部16が設けられている。
【００３５】また処理部12が参照するデータベースとし
て、サービスタイプコンテクストを含むサービスタイプ
情報を保持するサービスタイプリポジトリ13、エクスポ
ート処理されたサービスの情報を保持するサービスオフ
ァリポジトリ14がトレーダ１内に存在する（請求項10,
11) 。さらに、トレーダ１外には、サービスタイプの整
合性の検査に必要なサービスインタフェース定義を保持
するデータベースであるインタフェースリポジトリ６
（請求項12) が存在する。
て、サービスタイプコンテクストを含むサービスタイプ
情報を保持するサービスタイプリポジトリ13、エクスポ
ート処理されたサービスの情報を保持するサービスオフ
ァリポジトリ14がトレーダ１内に存在する（請求項10,
11) 。さらに、トレーダ１外には、サービスタイプの整
合性の検査に必要なサービスインタフェース定義を保持
するデータベースであるインタフェースリポジトリ６
（請求項12) が存在する。
【００３６】一方、トレーダ１のクライアント側でも、
トレーダへの処理を要求する要求処理部71と、トレーダ
へとのインタフェースをとるトレーダインタフェース72
との間に、上記のメタデータ生成部75の他に、トレーダ
１から受け取った応答をメタデータとして解釈するメタ
データ解釈部76が設けられている。
トレーダへの処理を要求する要求処理部71と、トレーダ
へとのインタフェースをとるトレーダインタフェース72
との間に、上記のメタデータ生成部75の他に、トレーダ
１から受け取った応答をメタデータとして解釈するメタ
データ解釈部76が設けられている。
【００３７】請求項２に係る本発明の構成を同図(2)に
示す。同図(1)との違いは、トレーダ１のインタフェー
スが共通化されており、共通インタフェース17（請求項
９）が存在する点である。すなわち、クライアント７で
は、要求処理内容を全てまとめてメタデータ生成部71で
メタデータ記述に変換し、インタフェース72を介してト
レーダ１に送られる。トレーダ１では該処理要求を共通
インタフェース17で受信し、メタデータ解釈部15で処理
要求全体をメタデータとして解釈する。
示す。同図(1)との違いは、トレーダ１のインタフェー
スが共通化されており、共通インタフェース17（請求項
９）が存在する点である。すなわち、クライアント７で
は、要求処理内容を全てまとめてメタデータ生成部71で
メタデータ記述に変換し、インタフェース72を介してト
レーダ１に送られる。トレーダ１では該処理要求を共通
インタフェース17で受信し、メタデータ解釈部15で処理
要求全体をメタデータとして解釈する。
【００３８】解釈後、メタデータ記述が含んでいる処理
要求内容（パラメータ）に応じて処理部12の各部分に処
理がディスパッチされる。処理結果はメタデータ生成部
16でメタデータ形式に変換された後にクライアント７に
返される。なお、同図(2)には請求項３〜７に対応する
トレーディング装置の構成として、処理部12の各部分か
ら必要に応じて呼び出され、認証処理を行う認証処理部
18（点線で図示）が設けられている。
要求内容（パラメータ）に応じて処理部12の各部分に処
理がディスパッチされる。処理結果はメタデータ生成部
16でメタデータ形式に変換された後にクライアント７に
返される。なお、同図(2)には請求項３〜７に対応する
トレーディング装置の構成として、処理部12の各部分か
ら必要に応じて呼び出され、認証処理を行う認証処理部
18（点線で図示）が設けられている。
【００３９】次に、このような構成を有する本発明の作
用を説明する。各請求項ではサービスタイプの補助情報
（包括情報）としてサービスタイプコンテクストを定義
し、サービスタイプ名の衝突とサービスタイプの示す概
念の混乱を防ぐ。サービスタイプコンテクストによって
サービスタイプ名の名前空間は分割され、サービスタイ
プコンテクストが異なれば、サービスタイプ名は衝突し
ない。サービスタイプコンテクストによりサービスタイ
プ名空間が構造化されたサービスタイプリポジトリ13内
の情報の構成例を図２(1)に示す。これを説明すると以
下のようになる。
用を説明する。各請求項ではサービスタイプの補助情報
（包括情報）としてサービスタイプコンテクストを定義
し、サービスタイプ名の衝突とサービスタイプの示す概
念の混乱を防ぐ。サービスタイプコンテクストによって
サービスタイプ名の名前空間は分割され、サービスタイ
プコンテクストが異なれば、サービスタイプ名は衝突し
ない。サービスタイプコンテクストによりサービスタイ
プ名空間が構造化されたサービスタイプリポジトリ13内
の情報の構成例を図２(1)に示す。これを説明すると以
下のようになる。
【００４０】(1)サービスタイプの構造（同図参照） ・サービスタイプ名で構成されるサービスタイプ名の名
前空間は、コンテクストX，Z，X.Y等のように、サービ
スタイプコンテクストで分割される ・サービスタイプコンテクスト間に包含関係を設定でき
る。例ではコンテクストXがコンテクストX.Yを包含して
いる ・サービスタイプの全体集合を包含するデフォルトコン
テクスト130が定義される。デフォルトコンテクスト130
は全てのサービスタイプコンテクストを直接あるいは間
接的に包含する。この例ではデフォルトコンテクスト13
0はSvcTypeA, D, Eを直接包含している。 ・サービスタイプコンテクストが異なる限り、同名のサ
ービスタイプは複数存在できる。この例ではデフォルト
コンテクスト130、サービスタイプコンテクストX.Y, Z
内にSvcTypeAが存在する。
前空間は、コンテクストX，Z，X.Y等のように、サービ
スタイプコンテクストで分割される ・サービスタイプコンテクスト間に包含関係を設定でき
る。例ではコンテクストXがコンテクストX.Yを包含して
いる ・サービスタイプの全体集合を包含するデフォルトコン
テクスト130が定義される。デフォルトコンテクスト130
は全てのサービスタイプコンテクストを直接あるいは間
接的に包含する。この例ではデフォルトコンテクスト13
0はSvcTypeA, D, Eを直接包含している。 ・サービスタイプコンテクストが異なる限り、同名のサ
ービスタイプは複数存在できる。この例ではデフォルト
コンテクスト130、サービスタイプコンテクストX.Y, Z
内にSvcTypeAが存在する。
【００４１】次に、トレーダでのサービスタイプコンテ
クストの取り扱いを説明する。サービスタイプコンテク
ストに基づくトレーディングの処理フローを図４に示
す。すなわち、トレーダ１に処理を要求するクライアン
ト７は、処理要求中のサービスタイプ名パラメータとし
て、サービスタイプ名の補助情報であるサービスタイプ
コンテクスト名を附加し、メタデータ生成部75でメタデ
ータ記述に変換する。メタデータ記述されたパラメータ
は、他のパラメータとともにインタフェース72を通じて
トレーダ１に送信される。
クストの取り扱いを説明する。サービスタイプコンテク
ストに基づくトレーディングの処理フローを図４に示
す。すなわち、トレーダ１に処理を要求するクライアン
ト７は、処理要求中のサービスタイプ名パラメータとし
て、サービスタイプ名の補助情報であるサービスタイプ
コンテクスト名を附加し、メタデータ生成部75でメタデ
ータ記述に変換する。メタデータ記述されたパラメータ
は、他のパラメータとともにインタフェース72を通じて
トレーダ１に送信される。
【００４２】インタフェース部11で処理要求を受け取っ
たトレーダ１は（ステップＳ１）、メタデータ記述され
たパラメータをメタデータ解釈部15で解釈し（同Ｓ
２）、要求を各処理部12の各部分に送る。各処理部12で
の処理終了後（同Ｓ３）、処理結果はメタデータ生成部
16でメタデータ記述に変換され、インタフェース11を通
じて処理要求元に送られる（同Ｓ４）。
たトレーダ１は（ステップＳ１）、メタデータ記述され
たパラメータをメタデータ解釈部15で解釈し（同Ｓ
２）、要求を各処理部12の各部分に送る。各処理部12で
の処理終了後（同Ｓ３）、処理結果はメタデータ生成部
16でメタデータ記述に変換され、インタフェース11を通
じて処理要求元に送られる（同Ｓ４）。
【００４３】処理結果を受け取ったクライアント７は、
応答中のメタデータ記述されたパラメータをメタデータ
解釈部76で解釈し、要求処理部71で応答結果に応じた処
理を行う。次に、コンテクストの概念に基づくトレーダ
１内での処理の様子を示す。
応答中のメタデータ記述されたパラメータをメタデータ
解釈部76で解釈し、要求処理部71で応答結果に応じた処
理を行う。次に、コンテクストの概念に基づくトレーダ
１内での処理の様子を示す。
【００４４】(2)サービスタイプコンテクスト登録処理
（同図(2)参照） サービスタイプリポジトリ13中のサービスタイプ情報の
初期状態（同図(1)）において、上位サービスタイプコ
ンテクストにデフォルトコンテクスト130を指定し、サ
ービスタイプコンテクストWを新規に登録する要求を受
けた場合、トレーダ１ではデフォルトコンテクスト130
中に新規サービスタイプコンテクストW（太線で図示。
以下同様）を生成する。
（同図(2)参照） サービスタイプリポジトリ13中のサービスタイプ情報の
初期状態（同図(1)）において、上位サービスタイプコ
ンテクストにデフォルトコンテクスト130を指定し、サ
ービスタイプコンテクストWを新規に登録する要求を受
けた場合、トレーダ１ではデフォルトコンテクスト130
中に新規サービスタイプコンテクストW（太線で図示。
以下同様）を生成する。
【００４５】(3)サービスタイプ登録処理（同図(3)参
照） 同図(2)を初期状態として、サービスタイプコンテクス
トX.Yを指定し、スーパタイプAの下に新規サービスタイ
プEを登録する場合を考える。トレーダ１ではサービス
タイプコンテクストX.Y を検索し、当該コンテクストX.
Y中にサービスタイプAの存在を確認すると、そのサブタ
イプとして新規サービスタイプEを生成する。
照） 同図(2)を初期状態として、サービスタイプコンテクス
トX.Yを指定し、スーパタイプAの下に新規サービスタイ
プEを登録する場合を考える。トレーダ１ではサービス
タイプコンテクストX.Y を検索し、当該コンテクストX.
Y中にサービスタイプAの存在を確認すると、そのサブタ
イプとして新規サービスタイプEを生成する。
【００４６】サービスタイプAはコンテクストX.Y以外に
もデフォルトコンテクスト130、コンテクストZに存在す
るが、コンテクストの概念が機能することでスーパタイ
プとなるサービスタイプは一意に決定される。 (4)エクスポート処理（同図(4)参照） 同図(3)を初期状態として、サービスタイプコンテクス
トZを指定し、サービスタイプDに新規サービスをエクス
ポート処理する場合を考える。
もデフォルトコンテクスト130、コンテクストZに存在す
るが、コンテクストの概念が機能することでスーパタイ
プとなるサービスタイプは一意に決定される。 (4)エクスポート処理（同図(4)参照） 同図(3)を初期状態として、サービスタイプコンテクス
トZを指定し、サービスタイプDに新規サービスをエクス
ポート処理する場合を考える。
【００４７】トレーダ１ではサービスタイプコンテクス
トZ を検索し、当該コンテクストZ中のサービスタイプD
の存在を確認すると、このサービスタイプDに新規サー
ビスNSVCを登録する。サービスタイプDはサービスタイ
プコンテクストZ以外にもデフォルトコンテクスト130中
に存在するが、コンテクストの概念が機能することで新
規サービスのサービスタイプは一意に決定される。
トZ を検索し、当該コンテクストZ中のサービスタイプD
の存在を確認すると、このサービスタイプDに新規サー
ビスNSVCを登録する。サービスタイプDはサービスタイ
プコンテクストZ以外にもデフォルトコンテクスト130中
に存在するが、コンテクストの概念が機能することで新
規サービスのサービスタイプは一意に決定される。
【００４８】(5)インポート処理（図３(1)〜(4)参照） 図２(4)の状態から、トレーダ１がインポート処理要求
を受けた場合を考える。インポート処理要求されるサー
ビスタイプ名とサービスタイプコンテクスト指定から、
以下のようにインポート処理対象となるサービスのサー
ビスタイプが決定される。
を受けた場合を考える。インポート処理要求されるサー
ビスタイプ名とサービスタイプコンテクスト指定から、
以下のようにインポート処理対象となるサービスのサー
ビスタイプが決定される。
【００４９】・サービスタイプAをコンテクスト指定な
しでインポート処理した場合、デフォルトコンテクスト
130に存在するサービスタイプAとそのサブタイプである
サービスタイプDとサービスタイプE、またデフォルトコ
ンテクスト130に内包されるサービスタイプコンテクス
トX.Y中のサービスタイプAとそのサブタイプであるサー
ビスタイプE、またサービスタイプコンテクストZ中のサ
ービスタイプAが該当する（図３(1)参照）。
しでインポート処理した場合、デフォルトコンテクスト
130に存在するサービスタイプAとそのサブタイプである
サービスタイプDとサービスタイプE、またデフォルトコ
ンテクスト130に内包されるサービスタイプコンテクス
トX.Y中のサービスタイプAとそのサブタイプであるサー
ビスタイプE、またサービスタイプコンテクストZ中のサ
ービスタイプAが該当する（図３(1)参照）。
【００５０】・サービスタイプAをサービスタイプコン
テクストXを指定してインポート処理した場合、サービ
スタイプコンテクストXの中のコンテクストX.Yのサービ
スタイプAと、そのサブタイプであるサービスタイプEが
該当する（同図(2)参照）。 ・サービスタイプEをサービスタイプコンテクストZを指
定してインポート処理した場合、サービスタイプコンテ
クストZ内にはサービスタイプEは存在しないので、該当
するサービスタイプはない（同図(3)参照）。
テクストXを指定してインポート処理した場合、サービ
スタイプコンテクストXの中のコンテクストX.Yのサービ
スタイプAと、そのサブタイプであるサービスタイプEが
該当する（同図(2)参照）。 ・サービスタイプEをサービスタイプコンテクストZを指
定してインポート処理した場合、サービスタイプコンテ
クストZ内にはサービスタイプEは存在しないので、該当
するサービスタイプはない（同図(3)参照）。
【００５１】・サービスタイプEをデフォルトコンテク
スト指定でインポート処理した場合、コンテクストの指
定がないので、デフォルトコンテクスト130のサービス
タイプEと、コンテクストX中のサービスタイプE、及び
X.YのサービスタイプEが該当する（同図(4)参照）。
スト指定でインポート処理した場合、コンテクストの指
定がないので、デフォルトコンテクスト130のサービス
タイプEと、コンテクストX中のサービスタイプE、及び
X.YのサービスタイプEが該当する（同図(4)参照）。
【００５２】[２]トレーダのクライアントの認証 請求項３〜７及び11, 13に係る本発明ではトレーダのク
ライアントの認証を行う。トレーダ１のクライアント７
はトレーダが持つリポジトリ13内のサービスタイプコン
テクスト、サービスタイプ、及びサービスに対して権限
情報を設定することができ、クライアント７は処理要求
中でこの権限に適合する署名を提示しなくてはならな
い。
ライアントの認証を行う。トレーダ１のクライアント７
はトレーダが持つリポジトリ13内のサービスタイプコン
テクスト、サービスタイプ、及びサービスに対して権限
情報を設定することができ、クライアント７は処理要求
中でこの権限に適合する署名を提示しなくてはならな
い。
【００５３】(1)認証処理を行う構成（図５参照） 認証はサービスタイプコンテクスト登録の際、更にサー
ビスタイプ登録、サービス登録、インポート処理の際に
行われる。トレーダ１のクライアント７は、処理要求の
他のパラメータと共に、その処理要求を行う権限を持つ
ことを示す認証情報と、処理の結果として生成される情
報（サービスタイプコンテクスト、サービスタイプ、サ
ービス等）に対して設定する権限情報をメタデータ生成
部75でメタデータ形式に変換し、インタフェース72を介
してトレーダ１に送信する。
ビスタイプ登録、サービス登録、インポート処理の際に
行われる。トレーダ１のクライアント７は、処理要求の
他のパラメータと共に、その処理要求を行う権限を持つ
ことを示す認証情報と、処理の結果として生成される情
報（サービスタイプコンテクスト、サービスタイプ、サ
ービス等）に対して設定する権限情報をメタデータ生成
部75でメタデータ形式に変換し、インタフェース72を介
してトレーダ１に送信する。
【００５４】共通インタフェース11を介してクライアン
ト７からの処理要求を受け取ったトレーダ１は、メタデ
ータ解釈部15で上記の権限情報及び認証情報を解釈して
抽出した後、この認証情報を用いて認証処理部18でクラ
イアント７が要求の権限を持っているか否かを判定す
る。
ト７からの処理要求を受け取ったトレーダ１は、メタデ
ータ解釈部15で上記の権限情報及び認証情報を解釈して
抽出した後、この認証情報を用いて認証処理部18でクラ
イアント７が要求の権限を持っているか否かを判定す
る。
【００５５】権限が認められた場合は処理部12の各部で
通常の処理を行い、生成された情報（サービスタイプコ
ンテクスト、サービスタイプ、サービス等）に権限情報
を設定する。処理結果はメタデータ生成部16でメタデー
タ記述に変換され、インタフェース11を介してクライア
ント７に返される。
通常の処理を行い、生成された情報（サービスタイプコ
ンテクスト、サービスタイプ、サービス等）に権限情報
を設定する。処理結果はメタデータ生成部16でメタデー
タ記述に変換され、インタフェース11を介してクライア
ント７に返される。
【００５６】(2)クライアント認証手順（図６参照） トレーダ１のクライアント７は、トレーダ１に登録する
サービスタイプコンテクスト、サービスタイプ、及びサ
ービスについて権限情報を設定できる。権限情報は他パ
ラメータと共にメタデータ記述されトレーダに送信され
る（ステップＳ１）。権限情報を設定することで、クラ
イアントからの以下の要求中に適切な署名を添付しない
と処理を受け付けないように制限することができる。
サービスタイプコンテクスト、サービスタイプ、及びサ
ービスについて権限情報を設定できる。権限情報は他パ
ラメータと共にメタデータ記述されトレーダに送信され
る（ステップＳ１）。権限情報を設定することで、クラ
イアントからの以下の要求中に適切な署名を添付しない
と処理を受け付けないように制限することができる。
【００５７】クライアントからの要求を受け取ったトレ
ーダはメタデータ解釈部で権限情報を抽出し（同Ｓ
１）、以下のようにサービスタイプリポジトリ、あるい
はサービスオファリポジトリに格納する。1)新規サービ
スタイプコンテクストに包含される配下のサービスタイ
プコンテクストを登録可能なクライアント７を制限する
権限情報は、コンテクスト情報と共にサービスタイプリ
ポジトリ13に格納される（請求項３, 11）。
ーダはメタデータ解釈部で権限情報を抽出し（同Ｓ
１）、以下のようにサービスタイプリポジトリ、あるい
はサービスオファリポジトリに格納する。1)新規サービ
スタイプコンテクストに包含される配下のサービスタイ
プコンテクストを登録可能なクライアント７を制限する
権限情報は、コンテクスト情報と共にサービスタイプリ
ポジトリ13に格納される（請求項３, 11）。
【００５８】2)新規サービスタイプの配下にサブタイプ
を登録処理可能なクライアント７を制限する権限情報
は、サービスタイプ情報と共にサービスタイプリポジト
リ13に格納される（請求項４, 11）。 3)新規サービスタイプコンテクストの配下に新たにサー
ビスタイプを登録処理可能なクライアント７を制限する
権限情報は、サービスタイプコンテクスト情報と共にサ
ービスタイプリポジトリ13に格納される（請求項５, 1
1）。
を登録処理可能なクライアント７を制限する権限情報
は、サービスタイプ情報と共にサービスタイプリポジト
リ13に格納される（請求項４, 11）。 3)新規サービスタイプコンテクストの配下に新たにサー
ビスタイプを登録処理可能なクライアント７を制限する
権限情報は、サービスタイプコンテクスト情報と共にサ
ービスタイプリポジトリ13に格納される（請求項５, 1
1）。
【００５９】4)サービスタイプとしてサービスをエクス
ポート処理可能なクライアント７を制限する権限情報
は、サービスタイプ情報と共にサービスタイプリポジト
リ13に格納される（請求項６, 11）。 5)登録すべきサービスをインポート処理可能なクライア
ント（インポータ）を制限する権限情報は、サービス情
報と共にサービスオファリポジトリ14に格納される（請
求項７, 11, 13）。
ポート処理可能なクライアント７を制限する権限情報
は、サービスタイプ情報と共にサービスタイプリポジト
リ13に格納される（請求項６, 11）。 5)登録すべきサービスをインポート処理可能なクライア
ント（インポータ）を制限する権限情報は、サービス情
報と共にサービスオファリポジトリ14に格納される（請
求項７, 11, 13）。
【００６０】すなわち、請求項７に係る本発明では、エ
クスポータが指定したサービスをインポート処理可能な
権限に基づきインポータの認証処理を行う（同Ｓ５）。
エクスポータは自身がエクスポート処理したサービスに
ついて権限情報を設定することができ、インポータはイ
ンポート処理要求中でこの権限に適合する署名を提示し
なくてはならない。
クスポータが指定したサービスをインポート処理可能な
権限に基づきインポータの認証処理を行う（同Ｓ５）。
エクスポータは自身がエクスポート処理したサービスに
ついて権限情報を設定することができ、インポータはイ
ンポート処理要求中でこの権限に適合する署名を提示し
なくてはならない。
【００６１】そして、サービスのインポータを制限する
権限情報は、有効な処理要求か否かを処理部12の各部で
判定して（同Ｓ６，Ｓ３）、認証の結果、トレーダ１の
サービスオファリポジトリ14に格納される（同Ｓ７）。 (3)インポータ認証手順 インポータの認証は、トレーダとインポータとの間の誰
何−応答手順に従って行われる。認証時の両者間での処
理の流れを図７に示し、以下に図８を参照して説明す
る。
権限情報は、有効な処理要求か否かを処理部12の各部で
判定して（同Ｓ６，Ｓ３）、認証の結果、トレーダ１の
サービスオファリポジトリ14に格納される（同Ｓ７）。 (3)インポータ認証手順 インポータの認証は、トレーダとインポータとの間の誰
何−応答手順に従って行われる。認証時の両者間での処
理の流れを図７に示し、以下に図８を参照して説明す
る。
【００６２】1)インポート処理要求を受けたトレーダ１
内のインポート処理部12は、認証処理部18に対してイン
ポータ（クライアント）５を認証する誰何情報の生成を
要求する（ステップＳ８）。生成された誰何情報はメタ
データ生成部16でメタデータ記述に変換され、インポー
タ５に渡されて間合せされる（同Ｓ９）。
内のインポート処理部12は、認証処理部18に対してイン
ポータ（クライアント）５を認証する誰何情報の生成を
要求する（ステップＳ８）。生成された誰何情報はメタ
データ生成部16でメタデータ記述に変換され、インポー
タ５に渡されて間合せされる（同Ｓ９）。
【００６３】2)インポータ５は受けた誰何情報を自己の
持つ私有鍵で暗号化後にハッシュ（簡略化された暗号
化）し、暗号化方法、ハッシュ方法の情報をメタデータ
記述したものと共にトレーダ１に対して応答する。 3)インポータ５の応答を受けたトレーダは、暗号化─ハ
ッシュ化された情報を認証処理部にて誰何情報と比較し
て認証を行い（同Ｓ10）、適切な応答であれば、通常の
インポート処理と同様に、インポート処理結果を返す
（同Ｓ11）。
持つ私有鍵で暗号化後にハッシュ（簡略化された暗号
化）し、暗号化方法、ハッシュ方法の情報をメタデータ
記述したものと共にトレーダ１に対して応答する。 3)インポータ５の応答を受けたトレーダは、暗号化─ハ
ッシュ化された情報を認証処理部にて誰何情報と比較し
て認証を行い（同Ｓ10）、適切な応答であれば、通常の
インポート処理と同様に、インポート処理結果を返す
（同Ｓ11）。
【００６４】このようにして、本発明に係るトレーディ
ング装置はトレーダとそのクライアントの間で授受され
る要求のパラメータと、応答のパラメータにメタデータ
記述を導入し、サービスタイプのサービスタイプコンテ
クスト、クライアントの認証情報及び権限情報等を厳密
かつ拡張可能な形式で記述することを可能にしている。
ング装置はトレーダとそのクライアントの間で授受され
る要求のパラメータと、応答のパラメータにメタデータ
記述を導入し、サービスタイプのサービスタイプコンテ
クスト、クライアントの認証情報及び権限情報等を厳密
かつ拡張可能な形式で記述することを可能にしている。
【００６５】
【発明の実施の形態】図１に示した本発明に係るトレー
ディング装置の実施例を図９に示したトレーディング処
理の流れに従って以下に説明する。 (１)サービスタイプコンテクスト及びサービスタイプの
登録処理手順（同図(1)参照） a)サービスタイプコンテクスト登録要求クライアント２
（図１(1)に示すクライアント７に相当）がトレーダ１
にサービスタイプコンテクスト名とその上位コンテクス
ト名を渡し、新規サービスタイプコンテクストの登録処
理を要求する。この時、サービスタイプを登録する権限
を示す認証情報、また新規サービスタイプコンテクスト
配下にサービスタイプコンテクスト、サービスタイプを
登録するために必要な権限情報を渡す。
ディング装置の実施例を図９に示したトレーディング処
理の流れに従って以下に説明する。 (１)サービスタイプコンテクスト及びサービスタイプの
登録処理手順（同図(1)参照） a)サービスタイプコンテクスト登録要求クライアント２
（図１(1)に示すクライアント７に相当）がトレーダ１
にサービスタイプコンテクスト名とその上位コンテクス
ト名を渡し、新規サービスタイプコンテクストの登録処
理を要求する。この時、サービスタイプを登録する権限
を示す認証情報、また新規サービスタイプコンテクスト
配下にサービスタイプコンテクスト、サービスタイプを
登録するために必要な権限情報を渡す。
【００６６】b)サービスタイプ登録要求クライアント３
（同クライアント７に相当）がトレーダに新規サービス
タイプ名とそのスーパタイプ名及びサービスタイプコン
テクスト名、及びプロパティ情報を渡し、新規サービス
タイプ登録を要求する。この時、サービスタイプを登録
する権限を示す認証情報、そのサービスタイプのサービ
スをエクスポート処理するのに必要な権限情報を渡す。
（同クライアント７に相当）がトレーダに新規サービス
タイプ名とそのスーパタイプ名及びサービスタイプコン
テクスト名、及びプロパティ情報を渡し、新規サービス
タイプ登録を要求する。この時、サービスタイプを登録
する権限を示す認証情報、そのサービスタイプのサービ
スをエクスポート処理するのに必要な権限情報を渡す。
【００６７】(２)サービスのエクスポート処理／インポ
ート処理手順（同図(2)参照） a)エクスポータ４（同クライアント７に相当）が自己の
インタフェース（Ｉ／Ｆ）リファレンスとサービスタイ
プ名、サービスのプロパティ値と、サービスタイプの附
加情報であるサービスタイプコンテクスト名をトレーダ
１に渡し、サービスエクスポート処理を要求する。同時
にエクスポート処理する権限を示す署名情報と、そのサ
ービスをインポート処理するのに必要な権限情報を同時
に渡す。
ート処理手順（同図(2)参照） a)エクスポータ４（同クライアント７に相当）が自己の
インタフェース（Ｉ／Ｆ）リファレンスとサービスタイ
プ名、サービスのプロパティ値と、サービスタイプの附
加情報であるサービスタイプコンテクスト名をトレーダ
１に渡し、サービスエクスポート処理を要求する。同時
にエクスポート処理する権限を示す署名情報と、そのサ
ービスをインポート処理するのに必要な権限情報を同時
に渡す。
【００６８】b)インポータ５（同クライアント７に相
当）はサービスタイプ名とそのサービスタイプの附加情
報であるサービスタイプコンテクスト名、制約式等を示
し、トレーダ１にインポート処理を要求する。同時にイ
ンポート処理を行う権限を持つことを示す認証情報を渡
す。
当）はサービスタイプ名とそのサービスタイプの附加情
報であるサービスタイプコンテクスト名、制約式等を示
し、トレーダ１にインポート処理を要求する。同時にイ
ンポート処理を行う権限を持つことを示す認証情報を渡
す。
【００６９】c)トレーダ１は選び出されたサービス群の
情報をインポータ５に返す。 d)クライアント（インポータ）５はインポート処理して
既に得たインタフェースリファレンスを用い、サーバ
（エクスポータ）４を呼び出す。この動作にはもうトレ
ーダ１は関与しない。
情報をインポータ５に返す。 d)クライアント（インポータ）５はインポート処理して
既に得たインタフェースリファレンスを用い、サーバ
（エクスポータ）４を呼び出す。この動作にはもうトレ
ーダ１は関与しない。
【００７０】(３)パラメータ毎のメタデータ記述の実施
例（図１(1)参照） (3.1)メタデータ生成部の動作 トレーダのクライアントでは、処理要求中のメタデータ
記述を生成する為に定型のフォーマットとなる文字列を
用いる。サービスタイプ登録要求オブジェクトがサービ
スタイプ登録を要求する際の、パラメータを個別にメタ
データ記述する場合の実施例は以下の通りである。
例（図１(1)参照） (3.1)メタデータ生成部の動作 トレーダのクライアントでは、処理要求中のメタデータ
記述を生成する為に定型のフォーマットとなる文字列を
用いる。サービスタイプ登録要求オブジェクトがサービ
スタイプ登録を要求する際の、パラメータを個別にメタ
データ記述する場合の実施例は以下の通りである。
【００７１】a)サービスタイプパラメータの生成（図10
参照） サービスタイプパラメータ用の定型フォーマット文字列
は、以下のように定義される。 name＿template = "<rdf:RDF> <rdf:Description about = %1 Traderns:InstanceOf =＼" CORBASvcType＼"> <rdf:Description about = %2 traderns:ContextOf = %1> </rdf:RDF>" サービスタイプパラメータの生成は図10のフローに従
う。メタデータ記述の開始文字列"<rdf:RDF>" の後に
（ステップＳ21，Ｓ22）、name＿template文字列中の"%
1"をサービスタイプ名の文字列、"%2"をサービスタイプ
のコンテクスト名の文字列で置換したものを追加し（同
Ｓ23）、最後にメタデータ記述の終了を示す文字列"</r
df:RDF>"を追加（同Ｓ24）したものがパラメータとな
る。
参照） サービスタイプパラメータ用の定型フォーマット文字列
は、以下のように定義される。 name＿template = "<rdf:RDF> <rdf:Description about = %1 Traderns:InstanceOf =＼" CORBASvcType＼"> <rdf:Description about = %2 traderns:ContextOf = %1> </rdf:RDF>" サービスタイプパラメータの生成は図10のフローに従
う。メタデータ記述の開始文字列"<rdf:RDF>" の後に
（ステップＳ21，Ｓ22）、name＿template文字列中の"%
1"をサービスタイプ名の文字列、"%2"をサービスタイプ
のコンテクスト名の文字列で置換したものを追加し（同
Ｓ23）、最後にメタデータ記述の終了を示す文字列"</r
df:RDF>"を追加（同Ｓ24）したものがパラメータとな
る。
【００７２】b)スーパタイプパラメータの生成（図11参
照) スーパタイプパラメータ用の定型フォーマット文字列は
以下のように定義される。 super ＿type＿template = " <rdf:Description about = %1 traderns:SubtypeOf = %2>" スーパタイプパラメータの生成は図11のフローに従う。
メタデータ記述の開始文字列"<rdf:RDF>" の後に、supe
r ＿type文字列中の"%1"をスーパタイプ名の文字列、"%
2"をスーパタイプのコンテクスト名の文字列で置換した
ものを追加し（同Ｓ25，Ｓ26)、最後にメタデータ記述
の終了を示す文字列"</rdf:RDF>"を追加したものがパラ
メータとなる（同Ｓ27，Ｓ28) 。
照) スーパタイプパラメータ用の定型フォーマット文字列は
以下のように定義される。 super ＿type＿template = " <rdf:Description about = %1 traderns:SubtypeOf = %2>" スーパタイプパラメータの生成は図11のフローに従う。
メタデータ記述の開始文字列"<rdf:RDF>" の後に、supe
r ＿type文字列中の"%1"をスーパタイプ名の文字列、"%
2"をスーパタイプのコンテクスト名の文字列で置換した
ものを追加し（同Ｓ25，Ｓ26)、最後にメタデータ記述
の終了を示す文字列"</rdf:RDF>"を追加したものがパラ
メータとなる（同Ｓ27，Ｓ28) 。
【００７３】(3.2)インタフェースの動作 トレーダ１及びクライアント７のインタフェース11及び
72の処理は、既存のものを用いることができる。該イン
タフェースは要求処理を受信した後、パラメータをメタ
データ解釈部15に通した後に処理部12の各部に渡す。
72の処理は、既存のものを用いることができる。該イン
タフェースは要求処理を受信した後、パラメータをメタ
データ解釈部15に通した後に処理部12の各部に渡す。
【００７４】(3.3)メタデータ解釈部の動作 トレーダ１内のメタデータ解釈部15は図12に示す辞書を
保持する。辞書は論述部100と単語部200を（多数) 保持
する。単語部200は名前空間210と単語名220で構成され
る。論述部100は辞書中の３つの要素110〜130を参照す
るリストである。
保持する。辞書は論述部100と単語部200を（多数) 保持
する。単語部200は名前空間210と単語名220で構成され
る。論述部100は辞書中の３つの要素110〜130を参照す
るリストである。
【００７５】メタデータ解釈部15では、他のオブジェク
トから受け取ったメタデータ記述を元にして辞書にエン
トリを追加する。メタデータ記述を読み込み、辞書を構
築する時の処理フローを図13に示す。先ずプロパティ(P
ROP)リストやオブジェクト(OBJ)リストを初期化した後
（ステップＳ31）、文字列が"<rdf:RDF>" で始まってい
ない場合はエラーとし（同Ｓ32）、次にメタデータの記
述の形式("<rdf: Description about=")で始まっていな
い場合もエラーとする（同Ｓ33, 34）。この次のトーク
ンを単語に追加し、ABOUTATTR に代入する（同Ｓ35）。
ABOUTATTR は論述の第１要素110となる。
トから受け取ったメタデータ記述を元にして辞書にエン
トリを追加する。メタデータ記述を読み込み、辞書を構
築する時の処理フローを図13に示す。先ずプロパティ(P
ROP)リストやオブジェクト(OBJ)リストを初期化した後
（ステップＳ31）、文字列が"<rdf:RDF>" で始まってい
ない場合はエラーとし（同Ｓ32）、次にメタデータの記
述の形式("<rdf: Description about=")で始まっていな
い場合もエラーとする（同Ｓ33, 34）。この次のトーク
ンを単語に追加し、ABOUTATTR に代入する（同Ｓ35）。
ABOUTATTR は論述の第１要素110となる。
【００７６】次に来るトークンも単語に追加し、同時に
PROPリストに追加する（同Ｓ36, 37）。PROPリストの要
素は論述の第２要素120となる。次に等号が来ない場合
もエラーとする（同Ｓ38）。次のトークンも単語に追加
し、同時にOBJリストに追加する（同Ｓ39）。OBJリスト
の要素は論述の第３要素130となる。メタデータ記述が
次に続いていればそのままPROPリスト及びOBJリストに
追加する。
PROPリストに追加する（同Ｓ36, 37）。PROPリストの要
素は論述の第２要素120となる。次に等号が来ない場合
もエラーとする（同Ｓ38）。次のトークンも単語に追加
し、同時にOBJリストに追加する（同Ｓ39）。OBJリスト
の要素は論述の第３要素130となる。メタデータ記述が
次に続いていればそのままPROPリスト及びOBJリストに
追加する。
【００７７】記述が閉じられたならば論述を生成する
（同Ｓ40, 42）。生成した論述の第１要素110にABOUTAT
TR を設定後、第２要素120、第３要素130にPROP, OBJリ
ストの要素を設定する（同Ｓ43, 44）。リストの要素が
まだ存在していれば（同Ｓ45）、更に論述を生成し、第
１要素110にABOUTATTR を、第２、第３要素120, 130 に
PROP, OBJリストの要素を設定し（同Ｓ46, Ｓ47, Ｓ43,
Ｓ44）、リストの要素がなくなった時に終了する。
（同Ｓ40, 42）。生成した論述の第１要素110にABOUTAT
TR を設定後、第２要素120、第３要素130にPROP, OBJリ
ストの要素を設定する（同Ｓ43, 44）。リストの要素が
まだ存在していれば（同Ｓ45）、更に論述を生成し、第
１要素110にABOUTATTR を、第２、第３要素120, 130 に
PROP, OBJリストの要素を設定し（同Ｓ46, Ｓ47, Ｓ43,
Ｓ44）、リストの要素がなくなった時に終了する。
【００７８】(3.4)リポジトリのデータ構造（図14参
照） トレーダ１の内部では、サービスタイプコンテクスト、
サービスタイプ、及びサービスの情報を管理する。これ
らの情報は図14に示すデータ構造の中に保持される。
照） トレーダ１の内部では、サービスタイプコンテクスト、
サービスタイプ、及びサービスの情報を管理する。これ
らの情報は図14に示すデータ構造の中に保持される。
【００７９】サービスタイプリポジトリ13は、サービス
タイプコンテクスト1311〜1314((A)〜(D))とサービスタ
イプ1321, 1322((A), (C))の情報を保持する。サービス
タイプコンテクスト及びサービスタイプはそれぞれツリ
ー構造を形成する。各サービスタイプコンテクスト1311
〜1314はそれぞれ上位サービスタイプコンテクストと下
位サービスタイプコンテクストを参照するリストを持
ち、これによりツリー構造を形成する。デフォルトコン
テクスト1311の上位サービスタイプコンテクストはヌル
(null)となる。また、各サービスタイプコンテクスト13
11〜1314はそのコンテクストに直接内包するサービスタ
イプのルートのリストを保持している。
タイプコンテクスト1311〜1314((A)〜(D))とサービスタ
イプ1321, 1322((A), (C))の情報を保持する。サービス
タイプコンテクスト及びサービスタイプはそれぞれツリ
ー構造を形成する。各サービスタイプコンテクスト1311
〜1314はそれぞれ上位サービスタイプコンテクストと下
位サービスタイプコンテクストを参照するリストを持
ち、これによりツリー構造を形成する。デフォルトコン
テクスト1311の上位サービスタイプコンテクストはヌル
(null)となる。また、各サービスタイプコンテクスト13
11〜1314はそのコンテクストに直接内包するサービスタ
イプのルートのリストを保持している。
【００８０】サービスタイプ1321, 1322はスーパタイプ
を参照するリストと、サブタイプを参照するリストとを
持ち、これによりツリー構造を形成する。任意のサービ
スタイプコンテクストにおけるルートサービスタイプ13
21のスーパタイプはヌルである。サービスタイプは更に
そのサービスタイプに属するサービス141〜144のリスト
をサービスオファリポジトリ14に保持する。
を参照するリストと、サブタイプを参照するリストとを
持ち、これによりツリー構造を形成する。任意のサービ
スタイプコンテクストにおけるルートサービスタイプ13
21のスーパタイプはヌルである。サービスタイプは更に
そのサービスタイプに属するサービス141〜144のリスト
をサービスオファリポジトリ14に保持する。
【００８１】すなわち、サービスオファリポジトリ14が
保持するサービスはサービスタイプ1321, 1322が保持す
るサービス(A)〜(D)中のリストから参照され、個々のサ
ービスの情報を保持する。 (3.5)サービスタイプコンテクスト登録処理（図15(1)参
照） 1) インタフェース定義 サービスタイプコンテクスト登録インタフェースを呼び
出すCORBA・IDLを次のように定義する 。
保持するサービスはサービスタイプ1321, 1322が保持す
るサービス(A)〜(D)中のリストから参照され、個々のサ
ービスの情報を保持する。 (3.5)サービスタイプコンテクスト登録処理（図15(1)参
照） 1) インタフェース定義 サービスタイプコンテクスト登録インタフェースを呼び
出すCORBA・IDLを次のように定義する 。
【００８２】 name パラメータに登録を要求するサービスタイプコン
テクスト名、及びsuper＿contextパラメータに上位サー
ビスタイプコンテクスト名を格納し、上記add＿context
オペレーションを呼び出す。super＿contextパラメータ
がヌル文字列の場合は、デフォルトコンテクスト直下の
コンテクストとしてサービスタイプコンテクストを登録
する。
テクスト名、及びsuper＿contextパラメータに上位サー
ビスタイプコンテクスト名を格納し、上記add＿context
オペレーションを呼び出す。super＿contextパラメータ
がヌル文字列の場合は、デフォルトコンテクスト直下の
コンテクストとしてサービスタイプコンテクストを登録
する。
【００８３】2)動作 図９(1)に示したサービスタイプコンテクスト登録要求
クライアント２とトレーダ１の動作を図13(1) に示す。
サービスタイプコンテクスト登録要求処理部21( 図１
（１）の要求処理部71に相当）は、メタデータ生成部25
（同75に相当) でサービスタイプコンテクスト情報、及
び上位サービスタイプコンテクスト情報のパラメータを
メタデータ形式で記述し、コンテクスト登録インタフェ
ース22（同72に相当) を介してトレーダ１のサービスタ
イプコンテクスト登録インタフェース112（同11に相当)
を呼び出す。
クライアント２とトレーダ１の動作を図13(1) に示す。
サービスタイプコンテクスト登録要求処理部21( 図１
（１）の要求処理部71に相当）は、メタデータ生成部25
（同75に相当) でサービスタイプコンテクスト情報、及
び上位サービスタイプコンテクスト情報のパラメータを
メタデータ形式で記述し、コンテクスト登録インタフェ
ース22（同72に相当) を介してトレーダ１のサービスタ
イプコンテクスト登録インタフェース112（同11に相当)
を呼び出す。
【００８４】トレーダ１のサービスタイプコンテクスト
登録インタフェース112は該パラメータをメタデータ解
釈部15に渡し、このメタデータ解釈部15ではパラメータ
をメタデータとして解釈する。この後、コンテクスト登
録処理部122（同12に相当)ではサービスタイプリポジト
リ13中に新規コンテクストを作成し、結果をメタデータ
生成部16でメタデータ形式に変換してクライアント２に
返す。
登録インタフェース112は該パラメータをメタデータ解
釈部15に渡し、このメタデータ解釈部15ではパラメータ
をメタデータとして解釈する。この後、コンテクスト登
録処理部122（同12に相当)ではサービスタイプリポジト
リ13中に新規コンテクストを作成し、結果をメタデータ
生成部16でメタデータ形式に変換してクライアント２に
返す。
【００８５】(3.6)サービスタイプ登録処理（図15(2)参
照） 1)インタフェース定義 サービスタイプ登録をメタデータ記述で行うには、上述
した既存インタフェースのパラメータを個々にメタデー
タで記述する。サービスタイプ名にサービスタイプコン
テクスト情報を附与する場合は、nameパラメータとsupe
r＿types パラメータの表記をメタデータで記述する。
照） 1)インタフェース定義 サービスタイプ登録をメタデータ記述で行うには、上述
した既存インタフェースのパラメータを個々にメタデー
タで記述する。サービスタイプ名にサービスタイプコン
テクスト情報を附与する場合は、nameパラメータとsupe
r＿types パラメータの表記をメタデータで記述する。
【００８６】例えば、論述「サービスタイプCはサービ
スタイプコンテクストXの中で定義される」を示すメタ
データ記述は次の通りである。 [SvcTypeC] --- InstanceOf ---> [CORBASvcType] [ContextX] --- ContextOf ---> [SvcTypeC] これを文字列形式で表すと以下のようになる。これがna
meパラメータの値となる。
スタイプコンテクストXの中で定義される」を示すメタ
データ記述は次の通りである。 [SvcTypeC] --- InstanceOf ---> [CORBASvcType] [ContextX] --- ContextOf ---> [SvcTypeC] これを文字列形式で表すと以下のようになる。これがna
meパラメータの値となる。
【００８７】 <rdf:RDF> <rdf:Description about="SvcTypeC" traderns:InstanceOf ="CORBASvcType"> <rdf:Description about="ContextX" traderns:ContextOf ="SvcTypeC"> </rdf:RDF> ここでRDF(Resource Description Framework)はネット
ワーク上のリソース（Webページ等）について記述する
ための枠組みである。RDFではリソースについて記述す
るために一階の述語論理に基づくメタデータ記述が行わ
れる。
ワーク上のリソース（Webページ等）について記述する
ための枠組みである。RDFではリソースについて記述す
るために一階の述語論理に基づくメタデータ記述が行わ
れる。
【００８８】例えば、論述「サービスタイプC はサービ
スタイプA, Bのサブタイプである」を示すメタデータ記
述を以下に示す。 これを文字列形式で表すと以下のようになる。これがsu
per＿typeパラメータの値となる。
スタイプA, Bのサブタイプである」を示すメタデータ記
述を以下に示す。 これを文字列形式で表すと以下のようになる。これがsu
per＿typeパラメータの値となる。
【００８９】 <rdf:RDF> <rdf:Description about="ServiceTypeC" traderns:SubtypeOf="SvcTypeA"> <rdf:Description about="ServiceTypeC" traderns:SubtypeOf="SvcTypeB"> </rdf:RDF> また、例えば、「プロパティPropertyd はサービスタイ
プC のプロパティであり、型はInteger 、モードはNORM
ALである」ことを示すメタデータ記述は、以下のように
なる。
プC のプロパティであり、型はInteger 、モードはNORM
ALである」ことを示すメタデータ記述は、以下のように
なる。
【００９０】 これを文字列形式で表すと以下のようになる。これがpr
ops パラメータの値となる。
ops パラメータの値となる。
【００９１】 <rdf:RDF> <rdf:Description about="Propertyd" traderns:PropertyOf="SvcTypeC"> <rdf:Description about="Propertyd" traderns:Type="Integer"> <rdf:Description about="Propertyd" traderns:Mode="NORMAL"> </rdf:RDF> 2)動作 サービスタイプ登録要求クライアント３とトレーダ１の
動作を図13(3)に示す。サービスタイプ登録要求処理部3
1（同図１(1)の要求処理部71に相当) は、メタデータ生
成部35（同75に相当）でサービスタイプコンテクスト情
報を含むサービスタイプ名とスーパタイプ名、プロパテ
ィ定義、インタフェース名パラメータのメタデータ記述
を作成し、サービスタイプ登録インタフェース32（同72
に相当）を介してトレーダのサービスタイプ登録インタ
フェース113（同11に相当）を呼び出す。
動作を図13(3)に示す。サービスタイプ登録要求処理部3
1（同図１(1)の要求処理部71に相当) は、メタデータ生
成部35（同75に相当）でサービスタイプコンテクスト情
報を含むサービスタイプ名とスーパタイプ名、プロパテ
ィ定義、インタフェース名パラメータのメタデータ記述
を作成し、サービスタイプ登録インタフェース32（同72
に相当）を介してトレーダのサービスタイプ登録インタ
フェース113（同11に相当）を呼び出す。
【００９２】トレーダ１のサービスタイプ登録インタフ
ェース113はパラメータをメタデータ解釈部15に渡し、
パラメータをメタデータとして解釈する。サービスタイ
プ登録処理部123（同12に相当）ではインタフェースリ
ポジトリ６中のデータを参照して新規サービスタイプの
検査を行った後、サービスタイプをサービスタイプリポ
ジトリ13中に作成する。処理終了後、処理結果はメタデ
ータ生成部16でメタデータに変換され、インカネーショ
ン番号がクライアント３に返される。
ェース113はパラメータをメタデータ解釈部15に渡し、
パラメータをメタデータとして解釈する。サービスタイ
プ登録処理部123（同12に相当）ではインタフェースリ
ポジトリ６中のデータを参照して新規サービスタイプの
検査を行った後、サービスタイプをサービスタイプリポ
ジトリ13中に作成する。処理終了後、処理結果はメタデ
ータ生成部16でメタデータに変換され、インカネーショ
ン番号がクライアント３に返される。
【００９３】(3.7)サービスエクスポート要求処理（図1
5(3)参照) 1)インタフェース定義 エクスポート要求処理をCORBA・IDLで図６(1) 〜に
示すように定義する。サービスエクスポート要求処理を
メタデータ記述で行うには、上記のCORBA・IDLインタフ
ェース定義のパラメータを同図(2) 〜に示すように
個々にメタデータで記述する。サービスタイプ名を示す
typeパラメータは、サービスタイプ登録時のnameパラメ
ータと同様に記述できる。
5(3)参照) 1)インタフェース定義 エクスポート要求処理をCORBA・IDLで図６(1) 〜に
示すように定義する。サービスエクスポート要求処理を
メタデータ記述で行うには、上記のCORBA・IDLインタフ
ェース定義のパラメータを同図(2) 〜に示すように
個々にメタデータで記述する。サービスタイプ名を示す
typeパラメータは、サービスタイプ登録時のnameパラメ
ータと同様に記述できる。
【００９４】例えば、論述「プロパティpropertydの型
はIntegerであり、値は０である」を示すメタデータ記
述は以下の通りである。 これを文字列形式で表すと次のようになる（同図(2)
参照）。これがpropertiesパラメータの値となる。
はIntegerであり、値は０である」を示すメタデータ記
述は以下の通りである。 これを文字列形式で表すと次のようになる（同図(2)
参照）。これがpropertiesパラメータの値となる。
【００９５】 <rdf:RDF> <rdf:Description about = "propertyd" traderns:Type = "Integer"> <rdf:Description about = "propertyd" traderns:Value = "0"> </rdf:RDF> 次に論述「オブジェクトリファレンスreference の値
は"IOR:xxxxxxx" である」を示すメタデータ記述は次の
通りである。
は"IOR:xxxxxxx" である」を示すメタデータ記述は次の
通りである。
【００９６】 "IOR:xxxxxxxx" --- InstanceOf ---> [reference] これを文字列形式で表すと以下のようになる（同参
照）。これがreferenceパラメータの値となる。 <rdf:RDF> <rdf:Description about = "IOR:xxxxxxxx" traderns:InstanceOf = "reference"> </rdf:RDF> 2)動作 サービスエクスポータ４とトレーダ１の動作を図15(3)
に示す。サービスエクスポート要求処理部41（図１(1)
の要求処理部71に相当) は、メタデータ生成部45（同75
に相当) でサービスのサービスタイプコンテクスト情報
を含むパラメータのメタデータ記述を作成し、エクスポ
ートインタフェース42（同72に相当) を通じてトレーダ
１のエクスポートインタフェース114（同11に相当) を
呼び出す。
照）。これがreferenceパラメータの値となる。 <rdf:RDF> <rdf:Description about = "IOR:xxxxxxxx" traderns:InstanceOf = "reference"> </rdf:RDF> 2)動作 サービスエクスポータ４とトレーダ１の動作を図15(3)
に示す。サービスエクスポート要求処理部41（図１(1)
の要求処理部71に相当) は、メタデータ生成部45（同75
に相当) でサービスのサービスタイプコンテクスト情報
を含むパラメータのメタデータ記述を作成し、エクスポ
ートインタフェース42（同72に相当) を通じてトレーダ
１のエクスポートインタフェース114（同11に相当) を
呼び出す。
【００９７】トレーダ１のエクスポートインタフェース
114は、パラメータをメタデータ解釈部15に渡し、パラ
メータをメタデータとして解釈する。この後、サービス
エクスポート処理部124（同12に相当) ではサービスタ
イプリポジトリ13を検査後、サービスオファリポジトリ
14に新規サービスを登録し、処理結果をメタデータ生成
部16でメタデータに変換後、オファIDをエクスポータ４
に返す。
114は、パラメータをメタデータ解釈部15に渡し、パラ
メータをメタデータとして解釈する。この後、サービス
エクスポート処理部124（同12に相当) ではサービスタ
イプリポジトリ13を検査後、サービスオファリポジトリ
14に新規サービスを登録し、処理結果をメタデータ生成
部16でメタデータに変換後、オファIDをエクスポータ４
に返す。
【００９８】(3.8)サービスインポート要求処理（図15
(4)参照) 1)インタフェース定義 インポート要求処理をメタデータ記述で行うには、上述
の既存インタフェースのパラメータを個々にメタデータ
で記述する。サービスタイプ名を示すtypeパラメータは
サービスタイプ登録時のnameパラメータと同様に記述で
きる。
(4)参照) 1)インタフェース定義 インポート要求処理をメタデータ記述で行うには、上述
の既存インタフェースのパラメータを個々にメタデータ
で記述する。サービスタイプ名を示すtypeパラメータは
サービスタイプ登録時のnameパラメータと同様に記述で
きる。
【００９９】例えば、論述「制約式は"xxxxxxxx"であ
る」を示すメタデータ記述は以下の通りである。 "xxxxxxxxx" --- InstanceOf ---> [Constraint] これを文字列形式で表すと次のようになる。これがcons
trパラメータの値となる。
る」を示すメタデータ記述は以下の通りである。 "xxxxxxxxx" --- InstanceOf ---> [Constraint] これを文字列形式で表すと次のようになる。これがcons
trパラメータの値となる。
【０１００】 <rdf:RDF> <rdf:Description about="xxxxxxxx" traderns:instanceOf="constr"> </rdf:RDF> 更に「プレファレンスは"xxxxxxxx"である」ことを示す
メタデータ記述は以下の通りである。
メタデータ記述は以下の通りである。
【０１０１】 "xxxxxxxxx" --- InstanceOf ---> [Preference] これを文字列形式で表すと以下のようになる。これがpr
efパラメータの値となる。 <rdf:RDF> <rdf:Description about="xxxxxxxx" traderns:instanceOf="pref"> </rdf:RDF> 2)動作 サービスインポータ５とトレーダ１の動作を図15(4)に
示す。サービスインポート処理部51（図１(1)の要求処
理部71に相当）は、インポート処理するサービスのサー
ビスタイプコンテクスト情報を含むパラメータのメタデ
ータ記述をインポート処理部55（同75に相当）で生成
し、インポートインタフェース部52（同72に相当）を通
じてトレーダ１のインポートインタフェース115（同11
に相当）を呼び出す。
efパラメータの値となる。 <rdf:RDF> <rdf:Description about="xxxxxxxx" traderns:instanceOf="pref"> </rdf:RDF> 2)動作 サービスインポータ５とトレーダ１の動作を図15(4)に
示す。サービスインポート処理部51（図１(1)の要求処
理部71に相当）は、インポート処理するサービスのサー
ビスタイプコンテクスト情報を含むパラメータのメタデ
ータ記述をインポート処理部55（同75に相当）で生成
し、インポートインタフェース部52（同72に相当）を通
じてトレーダ１のインポートインタフェース115（同11
に相当）を呼び出す。
【０１０２】トレーダ１内のインポートインタフェース
115はパラメータをメタデータ解釈部15に渡し、パラメ
ータをメタデータとして解釈する。この後、インポート
処理部125（同12に相当）でサービスタイプリポジトリ1
3中のサービスタイプの関係を調べた後、サービスオフ
ァリポジトリ14中からインポート処理対象となるサービ
スを検索する。検索結果はメタデータ生成部16でメタデ
ータに変換後、インポータ５に返す。
115はパラメータをメタデータ解釈部15に渡し、パラメ
ータをメタデータとして解釈する。この後、インポート
処理部125（同12に相当）でサービスタイプリポジトリ1
3中のサービスタイプの関係を調べた後、サービスオフ
ァリポジトリ14中からインポート処理対象となるサービ
スを検索する。検索結果はメタデータ生成部16でメタデ
ータに変換後、インポータ５に返す。
【０１０３】(４)オペレーション全体のメタデータ記述
の実施例（図１(2)参照） (4.1)メタデータ生成部の動作 メタデータ生成部の動作はパタメータ毎の場合(3.1)と
同様である。 (4.2)インタフェースの動作 トレーダ１のインタフェースは新規に作成される。イン
タフェースの例を図17(1)に示す。すなわち、CORBA・ID
L定義を"string operation"とし、その"description"中
に一連のオペレーション群をメタデータ記述している。
その表記は同図(2)に示すようにメタデータ生成部で生
成される。
の実施例（図１(2)参照） (4.1)メタデータ生成部の動作 メタデータ生成部の動作はパタメータ毎の場合(3.1)と
同様である。 (4.2)インタフェースの動作 トレーダ１のインタフェースは新規に作成される。イン
タフェースの例を図17(1)に示す。すなわち、CORBA・ID
L定義を"string operation"とし、その"description"中
に一連のオペレーション群をメタデータ記述している。
その表記は同図(2)に示すようにメタデータ生成部で生
成される。
【０１０４】(4.3)メタデータ解釈部の動作 トレーダ内のメタデータ解釈部の動作はパタメータ毎の
場合(3.3)と同様である。 (4.4)リポジトリのデータ構造 リポジトリのデータ構造は図12に示したものを使用する
ことができる。
場合(3.3)と同様である。 (4.4)リポジトリのデータ構造 リポジトリのデータ構造は図12に示したものを使用する
ことができる。
【０１０５】(4.5)サービスタイプコンテクスト登録処
理（図18(1)参照） 1)インタフェース定義 サービスタイプコンテクスト登録処理要求のパラメータ
をまとめてメタデータとして記述する場合は、サービス
タイプコンテクストを含む処理要求中のパラメータを一
つのメタデータとして記述する。
理（図18(1)参照） 1)インタフェース定義 サービスタイプコンテクスト登録処理要求のパラメータ
をまとめてメタデータとして記述する場合は、サービス
タイプコンテクストを含む処理要求中のパラメータを一
つのメタデータとして記述する。
【０１０６】例えば、論述「ContextXの下位コンテクス
トとしてContextYを登録する」のメタデータ記述は次の
ようになる。 [node1] --- InstanceOf ---> [RDF:Property] +-- PropName ---> [traderns:InstanceOf] +-- PropObj ---> [ContextY] +-- value ---> [CORBASvcTypeContext] [node1] --- add＿context ---> [someone] [contextY] --- ContextOf ---> [contextX] これを文字列形式で表したものを以下に示す。
トとしてContextYを登録する」のメタデータ記述は次の
ようになる。 [node1] --- InstanceOf ---> [RDF:Property] +-- PropName ---> [traderns:InstanceOf] +-- PropObj ---> [ContextY] +-- value ---> [CORBASvcTypeContext] [node1] --- add＿context ---> [someone] [contextY] --- ContextOf ---> [contextX] これを文字列形式で表したものを以下に示す。
【０１０７】 <rdf:RDF> <rdf:Description> <rdf:propObj ContextY/> <rdf:propName traderns:InstanceOf/> <rdf:value CORBASvcTypeContext/> <rdf:instanceOf Property/> <Traderns:add ＿context traderns:someone/> </rdf:Description> <rdf:Description about = "contextY" traderns:ContextOf="contextX"/> </rdf:RDF> 2)動作 サービスタイプコンテクスト登録要求クライアント２と
トレーダ１の動作を図18(1)に示す。サービスタイプコ
ンテクスト登録要求処理部21は、メタデータ生成部25を
呼んでサービスタイプコンテクスト情報を含む全パラメ
ータをまとめたメタデータ記述を作成し、クライアント
インタフェース22を介してトレーダ１の共通インタフェ
ース11を呼び出す。
トレーダ１の動作を図18(1)に示す。サービスタイプコ
ンテクスト登録要求処理部21は、メタデータ生成部25を
呼んでサービスタイプコンテクスト情報を含む全パラメ
ータをまとめたメタデータ記述を作成し、クライアント
インタフェース22を介してトレーダ１の共通インタフェ
ース11を呼び出す。
【０１０８】トレーダ１の共通インタフェース11はメタ
データ記述をメタデータ解釈部15に渡して解釈し、処理
要求内容を調べる。処理要求がサービスタイプコンテク
スト登録要求であった場合はコンテクスト登録処理部12
2に処理を移す。コンテクスト登録処理後は、その結果
をメタデータ生成部16でメタデータ記述に変換後、クラ
イアント２に応答する。
データ記述をメタデータ解釈部15に渡して解釈し、処理
要求内容を調べる。処理要求がサービスタイプコンテク
スト登録要求であった場合はコンテクスト登録処理部12
2に処理を移す。コンテクスト登録処理後は、その結果
をメタデータ生成部16でメタデータ記述に変換後、クラ
イアント２に応答する。
【０１０９】(4.6)サービスタイプ登録処理（図18(2)参
照） 1)インタフェース定義 サービスタイプ登録処理要求のパラメータをまとめてメ
タデータとして記述する場合は、処理要求中のパラメー
タ全てを一つのメタデータとして記述する。
照） 1)インタフェース定義 サービスタイプ登録処理要求のパラメータをまとめてメ
タデータとして記述する場合は、処理要求中のパラメー
タ全てを一つのメタデータとして記述する。
【０１１０】例えば、論述「ContextX中で定義されるSv
cTypeCを登録する。SvcTypeCはSvcTypeA, B のサブタイ
プであり、Integer 型のプロパティPropertyD を持つ」
のメタデータ記述は以下のようになる。 [node1] --- InstanceOf ---> [RDF:Property] +-- PropName ---> [SvcTypeC] +-- PropObj ---> [traderns:InstanceOf] +-- value ---> [CORBASvcType] [node1] --- add＿type ---> [someone] [contextX] --- ContextOf ---> [SvcTypeC] [SvcTypeC] --- traderns:SubTypeOf ---> [SvcTypeA] +-- traderns:SubTypeOf ---> [SvcTypeB] [PropertyD] --- traderns:PropertyOf ---> [SvcTypeC] +-- traderns:Type ---> [Integer] +-- traderns:Mode ---> [NORMAL] これを文字列形式で表すと、次のようになる。
cTypeCを登録する。SvcTypeCはSvcTypeA, B のサブタイ
プであり、Integer 型のプロパティPropertyD を持つ」
のメタデータ記述は以下のようになる。 [node1] --- InstanceOf ---> [RDF:Property] +-- PropName ---> [SvcTypeC] +-- PropObj ---> [traderns:InstanceOf] +-- value ---> [CORBASvcType] [node1] --- add＿type ---> [someone] [contextX] --- ContextOf ---> [SvcTypeC] [SvcTypeC] --- traderns:SubTypeOf ---> [SvcTypeA] +-- traderns:SubTypeOf ---> [SvcTypeB] [PropertyD] --- traderns:PropertyOf ---> [SvcTypeC] +-- traderns:Type ---> [Integer] +-- traderns:Mode ---> [NORMAL] これを文字列形式で表すと、次のようになる。
【０１１１】 <rdf:RDF> <rdf:Description> <rdf:propObj SvcTypeC/> <rdf:propName traderns:InstanceOf/> <rdf:value CORBASvcType/> <rdf:instanceOf Property/> <Traderns:add ＿type traderns:someone/> </rdf:Description> <rdf:Description about="ContextX" traderns:ContextOf="SvcTypeC"> <rdf:Description about="ServiceTypeC" traderns:SubtypeOf="SvcTypeA"> <rdf:Description about="ServiceTypeC" traderns:SubtypeOf="SvcTypeB"> <rdf:Description about="Propertyd" traderns:PropertyOf="SvcTypeC"> <rdf:Description about="Propertyd" traderns:Type="Integer"> <rdf:Description about="Propertyd" traderns:Nomde="NORMAL"> </rdf:RDF> 2)動作 サービスタイプ登録要求クライアント３とトレーダ１の
動作を図18(2)に示す。サービスタイプ登録要求処理部3
1は、メタデータ生成部35を呼んでサービスタイプコン
テクスト情報を含むパラメータを全てまとめたメタデー
タ記述を作成し、クライアントインタフェース32を介し
てトレーダ１の共通インタフェース11を呼び出す。
動作を図18(2)に示す。サービスタイプ登録要求処理部3
1は、メタデータ生成部35を呼んでサービスタイプコン
テクスト情報を含むパラメータを全てまとめたメタデー
タ記述を作成し、クライアントインタフェース32を介し
てトレーダ１の共通インタフェース11を呼び出す。
【０１１２】トレーダ１の共通インタフェースは、メタ
データ記述をメタデータ解釈部15に渡して解釈し、要求
内容を調べる。処理要求がサービスタイプ登録要求であ
った場合はサービスタイプ登録要求123に処理を移す。
サービスタイプ登録処理後は、その結果をメタデータ生
成部16でメタデータ記述に変換した後、クライアント２
に応答する。
データ記述をメタデータ解釈部15に渡して解釈し、要求
内容を調べる。処理要求がサービスタイプ登録要求であ
った場合はサービスタイプ登録要求123に処理を移す。
サービスタイプ登録処理後は、その結果をメタデータ生
成部16でメタデータ記述に変換した後、クライアント２
に応答する。
【０１１３】(4.7)サービスエクスポート要求処理（図1
8(3)参照） 1)インタフェース定義 エクスポート要求処理をCORBA・IDLで図17(1)に示した
ように定義する。サービスエクスポート要求処理のメタ
データをまとめてメタデータとして記述する場合は、上
記のCORBA・IDLインタフェース定義のメタデータをまと
めて同図(2)に示すように記述する。
8(3)参照） 1)インタフェース定義 エクスポート要求処理をCORBA・IDLで図17(1)に示した
ように定義する。サービスエクスポート要求処理のメタ
データをまとめてメタデータとして記述する場合は、上
記のCORBA・IDLインタフェース定義のメタデータをまと
めて同図(2)に示すように記述する。
【０１１４】例えば、論述「ServiceAをエクスポートす
る。ServiceAはContextXにおけるSvcTypeCのサービスで
あり、PropertyD の値は0 である」のメタデータ記述は
次のようになる。 [node1] --- propObj ---> [ServiceA] +-- propName ---> [traderns:InstanceOf] +-- value ---> [SvcTypeC] +-- instanceOf ---> [Property] +-- traderns:export ---> [someone] [ContextX] --- traderns:contextOf ---> [SvcTypeC] [PropertyD] --- traderns:Value ---> [0] [ServiceA] --- ifReference ---> [ior:xxxxxxxxxxxxxx] これを文字列形式で表すと、以下のようになる。
る。ServiceAはContextXにおけるSvcTypeCのサービスで
あり、PropertyD の値は0 である」のメタデータ記述は
次のようになる。 [node1] --- propObj ---> [ServiceA] +-- propName ---> [traderns:InstanceOf] +-- value ---> [SvcTypeC] +-- instanceOf ---> [Property] +-- traderns:export ---> [someone] [ContextX] --- traderns:contextOf ---> [SvcTypeC] [PropertyD] --- traderns:Value ---> [0] [ServiceA] --- ifReference ---> [ior:xxxxxxxxxxxxxx] これを文字列形式で表すと、以下のようになる。
【０１１５】 <rdf:RDF> <rdf:Description> <rdf:propObj ServiceA/> <rdf:propName traderns:InstanceOf/> <rdf:value SvcTypeC/> <rdf:instanceOf Property/> <Traderns:export traderns:someone/> </rdf:Description> <rdf:Description about="ContextX" traderns:ContextOf="SvcTypeC"> <rdf:Description about="PropertyD" traderns:Value="0"> <rdf:Description about="ServiceA" ifReference="ior:xxxxxxxxxxxx"> </rdf:RDF> 2)動作 サービスエクスポータ４とトレーダ１の動作を図18(3)
に示す。サービスエクスポート処理部41は、メタデータ
生成部45を呼んでサービスタイプコンテクストを含む全
パラメータをまとめたメタデータ記述を作成し、クライ
アントインタフェース42を介してトレーダ１の共通イン
タフェース11を呼び出す。
に示す。サービスエクスポート処理部41は、メタデータ
生成部45を呼んでサービスタイプコンテクストを含む全
パラメータをまとめたメタデータ記述を作成し、クライ
アントインタフェース42を介してトレーダ１の共通イン
タフェース11を呼び出す。
【０１１６】トレーダ１の共通インタフェース11はメタ
データ記述の文字列をメタデータ解釈部15に渡し、処理
内容を判別する。処理要求がサービスエクスポート要求
であった場合はサービスエクスポート処理部124に処理
を移す。エクスポート処理後の処理結果は、メタデータ
生成部16でメタデータ記述に変換後、エクスポータ４に
応答する。
データ記述の文字列をメタデータ解釈部15に渡し、処理
内容を判別する。処理要求がサービスエクスポート要求
であった場合はサービスエクスポート処理部124に処理
を移す。エクスポート処理後の処理結果は、メタデータ
生成部16でメタデータ記述に変換後、エクスポータ４に
応答する。
【０１１７】(4.8)サービスインポート要求処理（図18
(4)参照） 1)インタフェース定義 サービスインポート要求処理のパラメータをまとめてメ
タデータとして記述する場合は、処理要求中の全パラメ
ータを一つのメタデータとして記述する。
(4)参照） 1)インタフェース定義 サービスインポート要求処理のパラメータをまとめてメ
タデータとして記述する場合は、処理要求中の全パラメ
ータを一つのメタデータとして記述する。
【０１１８】例えば、論述「ContextXにおけるSvcTypeC
のサービスをインポートする。制約式は"xxxxxxxx"、プ
レファレンスは"yyyyyy"である」のメタデータ表記は次
のようになる。 [node1] --- propObj ---> [SvcTypeC] +-- propName ---> [traderns:InstanceOf] +-- value ---> [CORBASvc] +-- instanceOf ---> [Property] +-- traderns:query ---> [someone] [ContextX] --- traderns:contextOf ---> [SvcTypeC] [constr] --- Value ---> "xxxxxxxx" [pref] --- Value ---> "yyyyyyyy" これを文字列形式で表すと、次のようになる。
のサービスをインポートする。制約式は"xxxxxxxx"、プ
レファレンスは"yyyyyy"である」のメタデータ表記は次
のようになる。 [node1] --- propObj ---> [SvcTypeC] +-- propName ---> [traderns:InstanceOf] +-- value ---> [CORBASvc] +-- instanceOf ---> [Property] +-- traderns:query ---> [someone] [ContextX] --- traderns:contextOf ---> [SvcTypeC] [constr] --- Value ---> "xxxxxxxx" [pref] --- Value ---> "yyyyyyyy" これを文字列形式で表すと、次のようになる。
【０１１９】 <rdf:RDF> <rdf:Description> <rdf:propObj SvcTypeC/> <rdf:propName traderns:InstanceOf/> <rdf:value CORBASvc/> <rdf:instanceOf Property/> <traderns:query traderns:someone/> </rdf:Description> <rdf:Description about="ContextX" traderns:ContextOf="SvcTypeC"> <rdf:Description about="constr" traderns:Value="xxx"> <rdf:Description about="pref" traderns:Value="yyy"> </rdf:RDF> 2)動作 サービスインポータ５とトレーダ１の動作を図18(4)に
示す。サービスインポート処理部51は、メタデータ生成
部55を呼んでサービスタイプコンテクストを含む全パラ
メータをまとめたメタデータ記述を作成し、クライアン
トインタフェース52を介してトレーダ１の共通インタフ
ェース11を呼び出す。
示す。サービスインポート処理部51は、メタデータ生成
部55を呼んでサービスタイプコンテクストを含む全パラ
メータをまとめたメタデータ記述を作成し、クライアン
トインタフェース52を介してトレーダ１の共通インタフ
ェース11を呼び出す。
【０１２０】トレーダ１の共通インタフェース11はメタ
データ記述をメタデータ解釈部15に渡し、処理内容を判
別する。処理要求がサービスインポート要求であった場
合はインポート処理部125に処理を移す。インポートさ
れたサービス群の情報はメタデータ生成部16でメタデー
タ記述に変換され、インポータ５に返される。
データ記述をメタデータ解釈部15に渡し、処理内容を判
別する。処理要求がサービスインポート要求であった場
合はインポート処理部125に処理を移す。インポートさ
れたサービス群の情報はメタデータ生成部16でメタデー
タ記述に変換され、インポータ５に返される。
【０１２１】(５)サービスタイプコンテクスト処理 上記の各オペレーションにおけるパラメータ中のサービ
スタイプコンテクストは以下のようにして実現され、サ
ービスタイプ名の衝突や、サービスタイプの示す概念を
整理する。
スタイプコンテクストは以下のようにして実現され、サ
ービスタイプ名の衝突や、サービスタイプの示す概念を
整理する。
【０１２２】(5.1)サービスタイプコンテクスト登録処
理部の動作（図13(1) 、図18(1) 及び図19参照） メタデータ解釈部15からパラメータを受け取ったサービ
スタイプコンテクスト登録処理部122は、先ずデフォル
トコンテクストを起点として（ステップＳ51）、サービ
スタイプコンテクストを登録すべき上位のサービスタイ
プコンテクストを検索する（同Ｓ52）。指定されたコン
テクストが見つからなかった場合はエラーとする。
理部の動作（図13(1) 、図18(1) 及び図19参照） メタデータ解釈部15からパラメータを受け取ったサービ
スタイプコンテクスト登録処理部122は、先ずデフォル
トコンテクストを起点として（ステップＳ51）、サービ
スタイプコンテクストを登録すべき上位のサービスタイ
プコンテクストを検索する（同Ｓ52）。指定されたコン
テクストが見つからなかった場合はエラーとする。
【０１２３】次に上位コンテクストの内包するコンテク
ストリストを取り出し（同Ｓ53）、既存コンテクストと
の名前の重複を検査する（同Ｓ54〜Ｓ56）。名前が重複
するコンテクストがない場合は、新規コンテクストを生
成し、上位コンテクスト内の下位コンテクストリストに
当該コンテクストを追加する（同Ｓ57〜Ｓ59）。
ストリストを取り出し（同Ｓ53）、既存コンテクストと
の名前の重複を検査する（同Ｓ54〜Ｓ56）。名前が重複
するコンテクストがない場合は、新規コンテクストを生
成し、上位コンテクスト内の下位コンテクストリストに
当該コンテクストを追加する（同Ｓ57〜Ｓ59）。
【０１２４】(5.2)サービスタイプ登録処理部の動作
（図13(2) 、図18(2) 及び図20参照） メタデータ解釈部15からパラメータを受け取ったサービ
スタイプ登録処理部123は、先ずデフォルトコンテクス
トを起点として、サービスタイプを登録すべきサービス
タイプコンテクストをサービスタイプリポジトリから検
索する（ステップＳ61〜63）。
（図13(2) 、図18(2) 及び図20参照） メタデータ解釈部15からパラメータを受け取ったサービ
スタイプ登録処理部123は、先ずデフォルトコンテクス
トを起点として、サービスタイプを登録すべきサービス
タイプコンテクストをサービスタイプリポジトリから検
索する（ステップＳ61〜63）。
【０１２５】サービスタイプコンテクスト指定がない場
合はデフォルトコンテクスト指定として扱う。指定され
たサービスタイプコンテクストが見つからない場合はエ
ラーとする。登録先のサービスタイプコンテクスト獲得
後は、当該サービスタイプコンテクスト中に新規サービ
スタイプ名と既存サービスタイプ名との重複を検査し、
重複する場合はエラーとする（同Ｓ64, Ｓ65）。
合はデフォルトコンテクスト指定として扱う。指定され
たサービスタイプコンテクストが見つからない場合はエ
ラーとする。登録先のサービスタイプコンテクスト獲得
後は、当該サービスタイプコンテクスト中に新規サービ
スタイプ名と既存サービスタイプ名との重複を検査し、
重複する場合はエラーとする（同Ｓ64, Ｓ65）。
【０１２６】次にスーパタイプを当該コンテクスト中で
検索し、存在しない場合もエラーとする（同Ｓ66）。検
査終了後は既存のサービスタイプ登録と同様の処理で新
規サービスタイプがサービスタイプリポジトリ13の該当
するサービスタイプコンテクストに格納される（同Ｓ6
7）。
検索し、存在しない場合もエラーとする（同Ｓ66）。検
査終了後は既存のサービスタイプ登録と同様の処理で新
規サービスタイプがサービスタイプリポジトリ13の該当
するサービスタイプコンテクストに格納される（同Ｓ6
7）。
【０１２７】(5.3)サービスエクスポート処理部の動作
（図13(3) 、図18(3) 及び図21参照） メタデータ解釈部15からパラメータを受け取ったサービ
スエクスポート処理部124は、先ずデフォルトコンテク
ストを起点として指定サービスタイプのサービスタイプ
コンテクストを検索する（ステップＳ71〜73）。
（図13(3) 、図18(3) 及び図21参照） メタデータ解釈部15からパラメータを受け取ったサービ
スエクスポート処理部124は、先ずデフォルトコンテク
ストを起点として指定サービスタイプのサービスタイプ
コンテクストを検索する（ステップＳ71〜73）。
【０１２８】サービスタイプコンテクスト指定がない場
合はデフォルトコンテクスト指定として扱う。指定され
たサービスタイプコンテクストが見つからない場合はエ
ラーとする。サービスタイプコンテクスト検索終了後
は、当該サービスタイプコンテクスト中でサービスタイ
プを検索する（同Ｓ74, Ｓ75）。指定されたサービスタ
イプが存在しない場合はエラーとする。検索終了後は既
存のサービスエクスポートと同様に処理を行う（同Ｓ7
6）。
合はデフォルトコンテクスト指定として扱う。指定され
たサービスタイプコンテクストが見つからない場合はエ
ラーとする。サービスタイプコンテクスト検索終了後
は、当該サービスタイプコンテクスト中でサービスタイ
プを検索する（同Ｓ74, Ｓ75）。指定されたサービスタ
イプが存在しない場合はエラーとする。検索終了後は既
存のサービスエクスポートと同様に処理を行う（同Ｓ7
6）。
【０１２９】すなわち、エクスポートされたサービスの
プロパティの型がサービスタイプに定義されているプロ
パティの型に適合しており、かつサービスタイプ定義で
必須とされたプロパティの値が全て与えられていれば、
エクスポートの正当性が確認され、サービスはサービス
オファリポジトリの適切なエントリに登録される。
プロパティの型がサービスタイプに定義されているプロ
パティの型に適合しており、かつサービスタイプ定義で
必須とされたプロパティの値が全て与えられていれば、
エクスポートの正当性が確認され、サービスはサービス
オファリポジトリの適切なエントリに登録される。
【０１３０】(5.4)サービスインポート処理部の動作
（図13(4) 、図18(4) 及び図22参照） メタデータ解釈部15からパラメータを受け取ったサービ
スインポート処理部125は、先ずデフォルトコンテクス
トを起点として指定サービスタイプのサービスタイプコ
ンテクストを検索する（ステップＳ81〜83）。サービス
タイプコンテクスト指定がない場合はデフォルトコンテ
クスト指定として扱う。指定されたサービスタイプコン
テクストが見つからなかった場合はエラーとする。
（図13(4) 、図18(4) 及び図22参照） メタデータ解釈部15からパラメータを受け取ったサービ
スインポート処理部125は、先ずデフォルトコンテクス
トを起点として指定サービスタイプのサービスタイプコ
ンテクストを検索する（ステップＳ81〜83）。サービス
タイプコンテクスト指定がない場合はデフォルトコンテ
クスト指定として扱う。指定されたサービスタイプコン
テクストが見つからなかった場合はエラーとする。
【０１３１】サービスタイプコンテクスト検索終了後
は、そのコンテクストを起点としてこれに内包されるサ
ービスタイプコンテクストを走査する（同Ｓ84, Ｓ8
5）。当該コンテクストの内包するサービスタイプコン
テクストを再帰的に調べ、そのコンテクスト中のサービ
スタイプの内、インポート要求されたサービスタイプに
合致するものを調べて、適合するものは検索結果を収め
るサービスリストに追加する。
は、そのコンテクストを起点としてこれに内包されるサ
ービスタイプコンテクストを走査する（同Ｓ84, Ｓ8
5）。当該コンテクストの内包するサービスタイプコン
テクストを再帰的に調べ、そのコンテクスト中のサービ
スタイプの内、インポート要求されたサービスタイプに
合致するものを調べて、適合するものは検索結果を収め
るサービスリストに追加する。
【０１３２】全サービスタイプを走査した後、サービス
リストを通常のインポート応答データ生成処理にて処理
する（同Ｓ86）。なお、上記のサービスタイプコンテク
スト検索（Ｓ52, Ｓ63, Ｓ73, Ｓ83）、サービスタイプ
検索（Ｓ65, Ｓ66, Ｓ75）、及びコンテクスト走査（Ｓ
85）は、それぞれ図23, 図24, 及び図25に示す手順に従
って実行される。
リストを通常のインポート応答データ生成処理にて処理
する（同Ｓ86）。なお、上記のサービスタイプコンテク
スト検索（Ｓ52, Ｓ63, Ｓ73, Ｓ83）、サービスタイプ
検索（Ｓ65, Ｓ66, Ｓ75）、及びコンテクスト走査（Ｓ
85）は、それぞれ図23, 図24, 及び図25に示す手順に従
って実行される。
【０１３３】また、コンテクスト走査中のサービス検索
（Ｓ113）は図26に示すフローによって実行され、さら
にこのサービス検索中のサービスタイプ走査は図27に示
すフローによって実行される。 (６)認証処理 上記のようにオペレーションの内容をまとめて一つのメ
タデータとして記述した場合は、トレーダのクライアン
ト自身に関する記述をオペレーション内に含めることで
トレーダによるクライアントの認証を行うことができ
る。
（Ｓ113）は図26に示すフローによって実行され、さら
にこのサービス検索中のサービスタイプ走査は図27に示
すフローによって実行される。 (６)認証処理 上記のようにオペレーションの内容をまとめて一つのメ
タデータとして記述した場合は、トレーダのクライアン
ト自身に関する記述をオペレーション内に含めることで
トレーダによるクライアントの認証を行うことができ
る。
【０１３４】(6.1)全体の処理の流れ（図28参照） 上述した如く、クライアントの認証を行う場合は、クラ
イアントからの要求に、その要求を行う権限があること
を示す認証情報と、トレーダ１内に新たに生成される情
報（サービスタイプコンテクスト、サービスタイプ等)
にアクセスする（サブタイプの追加、削除等) 為に必要
な権限を示す権限情報を含める。
イアントからの要求に、その要求を行う権限があること
を示す認証情報と、トレーダ１内に新たに生成される情
報（サービスタイプコンテクスト、サービスタイプ等)
にアクセスする（サブタイプの追加、削除等) 為に必要
な権限を示す権限情報を含める。
【０１３５】認証情報及び権限情報を含む要求を受け取
ったトレーダは、メタデータ解釈部で当該情報を抽出し
て各処理部に処理を渡す。各処理部は処理対象（サービ
スタイプコンテクスト、サービスタイプ等) に権限が設
定されている場合には認証情報の存在を調べ、存在しな
い場合はエラーとする。
ったトレーダは、メタデータ解釈部で当該情報を抽出し
て各処理部に処理を渡す。各処理部は処理対象（サービ
スタイプコンテクスト、サービスタイプ等) に権限が設
定されている場合には認証情報の存在を調べ、存在しな
い場合はエラーとする。
【０１３６】認証情報が存在する場合は処理対象の権限
情報と照合し署名を検査する。適切な署名であった場合
は処理を続行するが、そうでなければエラーとする。認
証は以下の手順で行う。 1)クライアントの処理要求中から暗号化方式情報が示す
暗号化方式を用いてオペレーションを記述した文字列を
暗号化し（ステップＳ141）、暗号文を生成する。この
場合、リポジトリ13中の権限情報で暗号化を行う。この
時の権限情報はデフォルトコンテクスト（図14の1311）
に関する権限情報のみ、予めリポジトリ13中に用意され
ている。
情報と照合し署名を検査する。適切な署名であった場合
は処理を続行するが、そうでなければエラーとする。認
証は以下の手順で行う。 1)クライアントの処理要求中から暗号化方式情報が示す
暗号化方式を用いてオペレーションを記述した文字列を
暗号化し（ステップＳ141）、暗号文を生成する。この
場合、リポジトリ13中の権限情報で暗号化を行う。この
時の権限情報はデフォルトコンテクスト（図14の1311）
に関する権限情報のみ、予めリポジトリ13中に用意され
ている。
【０１３７】2)処理要求中のハッシュ方式情報の示すハ
ッシュ方式を用いて暗号文をハッシュし（同Ｓ142）、
クライアントからの認証情報と比較する（同Ｓ143）。
これは、権限情報と認証情報とが特定の関係に設定され
ているためである。 3)前項の結果、両者が等しい場合は適切なクライアント
からの要求と見なし、通常のオペレーション処理を行う
（同Ｓ144）。すなわち、新たに登録処理やエクスポー
ト処理の要求に係る情報を、クライアントから一緒に送
られてきた権限情報とともにリポジトリ13に格納する。
等しくない場合はオペレーションを拒否する（同Ｓ14
5）。
ッシュ方式を用いて暗号文をハッシュし（同Ｓ142）、
クライアントからの認証情報と比較する（同Ｓ143）。
これは、権限情報と認証情報とが特定の関係に設定され
ているためである。 3)前項の結果、両者が等しい場合は適切なクライアント
からの要求と見なし、通常のオペレーション処理を行う
（同Ｓ144）。すなわち、新たに登録処理やエクスポー
ト処理の要求に係る情報を、クライアントから一緒に送
られてきた権限情報とともにリポジトリ13に格納する。
等しくない場合はオペレーションを拒否する（同Ｓ14
5）。
【０１３８】すなわち、処理の結果、サービスタイプコ
ンテクスト、サービスタイプ等を生成する場合、あるい
は情報に変更を加える場合は、処理対象に設定する権限
情報の存在を調べる。権限情報が存在する場合は、この
情報を処理対象であるサービスタイプコンテクスト、サ
ービスタイプ等の属性として設定する。
ンテクスト、サービスタイプ等を生成する場合、あるい
は情報に変更を加える場合は、処理対象に設定する権限
情報の存在を調べる。権限情報が存在する場合は、この
情報を処理対象であるサービスタイプコンテクスト、サ
ービスタイプ等の属性として設定する。
【０１３９】(6.2)認証を伴うサービスタイプコンテク
スト登録要求処理（図29(1)参照） 1)インタフェース定義 認証を行う場合は、サービスタイプコンテクスト登録要
求クライアント２の情報として、クライアントの署名、
署名の暗号化アルゴリズム情報、署名のハッシュアルゴ
リズム情報などを渡す。
スト登録要求処理（図29(1)参照） 1)インタフェース定義 認証を行う場合は、サービスタイプコンテクスト登録要
求クライアント２の情報として、クライアントの署名、
署名の暗号化アルゴリズム情報、署名のハッシュアルゴ
リズム情報などを渡す。
【０１４０】これらの情報を表す、例えば論述「クライ
アント(someone) はサービスタイプコンテクスト登録に
署名"sign1" を附与する。クライアント情報の所在( 公
開鍵の在処) は"xxxxxx"であり、sign1 は"RSAcrypto"
で暗号化され、"MD5" でハッシュされている」という記
述は、メタデータで次のように表記できる。
アント(someone) はサービスタイプコンテクスト登録に
署名"sign1" を附与する。クライアント情報の所在( 公
開鍵の在処) は"xxxxxx"であり、sign1 は"RSAcrypto"
で暗号化され、"MD5" でハッシュされている」という記
述は、メタデータで次のように表記できる。
【０１４１】 [someone] --- traderns:signs ---> [sign1] +-- traderns:identified ---> [xxxxxxxxxxxx] [sign1] --- traderns:signedWith ---> "RSAcrypto" +-- traderns:hashedWith ---> "MD5" 更に、このサービスタイプコンテクスト下にサービスタ
イプコンテクスト、サービスタイプを登録可能な者を制
限する権限情報を附与する場合は、これらの情報もメタ
データで記述する。
イプコンテクスト、サービスタイプを登録可能な者を制
限する権限情報を附与する場合は、これらの情報もメタ
データで記述する。
【０１４２】例えば、論述「サービスタイプコンテクス
トY の下にサービスタイプコンテクストを登録する権限
( オーソリティ) は"xx"である」を示すメタデータ記述
は以下の通りである。 [contextY] --- traderns:contextAuthority ---> "xx" また論述「サービスタイプコンテクストY のサービスタ
イプを登録する権限(オーソリティ) は"yy"である」の
メタデータ記述は以下の通りである。
トY の下にサービスタイプコンテクストを登録する権限
( オーソリティ) は"xx"である」を示すメタデータ記述
は以下の通りである。 [contextY] --- traderns:contextAuthority ---> "xx" また論述「サービスタイプコンテクストY のサービスタ
イプを登録する権限(オーソリティ) は"yy"である」の
メタデータ記述は以下の通りである。
【０１４３】 [contextY] --- traderns:serviceTypeAuthority ---> "yy" 2)動作 認証を伴う場合の、サービスタイプコンテクスト登録要
求クライアント２とトレーダ (1)の動作を図29(1)に示
す。サービスタイプコンテクスト登録要求処理部21は、
メタデータ生成部25を呼んで前述した認証情報を含む全
パラメータをまとめたメタデータ記述を作成し、クライ
アントインタフェース22を通じてトレーダの共通インタ
フェースを呼び出す。
求クライアント２とトレーダ (1)の動作を図29(1)に示
す。サービスタイプコンテクスト登録要求処理部21は、
メタデータ生成部25を呼んで前述した認証情報を含む全
パラメータをまとめたメタデータ記述を作成し、クライ
アントインタフェース22を通じてトレーダの共通インタ
フェースを呼び出す。
【０１４４】トレーダ１の共通インタフェース11はメタ
データ記述をメタデータ解釈部15に渡して解釈し、処理
要求内容を調べる。処理要求がサービスタイプコンテク
スト登録要求であった場合にはサービスタイプコンテク
スト登録処理部122に処理を移す。
データ記述をメタデータ解釈部15に渡して解釈し、処理
要求内容を調べる。処理要求がサービスタイプコンテク
スト登録要求であった場合にはサービスタイプコンテク
スト登録処理部122に処理を移す。
【０１４５】コンテクスト登録処理部122はサービスタ
イプリポジトリ13から上位サービスタイプコンテクスト
の持つ権限情報を取り出し、要求中の認証情報と共に認
証処理部18にて認証処理を行う。認証成功後は認証を行
わない場合と同様に処理を行い、処理終了後、新たに生
成されたサービスタイプコンテクストに権限情報を設定
する。この後、処理結果をメタデータ生成部16でメタデ
ータ記述に変換後、クライアント２に応答する。
イプリポジトリ13から上位サービスタイプコンテクスト
の持つ権限情報を取り出し、要求中の認証情報と共に認
証処理部18にて認証処理を行う。認証成功後は認証を行
わない場合と同様に処理を行い、処理終了後、新たに生
成されたサービスタイプコンテクストに権限情報を設定
する。この後、処理結果をメタデータ生成部16でメタデ
ータ記述に変換後、クライアント２に応答する。
【０１４６】(6.3)認証を伴うサービスタイプ登録要求
処理（図29(2)参照） 1)インタフェース定義 認証を行う場合は、サービスタイプ登録要求クライアン
トの情報として、クライアントの署名、署名の暗号化ア
ルゴリズム情報、署名のハッシュアルゴリズム情報など
を渡す。これらの情報を表す論述は上述したものと同じ
になる。
処理（図29(2)参照） 1)インタフェース定義 認証を行う場合は、サービスタイプ登録要求クライアン
トの情報として、クライアントの署名、署名の暗号化ア
ルゴリズム情報、署名のハッシュアルゴリズム情報など
を渡す。これらの情報を表す論述は上述したものと同じ
になる。
【０１４７】更に、このサービスタイプにサブタイプを
登録可能な者を制限する権限情報を附与する場合は、こ
れらの情報もメタデータで記述する。例えば、論述「サ
ービスタイプAのサブタイプを登録する権限は"xx"であ
る」のメタデータ記述は以下のようになる。
登録可能な者を制限する権限情報を附与する場合は、こ
れらの情報もメタデータで記述する。例えば、論述「サ
ービスタイプAのサブタイプを登録する権限は"xx"であ
る」のメタデータ記述は以下のようになる。
【０１４８】 [serviceTypeA] --- traderns:subTypeAuthority ---> "xx" また論述「サービスタイプA としてサービスをエクスポ
ートする権限は"yy"である」のメタデータ記述は以下の
ようになる。 [serviceTypeA] --- traderns:exportAuthority ---> "yy" 2)動作 認証を伴う場合の、サービスタイプ登録要求クライアン
ト３とトレーダ１の動作を図29(2)に示す。サービスタ
イプ登録要求処理部31は、メタデータ生成部25を呼んで
前述した認証情報を含む全パラメータをまとめたメタデ
ータ記述を作成し、クライアントインタフェース22を通
じてトレーダの共通インタフェースを呼び出す。
ートする権限は"yy"である」のメタデータ記述は以下の
ようになる。 [serviceTypeA] --- traderns:exportAuthority ---> "yy" 2)動作 認証を伴う場合の、サービスタイプ登録要求クライアン
ト３とトレーダ１の動作を図29(2)に示す。サービスタ
イプ登録要求処理部31は、メタデータ生成部25を呼んで
前述した認証情報を含む全パラメータをまとめたメタデ
ータ記述を作成し、クライアントインタフェース22を通
じてトレーダの共通インタフェースを呼び出す。
【０１４９】トレーダ１の共通インタフェース11はメタ
データ記述をメタデータ解釈部15に渡して解釈し、処理
要求内容を調べる。処理要求がサービスタイプ登録要求
であった場合にはサービスタイプ登録処理部123に処理
を移す。サービスタイプ登録処理部123はサービスタイ
プリポジトリ13からサービスタイプコンテクストの権限
情報とスーパタイプの権限情報を取り出し、要求中の認
証情報と共に認証処理部18にて認証処理を行う。
データ記述をメタデータ解釈部15に渡して解釈し、処理
要求内容を調べる。処理要求がサービスタイプ登録要求
であった場合にはサービスタイプ登録処理部123に処理
を移す。サービスタイプ登録処理部123はサービスタイ
プリポジトリ13からサービスタイプコンテクストの権限
情報とスーパタイプの権限情報を取り出し、要求中の認
証情報と共に認証処理部18にて認証処理を行う。
【０１５０】認証成功後は認証を行わない場合と同様に
処理を行い、処理終了後、新たに生成されたサービスタ
イプに権限情報を設定する。この後、処理結果をメタデ
ータ生成部16でメタデータ記述に変換後、クライアント
３に応答する。 (6.4)認証を伴うサービスエクスポート要求処理（図29
(3)参照） 1)インタフェース定義 認証を行う場合は、エクスポータの情報として、エクス
ポータの署名、署名の暗号化アルゴリズム情報、署名の
ハッシュアルゴリズム情報などを渡す。これらの情報を
表す論述は上述したものと同じになる。
処理を行い、処理終了後、新たに生成されたサービスタ
イプに権限情報を設定する。この後、処理結果をメタデ
ータ生成部16でメタデータ記述に変換後、クライアント
３に応答する。 (6.4)認証を伴うサービスエクスポート要求処理（図29
(3)参照） 1)インタフェース定義 認証を行う場合は、エクスポータの情報として、エクス
ポータの署名、署名の暗号化アルゴリズム情報、署名の
ハッシュアルゴリズム情報などを渡す。これらの情報を
表す論述は上述したものと同じになる。
【０１５１】更に、このサービスをインポート可能な者
を制限する権限情報を附与する場合は、この情報もメタ
データで記述する。例えば、論述「サービスAをインポ
ートする権限は"yy"である」のメタデータ記述は以下の
ようになる。 [contextY] --- traderns:importAuthority ---> "xx" 2)動作 認証を伴う場合の、サービスエクスポータ４とトレーダ
１の動作を図29(3)に示す。サービスエクスポート処理
部41は、メタデータ生成部124を呼んで前項で述べた認
証情報を含む全パラメータをまとめたメタデータ記述を
作成し、クライアントインタフェース42を通じてトレー
ダの共通インタフェース11を呼び出す。
を制限する権限情報を附与する場合は、この情報もメタ
データで記述する。例えば、論述「サービスAをインポ
ートする権限は"yy"である」のメタデータ記述は以下の
ようになる。 [contextY] --- traderns:importAuthority ---> "xx" 2)動作 認証を伴う場合の、サービスエクスポータ４とトレーダ
１の動作を図29(3)に示す。サービスエクスポート処理
部41は、メタデータ生成部124を呼んで前項で述べた認
証情報を含む全パラメータをまとめたメタデータ記述を
作成し、クライアントインタフェース42を通じてトレー
ダの共通インタフェース11を呼び出す。
【０１５２】トレーダ１の共通インタフェース11は、メ
タデータ記述をメタデータ解釈部15に渡して解釈し、処
理要求内容を調べる。処理要求がサービスエクスポート
要求であった場合には、サービスエクスポート処理部12
4に処理を移す。エクスポート処理部124はサービスタイ
プリポジトリ13からサービスタイプ権限情報を取り出
し、要求中の認証情報と共に認証処理部にて認証処理を
行う。
タデータ記述をメタデータ解釈部15に渡して解釈し、処
理要求内容を調べる。処理要求がサービスエクスポート
要求であった場合には、サービスエクスポート処理部12
4に処理を移す。エクスポート処理部124はサービスタイ
プリポジトリ13からサービスタイプ権限情報を取り出
し、要求中の認証情報と共に認証処理部にて認証処理を
行う。
【０１５３】認証成功後は認証を行わない場合と同様に
処理を行い、処理終了後、サービスオファリポジトリ14
中に新たに生成されたサービスに権限情報を設定する。
この後、処理結果をメタデータ生成部16でメタデータ記
述に変換後、サービスエクスポータ４に応答する。
処理を行い、処理終了後、サービスオファリポジトリ14
中に新たに生成されたサービスに権限情報を設定する。
この後、処理結果をメタデータ生成部16でメタデータ記
述に変換後、サービスエクスポータ４に応答する。
【０１５４】(6.5)認証を伴うサービスインポート要求
処理（図29(4),(5)参照） 1)インタフェース定義 インポート要求処理するのに認証を必要とするサービス
をインポータ５がインポートしようとした場合に、トレ
ーダ１は認証に必要な誰何情報と、インポート要求に対
してトレーダが対応付けたインポート要求IDを返す。両
者はメタデータにより以下のように表される。
処理（図29(4),(5)参照） 1)インタフェース定義 インポート要求処理するのに認証を必要とするサービス
をインポータ５がインポートしようとした場合に、トレ
ーダ１は認証に必要な誰何情報と、インポート要求に対
してトレーダが対応付けたインポート要求IDを返す。両
者はメタデータにより以下のように表される。
【０１５５】 [op1] --- instanceOf --->[ServiceImportOperation] +-- operationId --->"00000000000" +-- importKey --->"11111111111" これを文字列形式で表すと、以下のようになる。
【０１５６】 <rdf:RDF> <rdf:Description> <traderns:instanceOf ServiceImportOperation/> <traderns:operationId "0000000000"/> <traderns:importKey "1111111111"/> </rdf:RDF> これに対しインポータは誰何情報に署名する。署名はメ
タデータ表記により以下のように表される。
タデータ表記により以下のように表される。
【０１５７】 [op1] --- operationId --->"00000000000" +-- signedWith --->sign1 [sign1] --- is --->"zzzzzzzz..........zzzzzzz" --- isEncryptedWith ---> "RSAcrypto" --- isHashedWith ---> "MD5" これを文字列形式に変換すると、以下のようになる。
【０１５８】 <rdf:RDF> <rdf:Description about="op1" traderns:operationId="0000000"> <rdf:Description about="op1" traderns:signedWith="sign1"> <rdf:Description about="sign1" traderns:is="zzzz......zzzz"/> <rdf:Description about="sign1" traderns:isEncryptedWith ="RSAcrypto"/> <rdf:Description about="sign1" traderns:isHashedWith="MD5"/> </rdf:RDF> 2)動作 認証処理を行う場合の、サービスインポータ５とトレー
ダ１の動作を図29(4),(5)に示す。インポータ５の認証
は、トレーダ１とインポータ５との間の誰何−応答手順
に従って行われる（図29(5)及び図30参照)。
ダ１の動作を図29(4),(5)に示す。インポータ５の認証
は、トレーダ１とインポータ５との間の誰何−応答手順
に従って行われる（図29(5)及び図30参照)。
【０１５９】サービスインポート要求処理部51は、先ず
メタデータ生成部55を呼んで認証情報も何も含まないイ
ンポート要求のメタデータ記述を生成し、クライアント
インタフェース52を介してトレーダ１の共通インタフェ
ース11を呼び出す。トレーダ１の共通インタフェース11
はメタデータ記述をメタデータ解釈部15に渡して解釈
し、処理要求内容を調べる（ステップＳ151, Ｓ152）。
処理要求がサービスインポート要求であった場合はサー
ビスインポート処理部125に処理を移す。インポート処
理部125はサービスオファリポジトリ14からサービスの
権限情報を取り出し、認証が必要な場合には認証処理部
18に対して誰何情報の生成を要求する（同Ｓ153）。
メタデータ生成部55を呼んで認証情報も何も含まないイ
ンポート要求のメタデータ記述を生成し、クライアント
インタフェース52を介してトレーダ１の共通インタフェ
ース11を呼び出す。トレーダ１の共通インタフェース11
はメタデータ記述をメタデータ解釈部15に渡して解釈
し、処理要求内容を調べる（ステップＳ151, Ｓ152）。
処理要求がサービスインポート要求であった場合はサー
ビスインポート処理部125に処理を移す。インポート処
理部125はサービスオファリポジトリ14からサービスの
権限情報を取り出し、認証が必要な場合には認証処理部
18に対して誰何情報の生成を要求する（同Ｓ153）。
【０１６０】インポート処理部125は誰何情報と、イン
ポート要求毎に一意に割り当てるインポート要求IDをメ
タデータ生成部16でメタデータ記述に変換し、クライア
ントに返す（同Ｓ154）。メタデータ記述された誰何情
報を受け取ったインポータ５は、メタデータ解釈部56で
誰何情報を解読する。インポート要求処理部51では誰何
情報に対して署名し、再度トレーダ１に送信する。
ポート要求毎に一意に割り当てるインポート要求IDをメ
タデータ生成部16でメタデータ記述に変換し、クライア
ントに返す（同Ｓ154）。メタデータ記述された誰何情
報を受け取ったインポータ５は、メタデータ解釈部56で
誰何情報を解読する。インポート要求処理部51では誰何
情報に対して署名し、再度トレーダ１に送信する。
【０１６１】トレーダ１では誰何情報への署名を照合し
（同Ｓ155）、権限が証明された場合には通常通りイン
ポート処理を行い（同Ｓ156）、インポート結果をメタ
データ形式に変換し、クライアント５に返す（同Ｓ15
7）。
（同Ｓ155）、権限が証明された場合には通常通りイン
ポート処理を行い（同Ｓ156）、インポート結果をメタ
データ形式に変換し、クライアント５に返す（同Ｓ15
7）。
【０１６２】
【発明の効果】本発明に係るトレーディング装置によれ
ば、以下の効果が得られる。 [１]サービスタイプ名の衝突の回避 一つのトレーダ中ではサービスタイプ名は一意でなくて
はならないという制限が回避される。サービスタイプ名
の回避にコンテクスト名を用いる事で、トレーダのクラ
イアントはサービスを用いる対象、サービスの適用され
る領域を意識することになり、サービスタイプを単なる
文字列として用いることによる名前の混乱が回避され
る。
ば、以下の効果が得られる。 [１]サービスタイプ名の衝突の回避 一つのトレーダ中ではサービスタイプ名は一意でなくて
はならないという制限が回避される。サービスタイプ名
の回避にコンテクスト名を用いる事で、トレーダのクラ
イアントはサービスを用いる対象、サービスの適用され
る領域を意識することになり、サービスタイプを単なる
文字列として用いることによる名前の混乱が回避され
る。
【０１６３】更にインポート時に、リンク動作の結果と
して複数のトレーダが保持するサービスがインポータに
提供される場合、コンテクスト名によりサービスタイプ
が分類され、インポータが適切なコンテクスト名を指定
することにより、インポータは自身の望むサービスタイ
プのサービスのみを得ることができる。更にこのコンテ
クストの記述をメタデータ記述で行うことにより、サー
ビスタイプの記述の自由度が増すことになる。
して複数のトレーダが保持するサービスがインポータに
提供される場合、コンテクスト名によりサービスタイプ
が分類され、インポータが適切なコンテクスト名を指定
することにより、インポータは自身の望むサービスタイ
プのサービスのみを得ることができる。更にこのコンテ
クストの記述をメタデータ記述で行うことにより、サー
ビスタイプの記述の自由度が増すことになる。
【０１６４】[２]トレーダによるクライアントの認証 トレーダは様々なクライアントからサービスタイプ登録
の要求や、エクスポート処理等の要求を受け、その度に
サービスタイプリポジトリやサービスオファリポジトリ
の情報を更新する。トレーダが認証手順を持つことで、
悪意あるクライアントからの処理要求を拒否することが
でき、結果として、サービスタイプリポジトリ及びサー
ビスオファリポジトリの情報を健全に保つことが可能に
なる。
の要求や、エクスポート処理等の要求を受け、その度に
サービスタイプリポジトリやサービスオファリポジトリ
の情報を更新する。トレーダが認証手順を持つことで、
悪意あるクライアントからの処理要求を拒否することが
でき、結果として、サービスタイプリポジトリ及びサー
ビスオファリポジトリの情報を健全に保つことが可能に
なる。
【０１６５】この認証手順をメタデータ記述で行うこと
により、パラメータを追加することなく認証のための暗
号化アルゴリズムである、例えばハッシュ法を任意に切
り替えて使うことができ、更には複数の暗号化アルゴリ
ズムを併用するなどの拡張性を持たせることが可能にな
る。
により、パラメータを追加することなく認証のための暗
号化アルゴリズムである、例えばハッシュ法を任意に切
り替えて使うことができ、更には複数の暗号化アルゴリ
ズムを併用するなどの拡張性を持たせることが可能にな
る。
【０１６６】[３]インポート処理の権限 インポータに対してトレーダが誰何情報を返し、誰何情
報に対して正しく認証情報を返したインポータのみにイ
ンポート要求処理を許可することで、エクスポータがサ
ービスを一部のオブジェクトに対してのみ公開すること
が可能となり、サーバオブジェクトを不正なクライアン
トが利用することを防ぐことが可能になる。
報に対して正しく認証情報を返したインポータのみにイ
ンポート要求処理を許可することで、エクスポータがサ
ービスを一部のオブジェクトに対してのみ公開すること
が可能となり、サーバオブジェクトを不正なクライアン
トが利用することを防ぐことが可能になる。
【０１６７】この認証手順をメタデータ記述で行うこと
で、前項と同様に拡張性が確保できるようになる。
で、前項と同様に拡張性が確保できるようになる。
【図１】本発明に係るトレーディング装置の構成原理図
である。
である。
【図２】本発明に係るトレーディング装置の動作原理図
（１）である。
（１）である。
【図３】本発明に係るトレーディング装置の動作原理図
（２）である。
（２）である。
【図４】本発明に係るトレーディング装置におけるトレ
ーディング処理時の動作フローチャート図である。
ーディング処理時の動作フローチャート図である。
【図５】本発明に係るトレーディング装置における認証
処理時の動作説明図である。
処理時の動作説明図である。
【図６】本発明に係るトレーディング装置における認証
処理時の動作フローチャート図である。
処理時の動作フローチャート図である。
【図７】本発明に係るトレーディング装置における誰何
−応答処理時の動作説明図である。
−応答処理時の動作説明図である。
【図８】本発明に係るトレーディング装置における誰何
−応答処理時の動作フローチャート図である。
−応答処理時の動作フローチャート図である。
【図９】本発明に係るトレーディング装置の手順実施例
を示したシーケンス図である。
を示したシーケンス図である。
【図１０】本発明に係るトレーディング装置におけるサ
ービスタイプ名のメタデータ生成フローチャート図であ
る。
ービスタイプ名のメタデータ生成フローチャート図であ
る。
【図１１】本発明に係るトレーディング装置におけるス
ーパタイプ名のメタデータ生成フローチャート図であ
る。
ーパタイプ名のメタデータ生成フローチャート図であ
る。
【図１２】本発明に係るトレーディング装置に用いるメ
タデータ辞書の構造例を示したブロック図である。
タデータ辞書の構造例を示したブロック図である。
【図１３】本発明に係るトレーディング装置におけるメ
タデータの解釈フローチャート図である。
タデータの解釈フローチャート図である。
【図１４】本発明に係るトレーディング装置に用いるリ
ポジトリのデータ構造例を示した図である。
ポジトリのデータ構造例を示した図である。
【図１５】本発明に係るトレーディング装置の動作実施
例（１）を示したブロック図である。
例（１）を示したブロック図である。
【図１６】本発明に係るトレーディング装置におけるメ
タデータの説明図（１）である。
タデータの説明図（１）である。
【図１７】本発明に係るトレーディング装置におけるメ
タデータの説明図（２）である。
タデータの説明図（２）である。
【図１８】本発明に係るトレーディング装置の動作実施
例（２）を示したブロック図である。
例（２）を示したブロック図である。
【図１９】本発明に係るトレーディング装置におけるサ
ービスタイプコンテクストの登録処理フローチャート図
である。
ービスタイプコンテクストの登録処理フローチャート図
である。
【図２０】本発明に係るトレーディング装置におけるサ
ービスタイプの登録処理フローチャート図である。
ービスタイプの登録処理フローチャート図である。
【図２１】本発明に係るトレーディング装置におけるエ
クスポート処理フローチャート図である。
クスポート処理フローチャート図である。
【図２２】本発明に係るトレーディング装置におけるイ
ンポート処理フローチャート図である。
ンポート処理フローチャート図である。
【図２３】本発明に係るトレーディング装置におけるコ
ンテクスト検索フローチャート図である。
ンテクスト検索フローチャート図である。
【図２４】本発明に係るトレーディング装置におけるサ
ービスタイプ検索フローチャート図である。
ービスタイプ検索フローチャート図である。
【図２５】本発明に係るトレーディング装置におけるコ
ンテクスト走査フローチャート図である。
ンテクスト走査フローチャート図である。
【図２６】本発明に係るトレーディング装置におけるサ
ービスタイプ中のサービス検索フローチャート図であ
る。
ービスタイプ中のサービス検索フローチャート図であ
る。
【図２７】本発明に係るトレーディング装置におけるサ
ービスタイプ走査フローチャート図である。
ービスタイプ走査フローチャート図である。
【図２８】本発明に係るトレーディング装置における認
証処理フローチャート図である。
証処理フローチャート図である。
【図２９】本発明に係るトレーディング装置の動作実施
例（３）を示したブロック図である。
例（３）を示したブロック図である。
【図３０】本発明に係るトレーディング装置における誰
何−応答処理時の動作フローチャート図である。
何−応答処理時の動作フローチャート図である。
【図３１】従来例の手順実施例を示したシーケンス図で
ある。
ある。
【図３２】従来例の構成を示したブロック図である。
【図３３】従来例の動作説明図である。
【図３４】インポート処理時のサービスのスクリーニン
グ処理
グ処理
１ トレーダ ６ インタフェースリポジトリ ２〜５，７ クライアント 21, 31, 41, 51, 71 要求処理部 16，25, 35, 45, 55, 75 メタデータ生成部 15, 26, 36, 46, 56, 76 メタデータ解釈部 11，17, 22, 32, 42, 52, 72, 112, 113, 114, 115 イ
ンタフェース 12, 122, 123, 124, 125 処理部 13 サービスタイプリポジトリ 14 サービスオファリポジトリ 18 認証処理部 130 デフォルトコンテクスト 図中、同一符号は同一又は相当部分を示す。
ンタフェース 12, 122, 123, 124, 125 処理部 13 サービスタイプリポジトリ 14 サービスオファリポジトリ 18 認証処理部 130 デフォルトコンテクスト 図中、同一符号は同一又は相当部分を示す。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 瀬口 義之 福岡県福岡市早良区百道浜２丁目２番１号 富士通九州通信システム株式会社内 (72)発明者 井手 敏博 福岡県福岡市早良区百道浜２丁目２番１号 富士通九州通信システム株式会社内 Ｆターム(参考） 5B045 AA03 BB03 BB19 BB48 5B089 GA01 GA11 GA21 GB10 JA11 JA12 JB22 KA12 KA17 KC58 KH30 5B098 AA10 GC16
Claims (15)
- 【請求項１】CORBA方式で相互接続される複数のクライ
アント及びトレーダを有するトレーディング装置におい
て、 各クライアント及び該トレーダが、それぞれのオペレー
ションの文字列型のパラメータを、サービスタイプと該
サービスタイプの補助情報であるサービスタイプコンテ
クストとを含むメタデータで個々に記述するメタデータ
生成部及び該メタデータを解釈するメタデータ解釈部を
有することを特徴としたトレーディング装置。 - 【請求項２】CORBA方式で相互接続される複数のクライ
アント及びトレーダを有するトレーディング装置におい
て、 各クライアント及び該トレーダが、それぞれのオペレー
ションの文字列型のパラメータとインタフェース中のオ
ペレーション名を、サービスタイプと該サービスタイプ
の上位情報であるサービスタイプコンテクストとを含む
メタデータで一まとめにして記述するメタデータ生成部
及び該メタデータを全体解釈するメタデータ解釈部を有
することを特徴としたトレーディング装置。 - 【請求項３】請求項２において、 該サービスタイプコンテクストの該トレーダへの登録を
要求するクライアントが、該登録に必要な権限を有する
ことを示す認証情報と新規サービスタイプコンテクスト
の配下に新たにサービスタイプコンテクストを登録する
権限を示す権限情報とを該メタデータ生成部で該メタデ
ータに含め、該メタデータを該トレーダが該メタデータ
解釈部で全体解釈して該認証情報と該権限情報を抽出
し、以て該認証情報と該権限情報に基づき該トレーダの
認証処理部で該サービスタイプコンテクストの登録認証
処理を行うことを特徴としたトレーディング装置。 - 【請求項４】請求項２において、 該サービスタイプの該トレーダへの登録を要求するクラ
イアントが、該登録に必要な権限を有することを示す認
証情報と新規サービスタイプの配下に新たにサブタイプ
を登録する権限を示す権限情報とを該メタデータ生成部
で該メタデータに含め、該メタデータを該トレーダが該
メタデータ解釈部で解釈して該認証情報と該権限情報を
抽出し、以て該認証情報と該権限情報に基づき該トレー
ダの認証処理部で該サービスタイプの登録認証処理を行
うことを特徴としたトレーディング装置。 - 【請求項５】請求項２において、 該サービスタイプコンテクストの該トレーダへの登録を
要求するクライアントが、該登録に必要な権限を有する
ことを示す認証情報と新規サービスタイプコンテクスト
にサービスタイプを登録する権限を示す権限情報とを該
メタデータ生成部で該メタデータに含め、該メタデータ
を該トレーダが該メタデータ解釈部で解釈して該認証情
報と該権限情報を抽出し、以て該認証情報と該権限情報
に基づき該トレーダの認証処理部で該サービスタイプコ
ンテクストの登録認証処理を行うことを特徴としたトレ
ーディング装置。 - 【請求項６】請求項２において、 該サービスタイプの該トレーダへの登録を要求するクラ
イアントが、該登録に必要な権限を有することを示す認
証情報と新規サービスタイプとしてサービスをエクスポ
ート処理する権限を示す権限情報とを該メタデータ生成
部で該メタデータに変換し、該メタデータを該トレーダ
が該メタデータ解釈部で解釈して該認証情報と該権限情
報を抽出し、以て該認証情報と該権限情報に基づき該ト
レーダの認証処理部で該サービスタイプの登録認証処理
を行うことを特徴としたトレーディング装置。 - 【請求項７】請求項２において、 該トレーダに対してエクスポータとしてサービスエクス
ポート処理を行うクライアントが、該エクスポート処理
を行うサービスを別のクライアントがインポータとして
インポート処理するために必要な権限情報をメタデータ
で記述し、該トレーダに対して該インポータがサービス
インポート処理する時に、該トレーダが、該インポータ
を認証する為の誰何情報をメタデータで記述し、これに
対して該インポータが該誰何情報に対応した署名情報を
メタデータで記述し、以て該トレーダが該誰何情報と該
署名情報とを照合することを特徴としたトレーディング
装置。 - 【請求項８】請求項１において、 該トレーダが、該クライアントとのインタフェースに、
各要求処理に対する個々の処理インタフェースを用いる
ことを特徴としたトレーディング装置。 - 【請求項９】請求項２乃至７のいずれかにおいて、 該トレーダが、該クライアントとのインタフェースに、
各要求処理に対する共通化された処理インタフェースを
用いることを特徴としたトレーディング装置。 - 【請求項10】請求項１において、 該トレーダが、データベースとして、該サービスタイプ
コンテクスト及び該コンテクストに含まれるサービスタ
イプ情報を保持するサービスタイプリポジトリと、該サ
ービスタイプ情報中のサービス情報を保持するサービス
オファリポジトリとを内部に有することを特徴としたト
レーディング装置。 - 【請求項11】請求項２乃至６のいずれかにおいて、 該トレーダが、データベースとして、該サービスタイプ
コンテクスト及び該コンテクストに含まれるサービスタ
イプ情報を保持するサービスタイプリポジトリ、該サー
ビスタイプ情報中のサービス情報を保持するサービスオ
ファリポジトリとを内部に有し、該サービスタイプリポ
ジトリが予めデフォルトコンテクストに対する権限情報
を保持しており、該認証処理部が、該クライアントから
の該権限情報に基づいて該パラメータを暗号化して生成
した認証情報が該クライアントからの該認証情報と一致
したときのみ、該サービスタイプ情報及び該サービス情
報を、該権限情報とともにそれぞれ該サービスタイプリ
ポジトリ及び該サービスオファリポジトリに保持するこ
とを特徴としたトレーディング装置。 - 【請求項12】請求項６において、 該トレーダが、該サービスタイプの整合性の検査に必要
なサービスインタフェース定義を保持するデータベース
であるインタフェースリポジトリを外部に有することを
特徴としたトレーディング装置。 - 【請求項13】請求項７において、 該トレーダが、データベースとして、該サービスタイプ
コンテクスト及び該コンテクストに含まれるサービスタ
イプ情報を保持するサービスタイプリポジトリと、該サ
ービスタイプ情報中のサービス情報を保持するサービス
オファリポジトリとを内部に有し、該サービスタイプリ
ポジトリが予めデフォルトコンテクストに対する権限情
報を保持しており、該認証処理部が、該誰何情報に対し
て該クライアントから得た署名情報が該クライアントか
らの該権限情報に基づいて生成される署名情報と一致し
たときのみ、該インポート処理を許可することを特徴と
したトレーディング装置。 - 【請求項14】請求項１乃至13のいずれかにおいて、 該認証情報として、ハッシュ法による暗号化法を用いる
ことを特徴としたトレーディング装置。 - 【請求項15】請求項１乃至14のいずれかにおいて、 該補助情報が、包括情報であることを特徴としたトレー
ディング装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11034765A JP2000235493A (ja) | 1999-02-12 | 1999-02-12 | トレーディング装置 |
| US09/373,530 US6571222B1 (en) | 1999-02-12 | 1999-08-12 | Trading system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11034765A JP2000235493A (ja) | 1999-02-12 | 1999-02-12 | トレーディング装置 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2000235493A true JP2000235493A (ja) | 2000-08-29 |
Family
ID=12423413
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11034765A Pending JP2000235493A (ja) | 1999-02-12 | 1999-02-12 | トレーディング装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6571222B1 (ja) |
| JP (1) | JP2000235493A (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004030310A (ja) * | 2002-06-26 | 2004-01-29 | Nec Corp | オブジェクト検索装置、オブジェクト検索システム、オブジェクト検索方法及びオブジェクト検索プログラム |
Families Citing this family (32)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2001052178A1 (en) * | 2000-01-13 | 2001-07-19 | Digimarc Corporation | Authenticating metadata and embedding metadata in watermarks of media signals |
| AU2001291033A1 (en) * | 2000-09-16 | 2002-03-26 | I-Many, Inc. | Web-based transactional system |
| US7197160B2 (en) * | 2001-03-05 | 2007-03-27 | Digimarc Corporation | Geographic information systems using digital watermarks |
| WO2002082387A1 (en) * | 2001-04-04 | 2002-10-17 | Microcell I5 Inc. | Method and system for effecting an electronic transaction |
| US7058637B2 (en) * | 2001-05-15 | 2006-06-06 | Metatomix, Inc. | Methods and apparatus for enterprise application integration |
| US6925457B2 (en) * | 2001-07-27 | 2005-08-02 | Metatomix, Inc. | Methods and apparatus for querying a relational data store using schema-less queries |
| WO2005029365A2 (en) | 2003-07-07 | 2005-03-31 | Metatomix, Inc. | Surveillance, monitoring and real-time events platform |
| US20030208499A1 (en) * | 2002-05-03 | 2003-11-06 | David Bigwood | Methods and apparatus for visualizing relationships among triples of resource description framework (RDF) data sets |
| US7890517B2 (en) * | 2001-05-15 | 2011-02-15 | Metatomix, Inc. | Appliance for enterprise information integration and enterprise resource interoperability platform and methods |
| US6856992B2 (en) * | 2001-05-15 | 2005-02-15 | Metatomix, Inc. | Methods and apparatus for real-time business visibility using persistent schema-less data storage |
| GB2381339A (en) * | 2001-10-05 | 2003-04-30 | Inventec Corp | Method and system for controlling production and exportation |
| KR20050103205A (ko) * | 2003-01-24 | 2005-10-27 | 코코 커뮤니케이션즈 코포레이션 | 어플리케이션에 관련된 중앙 관리 없이 익명의 신뢰할 수없는 집단간 안전한 통신과 자원 공유 방법 및 장치 |
| US7665063B1 (en) | 2004-05-26 | 2010-02-16 | Pegasystems, Inc. | Integration of declarative rule-based processing with procedural programming |
| US8953908B2 (en) | 2004-06-22 | 2015-02-10 | Digimarc Corporation | Metadata management and generation using perceptual features |
| US20060002479A1 (en) * | 2004-06-22 | 2006-01-05 | Fernandes Felix C A | Decoder for H.264/AVC video |
| US8335704B2 (en) | 2005-01-28 | 2012-12-18 | Pegasystems Inc. | Methods and apparatus for work management and routing |
| US20060271384A1 (en) * | 2005-05-31 | 2006-11-30 | Microsoft Corporation | Reference data aggregate service population |
| US8924335B1 (en) | 2006-03-30 | 2014-12-30 | Pegasystems Inc. | Rule-based user interface conformance methods |
| US7644042B2 (en) * | 2006-06-30 | 2010-01-05 | Amazon Technologies, Inc. | Managing transaction accounts |
| US8250525B2 (en) | 2007-03-02 | 2012-08-21 | Pegasystems Inc. | Proactive performance management for multi-user enterprise software systems |
| CN101636740A (zh) * | 2007-03-19 | 2010-01-27 | 富士通株式会社 | 服务控制系统、服务控制方法以及服务控制程序 |
| US10176523B1 (en) * | 2007-03-30 | 2019-01-08 | Vestmark, Inc. | System and method for automated trade processing |
| US10481878B2 (en) * | 2008-10-09 | 2019-11-19 | Objectstore, Inc. | User interface apparatus and methods |
| US8843435B1 (en) | 2009-03-12 | 2014-09-23 | Pegasystems Inc. | Techniques for dynamic data processing |
| US8468492B1 (en) | 2009-03-30 | 2013-06-18 | Pegasystems, Inc. | System and method for creation and modification of software applications |
| US8880487B1 (en) | 2011-02-18 | 2014-11-04 | Pegasystems Inc. | Systems and methods for distributed rules processing |
| US9195936B1 (en) | 2011-12-30 | 2015-11-24 | Pegasystems Inc. | System and method for updating or modifying an application without manual coding |
| US10469396B2 (en) | 2014-10-10 | 2019-11-05 | Pegasystems, Inc. | Event processing with enhanced throughput |
| US10698599B2 (en) | 2016-06-03 | 2020-06-30 | Pegasystems, Inc. | Connecting graphical shapes using gestures |
| US10698647B2 (en) | 2016-07-11 | 2020-06-30 | Pegasystems Inc. | Selective sharing for collaborative application usage |
| US11048488B2 (en) | 2018-08-14 | 2021-06-29 | Pegasystems, Inc. | Software code optimizer and method |
| US11567945B1 (en) | 2020-08-27 | 2023-01-31 | Pegasystems Inc. | Customized digital content generation systems and methods |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5905974A (en) * | 1996-12-13 | 1999-05-18 | Cantor Fitzgerald Securities | Automated auction protocol processor |
| JP2907174B2 (ja) | 1997-02-04 | 1999-06-21 | 日本電気株式会社 | 監視制御システムのユーザインタフェースシステム |
| JPH10240663A (ja) | 1997-02-27 | 1998-09-11 | Nippon Telegr & Teleph Corp <Ntt> | サービス管理システム |
| US6338050B1 (en) * | 1998-11-16 | 2002-01-08 | Trade Access, Inc. | System and method for providing and updating user supplied context for a negotiations system |
-
1999
- 1999-02-12 JP JP11034765A patent/JP2000235493A/ja active Pending
- 1999-08-12 US US09/373,530 patent/US6571222B1/en not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004030310A (ja) * | 2002-06-26 | 2004-01-29 | Nec Corp | オブジェクト検索装置、オブジェクト検索システム、オブジェクト検索方法及びオブジェクト検索プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US6571222B1 (en) | 2003-05-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2000235493A (ja) | トレーディング装置 | |
| KR101954268B1 (ko) | 블록체인 기반의 문서 관리 방법 및 이를 이용한 문서 관리 서버 | |
| US6006018A (en) | Distributed file system translator with extended attribute support | |
| JP4625334B2 (ja) | 情報処理装置、情報処理方法、情報処理プログラム及び記録媒体、並びに資源管理装置 | |
| US8578487B2 (en) | System and method for internet security | |
| Thompson et al. | Certificate-based authorization policy in a PKI environment | |
| US5594921A (en) | Authentication of users with dynamically configurable protocol stack | |
| EP1680727B1 (en) | Distributed document version control | |
| US5815574A (en) | Provision of secure access to external resources from a distributed computing environment | |
| US20150095657A1 (en) | Processing Extensible Markup Language Security Messages Using Delta Parsing Technology | |
| US20030172127A1 (en) | Execution of process by references to directory service | |
| US20050210263A1 (en) | Electronic form routing and data capture system and method | |
| JPH09509772A (ja) | 分散型デジタルディレクトリにおけるオブジェクト変更を保護する方法および装置 | |
| JP2002533830A (ja) | クライアント−サーバネットワークにおいてクライアントノードの近隣プログラムを判定するための装置および方法 | |
| JP2001236014A (ja) | 複数の政策をマージする機構 | |
| US7131138B2 (en) | Information exchanging system, information communication terminal, information exchanging method, and computer product | |
| WO2009132529A1 (zh) | 一种网页表单数据验证的方法和装置 | |
| CN110199283A (zh) | 用于在网络功能虚拟化环境中认证平台信任的系统和方法 | |
| US20070100854A1 (en) | Method of providing a validatable data structure | |
| JP3137173B2 (ja) | 認証情報管理装置 | |
| US7363487B2 (en) | Method and system for dynamic client authentication in support of JAAS programming model | |
| JP2000172646A (ja) | アプリケーション機能指定装置及び記憶媒体 | |
| JP3951638B2 (ja) | 認証アプリケーションサービスシステム | |
| CN116881275A (zh) | 数据库查询方法、装置及存储介质 | |
| Kim et al. | Vulnerability detection mechanism based on open API for multi-user's convenience |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20020730 |