JP4536292B2 - ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 - Google Patents
ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 Download PDFInfo
- Publication number
- JP4536292B2 JP4536292B2 JP2001180191A JP2001180191A JP4536292B2 JP 4536292 B2 JP4536292 B2 JP 4536292B2 JP 2001180191 A JP2001180191 A JP 2001180191A JP 2001180191 A JP2001180191 A JP 2001180191A JP 4536292 B2 JP4536292 B2 JP 4536292B2
- Authority
- JP
- Japan
- Prior art keywords
- orb
- server
- profile object
- profile
- corba
- 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.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/46—Indexing scheme relating to G06F9/46
- G06F2209/462—Lookup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/10015—Access to distributed or replicated servers, e.g. using brokers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multi Processors (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、分散システム環境上に構築されるネットワークシステム等に係り、より詳しくは、異機種や異バージョン等の製品間にて効率的な相互接続を可能とするネットワークシステム等に関する。
【０００２】
【従来の技術】
近年、ネットワーク技術の急激な普及によって、これを基盤とした分散システムの浸透が進み、システムの分散化およびマルチベンダ化が加速してきている。例えば、情報システムを構築して、様々なデータを電子化して業務の効率化を実現している企業は一般的になりつつあるが、多くの場合、個別の業務に特化して独立したシステムを使用しており、部門間にまたがる全社的な効率化や他の企業との共同作業を進めようとする際に、様々な問題点が生じている。例えば、企業間でのデータ共用の問題、システム間の相互接続の問題、各企業におけるシステム変更への対応の問題等である。このような問題に対処するために、分散オブジェクト技術が注目されている。この分散オブジェクト技術では、機能単位であるオブジェクトを分散システム上で管理し実行させる仕組みが提供されている。
【０００３】
オブジェクト技術標準化団体の米ＯＭＧ(Object Management Group)では、異なる納入業者(ベンダー)間の分散オブジェクト製品間の相互接続をその大きな目的として、ＣＯＲＢＡ(Common Object Request Broker Architecture)を仕様として定めている。ＣＯＲＢＡは、クライアントがネットワークに存在するオブジェクト(分散オブジェクト)を呼び出すための基盤を提供しており、このＣＯＲＢＡには、分散オブジェクト環境にて、様々なマシン上のサーバ・オブジェクトとクライアント・アプリケーションとのやり取りを仲介するミドルウェアであるＯＲＢ(Object Request Broker)の共通仕様が規程されている。
【０００４】
ここで、ＣＯＲＢＡに関する関連公報として、特開２０００−２２４２６２号公報、特開平１０−１８７６３７号公報が存在する。この特開２０００−２２４２６２号公報には、管理対象である通信ネットワークを構成する各装置の様々な管理オブジェクトの形式や管理プロトコルに柔軟に対応してネットワーク管理をするために、同一ＯＲＢ上の複数オブジェクトを管理するオブジェクトを情報管理オブジェクト(ＩＭＯ)と名づけ、ＩＭＯによる複数ＣＯＲＢＡオブジェクト(アプリケーションオブジェクト)をシステム管理する技術について示されている。
【０００５】
また、ＣＯＲＢＡサービスとして規程されているＣＯＲＢＡネーミングサービスは、ＣＯＲＢＡアーキテクチャ上、複数独立して存在し得る。そのために、ある特定のＣＯＲＢＡオブジェクトにアクセスしたいクライアントは、どのネーミングサービスにアクセスしていいか解らない。特開平１０−１８７６３７号公報では、複数のネーミングサービスが存在する場合に、ネーミングサービスの各構成要素を分散させた上で、個々の構成要素を擬似的に、一つのネーミングサービスに見せることによって、より柔軟性の高いネーミングサービスを提供する技術について開示されている。
【０００６】
【発明が解決しようとする課題】
ここで、各ＣＯＲＢＡ製品を供給するベンダーは、ＣＯＲＢＡ仕様をそれぞれ解釈し、それに従って実装を行い、ＣＯＲＢＡ準拠製品と銘打って製品出荷を行っている。しかしながら、ＣＯＲＢＡ準拠製品間の接続テストを実際に行うと、ベンダー毎のＣＯＲＢＡ仕様に対する解釈の違いや、ＯＲＢであるＣＯＲＢＡ−ＩＩＯＰ(Internet Inter-ORB Protocol)通信用のランタイムモジュール実装の不備、或いは、ＯＲＢの独自実装等によって、必ずしも相互接続が成功しない場合がある。
【０００７】
また、一旦、接続が成功したとしても、製品のリリースアップや修正毎にプログラムが変更されることから、製品間の接続検証をやり直す必要がある。更に、サーバ側のＯＲＢに優れた機能がサポートされたとしても、クライアントから動的に認識する手段を従来のＣＯＲＢＡ−ＩＩＯＰ通信環境では備えておらず、システム全体の通信機能は必ずしも最適化が図られてはいなかった。
また更に、上述した特開２０００−２２４２６２号公報および特開平１０−１８７６３７号公報には、異機種或いは異バージョンのＯＲＢ間通信を容易にするための技術については開示されておらず、上記課題を解決できるものではない。
【０００８】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、異なる仕様製品のＯＲＢ間通信における相互接続に際して、信頼性の向上と通信効率の向上を図ることにある。
【０００９】
【課題を解決するための手段】
かかる目的のもと、本発明は、ＣＯＲＢＡ−ＩＩＯＰ通信を実行するＯＲＢのサポート機能を提示できるプロファイル(Profile)オブジェクトをＣＯＲＢＡのオブジェクトとして定義、実装および公開することにより、他ベンダーがそのプロファイルオブジェクトを通じて接続しようとするＯＲＢの機能を把握し、その機能に沿った信頼性の高いＣＯＲＢＡ−ＩＩＯＰ通信(Interoperability)を可能にしている。
【００１０】
即ち、本発明は、第１のＯＲＢが搭載される第１の装置と、例えばベンダーが異なる第２のＯＲＢが搭載される第２の装置とを含むネットワークシステムであって、第１のＯＲＢが備える実装仕様を公開するためのプロファイル(Profile)オブジェクトを生成する生成手段と、生成されたプロファイルオブジェクトを登録する登録手段とを備え、この第２のＯＲＢは、登録手段にアクセスすることによりプロファイルオブジェクトを取得して第１のＯＲＢが備える実装仕様を認識し、第１のＯＲＢが備える実装仕様に基づいて第１のＯＲＢとの通信を実行することを特徴としている。
【００１１】
ここで、この登録手段としては、ＣＯＲＢＡのネーミングサービスを提供するネーミングサーバに、または、Ｗｅｂサーバ上にプロファイルオブジェクトを登録することが可能である。更に、リモートにある共有ディスクに登録するように構成することも可能である。
【００１２】
他の観点から把えると、本発明は、分散システム環境にて構築されるネットワークシステムであって、第１のＯＲＢが搭載されるサーバと、第１のＯＲＢとは仕様が異なる第２のＯＲＢが搭載されるクライアントと、サーバに搭載された第１のＯＲＢが備える仕様を公開するためのプロファイルオブジェクトをネーミングサービスに登録して提供するネーミングサーバと、を備え、第２のＯＲＢは、ネーミングサーバ経由でプロファイルオブジェクトにアクセスし、第１のＯＲＢが備える仕様を把握することを特徴としている。
【００１３】
ここで、このプロファイルオブジェクトへの定義としては、例えば、第１のＯＲＢにおいて可変長のパラメータを一度に扱える最大データ長に対し、この最大データ長を表現するメソッドを定義することが挙げられる。また、例えば、第１のＯＲＢがサポートしているＣＯＲＢＡ−ＩＩＯＰ通信メッセージを公開できるメソッドを定義することが挙げられる。このようなプロファイルオブジェクトを取得した第２のＯＲＢでは、例えば、可変長のパラメータを分割して送信し、また例えば、第１のＯＲＢによってサポートされているＣＯＲＢＡ−ＩＩＯＰ通信メッセージを用いて送信を実行するように構成することができる。かかる構成によって、異種ベンダー間における相互接続の信頼性を向上させることが可能となる。
【００１４】
一方、本発明は、分散システム環境にて構築されるネットワークシステムに設けられ、所定のＯＲＢが搭載されるサーバとして把握することができる。このサーバでは、ＯＲＢが備える実装仕様を公開するためのプロファイルオブジェクトを生成する生成手段と、生成されたプロファイルオブジェクトを自らのメモリ等に登録し、または、ネーミングサービスを提供するネーミングサーバやＷｅｂサーバ、共有ディスク等、他のサーバに登録する登録手段を備えている。
【００１５】
更に本発明は、分散システム環境にて構築されるネットワークシステムに設けられ、所定のＯＲＢが実装されるサーバとの間で通信を行うコンピュータ装置であるクライアントとして特定することが可能である。このクライアントでは、サーバにおけるＯＲＢの実装仕様を表すプロファイルオブジェクトを取得する取得手段と取得されたプロファイルオブジェクトを解析してＯＲＢの実装仕様を認識する認識手段と、認識されたＯＲＢの実装仕様に基づいてＯＲＢとの相互通信を実行する通信実行手段とを備えたことを特徴としている。
【００１６】
ここで、取得されたプロファイルオブジェクトを記憶する記憶手段を更に備え、この記憶手段により記憶されたプロファイルオブジェクトと取得手段により新たに取得されたプロファイルオブジェクトとを比較し、ＯＲＢ仕様の変更がある場合にはこの記憶手段に記憶されているプロファイルオブジェクトを更新するように構成できる。このように構成すれば、ＣＯＲＢＡ−ＩＩＯＰ通信を実行しようとする他の機種の仕様変更に対し、適切に対応することができる点で好ましい。
【００１７】
また、本発明は、オブジェクト間通信方法、プロファイルオブジェクト登録方法として把握することができる。また、コンピュータに、所定の機能を実現させるためのプログラムとして、更に、コンピュータに実行させるプログラムをコンピュータが読取可能に記憶した記憶媒体として把えることができる。これらのプログラムは、ＣＯＲＢＡ−ＩＩＯＰ通信を行うＯＲＢのサポート機能を外部から知ることのできるプロファイルオブジェクトを生成する機能(処理)と、他のＯＲＢとのＣＯＲＢＡ−ＩＩＯＰ通信に先立ち、生成されたプロファイルオブジェクトを登録する機能(処理)とをコンピュータに実現させることを特徴としている。
【００１８】
【発明の実施の形態】
以下、添付図面に従って、本発明における実施の形態について詳細に説明する。
図１は、本実施の形態が適用されるクライアントサーバシステムを説明するための図である。このシステムでは、ＣＯＲＢＡ(Common Object Request Broker Architecture)に準拠したコンピュータ装置であるクライアント１０とサーバ３０、およびネーミングサーバ５０がイントラネット等のネットワーク９を介して接続されている。クライアント１０とサーバ３０との間は、ＣＯＲＢＡで仕様が定められているＩＩＯＰ(Internet Inter-ORB Protocol)通信が行われる。
【００１９】
このＩＩＯＰは、ＯＲＢ(Object Request Broker)間の通信を実現するために米ＯＭＧ(Object Management Group)が定めた共通プロトコルである。ＣＯＲＢＡでは、異なるＯＲＢ間での通信を実現するために、ＴＣＰ/ＩＰやＯＳＩなどの通信プロトコルにおける上位の共通プロトコルとしてＧＩＯＰ(General Inter-ORB Protocol)が定められている。ＩＩＯＰは、このＧＩＯＰに従いＴＣＰ/ＩＰ等を使用して通信を行うために規定され、全てのＯＲＢ製品で実装が必須となっている。これにより、所定の内容について、各ベンダーにて提供される、異なるＯＲＢ製品間でのインタオペラビリティ(Interoperability)を可能としている。また、このＩＩＯＰを使用して、ＣＯＲＢＡ以外の代表的な分散システムと接続することが可能である。しかしながら、ＣＯＲＢＡ準拠製品間の接続テストを実際に行うと、ベンダー毎のＣＯＲＢＡ仕様に対する解釈の違い等によって、必ずしも相互接続が成功しない場合があり、本実施の形態では、かかる問題点を解決している。
【００２０】
本実施の形態では、クライアント１０にベンダーＸ社によって提供されるＸ社ＯＲＢ１１が搭載され、リモートにあるメソッドを読み出すことができるように機能されている。サーバ３０には、Ｘ社とは異なるベンダーであるＹ社によって提供されるＹ社ＯＲＢ３１が搭載されている。本実施の形態では、サーバ３０のＩＩＯＰ接続を司るＹ社ＯＲＢ３１のＣＯＲＢＡサポート仕様をクライアント１０のＸ社ＯＲＢ１１が知り得るオブジェクト(プロファイル(Profile)オブジェクト)を定義している。このProfileオブジェクトを実装し、インスタンス化し、公開することにより、クライアント１０がサーバ３０のＯＲＢ仕様を通信開始前に予め認識することを特徴としている。即ち、従来のＯＲＢにはプロファイルという概念は存在しなかったが、本実施の形態では、このプロファイルの概念を備えたProfileオブジェクトを実装および公開することにより、搭載されているＯＲＢの機能を、ＩＩＯＰ通信を行う相手装置に認識させることが可能となる。
【００２１】
ここで、ＣＯＲＢＡ共通サービスの中における最も一般的なサービスとして、ネーミングサービス(NamingService)がある。このネーミングサービスは、ＣＯＲＢＡオブジェクトに名前をつけて、オブジェクトに名前でアクセスできるようにするためのサービスであり、ネーミングサーバ５０にて、名前の登録と参照が行われる。各社から出荷されているＣＯＲＢＡ製品は、どの製品にもこのネーミングサービスが提供されている。本実施の形態では、このネーミングサービスに、サーバ３０のＹ社ＯＲＢ３１が備えるサポート機能を外部から知ることができるオブジェクト(Profileオブジェクト)を予め登録しておき、クライアント１０が稼動するＸ社ＯＲＢ１１がそのProfileオブジェクトにネーミングサーバ５０経由でアクセスする。Ｘ社ＯＲＢ１１は、そのProfileオブジェクト経由でサーバ３０のＹ社ＯＲＢ３１におけるＣＯＲＢＡ仕様を把握する。これによって、Ｘ社ＯＲＢ１１はＹ社ＯＲＢ３１との間のＩＩＯＰ通信障害を回避することができ、且つ、サーバ３０のＯＲＢ機能を利用した最適なＩＩＯＰ通信が可能となる。
【００２２】
図２は、サーバ３０の構成を示したブロック図である。サーバ３０では、自らが搭載しているＯＲＢ(例えばＸ社ＯＲＢ１１)のＣＯＲＢＡサポート仕様(ＯＲＢ仕様)を認識するＯＲＢ仕様認識部２１、認識されたＣＯＲＢＡサポート仕様に関する情報を格納するＯＲＢ仕様格納部２２、ＯＲＢ仕様格納部２２に格納されているＯＲＢ仕様とＯＲＢ仕様認識部２１により新たに認識されたＯＲＢ仕様とから、ＯＲＢ仕様の変更があったか否かを判断する仕様変更判断部２３、サーバ３０のＯＲＢサポート機能を示したProfileオブジェクトを作成するProfileオブジェクト作成部２４、作成されたProfileオブジェクトをネーミングサーバ５０に送信するProfileオブジェクト送信部２５を備えている。
【００２３】
図３は、サーバ３０にて実行されるProfileオブジェクトの登録処理を示すフローチャートである。サーバ３０では、まず、ＯＲＢ仕様認識部２１によって、サーバ３０に格納されているＹ社ＯＲＢ３１の仕様が認識される。そして、ＯＲＢ仕様格納部２２に格納されているＯＲＢの仕様との比較がなされ、例えばバージョンアップ等により、ＯＲＢ仕様が変更されたか否かを仕様変更判断部２３にて判断する(ステップ１０１)。変更されていない場合には、処理は終了するが、変更されている場合には、ネーミングサーバ５０への接続を行う(ステップ１０２)。そして、Profileオブジェクト作成部２４によってProfileオブジェクトが作成され(ステップ１０３)、作成されたProfileオブジェクトは、Profileオブジェクト送信部２５から送信されて、ネーミングサーバ５０に登録されることで(ステップ１０４)、Profileオブジェクト登録処理が終了する。
【００２４】
図４は、クライアント１０にて実行されるProfileオブジェクトの取得処理を示すフローチャートである。まず、クライアント１０のＸ社ＯＲＢ１１は、ネーミングサーバ５０への接続を行い(ステップ２０１)、ネーミングサービス経由でProfileオブジェクトを取得する(ステップ２０２)。ここで、前回取得されているProfileオブジェクトとの比較を行い(ステップ２０３)、ＯＲＢ仕様の変更があるか否かが判断される(ステップ２０４)。変更がなければ、そのまま処理が終了し、変更があれば、クライアント１０が記憶しているＹ社ＯＲＢ３１のProfileオブジェクトが更新されて(ステップ２０５)、Profileオブジェクトの取得処理が終了する。
【００２５】
次に、図３および図４にて説明した処理の適用例について説明する。
ＣＯＲＢＡのリモートオブジェクトのメソッドを呼び出すときに、パラメータが指定される。サーバ３０の可変長パラメータの最大値については、通常、クライアント１０では知り得る手段を有していない。従って、ＣＯＲＢＡ−ＩＩＯＰ通信が正常稼動しない場合が考えられる。しかしながら、本実施の形態によれば、以下に示すような構成によって、正常動作の確率向上が期待できる。
【００２６】
サーバ３０にて設けられているＹ社ＯＲＢ３１において、例えば、可変長のパラメータ(ＩＤＬ(Interface Definition Language)例：String)を一度に扱える最大データ長が１Ｍバイト(byte)とする。まず、サーバ３０では、Ｙ社ＯＲＢ３１の機能を表現するProfileオブジェクトをYprofObjとし、YprofObjのメソッドとして、int getMaxStringData()およびvoid setMaxStringData()が定義される。また、サーバ３０では、getMaxStringData()の戻り値が１ＭbyteになるようにYprofObjの実装が行われる。その後、YprofObjのインスタンス作成とネーミングサービスへの登録(bind())が行われる。
【００２７】
クライアント１０のＸ社ＯＲＢ１１では、ネーミングサービス経由でYprofObjのリファレンスが取得(resolve())された後、Ｙ社ＯＲＢ３１のStringにおけるＭＡＸ値１Ｍbyteが認識される。また、クライアント１０では、サーバ３０のオブジェクトリファレンスが取得された後、サーバ３０のメソッドに１.５Ｍbyte長のString型のパラメータが与えられる。Ｘ社ＯＲＢ１１では、Ｙ社ＯＲＢ３１のStringパラメータにおける最大値が１Ｍbyteであることが認識されているので、ＣＯＲＢＡ−ＩＩＯＰ通信メッセージのFragmentを使用し、このStringパラメータが１Ｍbyteと０.５Ｍbyteのパラメータに分割した送信が実行される。
【００２８】
ここで、Ｙ社ＯＲＢ３１の変更がなされ、StringのＭＡＸ値が２byteになった場合、１.５Ｍbyteのパラメータの分割送信を止めて、一度の送信に変更される。これによって、サーバ３０の特性を生かした効率の良いＣＯＲＢＡ−ＩＩＯＰ通信を実現することができる。
【００２９】
また、Ｙ社ＯＲＢ３１の変更がなされ、StringのＭＡＸ値が０.５Ｍbyteになった場合には、１.５Ｍbyteのパラメータを３分割送信する。このように、一般には接続障害が発生する場合でも、かかる仕組みを導入することによって、障害なしに相互接続を実現することが可能となる。
【００３０】
次に、ＩＩＯＰメッセージの例について、説明する。
ＣＯＲＢＡの最新仕様Version２.３では、ＣＯＲＢＡ−ＩＩＯＰ通信メッセージとして８種類のメッセージが規程されている。しかしながら、現状の各社ＣＯＲＢＡ製品は、最も頻繁に使用されるRequestおよびReplyはサポートされていても、それ以外の６種類(CancelRequest、LocateRequest、LocateReply、CloseConnection、MessageError、Fragment)のパラメータが全てのＣＯＲＢＡ製品にサポートされているとは限らない。このことにより、異種ベンダー間において、ＣＯＲＢＡ−ＩＩＯＰ通信が障害を起こすケースが考えられる。従って、ベンダーがサポートしているＩＩＯＰメッセージを公開できるメソッドをProfileオブジェクトに定義することによって、かかる障害を回避できる可能性が高まる。
【００３１】
サーバ３０では、Ｙ社ＯＲＢ３１のＩＩＯＰメッセージＸＸＸＸ(ＩＩＯＰメッセージ)のサポート状況を設定し、読み取り可能なメソッド(例：void_setXXXXSupported(boolean),boolean_getXXXXSupported())が定義される。例として、Ｙ社ＯＲＢ３１にて、Locate_Requestがサポートされていない場合に、Profileオブジェクトの中で、例えば、_setXXXXSupported()メソッドで偽(０)が実装される。
【００３２】
図５は、クライアント１０にて、ＩＩＯＰメッセージに対するサポートの有無による処理の一例を示した図である。前述したように、クライアント１０のＸ社ＯＲＢ１１は、ネーミングサーバ５０によるネーミングサービス経由でYProfObjのリファレンスを取得(resolve())する(ステップ３０１)。その後、getLocateRequestSupported()を呼び出し、Ｙ社ＯＲＢ３１がLocateRequestメッセージをサポートしているか否かが判断される(ステップ３０２)。サポートしている場合には、LocateRequestが送信され(ステップ３０３)、その後の処理が継続される(ステップ３０５)。サポートしていない場合には、LocateRequestの代わりにRequestが送信される(ステップ３０４)。即ち、クライアント１０からのLocateRequestは、クライアント１０からのRequestメッセージに代替可能となる。その後、処理継続がなされる(ステップ３０５)。Ｙ社ＯＲＢ３１では、Requestを受け取った後、Reply+LocationForward(LocateRequestに対するLocateReplyと等価)がＸ社ＯＲＢ１１に戻され、通信が続けられる。尚、この例では、Profileオブジェクトが存在しない場合には接続不能となる。
【００３３】
図６は、サーバ３０にて生成されるProfileオブジェクトの一例を示した図である。図６に示すProfileオブジェクトでは、struct giopVersion{にて、ＯＲＢのサポート１.０、１.１、１.２等が示される。例えば、１.２のときには、major01、minor02となる。octet SupportedIIOPMessage;では、サポートしているＩＩＯＰのメッセージが示される。ＣＯＲＢＡでは、８種類のメッセージが規程されており、例えば、0xFFはフルサポート、0xF7はLocateRequestサポートのないことが示されている。longlong MaxDataVolume;では、一度に送信できるデータ量の最大値(例えば、10,000,000 // １０Ｍbyte)が示される。string ORBVender Name;では、ＯＲＢベンダー名(例えば、"ＩＢＭ")が示される。更に、boolean InsSupport;は、ＩＮＳ(Interoeparble Naming Service)のサポートがあるか否かのフラグであり、例えば、１: サポート、０: サポートなし、が書き込まれる。
【００３４】
図７は、Profileオブジェクトの他の例を示す図である。ＣＯＲＢＡでは、相互接続に関して１０種類の"ObjectServiceContext"仕様が規程されている。図７に示す、例えば"is_TransactionService"は、"TransactionService"がサポートされているかどうかという意味であり、その他も同様である。Profileオブジェクトとしては、これらの仕様がサポートされているか否かを示すことで、ＯＲＢのサポート機能を提示することが可能となる。
【００３５】
以上のように、ＣＯＲＢＡでは、その仕様が外部仕様として規程され、外部に公開されているが、ＯＲＢの実装については提供されていないことから、従来、異種ＣＯＲＢＡ製品間の接続に関しては、実装の違いによって実機検証で様々な不具合が発生していた。例えば、１０Ｍバイトや２０Ｍバイト等の例えば部品表のバイナリデータ等、非常に大きなデータを相手側に送ろうとしたときに、現状のＯＲＢにおけるＣＯＲＢＡのレベルでは、どのくらいのデータ量をサポートするかについては定められていない。この結果、例えば、一気に１０Ｍバイトのデータを送った場合に、送りきれず、相手側では受信できずに障害が発生する場合があった。本実施の形態におけるProfileオブジェクトを用いれば、予め、どの程度のデータ量を受信することができるかを認識することができ、送信側から小出しに送って相手側がオーバフローしないように送信することが可能である。
【００３６】
また、従来のＣＯＲＢＡ製品では、接続した後のバージョンアップについても管理することができなかった。そのために、例えば、サーバ３０にてＧＩＯＰ１.０しかサポートされておらず、クライアント１０にてＧＩＯＰ１.２がサポートされている場合等にて、クライアント１０がＧＩＯＰ１.２で接続しようとすると、接続障害が生じる可能性があった。本実施の形態によれば、例えばサーバ３０のＹ社ＯＲＢ３１に変更があっても、Profileオブジェクトの変更によってクライアント１０のＸ社ＯＲＢ１１に変更内容を公開することが可能となり、相互接続障害を極力防ぐことが可能となる。
【００３７】
このように、今までＯＲＢにはプロファイルという概念は存在しなかったが、本実施の形態によれば、この概念を有するProfileオブジェクトを実装および公開することによって、異種ベンダー間のＣＯＲＢＡ−ＩＩＯＰ相互接続への信頼性向上と通信効率の向上を図ることができる。また、Profileオブジェクトは、ＣＯＲＢＡだけではなく、同様にＯＲＢを利用するＥＪＢ(Enterprise JavaBeans)の異種ベンダー環境にも適合させることが可能である。更に、複数ベンダーのＣＯＲＢＡサーバが混在する環境でも、ベンダー毎のProfileオブジェクトの名前を返すメソッドを持つオブジェクトを定義、実装、および公開することで、より異質な環境にも柔軟に対応することが可能となる。
【００３８】
尚、上述までの説明では、Profileオブジェクトの存在場所および呼び出し方法として、ＣＯＲＢＡのネーミングサービスを利用する例について示しているが、他の方法によってサポート機能を相手側に知らせることが可能である。例えば、ＦＴＰ(File Transfer Protocol)やＨＴＴＰ(Hypertext Transfer Protocol)などを利用した他のサブシステムを用いてサポート機能を認識する方法が考えられる。例えば、インターネットのＷｅｂ上にサーバ３０の備えるサポート機能の情報を配置し、クライアント１０がインターネットのＷｅｂにアクセスし、ＨＴＴＰによってサポート機能の情報を取得する等である。また、例えば、サーバ３０とクライアント１０とがリモートにある物理ドライブを共有し、例えばネットバイオス(NetBIOS)を用いてＬＡＮ経由でサポート機能を取得することも可能である。
【００３９】
図８は、ＨＴＴＰによってインターネットを介してＷｅｂサーバにアクセスし、ＯＲＢにおけるサポート機能の情報を取得する場合の例を示した図である。ここでは、Ｗｅｂサーバ７０が示され、クライアント１０とサーバ３０とはインターネット８０を介してＷｅｂサーバ７０に対して接続されている。Ｗｅｂサーバ７０には、Ｙ社ＯＲＢ３１の仕様が示されたProfileオブジェクトが予め格納されている。クライアント１０は、Ｘ社ＯＲＢ１１によってＹ社ＯＲＢ３１とＩＩＯＰ相互通信を実行するに先立ち、ＨＴＴＰを用いてＷｅｂサーバ７０からProfileオブジェクトを取得し、Ｙ社ＯＲＢ３１の仕様を認識する。仕様の認識後、ネットワーク９を介したＩＩＯＰ相互通信を行うことで、上述したネーミングサーバ５０からProfileオブジェクトを取得する場合と同様に、信頼性の高いＩＩＯＰ相互通信(Interoperability)を可能とすることができる。尚、かかる態様の場合には、図３のステップ１０２、ステップ１０４、および図４のステップ２０１で示した「ネーミングサーバ」を「Ｗｅｂサーバ」に置き換えれば良い。
【００４０】
図９は、共有ディスクを経由したProfileオブジェクトの受け渡し例を示した図である。ここでは、ローカルドライブを備え、各社のＯＲＢを備えたクライアント１０およびサーバ３０と、コンピュータ９０とがローカルエリアネットワーク(ＬＡＮ)９１を介して接続されている。同じＬＡＮ９１上のコンピュータ９０が備える物理ドライブ(例えばＣドライブ)をあたかも自分のコンピュータのローカルドライブ(例えばＸドライブ)として利用できる技術を共有ディスクと呼び、通常は、ＬＡＮ９１とアプリケーションとの規約であるネットバイオス(NetBIOS)という通信プロトコルが使用される。本実施の形態では、サーバ３０およびクライアント１０間で、共有ディスクを経由し、Profileオブジェクトの受け渡しを可能としている。かかる態様の場合には、図３のステップ１０２、ステップ１０４、図４のステップ２０１に示した「ネーミングサーバ」を「共有ディスク」に置き換えることで、一連の処理を説明することができる。即ち、サーバ３０は、共有ディスクへ接続し、生成されたProfileオブジェクトを共有ディスクへコピーする。クライアント１０では、共有ディスクへ接続した後に、共有ディスクからProfileオブジェクトを取得してサーバ３０の備えるＹ社ＯＲＢ３１のサポートしている仕様を認識し、認識された仕様に基づいて送受信を実行すれば良い。
【００４１】
尚、上述した各処理は、サーバ３０やクライアント１０等のコンピュータ装置にて、所定のプログラムによって実行される。このプログラムは、所定の記憶媒体によって提供することができる。また、プログラム伝送装置等から提供される場合がある。この記憶媒体としては、コンピュータ装置に実行させるプログラムが、ＣＤ−ＲＯＭ、ＤＶＤ、メモリ、ハードディスク等の記憶媒体に、コンピュータ装置に読み取り可能に記憶される態様が考えられる。また、プログラムがインターネット等のネットワークを介してインストールされる場合には、所定のプログラム伝送装置から提供される態様となる。この場合に、プログラム伝送装置としては、これらのプログラムを記憶させたＣＤ−ＲＯＭ、ＤＶＤ、メモリ、ハードディスク等の記憶手段と、この記憶手段からこれらのプログラムを読み出し、実行する装置側に、コネクタあるいはインターネットやＬＡＮ等のネットワークを介してこれらのプログラムを伝送する伝送手段とを備える構成が考えられる。
【００４２】
【発明の効果】
以上説明したように、本発明によれば、異なる仕様製品のＯＲＢ間通信における相互接続に際して、信頼性の向上を図ることが可能となる。
【図面の簡単な説明】
【図１】 本実施の形態が適用されるクライアントサーバシステムを説明するための図である。
【図２】 サーバの構成を示したブロック図である。
【図３】 サーバにて実行されるProfileオブジェクトの登録処理を示すフローチャートである。
【図４】 クライアントにて実行されるProfileオブジェクトの取得処理を示すフローチャートである。
【図５】 クライアントにて、ＩＩＯＰメッセージに対するサポートの有無による処理の一例を示した図である。
【図６】 サーバにて生成されるProfileオブジェクトの一例を示した図である。
【図７】 Profileオブジェクトの他の例を示す図である。
【図８】 ＨＴＴＰによってインターネットを介してＷｅｂサーバにアクセスし、ＯＲＢにおけるサポート機能の情報を取得する場合の例を示した図である。
【図９】 共有ディスクを経由したProfileオブジェクトの受け渡し例を示した図である。
【符号の説明】
９…ネットワーク、１０…クライアント、１１…Ｘ社ＯＲＢ、２１…ＯＲＢ仕様認識部、２２…ＯＲＢ仕様格納部、２３…仕様変更判断部、２４…Profileオブジェクト作成部、２５…Profileオブジェクト送信部、３０…サーバ、３１…Ｙ社ＯＲＢ、５０…ネーミングサーバ、７０…Ｗｅｂサーバ、８０…インターネット、９０…コンピュータ、９１…ローカルエリアネットワーク(ＬＡＮ)
【発明の属する技術分野】
本発明は、分散システム環境上に構築されるネットワークシステム等に係り、より詳しくは、異機種や異バージョン等の製品間にて効率的な相互接続を可能とするネットワークシステム等に関する。
【０００２】
【従来の技術】
近年、ネットワーク技術の急激な普及によって、これを基盤とした分散システムの浸透が進み、システムの分散化およびマルチベンダ化が加速してきている。例えば、情報システムを構築して、様々なデータを電子化して業務の効率化を実現している企業は一般的になりつつあるが、多くの場合、個別の業務に特化して独立したシステムを使用しており、部門間にまたがる全社的な効率化や他の企業との共同作業を進めようとする際に、様々な問題点が生じている。例えば、企業間でのデータ共用の問題、システム間の相互接続の問題、各企業におけるシステム変更への対応の問題等である。このような問題に対処するために、分散オブジェクト技術が注目されている。この分散オブジェクト技術では、機能単位であるオブジェクトを分散システム上で管理し実行させる仕組みが提供されている。
【０００３】
オブジェクト技術標準化団体の米ＯＭＧ(Object Management Group)では、異なる納入業者(ベンダー)間の分散オブジェクト製品間の相互接続をその大きな目的として、ＣＯＲＢＡ(Common Object Request Broker Architecture)を仕様として定めている。ＣＯＲＢＡは、クライアントがネットワークに存在するオブジェクト(分散オブジェクト)を呼び出すための基盤を提供しており、このＣＯＲＢＡには、分散オブジェクト環境にて、様々なマシン上のサーバ・オブジェクトとクライアント・アプリケーションとのやり取りを仲介するミドルウェアであるＯＲＢ(Object Request Broker)の共通仕様が規程されている。
【０００４】
ここで、ＣＯＲＢＡに関する関連公報として、特開２０００−２２４２６２号公報、特開平１０−１８７６３７号公報が存在する。この特開２０００−２２４２６２号公報には、管理対象である通信ネットワークを構成する各装置の様々な管理オブジェクトの形式や管理プロトコルに柔軟に対応してネットワーク管理をするために、同一ＯＲＢ上の複数オブジェクトを管理するオブジェクトを情報管理オブジェクト(ＩＭＯ)と名づけ、ＩＭＯによる複数ＣＯＲＢＡオブジェクト(アプリケーションオブジェクト)をシステム管理する技術について示されている。
【０００５】
また、ＣＯＲＢＡサービスとして規程されているＣＯＲＢＡネーミングサービスは、ＣＯＲＢＡアーキテクチャ上、複数独立して存在し得る。そのために、ある特定のＣＯＲＢＡオブジェクトにアクセスしたいクライアントは、どのネーミングサービスにアクセスしていいか解らない。特開平１０−１８７６３７号公報では、複数のネーミングサービスが存在する場合に、ネーミングサービスの各構成要素を分散させた上で、個々の構成要素を擬似的に、一つのネーミングサービスに見せることによって、より柔軟性の高いネーミングサービスを提供する技術について開示されている。
【０００６】
【発明が解決しようとする課題】
ここで、各ＣＯＲＢＡ製品を供給するベンダーは、ＣＯＲＢＡ仕様をそれぞれ解釈し、それに従って実装を行い、ＣＯＲＢＡ準拠製品と銘打って製品出荷を行っている。しかしながら、ＣＯＲＢＡ準拠製品間の接続テストを実際に行うと、ベンダー毎のＣＯＲＢＡ仕様に対する解釈の違いや、ＯＲＢであるＣＯＲＢＡ−ＩＩＯＰ(Internet Inter-ORB Protocol)通信用のランタイムモジュール実装の不備、或いは、ＯＲＢの独自実装等によって、必ずしも相互接続が成功しない場合がある。
【０００７】
また、一旦、接続が成功したとしても、製品のリリースアップや修正毎にプログラムが変更されることから、製品間の接続検証をやり直す必要がある。更に、サーバ側のＯＲＢに優れた機能がサポートされたとしても、クライアントから動的に認識する手段を従来のＣＯＲＢＡ−ＩＩＯＰ通信環境では備えておらず、システム全体の通信機能は必ずしも最適化が図られてはいなかった。
また更に、上述した特開２０００−２２４２６２号公報および特開平１０−１８７６３７号公報には、異機種或いは異バージョンのＯＲＢ間通信を容易にするための技術については開示されておらず、上記課題を解決できるものではない。
【０００８】
本発明は、以上のような技術的課題を解決するためになされたものであって、その目的とするところは、異なる仕様製品のＯＲＢ間通信における相互接続に際して、信頼性の向上と通信効率の向上を図ることにある。
【０００９】
【課題を解決するための手段】
かかる目的のもと、本発明は、ＣＯＲＢＡ−ＩＩＯＰ通信を実行するＯＲＢのサポート機能を提示できるプロファイル(Profile)オブジェクトをＣＯＲＢＡのオブジェクトとして定義、実装および公開することにより、他ベンダーがそのプロファイルオブジェクトを通じて接続しようとするＯＲＢの機能を把握し、その機能に沿った信頼性の高いＣＯＲＢＡ−ＩＩＯＰ通信(Interoperability)を可能にしている。
【００１０】
即ち、本発明は、第１のＯＲＢが搭載される第１の装置と、例えばベンダーが異なる第２のＯＲＢが搭載される第２の装置とを含むネットワークシステムであって、第１のＯＲＢが備える実装仕様を公開するためのプロファイル(Profile)オブジェクトを生成する生成手段と、生成されたプロファイルオブジェクトを登録する登録手段とを備え、この第２のＯＲＢは、登録手段にアクセスすることによりプロファイルオブジェクトを取得して第１のＯＲＢが備える実装仕様を認識し、第１のＯＲＢが備える実装仕様に基づいて第１のＯＲＢとの通信を実行することを特徴としている。
【００１１】
ここで、この登録手段としては、ＣＯＲＢＡのネーミングサービスを提供するネーミングサーバに、または、Ｗｅｂサーバ上にプロファイルオブジェクトを登録することが可能である。更に、リモートにある共有ディスクに登録するように構成することも可能である。
【００１２】
他の観点から把えると、本発明は、分散システム環境にて構築されるネットワークシステムであって、第１のＯＲＢが搭載されるサーバと、第１のＯＲＢとは仕様が異なる第２のＯＲＢが搭載されるクライアントと、サーバに搭載された第１のＯＲＢが備える仕様を公開するためのプロファイルオブジェクトをネーミングサービスに登録して提供するネーミングサーバと、を備え、第２のＯＲＢは、ネーミングサーバ経由でプロファイルオブジェクトにアクセスし、第１のＯＲＢが備える仕様を把握することを特徴としている。
【００１３】
ここで、このプロファイルオブジェクトへの定義としては、例えば、第１のＯＲＢにおいて可変長のパラメータを一度に扱える最大データ長に対し、この最大データ長を表現するメソッドを定義することが挙げられる。また、例えば、第１のＯＲＢがサポートしているＣＯＲＢＡ−ＩＩＯＰ通信メッセージを公開できるメソッドを定義することが挙げられる。このようなプロファイルオブジェクトを取得した第２のＯＲＢでは、例えば、可変長のパラメータを分割して送信し、また例えば、第１のＯＲＢによってサポートされているＣＯＲＢＡ−ＩＩＯＰ通信メッセージを用いて送信を実行するように構成することができる。かかる構成によって、異種ベンダー間における相互接続の信頼性を向上させることが可能となる。
【００１４】
一方、本発明は、分散システム環境にて構築されるネットワークシステムに設けられ、所定のＯＲＢが搭載されるサーバとして把握することができる。このサーバでは、ＯＲＢが備える実装仕様を公開するためのプロファイルオブジェクトを生成する生成手段と、生成されたプロファイルオブジェクトを自らのメモリ等に登録し、または、ネーミングサービスを提供するネーミングサーバやＷｅｂサーバ、共有ディスク等、他のサーバに登録する登録手段を備えている。
【００１５】
更に本発明は、分散システム環境にて構築されるネットワークシステムに設けられ、所定のＯＲＢが実装されるサーバとの間で通信を行うコンピュータ装置であるクライアントとして特定することが可能である。このクライアントでは、サーバにおけるＯＲＢの実装仕様を表すプロファイルオブジェクトを取得する取得手段と取得されたプロファイルオブジェクトを解析してＯＲＢの実装仕様を認識する認識手段と、認識されたＯＲＢの実装仕様に基づいてＯＲＢとの相互通信を実行する通信実行手段とを備えたことを特徴としている。
【００１６】
ここで、取得されたプロファイルオブジェクトを記憶する記憶手段を更に備え、この記憶手段により記憶されたプロファイルオブジェクトと取得手段により新たに取得されたプロファイルオブジェクトとを比較し、ＯＲＢ仕様の変更がある場合にはこの記憶手段に記憶されているプロファイルオブジェクトを更新するように構成できる。このように構成すれば、ＣＯＲＢＡ−ＩＩＯＰ通信を実行しようとする他の機種の仕様変更に対し、適切に対応することができる点で好ましい。
【００１７】
また、本発明は、オブジェクト間通信方法、プロファイルオブジェクト登録方法として把握することができる。また、コンピュータに、所定の機能を実現させるためのプログラムとして、更に、コンピュータに実行させるプログラムをコンピュータが読取可能に記憶した記憶媒体として把えることができる。これらのプログラムは、ＣＯＲＢＡ−ＩＩＯＰ通信を行うＯＲＢのサポート機能を外部から知ることのできるプロファイルオブジェクトを生成する機能(処理)と、他のＯＲＢとのＣＯＲＢＡ−ＩＩＯＰ通信に先立ち、生成されたプロファイルオブジェクトを登録する機能(処理)とをコンピュータに実現させることを特徴としている。
【００１８】
【発明の実施の形態】
以下、添付図面に従って、本発明における実施の形態について詳細に説明する。
図１は、本実施の形態が適用されるクライアントサーバシステムを説明するための図である。このシステムでは、ＣＯＲＢＡ(Common Object Request Broker Architecture)に準拠したコンピュータ装置であるクライアント１０とサーバ３０、およびネーミングサーバ５０がイントラネット等のネットワーク９を介して接続されている。クライアント１０とサーバ３０との間は、ＣＯＲＢＡで仕様が定められているＩＩＯＰ(Internet Inter-ORB Protocol)通信が行われる。
【００１９】
このＩＩＯＰは、ＯＲＢ(Object Request Broker)間の通信を実現するために米ＯＭＧ(Object Management Group)が定めた共通プロトコルである。ＣＯＲＢＡでは、異なるＯＲＢ間での通信を実現するために、ＴＣＰ/ＩＰやＯＳＩなどの通信プロトコルにおける上位の共通プロトコルとしてＧＩＯＰ(General Inter-ORB Protocol)が定められている。ＩＩＯＰは、このＧＩＯＰに従いＴＣＰ/ＩＰ等を使用して通信を行うために規定され、全てのＯＲＢ製品で実装が必須となっている。これにより、所定の内容について、各ベンダーにて提供される、異なるＯＲＢ製品間でのインタオペラビリティ(Interoperability)を可能としている。また、このＩＩＯＰを使用して、ＣＯＲＢＡ以外の代表的な分散システムと接続することが可能である。しかしながら、ＣＯＲＢＡ準拠製品間の接続テストを実際に行うと、ベンダー毎のＣＯＲＢＡ仕様に対する解釈の違い等によって、必ずしも相互接続が成功しない場合があり、本実施の形態では、かかる問題点を解決している。
【００２０】
本実施の形態では、クライアント１０にベンダーＸ社によって提供されるＸ社ＯＲＢ１１が搭載され、リモートにあるメソッドを読み出すことができるように機能されている。サーバ３０には、Ｘ社とは異なるベンダーであるＹ社によって提供されるＹ社ＯＲＢ３１が搭載されている。本実施の形態では、サーバ３０のＩＩＯＰ接続を司るＹ社ＯＲＢ３１のＣＯＲＢＡサポート仕様をクライアント１０のＸ社ＯＲＢ１１が知り得るオブジェクト(プロファイル(Profile)オブジェクト)を定義している。このProfileオブジェクトを実装し、インスタンス化し、公開することにより、クライアント１０がサーバ３０のＯＲＢ仕様を通信開始前に予め認識することを特徴としている。即ち、従来のＯＲＢにはプロファイルという概念は存在しなかったが、本実施の形態では、このプロファイルの概念を備えたProfileオブジェクトを実装および公開することにより、搭載されているＯＲＢの機能を、ＩＩＯＰ通信を行う相手装置に認識させることが可能となる。
【００２１】
ここで、ＣＯＲＢＡ共通サービスの中における最も一般的なサービスとして、ネーミングサービス(NamingService)がある。このネーミングサービスは、ＣＯＲＢＡオブジェクトに名前をつけて、オブジェクトに名前でアクセスできるようにするためのサービスであり、ネーミングサーバ５０にて、名前の登録と参照が行われる。各社から出荷されているＣＯＲＢＡ製品は、どの製品にもこのネーミングサービスが提供されている。本実施の形態では、このネーミングサービスに、サーバ３０のＹ社ＯＲＢ３１が備えるサポート機能を外部から知ることができるオブジェクト(Profileオブジェクト)を予め登録しておき、クライアント１０が稼動するＸ社ＯＲＢ１１がそのProfileオブジェクトにネーミングサーバ５０経由でアクセスする。Ｘ社ＯＲＢ１１は、そのProfileオブジェクト経由でサーバ３０のＹ社ＯＲＢ３１におけるＣＯＲＢＡ仕様を把握する。これによって、Ｘ社ＯＲＢ１１はＹ社ＯＲＢ３１との間のＩＩＯＰ通信障害を回避することができ、且つ、サーバ３０のＯＲＢ機能を利用した最適なＩＩＯＰ通信が可能となる。
【００２２】
図２は、サーバ３０の構成を示したブロック図である。サーバ３０では、自らが搭載しているＯＲＢ(例えばＸ社ＯＲＢ１１)のＣＯＲＢＡサポート仕様(ＯＲＢ仕様)を認識するＯＲＢ仕様認識部２１、認識されたＣＯＲＢＡサポート仕様に関する情報を格納するＯＲＢ仕様格納部２２、ＯＲＢ仕様格納部２２に格納されているＯＲＢ仕様とＯＲＢ仕様認識部２１により新たに認識されたＯＲＢ仕様とから、ＯＲＢ仕様の変更があったか否かを判断する仕様変更判断部２３、サーバ３０のＯＲＢサポート機能を示したProfileオブジェクトを作成するProfileオブジェクト作成部２４、作成されたProfileオブジェクトをネーミングサーバ５０に送信するProfileオブジェクト送信部２５を備えている。
【００２３】
図３は、サーバ３０にて実行されるProfileオブジェクトの登録処理を示すフローチャートである。サーバ３０では、まず、ＯＲＢ仕様認識部２１によって、サーバ３０に格納されているＹ社ＯＲＢ３１の仕様が認識される。そして、ＯＲＢ仕様格納部２２に格納されているＯＲＢの仕様との比較がなされ、例えばバージョンアップ等により、ＯＲＢ仕様が変更されたか否かを仕様変更判断部２３にて判断する(ステップ１０１)。変更されていない場合には、処理は終了するが、変更されている場合には、ネーミングサーバ５０への接続を行う(ステップ１０２)。そして、Profileオブジェクト作成部２４によってProfileオブジェクトが作成され(ステップ１０３)、作成されたProfileオブジェクトは、Profileオブジェクト送信部２５から送信されて、ネーミングサーバ５０に登録されることで(ステップ１０４)、Profileオブジェクト登録処理が終了する。
【００２４】
図４は、クライアント１０にて実行されるProfileオブジェクトの取得処理を示すフローチャートである。まず、クライアント１０のＸ社ＯＲＢ１１は、ネーミングサーバ５０への接続を行い(ステップ２０１)、ネーミングサービス経由でProfileオブジェクトを取得する(ステップ２０２)。ここで、前回取得されているProfileオブジェクトとの比較を行い(ステップ２０３)、ＯＲＢ仕様の変更があるか否かが判断される(ステップ２０４)。変更がなければ、そのまま処理が終了し、変更があれば、クライアント１０が記憶しているＹ社ＯＲＢ３１のProfileオブジェクトが更新されて(ステップ２０５)、Profileオブジェクトの取得処理が終了する。
【００２５】
次に、図３および図４にて説明した処理の適用例について説明する。
ＣＯＲＢＡのリモートオブジェクトのメソッドを呼び出すときに、パラメータが指定される。サーバ３０の可変長パラメータの最大値については、通常、クライアント１０では知り得る手段を有していない。従って、ＣＯＲＢＡ−ＩＩＯＰ通信が正常稼動しない場合が考えられる。しかしながら、本実施の形態によれば、以下に示すような構成によって、正常動作の確率向上が期待できる。
【００２６】
サーバ３０にて設けられているＹ社ＯＲＢ３１において、例えば、可変長のパラメータ(ＩＤＬ(Interface Definition Language)例：String)を一度に扱える最大データ長が１Ｍバイト(byte)とする。まず、サーバ３０では、Ｙ社ＯＲＢ３１の機能を表現するProfileオブジェクトをYprofObjとし、YprofObjのメソッドとして、int getMaxStringData()およびvoid setMaxStringData()が定義される。また、サーバ３０では、getMaxStringData()の戻り値が１ＭbyteになるようにYprofObjの実装が行われる。その後、YprofObjのインスタンス作成とネーミングサービスへの登録(bind())が行われる。
【００２７】
クライアント１０のＸ社ＯＲＢ１１では、ネーミングサービス経由でYprofObjのリファレンスが取得(resolve())された後、Ｙ社ＯＲＢ３１のStringにおけるＭＡＸ値１Ｍbyteが認識される。また、クライアント１０では、サーバ３０のオブジェクトリファレンスが取得された後、サーバ３０のメソッドに１.５Ｍbyte長のString型のパラメータが与えられる。Ｘ社ＯＲＢ１１では、Ｙ社ＯＲＢ３１のStringパラメータにおける最大値が１Ｍbyteであることが認識されているので、ＣＯＲＢＡ−ＩＩＯＰ通信メッセージのFragmentを使用し、このStringパラメータが１Ｍbyteと０.５Ｍbyteのパラメータに分割した送信が実行される。
【００２８】
ここで、Ｙ社ＯＲＢ３１の変更がなされ、StringのＭＡＸ値が２byteになった場合、１.５Ｍbyteのパラメータの分割送信を止めて、一度の送信に変更される。これによって、サーバ３０の特性を生かした効率の良いＣＯＲＢＡ−ＩＩＯＰ通信を実現することができる。
【００２９】
また、Ｙ社ＯＲＢ３１の変更がなされ、StringのＭＡＸ値が０.５Ｍbyteになった場合には、１.５Ｍbyteのパラメータを３分割送信する。このように、一般には接続障害が発生する場合でも、かかる仕組みを導入することによって、障害なしに相互接続を実現することが可能となる。
【００３０】
次に、ＩＩＯＰメッセージの例について、説明する。
ＣＯＲＢＡの最新仕様Version２.３では、ＣＯＲＢＡ−ＩＩＯＰ通信メッセージとして８種類のメッセージが規程されている。しかしながら、現状の各社ＣＯＲＢＡ製品は、最も頻繁に使用されるRequestおよびReplyはサポートされていても、それ以外の６種類(CancelRequest、LocateRequest、LocateReply、CloseConnection、MessageError、Fragment)のパラメータが全てのＣＯＲＢＡ製品にサポートされているとは限らない。このことにより、異種ベンダー間において、ＣＯＲＢＡ−ＩＩＯＰ通信が障害を起こすケースが考えられる。従って、ベンダーがサポートしているＩＩＯＰメッセージを公開できるメソッドをProfileオブジェクトに定義することによって、かかる障害を回避できる可能性が高まる。
【００３１】
サーバ３０では、Ｙ社ＯＲＢ３１のＩＩＯＰメッセージＸＸＸＸ(ＩＩＯＰメッセージ)のサポート状況を設定し、読み取り可能なメソッド(例：void_setXXXXSupported(boolean),boolean_getXXXXSupported())が定義される。例として、Ｙ社ＯＲＢ３１にて、Locate_Requestがサポートされていない場合に、Profileオブジェクトの中で、例えば、_setXXXXSupported()メソッドで偽(０)が実装される。
【００３２】
図５は、クライアント１０にて、ＩＩＯＰメッセージに対するサポートの有無による処理の一例を示した図である。前述したように、クライアント１０のＸ社ＯＲＢ１１は、ネーミングサーバ５０によるネーミングサービス経由でYProfObjのリファレンスを取得(resolve())する(ステップ３０１)。その後、getLocateRequestSupported()を呼び出し、Ｙ社ＯＲＢ３１がLocateRequestメッセージをサポートしているか否かが判断される(ステップ３０２)。サポートしている場合には、LocateRequestが送信され(ステップ３０３)、その後の処理が継続される(ステップ３０５)。サポートしていない場合には、LocateRequestの代わりにRequestが送信される(ステップ３０４)。即ち、クライアント１０からのLocateRequestは、クライアント１０からのRequestメッセージに代替可能となる。その後、処理継続がなされる(ステップ３０５)。Ｙ社ＯＲＢ３１では、Requestを受け取った後、Reply+LocationForward(LocateRequestに対するLocateReplyと等価)がＸ社ＯＲＢ１１に戻され、通信が続けられる。尚、この例では、Profileオブジェクトが存在しない場合には接続不能となる。
【００３３】
図６は、サーバ３０にて生成されるProfileオブジェクトの一例を示した図である。図６に示すProfileオブジェクトでは、struct giopVersion{にて、ＯＲＢのサポート１.０、１.１、１.２等が示される。例えば、１.２のときには、major01、minor02となる。octet SupportedIIOPMessage;では、サポートしているＩＩＯＰのメッセージが示される。ＣＯＲＢＡでは、８種類のメッセージが規程されており、例えば、0xFFはフルサポート、0xF7はLocateRequestサポートのないことが示されている。longlong MaxDataVolume;では、一度に送信できるデータ量の最大値(例えば、10,000,000 // １０Ｍbyte)が示される。string ORBVender Name;では、ＯＲＢベンダー名(例えば、"ＩＢＭ")が示される。更に、boolean InsSupport;は、ＩＮＳ(Interoeparble Naming Service)のサポートがあるか否かのフラグであり、例えば、１: サポート、０: サポートなし、が書き込まれる。
【００３４】
図７は、Profileオブジェクトの他の例を示す図である。ＣＯＲＢＡでは、相互接続に関して１０種類の"ObjectServiceContext"仕様が規程されている。図７に示す、例えば"is_TransactionService"は、"TransactionService"がサポートされているかどうかという意味であり、その他も同様である。Profileオブジェクトとしては、これらの仕様がサポートされているか否かを示すことで、ＯＲＢのサポート機能を提示することが可能となる。
【００３５】
以上のように、ＣＯＲＢＡでは、その仕様が外部仕様として規程され、外部に公開されているが、ＯＲＢの実装については提供されていないことから、従来、異種ＣＯＲＢＡ製品間の接続に関しては、実装の違いによって実機検証で様々な不具合が発生していた。例えば、１０Ｍバイトや２０Ｍバイト等の例えば部品表のバイナリデータ等、非常に大きなデータを相手側に送ろうとしたときに、現状のＯＲＢにおけるＣＯＲＢＡのレベルでは、どのくらいのデータ量をサポートするかについては定められていない。この結果、例えば、一気に１０Ｍバイトのデータを送った場合に、送りきれず、相手側では受信できずに障害が発生する場合があった。本実施の形態におけるProfileオブジェクトを用いれば、予め、どの程度のデータ量を受信することができるかを認識することができ、送信側から小出しに送って相手側がオーバフローしないように送信することが可能である。
【００３６】
また、従来のＣＯＲＢＡ製品では、接続した後のバージョンアップについても管理することができなかった。そのために、例えば、サーバ３０にてＧＩＯＰ１.０しかサポートされておらず、クライアント１０にてＧＩＯＰ１.２がサポートされている場合等にて、クライアント１０がＧＩＯＰ１.２で接続しようとすると、接続障害が生じる可能性があった。本実施の形態によれば、例えばサーバ３０のＹ社ＯＲＢ３１に変更があっても、Profileオブジェクトの変更によってクライアント１０のＸ社ＯＲＢ１１に変更内容を公開することが可能となり、相互接続障害を極力防ぐことが可能となる。
【００３７】
このように、今までＯＲＢにはプロファイルという概念は存在しなかったが、本実施の形態によれば、この概念を有するProfileオブジェクトを実装および公開することによって、異種ベンダー間のＣＯＲＢＡ−ＩＩＯＰ相互接続への信頼性向上と通信効率の向上を図ることができる。また、Profileオブジェクトは、ＣＯＲＢＡだけではなく、同様にＯＲＢを利用するＥＪＢ(Enterprise JavaBeans)の異種ベンダー環境にも適合させることが可能である。更に、複数ベンダーのＣＯＲＢＡサーバが混在する環境でも、ベンダー毎のProfileオブジェクトの名前を返すメソッドを持つオブジェクトを定義、実装、および公開することで、より異質な環境にも柔軟に対応することが可能となる。
【００３８】
尚、上述までの説明では、Profileオブジェクトの存在場所および呼び出し方法として、ＣＯＲＢＡのネーミングサービスを利用する例について示しているが、他の方法によってサポート機能を相手側に知らせることが可能である。例えば、ＦＴＰ(File Transfer Protocol)やＨＴＴＰ(Hypertext Transfer Protocol)などを利用した他のサブシステムを用いてサポート機能を認識する方法が考えられる。例えば、インターネットのＷｅｂ上にサーバ３０の備えるサポート機能の情報を配置し、クライアント１０がインターネットのＷｅｂにアクセスし、ＨＴＴＰによってサポート機能の情報を取得する等である。また、例えば、サーバ３０とクライアント１０とがリモートにある物理ドライブを共有し、例えばネットバイオス(NetBIOS)を用いてＬＡＮ経由でサポート機能を取得することも可能である。
【００３９】
図８は、ＨＴＴＰによってインターネットを介してＷｅｂサーバにアクセスし、ＯＲＢにおけるサポート機能の情報を取得する場合の例を示した図である。ここでは、Ｗｅｂサーバ７０が示され、クライアント１０とサーバ３０とはインターネット８０を介してＷｅｂサーバ７０に対して接続されている。Ｗｅｂサーバ７０には、Ｙ社ＯＲＢ３１の仕様が示されたProfileオブジェクトが予め格納されている。クライアント１０は、Ｘ社ＯＲＢ１１によってＹ社ＯＲＢ３１とＩＩＯＰ相互通信を実行するに先立ち、ＨＴＴＰを用いてＷｅｂサーバ７０からProfileオブジェクトを取得し、Ｙ社ＯＲＢ３１の仕様を認識する。仕様の認識後、ネットワーク９を介したＩＩＯＰ相互通信を行うことで、上述したネーミングサーバ５０からProfileオブジェクトを取得する場合と同様に、信頼性の高いＩＩＯＰ相互通信(Interoperability)を可能とすることができる。尚、かかる態様の場合には、図３のステップ１０２、ステップ１０４、および図４のステップ２０１で示した「ネーミングサーバ」を「Ｗｅｂサーバ」に置き換えれば良い。
【００４０】
図９は、共有ディスクを経由したProfileオブジェクトの受け渡し例を示した図である。ここでは、ローカルドライブを備え、各社のＯＲＢを備えたクライアント１０およびサーバ３０と、コンピュータ９０とがローカルエリアネットワーク(ＬＡＮ)９１を介して接続されている。同じＬＡＮ９１上のコンピュータ９０が備える物理ドライブ(例えばＣドライブ)をあたかも自分のコンピュータのローカルドライブ(例えばＸドライブ)として利用できる技術を共有ディスクと呼び、通常は、ＬＡＮ９１とアプリケーションとの規約であるネットバイオス(NetBIOS)という通信プロトコルが使用される。本実施の形態では、サーバ３０およびクライアント１０間で、共有ディスクを経由し、Profileオブジェクトの受け渡しを可能としている。かかる態様の場合には、図３のステップ１０２、ステップ１０４、図４のステップ２０１に示した「ネーミングサーバ」を「共有ディスク」に置き換えることで、一連の処理を説明することができる。即ち、サーバ３０は、共有ディスクへ接続し、生成されたProfileオブジェクトを共有ディスクへコピーする。クライアント１０では、共有ディスクへ接続した後に、共有ディスクからProfileオブジェクトを取得してサーバ３０の備えるＹ社ＯＲＢ３１のサポートしている仕様を認識し、認識された仕様に基づいて送受信を実行すれば良い。
【００４１】
尚、上述した各処理は、サーバ３０やクライアント１０等のコンピュータ装置にて、所定のプログラムによって実行される。このプログラムは、所定の記憶媒体によって提供することができる。また、プログラム伝送装置等から提供される場合がある。この記憶媒体としては、コンピュータ装置に実行させるプログラムが、ＣＤ−ＲＯＭ、ＤＶＤ、メモリ、ハードディスク等の記憶媒体に、コンピュータ装置に読み取り可能に記憶される態様が考えられる。また、プログラムがインターネット等のネットワークを介してインストールされる場合には、所定のプログラム伝送装置から提供される態様となる。この場合に、プログラム伝送装置としては、これらのプログラムを記憶させたＣＤ−ＲＯＭ、ＤＶＤ、メモリ、ハードディスク等の記憶手段と、この記憶手段からこれらのプログラムを読み出し、実行する装置側に、コネクタあるいはインターネットやＬＡＮ等のネットワークを介してこれらのプログラムを伝送する伝送手段とを備える構成が考えられる。
【００４２】
【発明の効果】
以上説明したように、本発明によれば、異なる仕様製品のＯＲＢ間通信における相互接続に際して、信頼性の向上を図ることが可能となる。
【図面の簡単な説明】
【図１】 本実施の形態が適用されるクライアントサーバシステムを説明するための図である。
【図２】 サーバの構成を示したブロック図である。
【図３】 サーバにて実行されるProfileオブジェクトの登録処理を示すフローチャートである。
【図４】 クライアントにて実行されるProfileオブジェクトの取得処理を示すフローチャートである。
【図５】 クライアントにて、ＩＩＯＰメッセージに対するサポートの有無による処理の一例を示した図である。
【図６】 サーバにて生成されるProfileオブジェクトの一例を示した図である。
【図７】 Profileオブジェクトの他の例を示す図である。
【図８】 ＨＴＴＰによってインターネットを介してＷｅｂサーバにアクセスし、ＯＲＢにおけるサポート機能の情報を取得する場合の例を示した図である。
【図９】 共有ディスクを経由したProfileオブジェクトの受け渡し例を示した図である。
【符号の説明】
９…ネットワーク、１０…クライアント、１１…Ｘ社ＯＲＢ、２１…ＯＲＢ仕様認識部、２２…ＯＲＢ仕様格納部、２３…仕様変更判断部、２４…Profileオブジェクト作成部、２５…Profileオブジェクト送信部、３０…サーバ、３１…Ｙ社ＯＲＢ、５０…ネーミングサーバ、７０…Ｗｅｂサーバ、８０…インターネット、９０…コンピュータ、９１…ローカルエリアネットワーク(ＬＡＮ)
Claims (9)
- 第１のＯＲＢ(ObjectRequest Broker)が搭載される第１の装置と第２のＯＲＢが搭載される第２の装置とを含むネットワークシステムであって、
前記第１のＯＲＢが備える実装仕様を提示するメソッドを含むプロファイルオブジェクトを生成する生成手段と、
前記生成手段により生成された前記プロファイルオブジェクトを登録して公開する登録手段とを備え、
前記第２のＯＲＢは、前記登録手段にアクセスすることにより前記プロファイルオブジェクトを取得して前記メソッドを呼び出してその戻り値を取得することにより前記第１のＯＲＢが備える実装仕様を取得し、当該第１のＯＲＢが備える実装仕様に合わせて当該第１のＯＲＢとの相互通信を実行することを特徴とする、
ネットワークシステム。 - 前記登録手段は、ＣＯＲＢＡ(Common Object Request Broker Architecture)のネーミングサービスを提供するネーミングサーバに前記プロファイルオブジェクトを登録することを特徴とする請求項１記載のネットワークシステム。
- 前記生成手段は、前記第１のＯＲＢに対する仕様の変更があった場合に、変更された仕様に基づいて前記プロファイルオブジェクトを生成することを特徴とする請求項１記載のネットワークシステム。
- 分散システム環境にて構築されるネットワークシステムであって、
第１のＯＲＢ(ObjectRequest Broker)が搭載されるサーバと、
前記第１のＯＲＢとは仕様が異なる第２のＯＲＢが搭載されるクライアントと、
前記サーバに搭載された前記第１のＯＲＢが備える仕様を提示するメソッドを含むプロファイルオブジェクトをネーミングサービスに登録して提供するネーミングサーバと、を備え、
前記クライアントの前記第２のＯＲＢは、前記ネーミングサーバ経由で前記プロファイルオブジェクトにアクセスし、前記第１のＯＲＢが備える仕様を前記メソッドを呼び出してその戻り値を取得することにより取得し、当該第１のＯＲＢが備える仕様に合わせて当該第１のＯＲＢとの相互通信を実行することを特徴とするネットワークシステム。 - 前記サーバは、前記第１のＯＲＢにおいて可変長のパラメータを一度に扱える最大データ長に対し、当該最大データ長を提示するメソッドを前記プロファイルオブジェクトに定義することを特徴とする請求項４記載のネットワークシステム。
- 前記第２のＯＲＢは、前記ネーミングサーバ経由で前記プロファイルオブジェクトを取得して前記第１のＯＲＢが扱える最大データ長を取得し、パラメータを分割して送信することを特徴とする請求項５記載のネットワークシステム。
- 分散システム環境にて構築されるネットワークシステムに設けられ、所定のＯＲＢ(Object Request Broker)が実装されるサーバとの間で通信を行うクライアントであって、
前記サーバにおける前記ＯＲＢの実装仕様を提示するメソッドを含む、公開されているプロファイルオブジェクトを取得する取得手段と、
前記取得手段により取得された前記メソッドを呼び出して前記ＯＲＢの実装仕様を取得する取得手段と、
前記取得手段により取得された前記ＯＲＢの実装仕様に合わせて前記ＯＲＢとの相互通信を実行する通信実行手段と、を備えたことを特徴とするクライアント。 - 第１のＯＲＢ(ObjectRequest Broker)と当該第１のＯＲＢとは仕様の異なる第２のＯＲＢとの間でなされる分散システム環境におけるオブジェクト間通信方法であって、
前記第１のＯＲＢの実装仕様を提示するメソッドを含むプロファイルオブジェクトを生成し、
生成された前記プロファイルオブジェクトを登録して公開し、
登録された前記プロファイルオブジェクトが前記第２のＯＲＢに取得されて前記第１のＯＲＢの仕様が前記メソッドを呼び出すことにより取得された後、前記第２のＯＲＢと前記第１のＯＲＢとの間にて、当該第１のＯＲＢの仕様に合わせた相互通信が実行されることを特徴とするオブジェクト間通信方法。 - コンピュータに、
ＣＯＲＢＡ(CommonObject Request Broker Architecture)−ＩＩＯＰ(Internet Inter-ORB Protocol)通信を行うＯＲＢ(ObjectRequest Broker)の実装仕様を他のＯＲＢに提示するメソッドを含むプロファイルオブジェクトを生成する機能と、
前記他のＯＲＢとの前記ＣＯＲＢＡ−ＩＩＯＰ通信に先立ち、生成された前記プロファイルオブジェクトを登録して公開する機能と、
登録された前記プロファイルオブジェクトにアクセスし、通信しようとするＯＲＢの実装仕様を前記メソッドを呼び出すことにより取得する機能と、
取得された前記通信しようとするＯＲＢの実装仕様に合わせて相互通信を実行する機能と、を実現させるためのプログラム。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001180191A JP4536292B2 (ja) | 2001-06-14 | 2001-06-14 | ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 |
| US10/159,305 US7131126B2 (en) | 2001-06-14 | 2002-05-30 | Network systems, servers, clients, communication methods between objects, profile object registration methods, programs, and storage media |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001180191A JP4536292B2 (ja) | 2001-06-14 | 2001-06-14 | ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003015891A JP2003015891A (ja) | 2003-01-17 |
| JP4536292B2 true JP4536292B2 (ja) | 2010-09-01 |
Family
ID=19020649
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001180191A Expired - Fee Related JP4536292B2 (ja) | 2001-06-14 | 2001-06-14 | ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7131126B2 (ja) |
| JP (1) | JP4536292B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2376096B (en) | 2001-05-30 | 2005-06-29 | Ibm | Identification of the source of a client/server flow |
| US7739688B1 (en) | 2006-01-03 | 2010-06-15 | Emc Corporation | Techniques for managing distribution of well-defined objects in a client/server system |
| JP5292670B2 (ja) * | 2006-02-22 | 2013-09-18 | 富士通株式会社 | 開発支援プログラム、開発支援方法、及び開発支援装置 |
| CN104683140A (zh) * | 2013-12-02 | 2015-06-03 | 中兴通讯股份有限公司 | 一种实现北向Corba接口规范无缝切换的方法及装置 |
Family Cites Families (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0785122A (ja) * | 1993-06-24 | 1995-03-31 | Yokoyama Yoshio | アプリケーシヨン構築システム |
| US6282580B1 (en) | 1996-07-02 | 2001-08-28 | Sun Microsystems, Inc. | Bridge providing communication between different implementations of object request brokers |
| US6016516A (en) * | 1996-08-07 | 2000-01-18 | Fuji Xerox Co. Ltd. | Remote procedure processing device used by at least two linked computer systems |
| JPH1049392A (ja) * | 1996-08-07 | 1998-02-20 | Fuji Xerox Co Ltd | 遠隔手続処理装置 |
| DE59604238D1 (de) | 1996-08-20 | 2000-02-24 | Alcatel Sa | Verfahren zur Verwaltung der Benennung von Objekten |
| JPH10320206A (ja) | 1997-03-14 | 1998-12-04 | Toshiba Corp | 分散オブジェクトシステムにおけるオブジェクトの状態管理方法ならびに装置、及び同方法がプログラムされ記録される記録媒体、もしくはプログラムとして伝搬される通信媒体 |
| US5999988A (en) * | 1997-03-31 | 1999-12-07 | Sun Microsystems, Inc. | Method and apparatus for generating and employing a run-time generated stub to reference an object in object oriented systems |
| DE69731182T2 (de) * | 1997-04-14 | 2005-10-13 | Alcatel | Nachrichtenverfahren zwischen einer Dienstvermittlungsstelle und einer Dienstkontrolleinrichtung in einem Fernmeldenetz |
| US6516354B2 (en) * | 1997-12-18 | 2003-02-04 | Sun Microsystems, Inc. | Method and apparatus for efficient representation of variable length identifiers in a distributed object system |
| JPH11232104A (ja) | 1998-02-13 | 1999-08-27 | Nec Corp | オブジェクトの更新管理方法及びクライアント／サーバ・システム |
| US6574675B1 (en) * | 1998-09-25 | 2003-06-03 | Netscape Communications Corporation | Simple workflow access protocol |
| JP2000148698A (ja) * | 1998-11-11 | 2000-05-30 | Hitachi Ltd | 分散オブジェクトセキュリティシステム |
| US6629112B1 (en) * | 1998-12-31 | 2003-09-30 | Nortel Networks Limited | Resource management for CORBA-based applications |
| JP2000224262A (ja) | 1999-01-29 | 2000-08-11 | Nippon Telegr & Teleph Corp <Ntt> | ネットワーク管理システム |
| US6453320B1 (en) * | 1999-02-01 | 2002-09-17 | Iona Technologies, Inc. | Method and system for providing object references in a distributed object environment supporting object migration |
| US6735771B1 (en) * | 1999-03-12 | 2004-05-11 | Perot Systems Corporation | System and method for delivering web services using common object request broker architecture |
| JP2000322288A (ja) | 1999-05-06 | 2000-11-24 | Fujitsu Ltd | 分散オブジェクト開発システム、および、分散オブジェクト開発をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体 |
| US6567818B1 (en) * | 1999-06-14 | 2003-05-20 | International Business Machines Corporation | Employing management policies to manage instances of objects |
| JP2001134540A (ja) | 1999-11-02 | 2001-05-18 | Nec Corp | 分散オブジェクト呼出しシステム |
| US6629128B1 (en) * | 1999-11-30 | 2003-09-30 | Recursion Software, Inc. | System and method for distributed processing in a computer network |
| JP2001159978A (ja) | 1999-12-02 | 2001-06-12 | Nec Corp | 分散オブジェクトプログラム実行支援システム |
| US6839748B1 (en) * | 2000-04-21 | 2005-01-04 | Sun Microsystems, Inc. | Synchronous task scheduler for corba gateway |
| US6578050B1 (en) * | 2000-06-01 | 2003-06-10 | Sprint Communications Company, L.P. | Method and apparatus for implementing persistence in name services associated with computer system |
| US6751646B1 (en) * | 2000-06-01 | 2004-06-15 | Sprint Communications Company L.P. | Method and apparatus for implementing CORBA compliant name services incorporating load balancing features |
-
2001
- 2001-06-14 JP JP2001180191A patent/JP4536292B2/ja not_active Expired - Fee Related
-
2002
- 2002-05-30 US US10/159,305 patent/US7131126B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US20020194391A1 (en) | 2002-12-19 |
| US7131126B2 (en) | 2006-10-31 |
| JP2003015891A (ja) | 2003-01-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11171897B2 (en) | Method and apparatus for composite user interface generation | |
| US5926636A (en) | Remote procedural call component management method for a heterogeneous computer network | |
| US7607128B2 (en) | Method and system for enabling a server application to be executed in the same virtual machine as a client application using direct object oriented programming method calls | |
| US7644415B2 (en) | Application programming interface to the simple object access protocol | |
| US6687831B1 (en) | Method and apparatus for multiple security service enablement in a data processing system | |
| US8276166B2 (en) | System and method for providing interoperability between different programming protocols | |
| US20080140760A1 (en) | Service-oriented architecture system and methods supporting dynamic service provider versioning | |
| US7051341B2 (en) | Method, system, and program for implementing a remote method call | |
| US20080140857A1 (en) | Service-oriented architecture and methods for direct invocation of services utilizing a service requestor invocation framework | |
| US20070174846A1 (en) | System and Method for Intercepting, Instrumenting and Characterizing Usage of an Application Programming Interface | |
| US7055147B2 (en) | Supporting interactions between different versions of software for accessing remote objects | |
| JPH1083308A (ja) | スタブ検索及びローディング・サブシステム、スタブ検索及びローディング方法並びにスタブ検索及びローディング用記録媒体 | |
| CN111510330B (zh) | 接口管理装置、方法及存储介质 | |
| US20020046304A1 (en) | Dynamic class loading | |
| US7043726B2 (en) | Binding of processes in network systems | |
| US7756969B1 (en) | Dynamic provisioning of identification services in a distributed system | |
| KR20020021237A (ko) | 임베디드 시스템의 통합 소프트웨어 개발 프레임워크를제공하는 실시간 미들웨어 장치 및 그 서비스 방법 | |
| JP4536292B2 (ja) | ネットワークシステム、サーバ、クライアント、オブジェクト間通信方法、プロファイルオブジェクト登録方法、プログラム、および記憶媒体 | |
| AU775624B2 (en) | Method and apparatus for dynamic command extensibility in an intelligent agent | |
| WO2017166166A1 (en) | System and method for providing runtime tracing for web-based client accessing transactional middleware platform using extension interface | |
| US20080245860A1 (en) | Method and System for Remote Card Access, Computer Program Product Therefor | |
| KR20040101537A (ko) | 기존의 시스템 관리 제품들 또는 소프트웨어 솔루션들과인터페이스하는 시스템 및 방법 | |
| US7770188B2 (en) | Winsock APIs | |
| US7870275B1 (en) | Communication scheme-independent infrastructure | |
| US20050165905A1 (en) | Device and method for changing instruction description, and storage medium storing program for changing instruction |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050830 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050927 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20051014 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20051209 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20051214 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060418 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20060710 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20060713 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061017 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20070220 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070521 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20070626 |
|
| A912 | Re-examination (zenchi) completed and case transferred to appeal board |
Free format text: JAPANESE INTERMEDIATE CODE: A912 Effective date: 20071130 |
|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20100412 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20100416 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100510 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20100616 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130625 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |