JP2020042809A - ウェブサービスとインターフェース記述言語（ｉｄｌ）ベースのリモートプロシージャコール（ｒｐｃ）サービスとの間をインターフェースするための技術及びそれを実施する光通信システム - Google Patents

Abstract

【課題】 ウェブサービスアプローチで、ＩＤＬベースのＲＰＣアーキテクチャをインターフェースする技術を提供する。【解決手段】 ウェブサービスプロトコルを介してクライアントアクセス可能な中央マネージャゲートウェイを含むＲＰＣアーキテクチャを含む。中央マネージャゲートウェイは、複数のネットワークエレメントと通信可能なサーバ直接対応側を含み、各ネットワークエレメントが共通のＩＤＬアーキテクチャ及びＲＰＣマネージャインスタンスを実施する。ＲＰＣマネージャインスタンスは、ネーミングサービスの公開を目的に、ネットワークトポロジーを「学習」し、他のＲＰＣマネージャインスタンスと通信してトポロジーデータベースを維持し、ネットワークエレメントはあるマスターエレメントを選択する。中央マネージャゲートウェイはクライアントリクエストを転送するためにマスターネットワークエレメントを自動的に突きとめる。【選択図】 図３

Description

本明細書は、概略として、リモートプロシージャコール（ＲＰＣ）インターフェースを利用する通信システムに関し、より具体的には、ウェブサービスとＩＤＬベースのＲＰＣサービスとの間をインターフェースするためのシステム及び方法並びにそれを用いる光通信システムに関する。

インターネット及びその関連技術の発展により、ウェブアプリケーション及びサービスは、ソフトウェア産業において益々大衆的かつ重要となっている。ウェブ技術の中でもＲｅｐｒｅｓｅｎｔａｔｉｖｅ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）は、最も普遍的かつ急成長している技術の１つとなっている。カスタマイズされたクライアント−エンドユーザインターフェースの開発及び統合を適応させるようにＲＥＳＴｆｕｌ ＡＰＩを提供するソフトウェアの必要性が増加している。現在では、ほとんどの開発言語が、ＲＥＳＴｆｕｌウェブサービスを構築するフレームワークを含む。

しかしながら、既存の多くの実施では、インターネットの初期段階中に開発された共通オブジェクト・リクエスト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）を利用する。ＣＯＲＢＡは、異なるプログラミング言語の利点を最大化して分散ネットワークエレメントサービス（ＮＥＳ）を管理するように多くのシステムがクロスプラットフォーム通信を採用するオブジェクトマネジメントグループによって定義されたソフトウェア標準である。例えば、Ｃ＋＋開発を考慮すると、ネイティブＣ＋＋開発環境はグラフィカルユーザインターフェース（ＧＵＩ）に対するネイティブサポートを有していないので、Ｃ＋＋はＧＵＩ開発のサポートに対して他の開発言語（例えば、ＪＡＶＡ）を必要とする。同様に、ＣＯＲＢＡは異なる実施（例えば、Ｃ、Ｃ＋＋、Ｊａｖａ、Ｐａｓｃａｌ、Ｐｙｔｈｏｎ、Ｒｕｂｙ）に対して提示されるインターフェース及びオブジェクトを調整するのにインターフェース定義言語（ＩＤＬ）を用い、それにより開発者は、「再度一から作り直す」必要がなくクロスプラットフォーム通信ソフトウェアを開発し、その延長として、そのようなソフトウェアシステムの開発に関連したコスト及び時間を節約する。ＣＯＲＢＡは、開発者から隠されている根底にあるクライアント−サーバ通信コードの多くでオブジェクトレベルにおいてアクセスがあるクロスプラットフォーム通信の明確に定義された形態を提供する。同様にして、ＣＯＲＢＡは、論理名を用いてオブジェクトの参照を登録及びルックアップする単純な形態を開発者に提供するネーミングサービスを特徴とする。

しかしながら、ＣＯＲＢＡは、軽微でない課題に起因して実行困難なソリューションを先送りしている。例えば、ＣＯＲＢＡアーキテクチャにおけるクライアント及びサーバの双方は、互換性を保証するようにランタイムにおいて同じＩＤＬを利用する必要がある。ＩＤＬ間の不整合は、結果としてクライアントとサーバの間の通信の完全な断絶をもたらすことになる。これは、公開された機能／方法に対するマイナーチェンジ及びアップグレードであっても、実行困難となり得るサーバとすべてのクライアントとの間の同期化を必要とするので、ＣＯＲＢＡの実施を相対的に脆弱にする。さらに、多数の既存のソリューションは、ＣＯＲＢＡ自体の知識だけでなくコアサービスへの変化の性質も必要とするある程度の独自ＣＯＲＢＡエレメントを利用する。この独自の知識は、広範囲に及ぶトレーニングを必要とし、残念なことに、それ以外の機能ソフトウェアの再利用ではなく、レガシーＣＯＲＢＡソフトウェアサービスの完全に一からの再開発を結果としてもたらしてしまう。

以下の図面と併せて読まれるべきである以下の詳細な説明に対して参照がなされるべきであり、同様の符号は同様の部分を表す。

図１は、ＣＯＲＢＡクライアント及びサーバについての通信アーキテクチャの簡略化したブロック図である。 図２は、本開示による光通信システムの例示的な一実施形態の簡略化したブロック図である。 図３は、図２の光通信システムでの使用に適したネットワーク管理システム（ＮＭＳ）の例示的な実施形態の簡略化したブロック図である。 図４は、図２の光通信システムで使用するためのリモートプロシージャコール（ＲＰＣ）アーキテクチャの例示的な実施形態の簡略化したブロック図である。 図５は、図４のＲＰＣアーキテクチャで使用するためのネットワークエレメントアドレスフォーマットの例を示す。 図６は、本開示の態様によるインターフェース記述言語（ＩＤＬ）継承モデルの簡略化したブロック図を示す。 図７は、本開示の実施形態によるＩＤＬベースのイベントメッセージについての通信の例を示す。 図８Ａは、本開示の実施形態による光通信システム内においてＲＰＣリクエストをサービスするための方法の例をまとめて示す。 図８Ｂは、本開示の実施形態による光通信システム内においてＲＰＣリクエストをサービスするための方法の例をまとめて示す。 図８Ｃは、本開示の実施形態による光通信システム内においてＲＰＣリクエストをサービスするための方法の例をまとめて示す。 図８Ｄは、本開示の実施形態による光通信システム内においてＲＰＣリクエストをサービスするための方法の例をまとめて示す。

上述のように、ＣＯＲＢＡベースの実施は配備された多数のソフトウェアアプリケーションで使用中であるが、本技術には、現在広く用いられているウェブベースの技術と比較して開発及び維持すべき課題が残っている。一方、ＣＯＲＢＡ及び現代のウェブベースの実施を融合させようとする試みに非常に多くの技術的課題が残っているので、既存のＣＯＲＢＡベースのシステムの機能コンポーネント及びレガシーサポートを保持する新たなソフトウェアシステムを作成する問題には課題が残っている。

既存のＣＯＲＢＡ開発プロセスは、プレーンテキストでＩＤＬを定義することを含む。ＩＤＬ言語は、他のコンパイラ型／インタープリタ型言語と同様に構文及び書式設定を含み、メソッド、引数及び種々のパラメータを定義する。そして、プレーンテキストのＩＤＬは、所望の言語、例えば、Ｃ＋＋又はＪａｖａにおけるアダプタを生成するようにコンパイルされる。生成されるアダプタはまた、所与のプログラムのランタイム（実行）中にインスタンス化可能なプリコンパイル済みＩＤＬアダプタともいわれることもある。そして、図１に示すように、ＣＯＲＢＡクライアント及びサーバアプリケーションは、それらの関連アダプタに基づいてクライアントとサーバの間に１：１の関係性を形成する。リクエストはクライアントとサーバの間で直接なされ、応答は、オブジェクトリクエストブローカの使用を通じてそれらのリクエストに基づいて返される。

残念ながら、ＣＯＲＢＡは、インターネットがその初期段階にあり、セキュリティが第一の関心事項でなかった時に開発された。ＣＯＲＢＡはセキュリティ方式を元々は実施せず、ＣＯＲＢＡインターフェースは実質的なセキュリティの危機をもたらす。ＣＯＲＢＡインターフェースのぞんざいな公開は、ＣＯＲＢＡはインターネット及び攻撃者にとって容易なターゲットにサーバを公開させたままとなるインターフェースレベルでのセキュリティチェックを有さないので、ソフトウェアシステム全体への潜在的な脅威である。

根本的なＩＤＬへのアップグレード及びマイナーチェンジはまた、ＣＯＲＢＡを用いることに対しても同様に大きな課題をもたらす。例えば、クライアント及びサーバは双方ともＩＤＬが整合しなくてはならず、そのため任意の変更は、同期化を目的としてクライアント及びサーバの双方のコードを更新されたＩＤＬで再コンパイルすることを余儀なくさせる。クライアント及びサーバのコードを扱う個別のチームは、完全なクライアント／サーバのＩＤＬ互換性を仮想的に不可能とするレートで変更を実施することができる多数の開発者を有することが多いので、このレベルの同期化は実行困難となってしまう。さらに、ソフトウェアエンジニアによる既存のＣＯＲＢＡ実施の再利用がセキュリティの危機として回避されることが多くても、ＣＯＲＢＡの古い知識及び厳格性は、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）及びＲＥＳＴなどの現代の技術を用いてコードを再開発する負の側面を凌ぎ得る。現代のウェブサービスを介してＣＯＲＢＡインターフェースを公開させるいくつかのアプローチ、例えば、ＲＥＳＴ、ＳＯＡＰが、ＣＯＲＢＡの再利用を可能とするように提案されている。ただし、これらのアプローチは、ミドルウェアとＣＯＲＢＡインターフェースの間の通信処理を開発しなくてはならないので、相当量の開発時間及び経験を未だに必要とする。

したがって、実施形態によると、ＳＯＡＰ及びＲＥＳＴなどのウェブサービスアプローチで、ＩＤＬベースのＲＰＣアーキテクチャ、例えば、ＣＯＲＢＡをインターフェースするための技術が開示される。特に、本開示の実施形態は、ＳＯＡＰ及びＲＥＳＴなどのウェブサービスプロトコルを介するクライアントアクセスを可能とするクライアント直接対応側を有する中央マネージャゲートウェイを含むＲＰＣアーキテクチャを含む。中央マネージャゲートウェイは、複数のネットワークエレメントと通信可能なサーバ直接対応側をさらに含み、各ネットワークエレメントが共通のＩＤＬアーキテクチャ及びＲＰＣマネージャインスタンスを実施する。ネットワークエレメントの各々、特に、それらのＲＰＣマネージャインスタンスは、ネーミングサービス、例えば、ＣＯＲＢＡネーミングサービスを公開させる目的で、システムのためのネットワークトポロジーを「学習」し、トポロジーデータベースを維持するように、他のＲＰＣマネージャインスタンスと通信し得る。ネットワークエレメントはあるマスターエレメントを選択し得るが、他はスレーブのままにする。中央マネージャゲートウェイは、マスターネットワークエレメントを自動的に突きとめ、クライアントリクエストをそこに転送し得る。同様に、マスターネットワークエレメントは、ウェブサービスリクエストを変換し、そのリクエストを満たすように１以上のＩＤＬ方法を実行し得る。そして、マスターネットワークエレメントは、実行されたＩＤＬ方法への応答をウェブサービスメッセージに変換し、それを、例えば、プロキシとして動作する中央マネージャゲートウェイによって発信元クライアントに戻し、又は所望の構成に依存してクライアントに直接戻して送信し得る。ＲＥＳＴはステートレスアーキテクチャを実施するので、ウェブサービスは、ＲＥＳＴ ＡＰＩコールにわたってデータメッセージの持続性をサポートしない。中央マネージャゲートウェイは、そのような持続性を管理及び促進するので、ＲＥＳＴウェブサービスメッセージもサポートしつつ、ＣＯＲＢＡインフラストラクチャ／サービスの整合性を維持することができる。

本開示の実施形態の１つの具体的で非限定的な例では、複数のＪａｖａアダプタの生成を可能とするＩＤＬフレームワークが開示される。Ｊａｖａアダプタの第１のアダプタは、コンパイル及び汎用ＣＯＲＢＡ通信を可能とするように、ＣＯＲＢＡベースのＣ＋＋システムに対して定義されたＩＤＬ定義を含み、Ｊａｖａアダプタの第２のアダプタは、ランタイムサービスを与える定義を含む。ランタイムサービスは、例えば、所与のアプリケーションに対して特定の論理を実施するようにアプリケーションプログラマーによってオーバーライドあるいは拡張され得るスタブ定義によって提供され得る。そして、ＲＥＳＴｆｕｌサービスは、ＩＤＬ要件、例えば、ＣＯＲＢＡに適合するＲＥＳＴサービスを提供し、また、アプリケーション特定論理をカスタマイズ及び統合する方法でエンドユーザに提供する複数のアダプタを実施し得る。ＩＤＬに基づくグラフィカルユーザインターフェース（ＧＵＩ）ライブラリはまた、クライアント側サービスを提供する目的のためにも生成され得る。ＧＵＩ、種々のアダプタ及び他の関連コンポーネントは、コードの再利用を最大化するようにクライアント及びサーバソフトウェアで再利用及びコンパイルされ得る（ただし、サーバは必ずしもＧＵＩを提示しない）。ＲＥＳＴサーバのコンテキストにおいては、複数のアダプタがパッケージ済みライブラリであってもよく、そこで定義及び実施される方法は、統合された開発環境がサポートする他の特徴とともに直接コール及びパッケージされ得る。

したがって、本開示は、ＩＤＬベースのサービスをぞんざいに公開させる既存のシステム、又はＣＯＲＢＡなどのＩＤＬベースのサービスを公開させる以前からの既存のアプリケーションを再設計及び開発することによってコードの再利用を阻害する他のアプローチを上回る多くの効果を提供する。例えば、ここで開示されるＲＰＣアーキテクチャで開発されたアプリケーションは、ハイレベルのカスタム化及びコードの再利用により迅速な開発及び拡張可能なフレームワークも提供しつつ、既存のＣＯＲＢＡサービスを利用し得る。さらに、ＳＯＡＰ及びＲＥＳＴなどの現代のサービスは、安全かつ容易に開発されるクライアントアクセスを提供するようにクライアント直接対応であり得る。そのため、ここで開示されるＲＰＣアーキテクチャは、（例えば、既存のＣＯＲＢＡサービスと完全な互換性を有する）レガシーコードアプリケーションを維持し、新たなクライアントアプリケーションを設計する従来の知識、向上した安全性 並びにＳＯＡＰ及びＲＥＳＴなどのウェブサービスアーキテクチャを有するＣＯＲＢＡなどのレガシーＲＰＣ技術を透過的にブリッジする能力の要件を除去することによって、コンピュータサービスシステムを向上させる。さらに、本開示によるＲＰＣアーキテクチャは、クライアントとＩＤＬベースのサービス、例えば、ＣＯＲＢＡとの間の１：Ｎ関係性を可能とし、これは図１に関して上記のようにクライアントとサーバの間の１：１関係性を通常与える制限を超越する。

図面では、図２は、本開示による光通信システム２００を示す。光通信システム２００は、説明の容易化のためであって限定ではなく非常に簡素な形態で示される。光通信システム２００は、海中光通信システムとして実施され得るものであり、要素の少なくとも一部は海面下に位置する。さらに、光通信システム２００は、複数のチャネル波長を介して送信可能な波長分割多重（ＷＤＭ）システムとして実施され得る。図示するように、光通信システム２００は、複数のケーブル地上局、すなわち、ケーブル地上局２０２−１、２０２−２及び２０２−３の間に延在する光伝送経路２０３を含む。

図示するように、光通信２００は、比較的大きな地理的な距離（例えば、数十、数百又は数千キロメートル）に及ぶ２１０としてまとめて示される光ファイバケーブルを含む。したがって、海底光ネットワークは、例えば、海底に沿って配設され、又は海上プラットフォームに配設される複数の「湿式」光コンポーネントを備え得る。ただし、ケーブルセグメントはこの件に関して必ずしも限定されることなく、光通信システム２００は、地上の光ファイバセグメントの少なくともある程度の長さを含み得る。ここで開示される例及びシナリオは、ケーブル地上局、すなわち、ＣＬＳを参照するが、開示はこの件に関して必ずしも限定されない。例えば、ここで開示される技術は、例えば、２〜３例を挙げると、ネットワークオペレーションセンター（ＮＯＣ）及びリモートオペレーションポジション（ＲＯＰ）を含む光通信システム内に位置する任意のステーションに同様に適用可能である。

続いて、光伝送経路２０３は、１以上の光ファイバ対を備える少なくとも１つの光ケーブル２１０を含む。光伝送経路２０３は、中継器２１８−１、２１８−２及び１以上の分岐ユニット、例えばＢＵ２２５を含む複数の光コンポーネントを含む。ＢＵは、分岐経路、例えば分岐経路２１４からチャネル波長を送信及び受信するために、再プログラム可能な光アド／ドロップマルチプレクサ（ＲＯＡＤＭ）又は（例えば、リモートモニタリング及び制御のための回路構成を含み得る）他の適切な光フィルタ／コンポーネントを含み得る。各ケーブル地上局は、種々の光コンポーネントへのアクセスを提供するために、及びシステム内のコマンド／応答エレメント（ＣＲＥ）へのインターフェースを提供するためにエレメント管理システム（ＥＭＳ）を含み得る。図２に示す光コンポーネントの各々はまた、ネットワークエレメントとも呼ばれ、各ネットワークエレメントは構成、モニタリング及びメンテナンスの目的でリモートアクセスを可能とする。この目的のため、用語のネットワークエレメントは、有線又は無線接続を通じてリモートネットワークベースの通信を可能とする回路構成及び／又はソフトウェアを含む光通信システム２００における任意のコンポーネント、例えば、ＢＵ、ＲＯＡＤＭ、光中継器、ＮＭＳ、ＥＭＳ、ＬＭＥ、ＰＦＥを参照する。

ケーブル地上局２０２−１〜２０２−３の各々は、海岸に沿って又はプラットフォームに配設され得る。ケーブル地上局２０２−１〜２０２−３の各々は、チャネル回線カード（図示せず）、給電装置（ＰＦＥ）２１２−１などのような回線終端装置（ＬＴＥ）を含み得る。ＰＦＥ２１２−１は、光伝送経路２０３に沿って定電圧又は定電流を供給するように構成され得る。

さらに図示するように、第１のケーブル地上局２０２−１は、ＮＭＳ２０４−１、ＥＭＳ２０６−１及びＬＭＥ２０８−１を含む。ＮＭＳ２０４−１は、図３を参照してさらに詳述するＮＭＳ３０４として実施され得る。各ＮＭＳは、Ｎ個のＥＭＳシステムと通信するように構成され得る。ＥＭＳシステムの各々は、所与のケーブル地上局に対してローカルに、あるいは隣接する中継器及び他の要素などの光コンポーネントと通信するように構成され得る。ＬＭＥ装置は、光伝送経路２０３に沿って名目上の性能を保証し、欠陥、例えば、ケーブル破損を検出するように、高損失ループバック（ＨＬＬＢ）又は他の測定を実行するのに利用され得る。

選択的に、２以上のケーブル地上局は、冗長性及び耐障害性のために、並びにネットワークエレメントのローカルな管理のために同様のコンポーネントを含み得る。例えば、第２のケーブル地上局２０２−２は、ＮＭＳ２０４−２、ＥＭＳ２０６−２及びＬＭＥ２０８−２を含み得る。さらに以下で説明するように、ＮＭＳコンポーネント２０４−１、２０４−２の各々は、単一のＮＭＳシステム３０４をまとめて形成してもよく、それによってユーザは、例えば、グラフィカルユーザインターフェース（ＧＵＩ）を直接介して、又はＡＰＩを介して、いずれのＮＭＳコンポーネントにもログインし、リクエストをサービスさせることができる。この例において、ＮＭＳコンポーネントの１つはマスターとして動作してもよく、それによってスレーブＮＭＳシステムは、ハンドリングのためにリクエストをプロキシし、あるいはマスターに転送する。マスターＮＭＳがオフラインになるイベントでは、光通信システム２００は、スレーブＮＭＳをマスターの役割に自動的に切り替えるように構成され得る。

図３は、本開示によるネットワーク管理システム（ＮＭＳ）アーキテクチャ３０４の例を示す。ＮＭＳアーキテクチャ３０４は、明瞭化のためであって限定ではなく非常に簡素な形態で示される。ＮＭＳアーキテクチャ３０４は、ＮＭＳアーキテクチャ３０４をまとめて提供するように、例えば、複数のＮＭＳサーバ、ＥＭＳサーバ、ＬＭＥなどを含む異なる構成で実施され得る。このように、コンポーネントは、冗長性、耐障害性を提供し、ＮＭＳアーキテクチャ２００のユーザに対して複数のアクセスポイントを提供するように、複数のケーブル地上局、例えば、図２のＣＬＳ２０２−１・・ＣＬＳ２０２−３に分散され得る。したがって、ＮＭＳ２０４は、単一のＮＭＳサーバ、例えばＮＭＳ２０４−１としてまとめて実施されてもよいし、図２に示すように複数のＮＭＳシステム、例えば、ＮＭＳ２０４−１、２０４−２を備えてもよい。

さらに図示するように、ＮＭＳ３０４は、コントローラ３０５、メモリ３０７、システムリソースデータベース３１２、セキュリティマネージャ３２０及びユーザインターフェース３２４を含む複数の関連するコンポーネントを含む。ＮＭＳ３０４は、ハードウェア（例えば、回路構成）、ソフトウェア、パブリック／プライベートクラウド又はそれらの組合せにおいて実施され得る。実施形態では、ＮＭＳ３０４は、ＮＭＳ処理、例えば、図８Ａ〜８Ｄの処理８００を実行するように、（ＮＭＳコントローラともいわれることがある）コントローラ３０５によって実行され得る、メモリ３０７に記憶された複数の非一時的命令として少なくともある程度実施され得る。ここで一般的にいうコントローラは、プロセッサ（例えば、×８６プロセス又は仮想コンピュータ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）又は他の任意の適切な処理デバイス／回路構成として実施され得る。

ユーザインターフェース３２４は、ユーザ、例えばユーザ４２９（図４）からのリクエストを受信及び処理するグラフィカルユーザインターフェース（ＧＵＩ）コンポーネント及び／又はＡＰＩコンポーネントを備え得る。実施形態では、ユーザインターフェースのＡＰＩは、ＲＥＳＴアーキテクチャを実施し得る。他の実施形態では、ユーザインターフェース３２４のＡＰＩは、ＣＯＲＢＡアーキテクチャを実施し得る。セキュリティマネージャ３２０は、ユーザから受信されたリクエスト３０１がユーザの関連する特権及びアクセス権限に基づいて許容可能となることを保証するように構成され得る。

ＮＭＳ２０４は、メモリ３０７に記憶されたシステムリソースデータベース３１２を含み得る。システムリソースデータベース３１２は、例えば、複数のＮＭＳ及びＥＭＳを含む複数のコンポーネントに分散されてもよく、図３に示す実施形態は限定を意図していない。例えば、各ケーブル地上局は、例えば、回線カード、ＰＦＥ、中継器、ＬＭＥ、イコライザ、コンピュータサーバ及び分岐ユニットを含む（ネットワークエレメントとも呼ばれ得る）各関連する光コンポーネントを示すデータを記憶するＥＭＳを含み得る。そして、ＮＭＳ２０３は、システムリソーステーブル３１２を集合的及び論理的に形成するようにケーブル地上局の各々からのＥＭＳデータを利用してもよく、ただし、データは異なるケーブル地上局に物理的に分散され得る。システムリソースデータベース３１２は、構造化照会言語（ＳＱＬ）データベース、フラットファイル（例えば、固有のユニバーサルマークアップ言語（ＸＭＬ））、インメモリデータ構造体又はそれらの任意の組合せを含み得る。

図４は、本開示の実施形態によるリモートプロシージャコール（ＲＰＣ）のためのアーキテクチャ４００の一例を説明するブロック図を示す。図示するように、クライアント側は、中央マネージャゲートウェイ４０１と通信するようにクライアント４０７を利用することができるユーザ４２９を含む。クライアント４０７は、ラップトップ、デスクトップコンピュータ、サーバコンピュータ、又はコントローラ／プロセッサと、メモリと、ユーザインターフェースなどとを有するスマートフォンのようなリモートコンピューティングデバイスを備え得る。中央マネージャゲートウェイ４０１はまた、ＲＰＣゲートウェイ４０１といわれることもある。なお、中央マネージャゲートウェイ４０１は、ネットワークエレメントの１つのネットワークエレメント４０６−１によって、又は光通信システム２００の異なるサーバコンピュータによってインスタンス化され得る。クライアント４０７は、ＲＥＳＴクライアント、又はＳＯＡＰなどの他の適切なクライアントアプローチを備え得る。クライアント４０７は、通信サービス及び動的変更のランタイムインスタンス化を可能とするウェブサービスオブジェクトライブラリ、例えばＲＥＳＴフレームワークを利用し得る。ＩＤＬベースのプロトコルとは対照的に、ウェブサービスは、クライアント−サーバの互換性を破壊することなくプロトコルレベルで変更がなされることを可能とする。したがって、ウェブサービスオブジェクトライブラリは、例えば、Ｃ、Ｃ＋＋、Ｊａｖａ、Ｒｕｂｙ、Ｃ＃、ＶＢ．ＮＥＴ、Ｌｕａ、Ｐｙｔｈｏｎ又は他の任意の適切なプログラミング言語などの任意数のプログラミング言語で開発され得る。

サーバ側コンポーネントのコンテキストにおいて、ＲＰＣアーキテクチャ４００は、マスターネットワークエレメントによって実施され得る中央マネージャゲートウェイ４０１及びリモートプロシージャコール（ＲＰＣ）マネージャ４０５を含む。図示するように、ネットワークエレメント４０６−１〜４０６−Ｎの各々は、ＲＰＣマネージャ４０５のインスタンスを実行する回路構成及び／又はソフトウェアを含み得る。ＲＰＣマネージャ４０５をインスタンス化するそれらのネットワークエレメントはまた、ネットワークエレメントマネージャともいわれることがある。ネットワークエレメント４０６−１〜４０６−Ｎの各々は、図３を参照して上述したＮＭＳサーバ３０４などのＮＭＳサーバとして実施され得る。ただし、各ネットワークエレメント４０６−１〜４０６−Ｎは、ラックマウント式コンピュータサーバを含む他のタイプのシステムとして実施されてもよい。いずれにしても、各ネットワークエレメント４０６−１〜４０６−Ｎは、関連するプロセッサ／コントローラによって実行された場合に、ＲＰＣマネージャ処理のローカルインスタンスを実行させる複数の命令を含み得る。ネットワークエレメントは、相互に通信し、例えば、投票を介して、又は単にいずれかのネットワークエレメントがまずオンラインになることによってマスターを選択することにより、「マスター」エレメントを選別し得る。図４に示すように、ネットワークエレメント４０６−１は、マスターエレメントであるため、中央マネージャゲートウェイ４０１によってクライアント４０７にアクセス可能なＲＰＣマネージャ４０５をホストする。

ＲＰＣマネージャ４０５の各インスタンスは、プロトコル非依存インターフェース４０９及びリクエストブローカ４１１を含む複数のコンポーネントを含み得る。プロトコル非依存インターフェース４０９は、ＲＥＳＴ又は他の所望のプロトコルを介してリクエストをサービスするためにＮ個のパーサモジュールを含み得る。パーサモジュールは、リクエストの解析を可能として、リクエストが有効である（例えば、不正な形式でない）場合に、（例えば、セキュリティマネージャ３２０を用いることによって）リクエストが認められるかを判定し、リクエストの要求が何であるかを判定する。リクエストブローカ４１１は、汎用中央マネージャＩＤＬパーサを含んでもよく、それは図６を参照して以下でより詳細に説明される。例えば、ＩＤＬパーサは、アダプタとしても知られておりＣＯＲＢＡ ＩＤＬから出力されるプリコンパイル済みＩＤＬを利用し得る。この例では、リクエストブローカ４１１は、ＣＯＲＢＡネーミングサービス４１４を提供し得る。ＣＯＲＢＡネーミングサービス４１４は、他のＣＯＲＢＡサーバアプリケーションが論理名を用いるオブジェクトの参照を公表することを可能とする。したがって、クライアント４０７は、ＲＰＣマネージャ４０５にネーミングサービス４１４を介して名称をルックアップすることを要求することによって、ローカルの論理名により実行される動作をリクエストし得る。

例えば、図５に示すように、ネットワークエレメントＢ４０６−２及びネットワークエレメントＣ４０６−３は、ネットワークエレメントアドレス５０１に基づいて光通信システム２００内で一意的に特定され得る。ネットワークエレメントアドレス５０１は、各ケーブル地上局が複数の関連するネットワークエレメントを有することを可能とする方式に従う文字列を含み得る。ただし、他のネーミング方式が利用されてもよく、図５に示す例は限定を意図するものではない。各ネットワークエレメントアドレスは、ケーブルステーション内のネットワークエレメント及びサブコンポーネントの階層を伝達する所定の一連のエンティティタイプ／エンティティＩＤ対を含むことができ、各エンティティを一意的に特定する。例えば、デュアルＴＬＡネットワークエレメントは、「Ｃａｂｌｅ．１／ＦＰ．１／ＤＴＬＡ．１．」などのそのケーブル及びファイバ対スコープのもとで一意的に特定される。

図５にさらに示すように、ネットワークエレメントアドレス５０１は、ケーブル地上局識別子５０２、ファイバ対識別子５０３、エレメントタイプＩＤ５０４及びエレメントＩＤ５０５のうちの少なくとも１以上を特定し得る。その上、ネットワークエレメントアドレスは、サブコンポーネントＩＤ、例えばサブコンポーネントＩＤ５０６を含み得る。したがって、各ネットワークエレメントは、ネーミングサービス４１４に登録され得るネットワークエレメントアドレスを割り当てられ得る。なお、マスターネットワークエレメント、例えば、図４に示すネットワークエレメントＡ４０６−１が、リクエストをサービスする目的で名称ルックアップを実行している間でも、他のネットワークエレメント、例えば、ネットワークエレメントＡ４０６−２〜４０６−Ｎはまた、新たなマスターネットワークエレメントが（例えば、欠陥、ケーブル破損、停電などに起因して）選択されるイベントにおいて、それらのローカル名称サービスを更新及び同期化する登録も受信し得る。

図４では、ＲＰＣマネージャ４０５の各インスタンスは、光通信システム２００内の他のネットワークエレメントから登録メッセージを受信することができる。登録データは、ネーミングサービス４１４による使用のためにトポロジーテーブル４１２に記憶され得る。登録データは、ＩＰアドレス（ＩＰｖ４、ＩＰｖ６など）、ホスト名、デバイスタイプ及び他のネットワークエレメントの特徴を含むことができる。ある場合には、各ネットワークエレメントに対するトポロジーテーブル４１２が、関連するシステムリソースデータベース３１２に記憶され得る（図３）。実施形態では、トポロジーテーブル４１２は、各ネットワークエレメント及びそのサブコンポーネントの階層的オブジェクトモデルを定義し、各コンポーネントは、属性を有するエンティティ及びサブコンポーネントを示す子エンティティとして提示される。そして、各エンティティは、そのネットワークエレメントアドレスによって一意的に特定されてもよく、図５に関して上述したような「Ａ．ＦＰ１．ＤＴＬＡ１」などのユーザフレンドリな名称を提供するようにフルネーム属性を含むことができる。ＲＰＣマネージャ４０５の各インスタンスは、トポロジースナップショットを回収する包括的ＩＤＬ ｇｅｔＴｏｐｏｌｏｇｙ（）の方法をサポート可能である。トポロジー変更イベント、例えばＣＯＲＢＡイベントは、属性値が各ネットワークエレメント／エンティティから変化すると送信可能となり、それにより各ＲＰＣマネージャ４０５は同期化されたトポロジーデータモデルを維持することができる（図７参照）。

動作において、クライアント４０７は、リクエストメッセージ４０８を送信する。リクエストメッセージ４０８は、例えば、ＳＯＡＰ又はＲＥＳＴなどのウェブサービスプロトコルにおいてフォーマット化され得る。したがって、リクエストメッセージ４０８は、情報スキーマがメッセージ自体から派生され得る自己記述フォーマットを有するように正確に記述され得る。例えば、ＪＳＯＮは、比較的容易な解析及びメッセージ適応性を可能とするこの形式で自己記述する。これに対して、ＣＯＲＢＡなどのＩＤＬベースの方式は、ＩＤＬにメッセージの方式を理解することを要求する。リクエストメッセージ４０８は、少なくとも１つのネットワークエレメント及び実行する動作を特定し得る。ネットワークエレメントは、ネットワークエレメントアドレス、例えば、図５に示すネットワークエレメントアドレス５０１によって特定され得る。動作は、構成パラメータ、ログデータ、アップタイム、ステータスなどのような所望のネットワークエレメントに対してリクエストされた属性／データを得るＧＥＴ動作を含み得る。動作は、特定の属性／データを変更するためのＳＥＴ動作をさらに含み得る。

中央マネージャゲートウェイ４０１は、リクエストメッセージ４０８を受信し得る。そして、中央マネージャゲートウェイ４０１は、リクエストを処理するのに現在のマスターネットワークエレメントを判定し得る。例えば、図４に示すように、ネットワークエレメントＡ４０６−１は、マスターネットワークエレメントとして動作している。したがって、中央マネージャゲートウェイ４０１は、ネットワークエレメントＡ４０６−１を突きとめ、それにリクエストメッセージ４０８を転送する。そして、ネットワークエレメントＡ４０６−１は、リクエストメッセージ４０８を受信してそれを処理する。

ネットワークエレメントＡ４０６−１、より具体的にはＲＰＣマネージャ４０５は、例えば、ＨＴＴＰパーサモジュールを用いてリクエストメッセージ４０８を解析して、ネットワークエレメントアドレス及び所望の動作を抽出するのにプロトコル非依存インターフェース４０９を利用し得る。ネットワークエレメントＡ４０６−１は、リクエストされたネットワークエレメントが存在するとの判定と、さらにＲＥＳＴインターフェースのステートレス属性を保持している間に必要となる任意の持続性の管理との前又は後に、（例えば、セキュリティマネージャ３２０を用いて）リクエストされた動作を許可するかを判定する認証を実行し得る。ＲＰＣマネージャ４０５は、抽出されたネットワークエレメントアドレスがシステムにおいて既知であるかを判定するのにトポロジーテーブル４１２に問い合わせることができる。ネットワークエレメントアドレスが既知でないイベントでは、ＲＰＣマネージャ４０５は、ＮＡＫメッセージ、例えば、ＨＴＴＰ ＮＯＴ＿ＦＯＵＮＤなどのＨＴＴＰエラーコードを送信し得る（４０４）。ネットワークエレメントがトポロジーテーブル４１２において見付けられた（及びリクエストが許可された）場合には、ＲＰＣマネージャ４０５は、リクエストメッセージ４０８の動作がトポロジーテーブル４１２に記憶された情報／属性などのローカルデータを介して実行され得るかを判定する。例えば、ステータス及びアップタイムなどのいくつかのリクエストが、ＣＯＲＢＡメッセージングを用いるリモートネットワークエレメントと必ずしも通信することなくサービスされ得る。そのようなある例は、ネットワークエレメント（例えば、ＬＭＥ）のもとでサブコンポーネント（例えば、ＬＭＥポート、ＬＭＥスイッチ位置）のリストを入手すること、並びに動作状態、故障ＬＥＤ状態、及び／又は（例えば、回路パックモデル及び物理的位置などを含む）在庫情報などのネットワークエレメントの属性及びサブコンポーネントの属性を回収することを含む。

リクエストされた動作がローカルデータを用いて実行不可能なイベントでは、ＲＰＣマネージャ４０５は、リクエストブローカ４１１を利用して抽出されたネットワークエレメントアドレスに関連したネットワークエレメントと通信することができる。この通信は、例えば、ＣＯＲＢＡプロトコルに適合するメッセージ４２２を送信するＩＤＬベースのメッセージング方式を用いることを含み得る。例えば、リクエストブローカ４１１は、システムにおいてネットワークエレメントの各々に関連したプリコンパイル済みＩＤＬインスタンス（又はアダプタ）を有し得る。したがって、リクエストブローカ４１１は、ターゲットのネットワークエレメントと互換性を有するＩＤＬでクライアントをインスタンス化するようにＩＤＬストア４１３からプリコンパイル済みＩＤＬを回収し得る。上述したように、クライアントのＩＤＬは、ＣＯＲＢＡベースのクライアント−サーバ通信においてサーバのＩＤＬと整合しなくてはならない。そのため、ＩＤＬストア４１３は、プリコンパイル済みＩＤＬアダプタのライブラリを含んでもよく、各プリコンパイル済みＩＤＬアダプタは１以上のネットワークエレメントに対応する。そして、リクエストブローカ４１１は、抽出されたネットワークエレメントアドレス及びリクエストされた動作に少なくともある程度基づいてリクエストメッセージ４０８を同等のＩＤＬベースのメッセージに変換し得る。そしてさらに、リクエストブローカ４１１は、抽出されたネットワークエレメントアドレスに関連したネットワークエレメントに対応するＩＤＬを用いて実行する１以上のリモートプロシージャコールを特定し得る。例えば、リクエストされた動作は特定の構成設定を回収するものであってもよく、ＩＤＬは、リクエストされた動作を満たすのに利用され得るリモートプロシージャコールＧＥＴ＿ＰＡＲＡＭＥＴＥＲ（）を定義し得る。そして、リクエストブローカ４１１は、ネットワークエレメントアドレスに関連したネットワークエレメントにメッセージ４２２を送信し得る。

シナリオの一例では、リクエストブローカ４１１は、リクエストメッセージ４０８を満たすために、１以上のプリコンパイル済みＩＤＬアダプタを用いて実行する２以上のリモートプロシージャコールを特定し得る。例えば、あるリクエストは、ログデータ、ステータスなどについてのリクエストのような２以上のネットワークエレメントと通信することを必要とし得る。他の例では、あるリクエストは、ネットワークエレメント上で２以上の異なるリモートプロシージャコールをコールすることを必要とし得る。例えば、エラーカウント、パワーレベル及び再送信カウントなどの複数の測定値についてのリクエストは、ユーザ４２９からＲＰＣマネージャ４０５によって受信されるある１つのリクエストを満たすようにメッセージング４２２を用いて複数のリモートプロシージャコールをコールすることを必要とし得る。したがって、ある１つのリクエストメッセージ４０８は、２以上のネットワークエレメントの１以上のリモートプロシージャコールをコール／実行することによって、２以上のネットワークエレメントとのメッセージ４２２の通信をもたらし得る。

したがって、本開示によるＲＰＣアーキテクチャ４００は、クライアント４０７と、複数のＩＤＬベースのサーバインスタンス、すなわち、ネットワークエレメント４０６−１〜４０６−Ｎとの間の１：Ｎの関係性を可能とする。ＣＯＲＢＡのコンテキストにおいて、そのような１：Ｎの関係性は、ＣＯＲＢＡが１：１の直接的クライアント−サーバ通信フローに限定されるので（上述の図１参照）、アーキテクチャの制限を超越する。

図６は、本開示の態様によるＩＤＬ継承モデル６００の一例を示す。図示するように、ＩＤＬ継承モデル６００は、汎用中央マネージャベースＩＤＬ６０１、ウェブサービス６０２（例えば、ＲＥＳＴサーバ）、ＲＰＣマネージャベースＩＤＬ６０３、ＲＰＣマネージャＡ ＩＤＬ６０４及びＲＰＣマネージャＢ ＩＤＬ６０５を含む。汎用中央マネージャＩＤＬ６０１は、すべてのサーバコンポーネントに共通のインターフェースを定義する。ウェブサービス６０２は、ユーザリクエスト、例えば、ＲＥＳＴリクエスト、ＳＯＡＰリクエストをハンドリングするようにＲＰＣマネージャ４０６（図４）によってインスタンス化されてもよく、図４に関して上述したように、リクエストを同等のリモートプロシージャコールに変換する目的で汎用中央マネージャベースＩＤＬを実施することができる。

同様にして、ＲＰＣマネージャベースＩＤＬ６０３は、例えば、ステータス情報、動作パラメータ、診断情報を取得するリモートプロシージャコールなどの各ネットワークエレメントに共通のインターフェースを定義し得る。ＲＰＣマネージャＡ ＩＤＬ６０４及びＲＰＣマネージャＢ ＩＤＬ６０５は、１以上のタイプのネットワークエレメントに特定のインターフェースをさらに定義し得る。例えば、ＲＰＣマネージャＡ ＩＤＬ６０４は回線モニタリング装置（ＬＭＥ）に特定のインターフェースを定義し、ＲＰＣマネージャＢ ＩＤＬ６０５は光中継デバイスに特定のインターフェースを定義し得る。したがって、ネットワークエレメント、例えば、ネットワークエレメント４０６−１〜４０６−３は、リクエストをサービスするのに適切なインターフェースが確実に利用可能となるように、それらのデバイスのタイプに特定のＩＤＬを導出し得る。他の例では、ＲＰＣマネージャＡ ＩＤＬ６０４及びＲＰＣマネージャＢ ＩＤＬ６０５は、ユーザが各所定のプレースホルダ機能に関連した論理をカスタマイズできるように、ランタイムで動的に設定し得る「スタブ」又はプレースホルダ機能を定義し得る。したがって、各クライアント／サーバインスタンスは、２以上のプリコンパイル済みＩＤＬアダプタ、すなわち少なくとも、例えば、ＣＯＲＢＡを介して通信する共通／デフォルトの方法及び機能を定義する第１のＩＤＬアダプタ、並びに公開されたＲＰＣ動作のランタイムカスタマイズ化を可能とするスタブ／プレースホルダ機能を有する第２のＩＤＬアダプタをロードすることができる。

図７は、本開示の実施形態によるイベント通信フローの例を示す。図示するように、ネットワークエレメントＢ４０６−２は、ＩＤＬベースのイベントメッセージ７０２を送信する。例えば、ＩＤＬベースのイベントメッセージ７０２は、ＣＯＲＢＡプロトコルに適合し得る。ネットワークエレメントＡ４０６−１は、ＲＰＣ管理目的のためのマスターとして動作して、ＩＤＬベースのイベントメッセージ７０２を受信する。ネットワークエレメントＡ４０６−１は、ＲＰＣマネージャ４０５をインスタンス化することによって、ＩＤＬベースのイベント７０２をウェブサービスメッセージ７０３に変換する。ウェブサービスメッセージ７０３は、ネットワークエレメントアドレス及びイベントタイプの識別子を少なくとも含む。そして、ネットワークエレメントＡ４０６−１は、ウェブサービスメッセージ７０３をクライアント４０７に送信する。

図８Ａ〜８Ｄは、上記の態様及び実施形態を具現化するＲＰＣアーキテクチャによってリクエストをサービスするための処理８００の一例をまとめて提供する。処理８００は、ＲＰＣマネージャ又は中央マネージャゲートウェイインスタンスとして動作する場合に、ＮＭＳ３０４のコントローラ３０５（図３）によって実行され得る複数の機械可読命令として明示し得る。

動作８０２では、中央マネージャゲートウェイ４０１のサーバは、クライアント、例えば、クライアント４０７からのウェブサービスのリクエストを受信する（図４）。ウェブサービスのリクエストは、例えば、ＲＥＳＴ又はＳＯＡＰに適合するフォーマットであり得る。ウェブサービスのリクエストは、１以上のターゲットのネットワークエレメントアドレス、及びターゲットのネットワークエレメント上で実行する動作の識別子を含み得る。動作８０４では、中央マネージャゲートウェイ４０１は、ネットワークエレメントのいずれがマスターとして動作しているかを特定する。マスターネットワークエレメントが存在しないイベントにおいて、動作８０８では、中央マネージャゲートウェイ４０１は、否定応答（ＮＡＫ）メッセージ、例えば、ＨＴＴＰエラーコードを送信する。ＮＡＫメッセージは、動作８０２において受信されるリクエスト、例えば、ＲＥＳＴ、ＪＳＯＮなどと同じフォーマットで送信され得る。一方、動作８０６では、中央マネージャゲートウェイ４０１は、ウェブサービスのリクエストをマスターＲＰＣマネージャ、例えば、図４に示すようにネットワークエレメントＡ４０６−１に転送／送信する。

動作８１０では、マスターＲＰＣマネージャが、転送されたウェブサービスのリクエストを受信する。動作８１２では、マスターＲＰＣマネージャは、例えば、ＨＴＴＰパーサモジュールを用いて、受信されたウェブサービスのリクエストからターゲットのネットワークエレメントアドレス及び動作を抽出する。ネットワークエレメントアドレスのフォーマットは、図５に関して図示及び上述したフォーマットに適合し得る。動作８１４では、マスターＲＰＣマネージャは、抽出されたターゲットのネットワークエレメントアドレスに関連したネットワークエレメントが存在するかを判定する。これは、例えば、抽出されたターゲットのネットワークエレメントアドレスが既知であるかを判定するのにトポロジーテーブル４１２に問い合わせることを含み得る。ターゲットのネットワークエレメントアドレスが存在する場合には、処理は動作８１８へ続き、そうでなければ、処理は動作８１６へ続いて、マスターＲＰＣマネージャがＮＡＫメッセージをクライアントに送信し戻す。ＮＡＫメッセージは、動作８０２において受信されたリクエストと同じフォーマットで送信され得る。

動作８１８では、マスターＲＰＣマネージャは、リクエストをサービスするのにローカルデータが利用され得るかを判定する。上記のように、アップタイム、ステータスなどのようないくつかの情報は、トポロジーテーブル４１２、あるいはメモリ３０７に記憶され得る。したがって、ローカルデータに記憶された属性／特徴は、リクエストをサービスするのに利用され得る。ローカルデータがリクエストを満たす場合には、マスターＲＰＣマネージャは、ローカルデータから情報を回収し、応答メッセージを生成する。動作８２２では、マスターＲＰＣマネージャは、動作８０２において受信されたリクエストを同じフォーマット、例えば、ＪＳＯＮ、ＸＭＬ又は他のＲＥＳＴ／ＳＯＡＰ互換フォーマットで、生成された応答メッセージをクライアントに送信する。

動作８２４では、マスターＲＰＣマネージャは、抽出されたターゲットのネットワークエレメントアドレスに関連したターゲットのネットワークエレメントに対応するプリコンパイル済みＩＤＬアダプタ（又は単にアダプタ）を選択及びインスタンス化し得る。動作８２４は、ＲＰＣマネージャがターゲットのネットワークエレメントと通信できるようになるＩＤＬを特定するように、ＩＤＬストア４１３上でルックアップを問合わせ／実行するマスターＲＰＣマネージャを含み得る。図６に関して上記のように、複数のネットワークエレメントは、同じＲＰＣマネージャのＩＤＬに関連付けられ得る。したがって、ＲＰＣマネージャは、既知のタイプのターゲットのネットワークエレメントに基づいて、プリコンパイル済みＩＤＬアダプタを単に回収し得る。代替的に又はさらに、ＩＤＬストア４１３は、例えば１：１の関係性で、各ネットワークエレメントを特定のプリコンパイル済みＩＤＬアダプタに関連付け得る。そのため、マスターＲＰＣマネージャは、ＩＤＬストア４１３においてターゲットのネットワークエレメントとその対応するＩＤＬとの間の関連に基づいて用いるプリコンパイル済みＩＤＬアダプタを決定し得る。

いずれのイベントにおいても、動作８２６に続いて、マスターＲＰＣマネージャは、動作８２４においてインスタンス化／選択されたプリコンパイル済みＩＤＬアダプタに基づいて、ターゲットのネットワークエレメント上でコールする１以上のリモートプロシージャコール、例えば機能／方法を特定することができる。動作８２８では、マスターＲＰＣマネージャは、ターゲットのネットワークエレメントに対して特定された１以上のリモートプロシージャコールを実行する。動作８３０では、マスターＲＰＣマネージャは、実行されたリモートプロシージャコールからの応答を受信し、動作８０２においてクライアントから受信されたリクエストの同じフォーマット、例えばＸＭＬ／ＪＳＯＮで、応答に基づいて応答メッセージを生成する。動作８３２では、マスターＲＰＣマネージャは、例えば、中央マネージャゲートウェイ４０１を通じて生成された応答メッセージをルーティングすること、又は生成された応答メッセージをクライアントに直接送信することによって、生成された応答メッセージをクライアントに送信する。

本開示の態様によると、ネットワーク管理システムが開示される。ネットワーク管理システムは、メモリと、コントローラであって、リモートコンピューティングデバイスからユーザリクエストを受信し、ユーザリクエストは少なくとも１つのネットワークエレメントアドレス及び少なくとも１つのネットワークエレメントアドレス上で実行する動作の識別子を含み、少なくとも１つのネットワークエレメントアドレス及び少なくとも１つのネットワークエレメントアドレス上で実行する動作の識別子を抽出し、少なくとも１つのネットワークエレメントアドレスに関連したプリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタをメモリから選択し、選択されたプリコンパイル済みＩＤＬアダプタに基づいてユーザリクエストを満たす少なくとも１つのリモートプロシージャコール（ＲＰＣ）機能を選択し、少なくとも１つのネットワークエレメントアドレスに関連した１以上のネットワークエレメントに少なくとも１つのＩＤＬベースのメッセージを送信することによって少なくとも１つのＲＰＣ機能を実行し、実行された少なくとも１つのＲＰＣ機能からの応答に基づいてリモートコンピューティングデバイスに応答メッセージを送信するコントローラとを備え、応答メッセージはユーザリクエストと同じフォーマットである。

本開示の他の態様によると、リモートプロシージャコールリクエストをサービスするためのコンピュータ実施方法が開示される。コンピュータ実施方法は、コントローラによって、リモートコンピューティングデバイスからユーザリクエストを受信する動作であって、ユーザリクエストは少なくとも１つのネットワークエレメントアドレス及び少なくとも１つのネットワークエレメントアドレス上で実行する動作の識別子を含む自己記述メッセージを含む動作と、コントローラによって、少なくとも１つのネットワークエレメントアドレス及び少なくとも１つのネットワークエレメントアドレス上で実行する動作の識別子を抽出する動作と、コントローラによって、少なくとも１つのネットワークエレメントアドレスに関連したプリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタをメモリから選択する動作と、コントローラによって、選択されたプリコンパイル済みＩＤＬアダプタに基づいてユーザリクエストを満たす少なくとも１つのリモートプロシージャコール（ＲＰＣ）機能を選択する動作と、コントローラによって、少なくとも１つのネットワークエレメントアドレスに関連した１以上のネットワークエレメントに少なくとも１つのＩＤＬベースのメッセージを送信することによって少なくとも１つのＲＰＣ機能を実行する動作と、コントローラによって、実行される少なくとも１つのＲＰＣ機能からの応答に基づいてリモートコンピューティングデバイスに応答メッセージを送信する動作とを含み、応答メッセージはユーザリクエストと同じフォーマットである。

本開示のさらに他の態様によると、光通信システムが開示される。光通信システムは、複数のケーブル地上局の間に延在する光通信経路を備え、複数のケーブル地上局の各々は、光通信経路に沿って配設された複数のネットワークエレメントの１以上のネットワークエレメントに関連付けられており、システムは、ＲＰＣゲートウェイサーバを備え、ＲＰＣゲートウェイサーバはユーザリクエストを受信し、ユーザリクエストは、動作の識別子、及び動作を実行し、マスターネットワークエレメントとして動作するネットワークエレメントを特定し、特定されたマスターネットワークエレメントに第１のメッセージを送信する少なくとも１つのネットワークエレメントの識別子を含む自己記述メッセージを含み、第１のメッセージは、マスターネットワークエレメントに、少なくとも１つのネットワークエレメントの識別子に関連したネットワークエレメントに対応するプリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタを選択させ、マスターネットワークエレメントに、選択されたＩＤＬアダプタ及び動作に基づいてネットワークエレメントに少なくとも１つのメッセージを送信させる。

ここで開示される方法の実施形態は、コントローラ、プロセッサ及び／又は他のプログラム可能なデバイスを用いて実施され得る。その目的のために、ここで説明する方法は、１以上のプロセッサによって実行されると方法を実行するそこに記憶された命令を有する有形の非一時的コンピュータ可読媒体上で実施され得る。

したがって例えば、ＮＭＳ３０４は、ここで説明する動作を実行するように、（例えば、ファムウェア又はソフトウェアに）命令を記憶する記憶媒体を含み得る。記憶媒体は、任意のタイプの有形の媒体、例えば、フロッピーディスク、光ディスク、コンパクトディスク読出し専用メモリ（ＣＤ−ＲＯＭ）、コンパクトディスクリライタブル（ＣＤ−ＲＷ）及び光磁気ディスクを含む任意のタイプのディスク、読出し専用メモリ（ＲＯＭ）、ダイナミック及びスタティックランダムアクセスメモリ（ＲＡＭ）などのＲＡＭ、消去可能なプログラマブル読出し専用メモリ（ＥＰＲＯＭ）、電気的に消去可能なプログラマブル読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、磁気若しくは光カード、又は電子命令を記憶するのに適した任意のタイプの媒体などの半導体デバイスを含み得る。

ここでの任意のブロック図は、本開示の原理を具現化する説明的回路構成の概念図を示すことが当業者には理解される。同様に、任意のブロック図、フローチャート、フロー図、状態遷移図、疑似コードなどは、コンピュータ可読媒体において実質的には示されるので、コンピュータ又はプロセッサが明示されるか否かに関わらず、そのようなコンピュータ又はプロセッサによって実行され得る種々の処理を示すことが理解される。ソフトウェアモジュール又はソフトウェアであるように示唆される単なるモジュールは、フローチャートのエレメント又は処理ステップ及び／若しくは本文の説明の性能を示す他のエレメントの任意の組合せとしてここでは示され得る。そのようなモジュールは、明示又は示唆されるハードウェアによって実行され得る。

図面に示す種々のエレメントの機能は、「プロセッサ」と付された任意の機能ブロックを含み、専用のハードウェアと、適切なソフトウェアに関連したソフトウェア実行可能なハードウェアの使用を通じて提供され得る。機能は、単一の専用プロセッサによって、単一の共用プロセッサによって、又はその一部が供用され得る複数の個々のプロセッサによって提供され得る。さらに、用語「プロセッサ」の明示的な使用は、ソフトウェアを実行可能なハードウェアに排他的に言及するように解釈されるべきではなく、限定することなく、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）及び不揮発性ストレージを示唆的に含み得る。他の従来的及び／又はカスタムのハードウェアも、含まれ得る。

特に断りがない限り、単語「実質的に」の使用は、正確な関係性、状況、配置、向き及び／又は他の特徴、並びに当業者によって理解されるようなそれらの変形を含むと解釈され得るものであり、そのような変形の及ぶ範囲内では、開示する方法及びシステムに実質的には影響を与えない。本開示の全体にわたって、名詞を修飾する冠詞「ａ」及び／又は「ａｎ」及び／又は「ｔｈｅ」の使用は、便宜的に用いられ、特に断りがない限り、修飾される名詞の１つ又は２つ以上を含むように理解され得る。用語「備える」、「含む」及び「有する」は、包括的であり、列挙される要素以外の追加的要素があり得ることを意味することを意図している。

方法及びシステムをその特定の実施形態に対して説明したが、それらはそのようには限定されない。明らかに多くの変更例及び変形例が、上記の教示の観点から明らかとなり得る。ここで記載及び説明される部分の詳細、材料及び配置の多くの追加的変更が、当業者によってなされ得る。

実施形態の例のこれまでの説明は、説明及び記載の目的のために提示された。網羅的であり、又は開示される正確な形態に本開示を限定することは意図されていない。多くの変更例及び変形例が、この開示の観点で可能である。本開示の範囲は、この詳細な説明によってではなく、ここに添付される特許請求の範囲によって限定されることが意図される。

Claims (15)

1. ネットワーク管理システムであって、
   メモリと、
   コントローラであって、
   リモートコンピューティングデバイスからユーザリクエストを受信し、前記ユーザリクエストは少なくとも１つのネットワークエレメントアドレス及び前記少なくとも１つのネットワークエレメントアドレス上で実行する動作の識別子を含み、
   前記少なくとも１つのネットワークエレメントアドレス及び前記少なくとも１つのネットワークエレメントアドレス上で実行する前記動作の前記識別子を抽出し、
   前記少なくとも１つのネットワークエレメントアドレスに関連したプリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタを前記メモリから選択し、
   前記選択されたプリコンパイル済みＩＤＬアダプタに基づいて前記ユーザリクエストを満たす少なくとも１つのリモートプロシージャコール（ＲＰＣ）機能を選択し、
   前記少なくとも１つのネットワークエレメントアドレスに関連した１以上のネットワークエレメントに少なくとも１つのＩＤＬベースのメッセージを送信することによって前記少なくとも１つのＲＰＣ機能を実行し、
   前記実行された少なくとも１つのＲＰＣ機能からの応答に基づいて前記リモートコンピューティングデバイスに応答メッセージを送信し、前記応答メッセージが前記ユーザリクエストと同じフォーマットである、コントローラと
   を備えたネットワーク管理システム。
2. 前記ユーザリクエストが、Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）標準又はＲｅｐｒｅｓｅｎｔａｔｉｖｅ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ（ＲＥＳＴ）標準に適合する自己記述メッセージである、請求項１に記載のネットワーク管理システム。
3. 前記少なくとも１つのＲＰＣ機能が、共通オブジェクト・リクエスト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）のアーキテクチャに基づいて実行される、請求項１に記載のネットワーク管理システム。
4. 前記少なくとも１つのネットワークエレメントアドレスが、ケーブル地上局の識別子、エレメントタイプ、エレメント識別子（ＩＤ）及び／又はサブコンポーネントＩＤの内の少なくとも１つを含む、請求項１に記載のネットワーク管理システム。
5. 前記メモリがそこに記憶されたトポロジーテーブルをさらに含み、前記トポロジーテーブルは、光通信システム内の異なるネットワークエレメントに各々が対応する複数のネットワークエレメントアドレスを含む、請求項４に記載のネットワーク管理システム。
6. 前記メモリがそこに記憶されたＩＤＬアダプタテーブルをさらに含み、前記ＩＤＬアダプタテーブルは複数のプリコンパイル済みＩＤＬアダプタを含み、前記プリコンパイル済みＩＤＬアダプタの各々は、光通信システム内の１以上のネットワークエレメントに関連付けられている、請求項１に記載のネットワーク管理システム。
7. 前記メモリからの前記少なくとも１つのネットワークエレメントアドレスに関連した前記プリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタを選択するステップが、前記ＩＤＬアダプタテーブル上でルックアップを実行するステップを含む、請求項６に記載のネットワーク管理システム。
8. 前記メモリからの前記少なくとも１つのネットワークエレメントアドレスに関連した前記プリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタを選択するステップが、少なくとも第１及び第２のプリコンパイル済みＩＤＬアダプタを特定するステップを含み、前記第１のプリコンパイル済みＩＤＬアダプタは汎用のＩＤＬベースの通信のための方法を含み、前記第２のプリコンパイル済みＩＤＬアダプタは、ネットワークエレメントに対してカスタマイズされた論理を提供するようにランタイム拡張性のためのスタブインターフェースを定義する、請求項１に記載のネットワーク管理システム。
9. 少なくとも第１のケーブル地上局と第２のケーブル地上局との間に延在する通信経路を有する海底光通信システムにおいて実施される請求項１に記載のネットワーク管理システム。
10. リモートプロシージャコールリクエストをサービスするためのコンピュータ実施方法であって、
    コントローラによって、リモートコンピューティングデバイスからユーザリクエストを受信するステップであって、前記ユーザリクエストは、少なくとも１つのネットワークエレメントアドレス及び前記少なくとも１つのネットワークエレメントアドレス上で実行する動作の識別子を含む自己記述メッセージを含む、ステップと、
    前記コントローラによって、前記少なくとも１つのネットワークエレメントアドレス及び前記少なくとも１つのネットワークエレメントアドレス上で実行する前記動作の前記識別子を抽出するステップと、
    前記コントローラによって、前記少なくとも１つのネットワークエレメントアドレスに関連したプリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタをメモリから選択するステップと、
    前記コントローラによって、前記選択されたプリコンパイル済みＩＤＬアダプタに基づいて前記ユーザリクエストを満たす少なくとも１つのリモートプロシージャコール（ＲＰＣ）機能を選択するステップと、
    前記コントローラによって、前記少なくとも１つのネットワークエレメントアドレスに関連した１以上のネットワークエレメントに少なくとも１つのＩＤＬベースのメッセージを送信することによって、前記少なくとも１つのＲＰＣ機能を実行するステップと、
    前記コントローラによって、前記実行された少なくとも１つのＲＰＣ機能からの応答に基づいて前記リモートコンピューティングデバイスに応答メッセージを送信するステップであって、前記応答メッセージは前記ユーザリクエストと同じフォーマットである、ステップと
    を備える方法。
11. 前記少なくとも１つのネットワークエレメントアドレスに関連した前記プリコンパイル済みＩＤＬアダプタを前記メモリから選択するステップが、ＩＤＬアダプタテーブル上でルックアップを実行するステップを含み、前記ＩＤＬアダプタテーブルは、ネットワークエレメントとプリコンパイル済みＩＤＬアダプタとの間の複数の関連性を含む、請求項１０に記載の方法。
12. 複数のケーブル地上局の間に延在する光通信経路を備えた光通信システムであって、前記複数のケーブル地上局の各々は、前記光通信経路に沿って配設された複数のネットワークエレメントの１以上のネットワークエレメントに関連付けられており、
    ＲＰＣゲートウェイサーバであって、
    ユーザリクエストを受信し、前記ユーザリクエストは、動作の識別子及び前記動作を実行する少なくとも１つのネットワークエレメントの識別子を含む自己記述メッセージを含み、
    マスターネットワークエレメントとして動作するネットワークエレメントを特定し、
    前記特定されたマスターネットワークエレメントに第１のメッセージを送信し、前記第１のメッセージは、前記マスターネットワークエレメントに、前記少なくとも１つのネットワークエレメントの前記識別子に関連したネットワークエレメントに対応するプリコンパイル済みインターフェース記述言語（ＩＤＬ）アダプタを選択させ、前記マスターネットワークエレメントに、前記選択されたＩＤＬアダプタ及び前記動作に基づいて前記ネットワークエレメントに少なくとも１つのメッセージを送信させる、ＲＰＣゲートウェイサーバ
    を備える光通信システム。
13. 前記特定されたマスターネットワークエレメントに送信された前記第１のメッセージが、前記特定されたマスターネットワークエレメントに、共通オブジェクト・リクエスト・ブローカ・アーキテクチャ（ＣＯＲＢＡ）を介して、前記少なくとも１つのネットワークエレメントの前記識別子に関連した前記ネットワークエレメントと通信させるように構成された、請求項１２に記載の光通信システム。
14. 前記ＲＰＣゲートウェイサーバが、前記光通信システムにおいて前記複数のネットワークエレメントを管理するように構成されたネットワーク管理サーバ（ＮＭＳ）内で実施される、請求項１２に記載の光通信システム。
15. 前記少なくとも１つのネットワークエレメントの前記識別子に関連した前記ネットワークエレメントが、分岐ユニット（ＢＵ）、ネットワーク管理システム、再プログラム可能な光アド／ドロップマルチプレクサ（ＲＯＡＤＭ）、中継器、給電装置（ＰＦＥ）又は回線モニタリング装置（ＬＭＥ）を備える、請求項１２に記載の光通信システム。