ネットワークノード、情報処理システムおよび方法
【課題】ユーザがエッジノードに、入力データを処理して出力するアプリをデプロイする時に、アプリの出力先と入出力装置部の公開ユーザとの整合性を保証する。
【解決手段】エッジノード100はアプリの出力先とユーザの対応を管理する出力先/ユーザ対応テーブル400を持つ。予め、出力先/ユーザ対応テーブル400には、エッジノード100を利用するユーザ105毎に使用する出力先の情報が登録される。エッジノード100の処理部110のアプリデプロイ受付部165は、ユーザ105からアプリのデプロイを受け付ける時に、出力先/ユーザ対応テーブル400からアプリの出力先に対応するユーザを特定し、そのユーザがアプリの使用する入出力装置部102の入出力装置が公開を許可しているユーザと整合しているかどうかを確認し、デプロイの可否を判断する。
【解決手段】エッジノード100はアプリの出力先とユーザの対応を管理する出力先/ユーザ対応テーブル400を持つ。予め、出力先/ユーザ対応テーブル400には、エッジノード100を利用するユーザ105毎に使用する出力先の情報が登録される。エッジノード100の処理部110のアプリデプロイ受付部165は、ユーザ105からアプリのデプロイを受け付ける時に、出力先/ユーザ対応テーブル400からアプリの出力先に対応するユーザを特定し、そのユーザがアプリの使用する入出力装置部102の入出力装置が公開を許可しているユーザと整合しているかどうかを確認し、デプロイの可否を判断する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、カメラやセンサ等の入出力装置を持つネットワークノードを複数のユーザで共有する場合の権限管理に関し、特にユーザがネットワークノードにアプリケーションを投入するときに発生する権限違反を防ぐための権限管理技術に関する。
【背景技術】
【０００２】
従来、情報技術(Information Technology：IT)サービスはそれぞれ個別のIT装置を用いて、サイロ化した状態で提供されていた。近年のクラウド化の流れに伴い、複数のITサービスが同じプラットフォームを利用する、マルチテナントが拡大している。
【０００３】
ITサービスの１つに、インターネット・プロトコル(Internet Protocol：IP)カメラやセンサ等の実世界の情報を取得する入出力装置を使用した監視サービスがある。監視サービスをマルチテナントで提供するためのプラットフォームには、複数の入出力装置を所持し、それらの入出力装置からの入力データを統合して平均化やサマライズといった一次処理を行う、エッジノードが有力である。複数のユーザがエッジノードを共有し、各ユーザがそれぞれ一次処理を行うためのアプリケーションをエッジノードに投入することで、エッジノード上でユーザ毎のサービスが稼動する。この、エッジノードへのアプリケーションの投入を、”デプロイ”と呼ぶ。
【０００４】
複数ユーザでエッジノードを共有するにあたり、ユーザ毎の利用権限の管理が必須となる。このような利用権限管理に関する例として、特許文献１では、アプリケーションが使用するリソースに対するアクセスを制御する情報処理装置及び情報処理プログラムが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２３３９４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１で開示されている技術によれば、エッジノードの所持する入出力装置やアプリケーションのそれぞれに公開ユーザを設定可能である。
【０００７】
しかし、ユーザからのアプリケーションデプロイを受け入れるエッジノードでは、入出力装置の公開ユーザの設定者と、アプリケーションの出力先の設定者が異なる可能性が考えられる。
【０００８】
従って、アプリケーションの出力先と、アプリケーションが処理するデータを入力する入出力装置の公開ユーザは必ずしも一致しておらず、もし、入出力装置からの入力データを一次処理して、入出力装置の公開ユーザ以外へ出力するアプリケーションがデプロイされてしまうと、公開範囲違反が発生してしまう。
【０００９】
従って、アプリケーションのデプロイ時に、アプリケーションの出力先と入出力装置の公開ユーザの整合を確認しなくてはならない課題がある。
【００１０】
本発明の目的は、上記の課題を解決し、入力データを処理して出力するアプリケーションをデプロイする時に、アプリケーションの出力先と入出力装置の公開ユーザとの整合性を保証することが可能なネットワークノード、情報処理システムおよび方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記の目的を達成するため、本発明においては、ネットワークノードとして、１つ以上の入出力装置からデータの入力を受け付け、入出力装置から入力されたデータを処理して出力するアプリケーションが稼動する処理部と、入出力装置の公開範囲を保持する記憶部とを備え、処理部は、アプリケーションの投入を受け付ける際に、アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、アプリケーションの投入の受付可否を判断するネットワークノードを提供する。
【００１２】
また、上記の目的を達成するため、本発明においては、複数の入出力装置と入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードとを有する情報処理システムであって、ネットワークノードに、入出力装置の公開範囲データを保持しておき、ネットワークノードが、アプリケーションの投入を受け付ける際に、保持した公開範囲データに基づき、アプリケーションの出力先が、アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、アプリケーションの投入の受付可否を判断する情報処理システムを提供する。
【００１３】
更に、上記の目的を達成するため、本発明においては、１つ以上の入出力装置からデータの入力を受け付け、入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードにおける情報処理方法であって、ネットワークノードに入出力装置の公開範囲データを保持しておき、アプリケーションの投入を受け付ける場合に、この公開範囲データに基づき、アプリケーションの出力先が、アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、当該アプリケーションの投入の受付可否を判断するネットワークノードにおける情報処理方法を提供する。
【００１４】
すなわち、本発明では、上記の目的を解決するため、エッジノードなどのネットワークノードはアプリケーションの出力先とユーザの対応を管理するテーブルを持つ。ネットワークノードを利用するユーザは、予めそのテーブルに使用する出力先の情報を登録しておく。ネットワークノードは、ユーザからアプリケーションのデプロイを受け付ける時に、アプリケーションの出力先に登録されているユーザが、アプリケーションの使用する入出力装置が公開を許可するユーザと整合しているかを確認し、デプロイの可否を判断する。
【発明の効果】
【００１５】
本発明によれば、入出力装置の公開ユーザがアプリケーションの公開ユーザに引き継がれるため、アプリケーションの送信先ミスによるデータの誤送信の防止が可能となる。また、高いセキュリティを維持しつつ複数ユーザの入出力装置とアプリケーションの統合が可能となる。また、同一の入出力装置を用いて複数のサービスを展開出来るため、コストを低減可能である。
【図面の簡単な説明】
【００１６】
【図１】第１の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図２】第１の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図３】第１の実施形態においてエッジノードで動作するアプリケーション（以下、アプリ）一覧を管理する管理テーブルの一例を示す図である。
【図４】第１の実施形態においてエッジノードを利用するユーザの出力先一覧を管理する管理テーブルの一例を示す図である。
【図５】第１の実施形態においてエッジノード管理者がエッジノードに入出力装置を追加する時の処理の一例を示すシーケンス図である。
【図６】第１の実施形態においてユーザがエッジノードの入出力装置情報を取得するときの処理の一例を示すシーケンス図である。
【図７】第１の実施形態においてネットワークシステム管理者がエッジノード利用ユーザとその出力先一覧を登録するときの処理の一例を示すシーケンス図である。
【図８】第１の実施形態においてユーザがエッジノードにアプリをデプロイする時の処理の一例を示すシーケンス図である。
【図９】第１の実施形態においてユーザがエッジノードにアプリをデプロイする時に公開ユーザの整合を確認する処理の一例を示すフローチャート図である。
【図１０】第２の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図１１】第２の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図１２】第２の実施形態においてエッジノードを利用するユーザの出力先一覧を管理する管理テーブルの一例を示す図である。
【図１３】第２の実施形態においてネットワークシステム管理者がエッジノードに管理操作を要求した時に管理権限の有無を確認する処理の一例を示すフローチャート図である。
【図１４】第３の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図１５】第３の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図１６】第３の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図１７】第３の実施形態においてエッジノード管理者がエッジノードに入出力装置を追加する時の処理の一例を示すシーケンス図である。
【図１８】第３の実施形態においてユーザがエッジノードにアプリをデプロイする時の処理の一例を示すシーケンス図である。
【図１９】第３の実施形態においてユーザがエッジノードにアプリをデプロイする時に公開ユーザの整合を確認する処理の一例を示すフローチャート図である。
【図２０】第４の実施形態においてユーザがエッジノードにアプリをデプロイする時の処理の一例を示すシーケンス図である。
【図２１】第４の実施形態においてユーザがエッジノードにアプリをデプロイする時に公開ユーザの整合を確認する処理の一例を示すフローチャート図である。
【図２２】第５の実施形態においてアプリがデータ出力を要求したときの処理の一例を示すシーケンス図である。
【図２３】第６の実施形態においてエッジノード管理者が入出力装置の公開範囲を変更した時の処理の一例を示すフローチャート図である。
【図２４】第７の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図２５】第７の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図２６】第８の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図２７】第８の実施形態においてユーザ端末がエッジノードで動作するアプリにアクセスする場合の処理の一例を示すシーケンス図である。
【図２８】第８の実施形態においてアプリのアクセス権限を確認する処理の一例を示すシーケンス図である。
【図２９】第９の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図３０】第９の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図３１】第９の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施形態を図面に基づいて詳細に説明する。各図における同一符号は同一物あるいは相当物を示す。また、類似物については、説明の都合上、符号に添え字を追加して区別することがある。また、先にも述べたように、本明細書において、エッジノードへのアプリケーションの投入を、”デプロイ”と呼ぶ。なお、本明細書において、入出力装置という場合、入出力両機能を有する装置のみを意味するのでなく、入力機能のみを有する装置、出力機能のみを含む装置、さらには入出力の両機能を有する装置の何れかを意味するものである点を留意されたい。また、ネットワークノードの処理部で実行される各種のプログラム、またはその一部を、「部」、「ユニット」、「手段」、「機能」等と呼ぶ場合がある。
【実施形態１】
【００１８】
図１は、第１の実施形態に係るネットワークシステムの概略を示したブロック図である。本実施例のネットワークシステムは、ネットワークノードであるエッジノード100、同じくネットワークノードである上位ノード101からなり、エッジノード100には少なくとも一個の入出力装置を備える入出力装置部102と、エッジノード管理者103がアクセスし、上位ノードにはユーザ端末104とユーザ105とネットワークシステム管理者106がアクセスする。
【００１９】
エッジノード100は、処理部である中央処理部（Central Processing Unit：CPU）110、記憶部である主記憶111、インタフェース部であるネットワークインタフェース(Interface：I/F)112、入出力部(Input/Output：I/O)部113、コンソール114を保持し、CPU110と主記憶111間はメモリバス120で接続され、CPU110とネットワークI/F112、CPU110とI/O部113、CPU110とコンソール114間はそれぞれI/Oバス121、122、123で接続される。
【００２０】
I/O部113と入出力装置部102は、入出力装置のI/F124で接続される。入出力装置が接続されるI/O部113とI/F 124の規格は特には指定せず、例えばイーサネット（登録商標：Ethernet）、PCI(Peripheral Component Interconnect)、PCI Express、USB(Universal Serial Bus)、IEEE1394と言った規格が考えられる。エッジノード管理者103はコンソール114に対して直接入力I/F125でアクセスを行う。
【００２１】
上位ノード101は管理ブレード130と機能ブレード131とスイッチ132の組み合わせからなる。
【００２２】
管理ブレード130は、CPU133、主記憶134、ネットワークI/F135、コンソール136を保持し、CPU133と主記憶134間はメモリバス141で接続され、CPU133とネットワークI/F135、CPU133とコンソール136はそれぞれI/Oバス142、143で接続される。
【００２３】
機能ブレード131は、CPU133、主記憶134、ネットワークI/F135を２つ保持し、CPU133と主記憶134間はメモリバス141で接続され、CPU133とネットワークI/F135はI/Oバス142で接続される。
【００２４】
エッジノード100のネットワークI/F112と上位ノード101のスイッチ132はバックボーンネットワーク150で接続される。上位ノード101のスイッチ132と管理ブレード130、スイッチ132と機能ブレード131はそれぞれ装置内ネットワーク151で接続される。機能ブレード131とユーザ端末104はアクセスネットワーク152で接続される。
【００２５】
ネットワークシステム管理者106とユーザ105はそれぞれ上位ノード101のコンソール136に直接入力I/F153でアクセスする。ユーザ105はユーザ端末104に端末I/F154でアクセスする。
【００２６】
エッジノード100のCPU110では、アプリケーションミドルウェア（以下、アプリミドル）160とそれを利用するアプリケーション（以下、アプリ）161、入出力装置登録部162、入出力装置情報公開部163、ユーザ登録部164、アプリケーションデプロイ（以下、アプリデプロイ）受付部165、公開ユーザ整合確認部166などがプログラムとして動作する。なお、これらのプログラムは主記憶１１１などの記憶部に記憶され、必要に応じてCPU110に導入され、実行される。なお、アプリミドル160は、アプリ161が使用するライブラリのセットである。
【００２７】
エッジノード100の主記憶には、その他、入出力装置管理テーブル200、アプリ管理テーブル300、出力先/ユーザ対応テーブル400が保存される。なお、本実施形態では以上の3つのテーブルを保持しているが、管理項目を保持するテーブルの構成は本発明の本質とは無関係であり、別の実施形態として、これらのテーブルが保持する管理項目を1〜2つのテーブルに纏めて保持しても構わない。
【００２８】
アプリ161は、入出力装置部102からの入力を受け取って一次処理を行い、上位ノード101の機能ブレード131へと送信する。
【００２９】
入出力装置登録部162は、入出力装置部102の情報を入出力装置管理テーブル200に登録する機能を所持する。例えばエッジノード管理者103が入出力装置部102に入出力装置を追加する場合に、入出力装置登録部162を使用する。
【００３０】
入出力装置情報公開部163は、入出力装置管理テーブル200の登録内容を、ユーザ105、ネットワークシステム管理者106、エッジノード管理者103に公開する機能を所持する。
【００３１】
ユーザ登録部164は、ユーザ毎の出力先/ユーザ対応テーブル400に登録する機能を所持する。ネットワークシステム管理者106、エッジノード管理者103はユーザ登録部164を使用し、ユーザ毎の使用アドレスを、出力先/ユーザ対応テーブル400に登録する。
【００３２】
アプリデプロイ受付部165は、アプリのデプロイを受付け、アプリ管理テーブル300を更新する機能を所持する。ユーザ105はエッジノード100にアプリを配布する時にアプリデプロイ受付部165を使用する。
【００３３】
公開ユーザ整合確認部166は、入出力装置管理テーブル200に設定された公開ユーザと、アプリ管理テーブル300と出力先/ユーザ対応テーブル400に設定されたアプリの出力先との整合性をチェックする機能を持つ。本実施例では、公開ユーザ整合確認部166は、ユーザ105がアプリデプロイ受付部165を使用してアプリをデプロイする時に、アプリの出力権限の整合性が取れているかどうかを確認するために動作する。
【００３４】
次に、第１の実施形態が適用されたネットワークシステムにおいて、エッジノード100が保持する管理テーブルの構成を説明する。
【００３５】
図２は、入出力装置管理テーブル200を示したものである。図２に示すように、入出力装置管理テーブル200は、入出力装置識別子(Identifier：ID)列201、入出力装置名称列202、接続列203、入出力装置アドレス列204、所有者列205、公開ユーザ列206の各列からなる。
【００３６】
入出力装置ID列201は、入出力装置管理テーブル200で管理する入出力装置のIDを保持する。本実施形態ではDev-1、Dev-2・・・としている。入出力装置名称列202は入出力装置の名称を保持する。本実施形態ではIPカメラ1、IPカメラ2・・・と名称の次にシリアル番号を割り当てている。
【００３７】
接続列203は入出力装置の接続形態を保持する。本実施形態では接続プロトコルの情報としてTCP/IPを保持している。他に入出力装置の接続プロトコルとしては、PCI、PCI-Express、USB、IEEE1394などの規格も考えられる。
【００３８】
入出力装置アドレス列204は各入出力装置のアドレスを保持する。入出力装置アドレス列204は接続列203に対応しており、両者の組み合わせによって入出力装置へのアクセス先が一意に特定可能なものである。例えば本実施形態では接続列203が保持する接続形態はTCP/IP(Transmission Control Protocol/Internet Protocol)であり、入出力装置アドレス列ではIPアドレスとポート番号を保持している。他の接続形態の場合はそれに応じたアドレスを保持することになり、例えば接続形態がPCIバスの場合はバス番号・デバイス番号・ファンクション番号を保持すると考えられる。
【００３９】
所有者列205は入出力装置の所有ユーザを保持する。公開ユーザ列206は入出力装置を閲覧したり、使用する権限を持つユーザ105の一覧を保持する。
【００４０】
図３は、アプリ管理テーブル300を示したものである。図３に示すようにアプリ管理テーブル300は、アプリID列301、アプリ名称列302、デプロイユーザ列303、入出力装置ID列304、入出力装置名称列305、出力先列306の各列からなる。
【００４１】
アプリID列301は、アプリ管理テーブル300で管理するアプリのIDを保持する。本実施形態ではAP-1、AP-2・・・としている。アプリ名称列302は、アプリの名称を保持する。
【００４２】
デプロイユーザ列303は、アプリをデプロイしたユーザ情報を保持する。
【００４３】
入出力装置ID列304は、アプリが使用する入出力装置IDの一覧を保持する。入出力装置名称列305は、入出力装置ID列304で参照する入出力装置の名称の一覧を保持する。
【００４４】
出力先列306は、アプリの出力先を保持する。本実施例では、アプリの出力はTCP/IPによる上位ノード101の機能ブレード131への送信を想定しており、IPアドレスとポート番号を保持している。
【００４５】
図４は、出力先/ユーザ対応テーブル400を示したものである。図４に示すように出力先/ユーザ対応テーブル400は、登録ID列401、ユーザ列402、出力先列403の各列からなる。
【００４６】
登録ID列401は、出力先/ユーザ対応テーブルが管理する出力先/ユーザ対応の組み合わせのIDを保持する。本実施例では＃１、＃２、＃３・・・としている。ユーザ列402は出力先/ユーザ対応の組み合わせにおいて、ユーザを保持する。
【００４７】
出力先列403は出力先/ユーザ対応の組み合わせにおいて、ユーザ列402で示すユーザが登録する出力先を保持する。出力先は必ずしも１通りではなく、１ユーザが複数の出力先アドレスを使用する場合も考えられる。本実施形態ではユーザ毎のIPアドレスのユーザのポート番号を保持している。
【００４８】
次に、第１の実施形態が適用されたネットワークシステムの動作を説明する。
【００４９】
図５は、エッジノード管理者103が入出力装置を追加するときの動作を示したシーケンス図である。図５に示すように、本動作には、エッジノード管理者103、入出力装置登録部162、入出力装置管理テーブル200が関連する。
【００５０】
まず、エッジノード管理者103は、S501でエッジノード100に入出力装置を接続する。次に、エッジノード管理者103は、コンソール114を使用して、入出力装置登録部162にS501で接続した入出力装置の登録を要求し、それと共に、入出力装置の装置情報（名称、接続、入出力装置アドレス、所有者、公開ユーザ）を伝える（S502）。
【００５１】
次に、入出力装置登録部162は、入出力装置登録テーブル200に格納されているエントリの一覧を取得する（S503）。
【００５２】
次に、入出力装置登録部162は、S504において、S503で取得したエントリ一覧の中に、S502で登録を要求された入出力装置の情報と同一装置のエントリが存在しているかどうかチェックし、登録の可否を判定する。具体的には、同一装置のエントリが存在していなければ登録可能と判定し、同一装置のエントリが存在している場合は、新規にエントリを登録すると入出力装置管理テーブル200のエントリとコンフリクトするため、登録不可能と判定する。
【００５３】
次に、入出力装置登録部162は、S504で登録可と判断した場合は、入出力装置ID列201において重複しない入出力IDを割当て、入出力装置管理テーブル200にエントリを追加する（S505）。
【００５４】
次に、入出力装置登録部162は、エッジノード管理者103に登録要求の結果を返す（S506）。
【００５５】
図６は、ユーザ105が入出力装置管理テーブル200より入出力装置情報を取得する動作を示したシーケンス図である。図６に示すように、本動作には、ユーザ105、入出力装置公開部163、入出力装置管理テーブル200が関連する。
【００５６】
まず、ユーザ105は、管理ブレード130のコンソール136を使用して、入出力装置情報公開部163に、ユーザ105に公開されている入出力装置情報の要求を送る（S601）。
【００５７】
次に、入出力装置情報公開部163は、入出力装置管理テーブル200のうち、公開ユーザ列206にS601を要求したユーザが含まれる入出力装置のエントリを検索して、そのエントリの装置情報である入出力装置ID列201と入出力装置名称列202とを取得する（S602）。
【００５８】
次に、入出力装置163は、ユーザ105に、S602で取得した入出力装置の一覧とその装置情報（入出力装置ID、入出力装置名称）を返す（S603）。
【００５９】
図７は、ネットワークシステム管理者106が出力先/ユーザ対応テーブル400に、エッジノード100を使用するユーザ105と、そのユーザに対応する出力先の登録を行う動作を示したシーケンス図である。図７に示すように、本動作には、ネットワークシステム管理者106、ユーザ登録部164、出力先/ユーザ対応テーブル400が関連する。
【００６０】
まず、ネットワークシステム管理者106は、S701において、管理ブレード130のコンソール136を使用して、ユーザ登録部164に、ユーザ登録の要求を要求し、それと共に、ユーザ情報（ユーザ名、ユーザの使用アドレス範囲）を伝える。
【００６１】
次に、ユーザ登録部164は、出力先/ユーザ対応テーブル400に格納されているエントリの一覧を取得する（S702）。
【００６２】
次に、ユーザ登録部164は、S703において、S702で取得したエントリ一覧の中に、S701で登録を要求されたユーザと同一ユーザのエントリが存在しているかどうかチェックし、登録の可否を判定する。具体的には、同一ユーザのエントリが存在していなければ登録可能と判定し、同一ユーザのエントリが存在している場合は、新規にエントリを登録するとコンフリクトとなるため、登録不可能と判定する。
【００６３】
次に、ユーザ登録部164は、S703で登録可と判断した場合は、登録ID列401において重複しない登録IDを割当て、出力先/ユーザ対応テーブル400にエントリを追加する（S704）。
【００６４】
次に、ユーザ登録部162は、ネットワークシステム管理者106に登録要求の結果を返す（S705）。
【００６５】
入出力装置管理テーブル200に入出力装置部102の情報が登録され、出力先/ユーザ対応テーブル400にユーザ105の出力先が登録された後、ユーザ105はエッジノード100にアプリをデプロイする。
【００６６】
アプリは、指定する入出力装置部102から入力データを取得し、CPU110で一次処理を行い、指定した機能ブレード131へ送信する、一連の動作を行うと想定する。
【００６７】
図８は、ユーザ105がエッジノード100にアプリをデプロイする動作を示したシーケンス図である。図８に示すように、本動作には、ユーザ105、アプリデプロイ受付部165、公開ユーザ整合確認部166、入出力装置管理テーブル200、出力先/ユーザ対応テーブル400、アプリ管理テーブル300が関連する。
【００６８】
まず、ユーザ105は、S801において、管理ブレード130のコンソール136を使用して、アプリデプロイ受付部165に、アプリデプロイを要求し、それと共に、デプロイするアプリの情報を送る。
【００６９】
アプリデプロイ受付部165は、S802において、公開ユーザ整合確認部166に、公開ユーザ整合確認を要求し、それと共に、S801で受信したアプリが使用する入出力装置のIDとアプリの出力先とを送る。
【００７０】
公開ユーザ整合確認部166は、まず、入出力装置管理テーブル200のエントリのうち、入出力装置ID列201がS802で受信したアプリが使用する入出力装置のIDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得する（S803）。S803で取得したユーザ一覧は、アプリが使用する入出力装置の公開ユーザの一覧に相当する。ちなみに、アプリが複数の入出力装置を使用し、それぞれの入出力装置で異なる公開ユーザ一覧を設定している場合も考えられる。その場合、公開ユーザ整合確認部166は全ての公開ユーザ一覧のANDをとったものを使用する。
【００７１】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のエントリのうち、出力先列403にS802で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S804）。S804で取得したユーザは、アプリ出力先に対応するユーザに相当する。
【００７２】
次に、S805において、公開ユーザ整合確認部166はS803で取得した公開ユーザ一覧と、S804で取得したアプリ出力先に対応するユーザとの整合を確認し、アプリデプロイ受付部165に結果を伝える（S806）。
【００７３】
次に、S806の確認結果が整合であれば、アプリデプロイ受付部165は、S807でアプリをデプロイし、アプリ管理テーブル300に、アプリID列301において重複しないIDを割り当てて、エントリを追加する（S808）。S806の確認結果が不整合であれば、アプリデプロイ受付部165は、S807とS808に示す、アプリデプロイとアプリ管理テーブル300の更新は実施しない。
【００７４】
次に、アプリデプロイ受付部165は、ユーザ105にデプロイ要求結果を返す（S809）。
【００７５】
以上のように、ユーザ105がアプリのデプロイを要求したときに、アプリ出力先に対応するユーザが、アプリが使用する入出力装置の公開ユーザ一覧と整合しているかチェックすることで、アプリの出力先は入出力装置が設定した公開ユーザに従っていると保証可能となる。
【００７６】
図９は、エッジノード100がアプリデプロイを受け付ける時に、CPU110でプログラムとして動作する公開ユーザ整合確認部166が行う処理を示すフローチャートである。
【００７７】
まず、公開ユーザ整合確認部166は、図８のS802に示すように、公開ユーザ整合確認の要求を受け、それと共に、アプリ情報（アプリが使用する入出力装置のID、アプリの出力先）を受信する（S901）。
【００７８】
次に、公開ユーザ整合確認部166は、図８のS803に示すように、入出力装置管理テーブル200から、入出力装置ID列201が、S901で受信したアプリが使用する入出力装置IDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得して、公開ユーザ一覧とする（S902）。
【００７９】
次に、公開ユーザ整合確認部166は、図８のS804に示すように、出力先/ユーザ対応テーブル400から、出力先列403にS802で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S903）。
【００８０】
次に、公開ユーザ整合確認部166は、図８のS805に対応して、S903で取得したユーザが、S902で取得したユーザ一覧に含まれているかどうかを確認する（S904）。
【００８１】
S904の結果がYesであれば、アプリ出力先が対応するユーザは、アプリの使用する入出力装置の公開ユーザ一覧と整合しているので、整合確認部166は、公開ユーザは整合であることを返信する（S905）。S904の結果がNoであれば、公開ユーザ整合確認部166は、公開ユーザが不整合であると返信する（S906）。
【００８２】
以上説明した第1の実施形態では、エッジノードからのネットワークインタフェースは１つである。しかし、複数ユーザでネットワークシステムを共有するにあたり、管理系の操作と業務系の操作で別々のパスを使用したり、業務系の操作でも各ユーザが別々のパスを使用して、操作の独立性を保証してセキュリティを高めた運用形態が考えられる。
【００８３】
図１に示すネットワークシステムにおいて、管理系と業務系で別々のパスを使用する運用形態を行うためには、ネットワークI/F112、スイッチ132、バックボーンネットワーク150を論理的に分割することで、エッジノード100間と上位ノード101間に複数のパスを構成するアプローチが考えられる。
【００８４】
具体的なアプローチの例を説明する。まず、エッジノード100は、VLAN（Virtual Local Area Network）を用いて、1つのネットワークI/F 112を、仮想的に複数のネットワークI/Fであるように見せる。次に、上位ノード101のスイッチ132は、VLANを適用することにより、1つのスイッチ132を仮想的に複数のスイッチであるように見せる。最後に、ネットワークI/F112とスイッチ132との間をVLANに対応するバックボーンネットワーク150で繋ぐことで、エッジノード100のネットワークI/F 112と上位ノード101のスイッチ132の間に、仮想的な複数のパスが張られる。
【００８５】
また、仮想的なアプローチだけではなく、必要なパスに応じて、複数の物理ネットワークI/F112やスイッチ132を所持するようなネットワークシステムを構築することも考えられる。
【００８６】
このように、複数のパスを使用するためには、仮想的なアプローチと物理的なアプローチの2通りが考えられるが、効果は同様である。
【実施形態２】
【００８７】
次に、第２の実施形態として、エッジノード100と上位ノード101間に、複数の物理的パスを持ち、管理系と業務系のパスを分割可能とするネットワークシステムを考える。
【００８８】
図１０は第２の実施形態を適用したネットワークシステムの概略を示すブロック図である。
【００８９】
まず、第２の実施形態におけるエッジノード1000について、第１の実施形態との差分を説明する。エッジノード1000は、接続先である管理ブレード130と機能ブレード131の数に応じてネットワークI/F1010を所持する。CPU110とネットワークI/F1010はI/Oバス1011で接続される。
【００９０】
次に、第２の実施形態における上位ノード1001について、第1の実施形態との差分を説明する。上位ノード1001は接続先のセグメント毎にスイッチ1012を所持する。
【００９１】
バックボーンネットワーク1020の構成は、インタフェース部であるネットワークI/F1010やスイッチ1012の構成に依存する。具体的には、ネットワークI/F1010、1010(2)、1010(3)やスイッチ1012、1012(2)、1012(3)が物理的に複数存在する場合は同様に物理的に複数存在し、ネットワークI/F1010やスイッチ1012が論理的に分割されている場合は同様に論理的に分割される。
【００９２】
第２の実施形態では、ネットワークシステム管理者106とユーザ105は別々のパスを使用する。そのため、エッジノード1000の公開ユーザ整合確認部1034は、アプリの動作権限の確認のみでなく、管理操作の要求を受信した際に管理操作の要求元が管理操作を行う権限があるかどうかを使用パスによって判断可能である。具体的には、入出力装置登録部1030、入出力装置情報公開部1031、ユーザ登録部1032、アプリデプロイ受付部1033は、ネットワークシステム管理者106或いはユーザ105より管理操作の要求を受けた時に、公開ユーザ整合確認部1034に管理操作を行う権限の確認を要求し、権限の有無によって管理操作を受け付けるかどうか決定する。
【００９３】
図１１は、第２の実施形態におけるアプリ管理テーブル1100を示したものである。図１１に示すように、アプリ管理テーブル1100は、アプリID列1101、アプリ名称列1102、デプロイユーザ列1103、入出力装置ID列1104、入出力装置名称列1105、出力先列1106に加え、使用パス列1107の各列からなる。
【００９４】
これらの列のうち1101〜1106は、第１の実施形態におけるアプリ管理テーブル300と同様であるため、差分である使用パス列1107のみ説明する。
【００９５】
使用パス列1107は、アプリがデータ出力時に使用するパスを保持している。それぞれのパスは、エッジノード1000のネットワークI/F1010、バックボーンネットワーク1020、上位ノード1001のスイッチ1011までの経路を指す。使用パス列1107の名づけルールは、本実施形態では業務パス-1、業務パス-2・・・としている。
【００９６】
図１２は、第２の実施形態における出力先/ユーザ対応テーブル1200を示したものである。図１２に示すように出力先/ユーザ対応テーブル1200は、登録ID列1201、ユーザ列1202、出力先列1203、使用パス列1204の各列からなる。
【００９７】
これらの列のうち1201〜1203は、第１の実施形態における出力先/ユーザ対応テーブル400と同様であるため、差分である使用パス列1204のみ説明する。
【００９８】
使用パス列1204は、ネットワークシステム管理者106やユーザ105が使用するパスを保持する。ユーザ105と使用パスの組み合わせはポリシーによるが、セキュリティを重視する場合は、エントリ1220〜1222のように、ユーザ105毎に別々の業務パスを割当て、通信における他ユーザからの干渉を防止する適用形態が考えられる。
【００９９】
第２の実施形態における出力先/ユーザ対応テーブル1200は、ユーザ105が使用する業務パスのエントリ1220〜1222だけでなく、ネットワークシステム管理者106が使用する管理パスのエントリ1210も保持している。
【０１００】
第２の実施形態における公開ユーザ整合確認部1034は、出力先/ユーザ対応テーブル1200を参照して、管理要求元が管理パスに含まれるかどうかを判断可能である。
【０１０１】
図１３は、公開ユーザ整合確認部1034が、管理操作要求元の権限をチェックする動作を示したフローチャートである。
【０１０２】
まず、入出力装置登録部1030、入出力装置情報公開部1031、ユーザ登録部1032、アプリデプロイ受付部1033は、ネットワークシステム管理者106から管理操作の要求を受信すると、公開ユーザ整合確認部1034に管理権限の確認を要求し、それと共に、管理操作要求元のアドレスを伝える（S1301）。
【０１０３】
次に、公開ユーザ整合確認部1034は、出力先/ユーザ対応テーブル1200から、使用パス列1204が管理操作権限のある管理パスであるエントリを探し、そのエントリのユーザ列1202を取得する（S1302）。
【０１０４】
次に、公開ユーザ整合確認部1034は、出力先/ユーザ対応テーブル1200から、S1301で受信した管理操作要求元アドレスが、出力先列1203に含まれるユーザを取得する（S1903）。
【０１０５】
次に、公開ユーザ整合確認部1034は、S1303で取得した管理操作要求元に対応するユーザが、S1304で取得した管理パスの対応ユーザの一覧に含まれているかどうかを判断する（S1304）。
【０１０６】
S1304の結果がYesであれば、公開ユーザ整合確認部1034は、管理操作を実行する権限ありと返信し（S1305）、S1304の結果がNoであれば、公開ユーザ整合確認部1034は、管理操作を実行する権限なしと返信する（S1306）。
【０１０７】
なお、本実施例ではネットワークシステム管理者のみに管理権限がある想定だが、ユーザ105にも一部の管理権限を与えて、ユーザ105が各動作部1030〜1034に管理要求を送った時にこのシーケンスと同様に権限を確認する実施形態も考えられる。
【０１０８】
第２の実施形態において、ユーザ105毎に別々のパスを割り当てた場合、ユーザ毎の通信内容は干渉しない。この実施形態において、DHCPサーバとDNSサーバにより、パス毎にドメイン名とIPアドレス領域を設定して自動的にIP割り振ることで、IPアドレスの設定や解決を省略可能であり、出力先の整合性確認のステップも簡略化可能となる。
【実施形態３】
【０１０９】
そこで、DHCPサーバとDNSサーバによってIPアドレスの設定や解決を自動化する、第３の実施形態を考える。
【０１１０】
図１４は、第３の実施形態を適用したネットワークシステムの概略を表すブロック図である。第２の実施形態との差分を説明する。
【０１１１】
上位ノード1401にはDHCPサーバ1402とDNSサーバ1403が存在し、ネットワークシステム管理者106とユーザ105が使用するパスにおいて、IPアドレス設定やホスト名の解決を行う。
【０１１２】
DHCPサーバ1402とDNSサーバ1403はパス毎に1つずつ存在しても良いが、スイッチ1011がリレー機能を適用可能ならば、1つのDHCPサーバ1402とDNSサーバ1403で複数のパスを担当可能である。図１４はスイッチのリレー機能を適用する想定図であり、1404はリレーの接続を表している。なお、図１４の構成は一例であり、これらのDHCPサーバ1402とDNSサーバ1403は上位ノード1401中に存在する必要はなく、上位ノード1401が接続されるネットワーク上に存在しても良い。
【０１１３】
さて、エッジノード1400では、構成変更に伴って、入出力装置登録部1410、入出力装置情報公開部1411、アプリデプロイ登録部1412、公開ユーザ整合確認部1413の機能と、入出力装置管理テーブル1500、アプリ管理テーブル1600の保持する内容が変化する。
【０１１４】
図１５は、第３の実施形態における入出力装置管理テーブル1500を示したものである。図１５に示すように、入出力装置管理テーブル1500は、入出力装置ID列1501、入出力装置名称列1502、接続列1503、入出力装置アドレス1504、所有者列1505、公開ユーザ列1506の各列からなる。
【０１１５】
これらの列のうち1501〜1506は、第１の実施形態における入出力装置管理テーブル200と同様であるため、差分である公開出力先ユーザ列1507のみ説明する。公開出力先ユーザ列1507は公開ユーザ1506に登録されたユーザが使用可能なドメインを格納している。
【０１１６】
図１６は、第３の実施形態におけるアプリ管理テーブル1600を示したものである。図１６に示すようにアプリ管理テーブル1600は、アプリID列1601、アプリ名称列1602、デプロイユーザ列1603、入出力装置ID列1604、入出力装置名称列1605、出力先列1606、出力先ユーザ列1607の各列からなる。
【０１１７】
これらの列のうち1601〜1605は第１の実施形態におけるアプリ管理テーブル300と同様であるため、差分である出力先列1606と出力先ユーザ列1607のみ説明する。
【０１１８】
出力先列1606は、アプリの出力先として、ホスト名＋ドメイン名で表されたIPアドレスとポート番号を保持している。出力先ユーザ列1607は、出力先列1606に対応するユーザを保持している。
【０１１９】
入出力装置管理テーブル1500とアプリ管理テーブル1600から分かるように、第３の実施形態では、DHCPサーバ1402とDNSサーバ1403によって、ユーザ毎に使用可能なドメインとそのセグメントが割り振られるため、ユーザを指定すればその公開ユーザを決定できる。従って、第１の実施形態のように出力先/ユーザ対応テーブルに登録しなくとも、出力先のIPアドレスとユーザの対応を行うことが出来る。
【０１２０】
図１７は、第３の実施形態において、エッジノード管理者103が入出力装置を追加するときの動作を示したシーケンス図である。図１７に示すように、本動作には、エッジノード管理者103、入出力装置登録部1410、入出力装置管理テーブル1500が関連する。
【０１２１】
まず、エッジノード管理者103はS1701において、入出力装置をエッジノードに接続する。
【０１２２】
次に、エッジノード管理者103は、コンソール114を使用して、入出力装置登録部1410にS1701で接続した入出力装置の登録を要求し、それと共に、入出力装置の情報（名称、接続、入出力装置アドレス、所有者、公開ユーザ、公開ユーザのドメイン名）を伝える（S1702）。
【０１２３】
次に、入出力装置登録部1410は、入出力装置登録テーブル1500に格納されているエントリの一覧を取得する（S1703）。
【０１２４】
次に、入出力装置登録部1410は、S1704において、S1703で取得したエントリ一覧の中に、S1702で登録を要求された入出力装置の情報と同一装置のエントリが存在しているかどうかチェックし、登録の可否を判定する。具体的には、同一装置のエントリが存在していなければ登録可能と判定し、同一装置のエントリが存在している場合は、新規にエントリを登録すると入出力装置管理テーブル1500のエントリがコンフリクトするため、登録不可能と判定する。
【０１２５】
次に、入出力装置登録部1410は、S1704で登録可と判断した場合は、入出力装置ID列1501において重複しない入出力IDを割当て、入出力装置管理テーブル1500にエントリを追加する（S1705）。
【０１２６】
次に、入出力装置登録部1410は、エッジノード管理者103に登録要求の結果を返す（S1706）。
【０１２７】
第３の実施形態において、ユーザ105がエッジノード1400の入出力装置102の情報を取得する時の動作は、第１の実施形態における図６に示すシーケンスと同様である。
【０１２８】
図１８は、第３の実施形態において、ユーザ105がエッジノード1400にアプリをデプロイする時の動作を示したシーケンス図である。図１８に示すように、本動作には、ユーザ105、アプリデプロイ受付部1412、公開ユーザ整合確認部1413、入出力装置管理テーブル1500、アプリ管理テーブル1600が関連する。
【０１２９】
まず、ユーザ105は、管理ブレード130のコンソール136を使用して、アプリデプロイ受付部1412に、アプリデプロイを要求し、それと共に、デプロイするアプリのアプリ情報（アプリが使用する入出力装置のIDとアプリ出力先）を送る。本実施形態では、アプリ出力先は、IPアドレスではなく、ホスト名＋ドメイン名で表される（S1801）。
【０１３０】
アプリデプロイ受付部1412は、公開ユーザ整合確認部1413に、公開ユーザ整合確認を要求し、それと共に、S1801で受信したアプリが使用する入出力装置のIDとアプリの出力先とを送る（S1802）。
【０１３１】
公開ユーザ整合確認部1413は、入出力装置管理テーブル1500のエントリのうち、入出力装置ID列1501がS1802で受信したアプリが使用する入出力装置のIDであるエントリを探し、そのエントリの公開ユーザのドメイン名列1506の内容を取得する（S1803）。本シーケンスで取得したドメイン名一覧は、アプリが使用する入出力装置の公開範囲の一覧に相当する。ちなみに、アプリが複数の入出力装置を使用し、それぞれの入出力装置で異なる公開ドメイン名一覧を設定している場合も考えられる。その場合、公開ユーザ整合確認部1413は全ての公開ドメイン名一覧のANDをとったものを使用する。
【０１３２】
次に、公開ユーザ整合確認部1413は、S1804において、S1803で取得した公開ユーザのドメイン名一覧と、S1802で取得したアプリ出力先との整合を確認し、アプリデプロイ受付部1412に結果を伝える（S1805）。
【０１３３】
以降、S1806〜S1808のステップは、第１の実施例におけるアプリデプロイのシーケンスS807〜S809と同様である。
【０１３４】
以上のように、第３の実施形態では、公開ユーザ整合確認部1413は、ドメイン名の解決によって、出力先に対応するユーザが判別出来るため、入出力装置管理テーブル1500が保持する情報のみで公開ユーザの整合の確認を行うことが可能となる。
【０１３５】
図１９は、第３の実施形態における、公開ユーザ整合確認部1413の動作を示すフローチャートである。
【０１３６】
まず、公開ユーザ整合確認部1413は、図１８のS1802に示すように、公開ユーザ整合確認の要求を受け、それと共に、アプリ情報（アプリが使用する入出力装置のIDとアプリの出力先）を受信する（S1901）。第３の実施形態では、アプリの出力先はホスト名＋ドメイン名の形態で知らせられる。
【０１３７】
次に、公開ユーザ整合確認部1413は、図１８のS1803に示すように、入出力管理テーブル1500から、入出力装置ID列1501が、S1901で受信したアプリが使用する入出力装置IDであるエントリを探し、そのエントリの公開ユーザのドメイン名列1507の内容を取得して、公開ドメイン名一覧とする（S1902）。
【０１３８】
次に、公開ユーザ整合確認部1413は、図１８のS1804に示すように、S1901で受信したアプリ出力先のドメイン名が、S1902で取得したアプリが使用する入出力装置の公開ユーザのドメイン名一覧に含まれているかどうかを確認する（S1903）。
【０１３９】
S1903の結果がYesであれば、アプリ出力先が対応するユーザは、アプリの使用する入出力装置の公開ユーザ一覧と整合しているので、公開ユーザ整合確認部1413は、公開ユーザは整合であることを返信する（S1904）。S1903の結果がNoであれば、公開ユーザ整合確認部1413は、公開ユーザが不整合であると返信する（S1905）。
【実施形態４】
【０１４０】
次に、第４の実施形態について説明する。第１の実施形態では、アプリデプロイ受付部165がデプロイを受け付けた時に、アプリの出力ユーザとアプリが利用する入出力装置の公開ユーザの整合が取れていなかった場合はデプロイを拒否していたが、第４の実施形態ではアプリの出力ユーザを制限することでアプリの利用する入出力装置の公開ユーザとの整合を保証し、その上でデプロイを実行する。
【０１４１】
第４の実施形態は、第１の実施形態と物理的な構成は同様であり、動作のみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１４２】
図２０は第４の実施形態においてユーザ105がデプロイを要求した場合の動作を示したシーケンス図である。図２０に示す通り、本動作には、ユーザ105、管理ブレード130、アプリデプロイ受付部165、公開ユーザ整合部166、入出力装置管理テーブル200、出力先/ユーザ対応テーブル400、アプリ管理テーブル300が関連する。
【０１４３】
本シーケンスのS2001〜S2004までは、第１の実施形態におけるアプリデプロイのS801〜S804と同様である。ここまで、公開ユーザ整合確認部166は、S2003でアプリが使用する入出力装置に対応する公開ユーザ一覧を取得し、S2004でアプリの出力先に対応するユーザを取得している。
【０１４４】
次に、S2005において、公開ユーザ整合確認部166はS2003で取得した公開ユーザ一覧と、S2004で取得したアプリ出力先に対応するユーザとの整合を確認する。もし不整合であった場合、公開ユーザ整合確認部166は、整合性が得られるようにS2002で取得したアプリの出力先を制限する。また、S2003で取得した公開ユーザ一覧と、S2004で取得したアプリ出力先に対応するユーザとが、全く共通点が無い場合、アプリの出力先を制限しても整合性が得られないと判断する。（S2005）。
【０１４５】
次に、公開ユーザ整合確認部166は、整合結果と共に制限後のアプリ出力先をアプリデプロイ受付部165に返す。なお、S2005でアプリの出力先を制限しても整合性が得られないと判断した場合は、整合結果は不整合で出力先の修正は不可能であると伝える（S2006）。
【０１４６】
次に、アプリデプロイ受付部165は、S2006で受信した確認結果が整合であれば、アプリのデプロイを実行し（S2007）、アプリ管理テーブル300に、アプリID列301において重複しないIDを割り当てて、エントリを追加する（S2008）。アプリデプロイ受付部165は、S2006で受信した確認結果が不整合で、それと共に、制限後の出力先を受信した場合は、アプリデプロイ受付部165は、受信した制限後の出力先に従ってアプリのデプロイを実行し（S2007）アプリ管理テーブル300に、アプリID列301において重複しないIDを割り当てて、エントリを追加する（S2008）。アプリデプロイ受付部165は、S2006で受信した確認結果が不整合で、それと共に出力先の修正は不可能と受信した場合は、S2007とS2008に示す、アプリデプロイとアプリ管理テーブル300の更新は実施しない。
【０１４７】
次に、アプリデプロイ受付部165は、ユーザ105にデプロイ要求結果を返す（S2009）。
【０１４８】
図２１は、第４の実施形態におけるアプリデプロイ時の、公開ユーザ整合確認部166の動作を示したフローチャートである。
【０１４９】
まず、公開ユーザ整合確認部166は、図２０のS2002に示すように、公開ユーザ整合確認の要求を受け、それと共に、アプリ情報（アプリが使用する入出力装置のID、アプリの出力先）を受信する（S2101）。
【０１５０】
次に、公開ユーザ整合確認部166は、図２０のS2003に示すように、入出力装置管理テーブル200から、入出力装置ID列201が、S2101で受信したアプリが使用する入出力装置IDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得して、公開ユーザ一覧とする（S2102）。
【０１５１】
次に、公開ユーザ整合確認部166は、図２０のS2004に示すように、出力先/ユーザ対応テーブル400のエントリから、出力先列403にS2101で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S2103）。
【０１５２】
次に、公開ユーザ整合確認部166は、図２０のS2005に示すように、S2103で取得したユーザが、S2102で取得したユーザ一覧に含まれているかどうかを確認する（S2104）。
S2104の結果が完全に包含関係であれば、アプリ出力先が対応するユーザは、アプリの使用する入出力装置の公開ユーザ一覧と整合しているので、整合確認部166は、公開ユーザは整合であることを返信する（S2105）。S2104の結果が一部のみの包含関係であれば、整合確認部166は、S2101で受信したアプリ出力先を、包含されている部分のみに制限し（S2106）、公開ユーザは不整合である結果と共に制限後のアプリ出力先を返信する（S2107）。S2104の結果が全く包含関係に無いならば、整合結果は不整合であり、修正は不可能であると返信する（S2108）。
【実施形態５】
【０１５３】
次に、第５の実施形態について説明する。第１の実施形態ではアプリデプロイ受付部165がアプリデプロイを受け付けた時に、公開ユーザ整合確認部がアプリの公開ユーザの整合を確認していたが、第５の実施形態では既にデプロイされて動作中のアプリが外部出力を行おうとした時に公開ユーザの整合を確認して、出力するかどうかを決定する。
【０１５４】
第５の実施形態は、第１の実施形態と物理的な構成は同様であり、動作のみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１５５】
図２２は、第５の実施形態において、アプリ161が外部出力を行おうとした時の動作を示すシーケンス図である。図２２に示すとおり、本動作には、アプリ161、アプリミドル160、公開ユーザ整合確認部166、アプリ管理テーブル300、入出力管理テーブル200、出力先/ユーザ対応テーブル400が関連する
まず、アプリ161は、外部への出力を行おうとした時は、アプリミドル160に外部送信の要求を行い、出力先とデータを指定する（S2201）。
【０１５６】
次に、アプリミドル160は、公開ユーザ整合確認部166に、公開ユーザ整合の確認を要求し、それと共にS2201で指定された出力先とS2201を要求したアプリのIDを送信する（S2202）。
【０１５７】
公開ユーザ整合確認部166は、アプリ管理テーブル300のエントリのうち、アプリID列301がS2202で取得したアプリIDであるエントリを探し、そのエントリの入出力装置ID列304の内容を取得する（S2203）。
【０１５８】
次に、公開ユーザ整合確認部166は、入出力装置管理テーブル200のエントリのうち、入出力装置ID列201がS2203で取得した入出力装置のIDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得する（S2204）。
【０１５９】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のエントリのうち、出力先列403にS2202で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S2205）。
【０１６０】
次に、S2206において、公開ユーザ整合確認部166は、S2204で取得した入出力装置の公開ユーザ一覧と、S2205で取得した出力先が対応するユーザの一覧との整合の確認を行う。具体的には、第１の実施形態で行う公開ユーザ整合確認と同様、図９のフローチャートのS904と同等の評価を行う。
【０１６１】
次に、公開ユーザ整合確認部166はアプリミドル160に整合性確認結果を返信する（S2207）。
【０１６２】
アプリミドル160は、S2208において、S2207の整合確認結果に問題が無ければ外部出力を実行する。S2207の整合確認結果に問題がある場合は外部出力を中止する。
【０１６３】
次に、アプリミドル160は、アプリ161に外部出力結果を返す（S2209）。
【０１６４】
第５の実施形態によれば、アプリデプロイ後でも、アプリ動作中に公開ユーザの整合確認が可能となる。アプリデプロイ時に、アプリの出力先を取得できない場合は、第１の実施形態は不可能であるため、第５の実施形態が有力である。
【実施形態６】
【０１６５】
次に、第６の実施形態について説明する。第６の実施形態は、エッジノード管理者103が、アプリ161が使用している入出力装置の公開ユーザを変更するものである。
【０１６６】
第６の実施形態は、第１の実施形態と物理的な構成は同様であり、動作のみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１６７】
図２３は第６の実施形態において、エッジノード管理者161が入出力装置の公開ユーザを変更する時の動作を示すシーケンス図である。図２３に示すとおり、本動作には、エッジノード管理者161、入出力装置登録部162、公開ユーザ整合確認部166、アプリ管理テーブル300、入出力装置管理テーブル200、出力先/ユーザ対応テーブル400が関連する。
【０１６８】
まず、エッジノード管理者103は、コンソール114を使用して、入出力装置登録部162に、設定を変更する入出力装置IDと設定変更後の公開ユーザを伝える（S2301）。
【０１６９】
入出力装置登録部162は、公開ユーザ整合確認部166に、公開ユーザ整合性確認を要求し、それと共に、入出力装置IDと変更情報後の公開ユーザとを伝える（S2302）。
【０１７０】
公開ユーザ整合確認部166は、アプリ管理テーブル300のうち、入出力装置ID列304にS2302で取得した入出力装置IDが含まれるエントリを探し、そのエントリの出力先列306を取得する（S2303）。
【０１７１】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のうち、出力先列403にS2303で取得したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402を取得する（S2304）。
【０１７２】
次に、S2305において、公開ユーザ整合確認部166は、S2306で取得したアプリ出力先に対応するユーザ一覧と、S2302で取得した変更後の公開ユーザとを比較して整合性を判断する。具体的には第４の実施形態の図２１のS2104〜S2108と同様の判断を行う。すなわち、S2304で取得したアプリ出力先に対応するユーザが、S2302で取得した変更後の入出力装置の公開ユーザの範囲に包含されているかどうか比較し（2305）、包含されていない場合は包含されるようにアプリ出力先を制限してアプリ管理テーブル300の出力先列306を変更する（S2306）。なお、アプリ管理テーブル300の変更に伴って、アプリの出力先を制限するためには、第５の実施形態と同様の手法を適用する必要がある。
【０１７３】
次に、公開ユーザ整合確認部166は、入出力装置登録部162に、整合確認結果とS2306でのアプリ管理テーブルの変更結果を伝える（S2307）。
【０１７４】
次に、入出力装置登録部162は、入出力装置管理テーブル200のうち、入出力装置ID列201がS2301で受信した入出力装置IDであるエントリを探し、そのエントリの公開ユーザ列206をS2301で受信した変更後の公開ユーザに更新する（S2308）。
次に、入出力装置登録部162は、エッジノード管理者103にS2306の変更結果を返す（S2309）。
【実施形態７】
【０１７５】
次に、第７の実施形態について説明する。第７の実施形態では、入出力装置単位で公開ユーザを設定するのではなく、入出力装置が提供するAPI（Application Program Interface）毎に公開ユーザを設定可能とするものである。
【０１７６】
第７の実施形態は、第１の実施形態とは、入出力管理テーブル200とアプリ管理テーブル300が異なるのみで、他の物理的な構成や動作は同様である。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１７７】
図２４は第７の実施形態における入出力装置管理テーブル2400を示したものである。
【０１７８】
図２４に示すように、第７の実施形態における入出力装置管理テーブル2400は、入出力装置ID列2401、入出力装置名称列2402、接続列2403、入出力装置アドレス列2404、所有者列2405、API列2406、公開ユーザ列2407の各列からなる。
【０１７９】
これらの列のうち、2401〜2405は、第１の実施形態における入出力装置管理テーブル200の201〜205と同様である。
【０１８０】
API列2406は、入出力装置が提供するAPIを保持する。例えば本実施例では、入出力装置のIPカメラは画像取得APIと方向変更アクチュエータAPIを提供する。
【０１８１】
公開ユーザ列2407は、API列2406で公開するAPI毎に公開を許可するユーザを保持している。本実施例では、入出力装置IDがDev-1の IPカメラ1のAPIは、画像取得APIと方向変更アクチュエータAPI共にユーザAのみへの公開だが、入出力装置IDがDev-2のIPカメラ2は、画像取得APIはユーザAとユーザBへ公開し、方向変更アクチュエータAPIはユーザAのみへの公開としている。
【０１８２】
図２５は第７の実施形態におけるアプリ管理テーブル2500を示したものである。
【０１８３】
図２５に示すように、第７の実施形態におけるアプリ管理テーブル2500は、アプリID列2501、アプリ名称列2502、デプロイユーザ列2503、入出力装置ID列2504、入出力装置名称列2505、API列2506、出力先列2507の各列からなる。
【０１８４】
これらの列のうち、2501〜2505と2507は、第１の実施形態におけるアプリ管理テーブルの300の301〜305と306と同様である。
【０１８５】
API列2506はアプリが使用する入出力装置ではなく、APIを保持する。本実施例によれば、アプリIDがAP-11とAP-12のアプリはそれぞれIPカメラ1とIPカメラ2の画像取得APIを使用するが、方向変更アクチュエータAPIは使用しない。
【実施形態８】
【０１８６】
次に、第８の実施形態について説明する。第８の実施形態では、アプリ161は機能ブレード131に出力するのみではなく、ユーザ端末104が機能ブレード131を使用してアプリ161にリクエストのためにアクセスする機能を保持しており、リクエストのためのアクセス時に公開ユーザ整合の確認を行うものである。例えば、ユーザ端末104が希望するタイミングでエッジノード100からデータを取得する場合や、ユーザ端末104が図２４の第７の実施形態における入出力装置管理テーブル2400に示す方向変更アクチュエータAPIを使用するアプリ161にアクセスして、方向変更アクチュエータAPIを動作させる場合への適用が考えられる。
【０１８７】
第８の実施形態は、第１の実施形態と物理的な構成は同様であり、入出力装置管理テーブル200と動作シーケンスのみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１８８】
図２６は第８の実施形態におけるアプリ管理テーブル2600を示したものである。
【０１８９】
図２６に示すように、第８の実施形態におけるアプリ管理テーブル2600は、アプリID列2601、アプリ名称列2602、デプロイユーザ列2603、入出力装置ID列2604、入出力装置名称列2605、アクセス許可ユーザ列2606の各列からなる。
【０１９０】
これらの列のうち、2601〜2605は第１の実施形態におけるアプリ管理テーブル300の301〜305と同様である。
【０１９１】
アクセス許可ユーザ列2606はアプリにアクセスを許可するユーザ名を保持している。
【０１９２】
本実施例で稼動するアプリは、リクエスト元であるユーザがアプリにアクセスしてアプリが記録した画像をリクエストして取得する（PULL）タイプの画像レコーダを想定する。
【０１９３】
図２７は、第８の実施形態においてユーザ端末104が、リクエストを受信する手段や機能を有するアプリ161に、リクエストであるPULL要求を行う時の動作を示したシーケンス図である。図２７に示すように、本動作には、ユーザ端末104、アプリミドル160、公開ユーザ整合確認部166、アプリ管理テーブル2600、出力先/ユーザ対応テーブル400が関連する。
【０１９４】
まず、ユーザ端末104は、機能ブレード131とスイッチ132とネットワークI/F112を介して、PULL要求とアプリIDを送信する。PULL要求とアプリIDはアプリミドル160で受け付けられる（S2701）。
【０１９５】
アプリミドル160は、公開ユーザ整合確認部166に、公開ユーザ整合の確認を要求し、それと共に、リクエスト元のアドレスとS2701で受信したアプリIDとを渡す（S2702）。
【０１９６】
公開ユーザ整合確認部166は、アプリ管理テーブル2600のうち、アプリID列2601がS2702で取得したアプリIDであるエントリを探し、そのエントリのアクセス許可ユーザ列2606を取得する（S2703）。
【０１９７】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のうち、出力先列403にS2702で取得した要求元IPアドレスが含まれるエントリを探し、そのエントリのユーザ列402を取得する（S2704）。
【０１９８】
次に、公開ユーザ整合確認部166は、S2705において、S2703で取得したアプリにアクセス可能なユーザと、S2704で取得した要求元IPアドレスに対応するユーザとの整合を確認する。具体的には、第１の実施形態における図９のS904と同様の判断を行う。
【０１９９】
次に、公開ユーザ整合確認部166は、アプリミドル160に、整合確認結果を返す（S2706）。
【０２００】
S2706の確認結果に問題が無ければ、アプリミドル160は、アプリにS2701で受信した要求を実行させ（S2707）、実行結果をユーザ端末104まで返す（S2708）。S2707において、S2706の確認結果に問題があった場合は、アプリミドル160は、S2701で受信した要求は実行せず（S2707）、公開ユーザが不整合であったことをユーザ端末104まで返す（S2708）。
【０２０１】
図２８は第８の実施形態における公開ユーザ整合部166の動作を示したフローチャートである。
【０２０２】
まず、公開ユーザ整合部166は、図２７のS2702に示すように、公開ユーザ整合の確認要求を受信し、それと共に、要求元のアドレスとアプリIDとを受信する（S2801）。
【０２０３】
次に、公開ユーザ整合部166は、図２７のS2703に示すように、アプリ管理テーブル2600のうち、アプリID列2601がS2801で受信したアプリIDであるエントリを探し、そのエントリのアクセス許可ユーザ列2606を取得する（S2802）。
【０２０４】
次に、公開ユーザ整合部166は、図２７のS2704に示すように、出力先/ユーザ対応テーブル400のうち、出力先列403にS2801で受信した要求元IPアドレスが含まれるエントリを探し、そのエントリのユーザ列402を取得する（S2803）。
【０２０５】
次に、公開ユーザ整合部166は、図２７のS2705に示すように、S2803で取得した要求元アドレスに対応するユーザと、S2802で取得したアプリにアクセス可能ユーザとの整合を確認する。具体的には、第１の実施形態における図９のS904と同様に、要求元ユーザがアクセス可能ユーザ一覧に含まれているかどうかをチェックし（S2804）、含まれているならば整合と返信し（S2805）、含まれていないならば不整合と返信（S2806）する。
【実施形態９】
【０２０６】
次に、第９の実施形態について説明する。第９の実施形態では、エッジノードは、管理機能モジュールとアプリ動作モジュールの2つのモジュールから構成されており、1つの管理機能モジュールで複数のアプリ動作モジュールを纏めて管理可能とするものである。
【０２０７】
図２９は第９の実施形態を適用したネットワークシステムの概略図を示したブロック図である。
【０２０８】
第９の実施形態は、エッジノード100が管理モジュール2900とアプリ動作モジュール2901に分かれて上位ノード101のスイッチ132との接続が変更となった以外は、第１の実施形態と同様である。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０２０９】
管理モジュール2900は、CPU 2910、主記憶2911、ネットワークI/F 2912、コンソール2913を保持する。CPU 2910と主記憶2911はメモリバス2920で接続される。CPU 2910とネットワークI/F 2912、コンソール2913は、それぞれI/Oバス2921、2922で接続される。
【０２１０】
CPU 2910上では、入出力装置情報公開部2930、入出力装置登録部2931、ユーザ登録部2932、アプリデプロイ受付部2933、公開ユーザ整合確認部2934が動作する。
【０２１１】
主記憶2911上には、入出力管理テーブル3000、アプリ管理テーブル3100、出力先/ユーザ対応テーブル400が置かれる。
【０２１２】
CPU上で動作する各動作部2930〜2934は、動作は第１の実施形態における各動作部162〜166と同様であるが、主記憶上2911の入出力管理テーブル3000とアプリ管理テーブル3100の変更に伴って、扱うデータは変化する。
【０２１３】
アプリ動作モジュール2901は、CPU 2940、主記憶2941、ネットワークI/F 2942、I/O部2943を保持する。CPU2940と主記憶2941はメモリバス2950で接続される。CPU2940とネットワークI/F 2942、I/O部2943は、それぞれI/Oバス2951、2952で接続される。
【０２１４】
CPU2940上では、アプリミドル2960とそれを使用するアプリ2961が動作する。
【０２１５】
管理モジュール2900とアプリ動作モジュール2901は、それぞれ２つのネットワークI/F 2912を所持している。片方のネットワークI/F 2912は、バックボーンネットワーク2970に接続され、上位ノード101のスイッチ132に繋がる。もう片方のネットワークI/F 2912はエッジノード内部ネットワーク2971に接続され、エッジノード内管理ネットワーク2972で集約される。管理モジュール2900は、エッジノード内部ネットワーク2971によって、アプリ動作モジュール2901に管理操作を行うことが可能となる。
【０２１６】
なお、第２の実施形態と同様に、2つのネットワークI/F 2912は、管理モジュール290及びアプリ動作モジュール2901が物理的に2つ所持しても構わないし、1つのネットワークI/FをVLANなどによって論理的に2つに見せても構わない。
【０２１７】
図３０は第９の実施形態における入出力装置管理テーブル3000を示したものである。
【０２１８】
図３０に示すように、第９の実施形態における入出力装置管理テーブル3000は、アプリ動作モジュール番号列3001、入出力装置ID列3002、入出力装置名称列3003、接続列3004、入出力装置アドレス列3005、所有者列3006の各列からなる。
【０２１９】
アプリ動作モジュール番号列3001は、アプリ動作モジュールの番号を示している。本実施例では、Func-1、Func-2・・・としている。
【０２２０】
列3002〜3007は、第１の実施形態における入出力管理テーブル200の列201〜205と同様である。
【０２２１】
図３１は第９の実施形態におけるアプリ管理テーブル3100を示したものである。
【０２２２】
図３１に示すように、第９の実施形態におけるアプリ管理テーブル3100は、アプリ動作モジュール番号列3101、アプリID列3102、アプリ名称列3103、デプロイユーザ列3104、入出力装置ID列3105、入出力装置名称列3106、出力先列3107の各列からなる。
【０２２３】
アプリ動作モジュール番号列3101は、図３０に示す入出力装置管理テーブル3000のアプリ動作モジュールの番号列3001と同様、アプリ動作モジュールの番号を示しており、表記も同様にFunc-1、Func-2・・・としている。
【０２２４】
列3102〜3107は、第１の実施形態におけるアプリ管理テーブル300の列301〜306と同様である。
【０２２５】
第９の実施形態では、入出力管理テーブル3000とアプリ管理テーブル3100がアプリ動作モジュール番号列3001、3101を所持することで、管理モジュール2900は、複数のアプリ動作モジュール2901を識別してそれぞれ管理することが可能となる。
【０２２６】
以上本発明の種々の実施形態を詳述してきたが、本発明はこれらの実施形態に限定されるものではなく、例えば、図１、図１０、図１４、図２９に示したネットワークシステム構成の様に、ネットワークノードが二層に構成された場合のみならず、上位ノードの更に上位にデータセンタ等の最上位のノードがネットワークを介して接続される様な三層、あるいはそれ以上の階層に構成されたネットワークシステムにも適用可能であることは言うまでもない。この場合、ネットワークシステム管理者は、データセンタのサーバ等、より上位の階層のノードのサーバや管理ブレード等から種々の情報を入力することも可能であることは言うまでもない。
【産業上の利用可能性】
【０２２７】
本発明は、工場監視用のセンサコントローラ、画像監視システムを、複数のユーザで共用する時の権限管理に適する情報処理システムとして有用である。
【符号の説明】
【０２２８】
100、1000、1400…エッジノード
101、1001、1401…上位ノード
102…入出力装置部
103…エッジノード管理者
104…ユーザ端末
105…ユーザ
106…ネットワークシステム管理者
110、133、2910、2940…CPU
111、134、2911、2941…主記憶
112、135、1010、2912、2942…ネットワークI/F
113、2943…I/O部
114、136、2913…コンソール
120、141、2920、2950…メモリバス
121、122、123、142、143、1011、2921、2922、2951、2952…I/Oバス
124…入出力装置部ネットワーク
125、153、154…入力I/F
130…管理ブレード
131…機能ブレード
132、1012…スイッチ
150、1020、2970…バックボーンネットワーク
151…上位ノード内部ネットワーク
152…ローカルネットワーク
160、2960…アプリミドル
161、2961…アプリ
162、1030、1410、2930…入出力装置登録部
163、1031、1411、2931…入出力装置情報公開部
164、1032、2932…ユーザ登録部
165、1033、1412、2933…アプリデプロイ受付部
166、1034、1413、2934…公開ユーザ整合確認部
200、1500、3000…入出力装置管理テーブル
300、1100、1600、3100…アプリ管理テーブル
400、1200…出力先/ユーザ対応テーブル
1402…DHCPサーバ
1403…DNSサーバ
1404…リレーネットワーク
2900…エッジノード管理モジュール
2901…エッジノードアプリ動作モジュール
2971…エッジノード内ネットワーク
2972…エッジノード内管理系ネットワーク。
【技術分野】
【０００１】
本発明は、カメラやセンサ等の入出力装置を持つネットワークノードを複数のユーザで共有する場合の権限管理に関し、特にユーザがネットワークノードにアプリケーションを投入するときに発生する権限違反を防ぐための権限管理技術に関する。
【背景技術】
【０００２】
従来、情報技術(Information Technology：IT)サービスはそれぞれ個別のIT装置を用いて、サイロ化した状態で提供されていた。近年のクラウド化の流れに伴い、複数のITサービスが同じプラットフォームを利用する、マルチテナントが拡大している。
【０００３】
ITサービスの１つに、インターネット・プロトコル(Internet Protocol：IP)カメラやセンサ等の実世界の情報を取得する入出力装置を使用した監視サービスがある。監視サービスをマルチテナントで提供するためのプラットフォームには、複数の入出力装置を所持し、それらの入出力装置からの入力データを統合して平均化やサマライズといった一次処理を行う、エッジノードが有力である。複数のユーザがエッジノードを共有し、各ユーザがそれぞれ一次処理を行うためのアプリケーションをエッジノードに投入することで、エッジノード上でユーザ毎のサービスが稼動する。この、エッジノードへのアプリケーションの投入を、”デプロイ”と呼ぶ。
【０００４】
複数ユーザでエッジノードを共有するにあたり、ユーザ毎の利用権限の管理が必須となる。このような利用権限管理に関する例として、特許文献１では、アプリケーションが使用するリソースに対するアクセスを制御する情報処理装置及び情報処理プログラムが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２３３９４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１で開示されている技術によれば、エッジノードの所持する入出力装置やアプリケーションのそれぞれに公開ユーザを設定可能である。
【０００７】
しかし、ユーザからのアプリケーションデプロイを受け入れるエッジノードでは、入出力装置の公開ユーザの設定者と、アプリケーションの出力先の設定者が異なる可能性が考えられる。
【０００８】
従って、アプリケーションの出力先と、アプリケーションが処理するデータを入力する入出力装置の公開ユーザは必ずしも一致しておらず、もし、入出力装置からの入力データを一次処理して、入出力装置の公開ユーザ以外へ出力するアプリケーションがデプロイされてしまうと、公開範囲違反が発生してしまう。
【０００９】
従って、アプリケーションのデプロイ時に、アプリケーションの出力先と入出力装置の公開ユーザの整合を確認しなくてはならない課題がある。
【００１０】
本発明の目的は、上記の課題を解決し、入力データを処理して出力するアプリケーションをデプロイする時に、アプリケーションの出力先と入出力装置の公開ユーザとの整合性を保証することが可能なネットワークノード、情報処理システムおよび方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記の目的を達成するため、本発明においては、ネットワークノードとして、１つ以上の入出力装置からデータの入力を受け付け、入出力装置から入力されたデータを処理して出力するアプリケーションが稼動する処理部と、入出力装置の公開範囲を保持する記憶部とを備え、処理部は、アプリケーションの投入を受け付ける際に、アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、アプリケーションの投入の受付可否を判断するネットワークノードを提供する。
【００１２】
また、上記の目的を達成するため、本発明においては、複数の入出力装置と入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードとを有する情報処理システムであって、ネットワークノードに、入出力装置の公開範囲データを保持しておき、ネットワークノードが、アプリケーションの投入を受け付ける際に、保持した公開範囲データに基づき、アプリケーションの出力先が、アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、アプリケーションの投入の受付可否を判断する情報処理システムを提供する。
【００１３】
更に、上記の目的を達成するため、本発明においては、１つ以上の入出力装置からデータの入力を受け付け、入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードにおける情報処理方法であって、ネットワークノードに入出力装置の公開範囲データを保持しておき、アプリケーションの投入を受け付ける場合に、この公開範囲データに基づき、アプリケーションの出力先が、アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、当該アプリケーションの投入の受付可否を判断するネットワークノードにおける情報処理方法を提供する。
【００１４】
すなわち、本発明では、上記の目的を解決するため、エッジノードなどのネットワークノードはアプリケーションの出力先とユーザの対応を管理するテーブルを持つ。ネットワークノードを利用するユーザは、予めそのテーブルに使用する出力先の情報を登録しておく。ネットワークノードは、ユーザからアプリケーションのデプロイを受け付ける時に、アプリケーションの出力先に登録されているユーザが、アプリケーションの使用する入出力装置が公開を許可するユーザと整合しているかを確認し、デプロイの可否を判断する。
【発明の効果】
【００１５】
本発明によれば、入出力装置の公開ユーザがアプリケーションの公開ユーザに引き継がれるため、アプリケーションの送信先ミスによるデータの誤送信の防止が可能となる。また、高いセキュリティを維持しつつ複数ユーザの入出力装置とアプリケーションの統合が可能となる。また、同一の入出力装置を用いて複数のサービスを展開出来るため、コストを低減可能である。
【図面の簡単な説明】
【００１６】
【図１】第１の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図２】第１の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図３】第１の実施形態においてエッジノードで動作するアプリケーション（以下、アプリ）一覧を管理する管理テーブルの一例を示す図である。
【図４】第１の実施形態においてエッジノードを利用するユーザの出力先一覧を管理する管理テーブルの一例を示す図である。
【図５】第１の実施形態においてエッジノード管理者がエッジノードに入出力装置を追加する時の処理の一例を示すシーケンス図である。
【図６】第１の実施形態においてユーザがエッジノードの入出力装置情報を取得するときの処理の一例を示すシーケンス図である。
【図７】第１の実施形態においてネットワークシステム管理者がエッジノード利用ユーザとその出力先一覧を登録するときの処理の一例を示すシーケンス図である。
【図８】第１の実施形態においてユーザがエッジノードにアプリをデプロイする時の処理の一例を示すシーケンス図である。
【図９】第１の実施形態においてユーザがエッジノードにアプリをデプロイする時に公開ユーザの整合を確認する処理の一例を示すフローチャート図である。
【図１０】第２の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図１１】第２の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図１２】第２の実施形態においてエッジノードを利用するユーザの出力先一覧を管理する管理テーブルの一例を示す図である。
【図１３】第２の実施形態においてネットワークシステム管理者がエッジノードに管理操作を要求した時に管理権限の有無を確認する処理の一例を示すフローチャート図である。
【図１４】第３の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図１５】第３の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図１６】第３の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図１７】第３の実施形態においてエッジノード管理者がエッジノードに入出力装置を追加する時の処理の一例を示すシーケンス図である。
【図１８】第３の実施形態においてユーザがエッジノードにアプリをデプロイする時の処理の一例を示すシーケンス図である。
【図１９】第３の実施形態においてユーザがエッジノードにアプリをデプロイする時に公開ユーザの整合を確認する処理の一例を示すフローチャート図である。
【図２０】第４の実施形態においてユーザがエッジノードにアプリをデプロイする時の処理の一例を示すシーケンス図である。
【図２１】第４の実施形態においてユーザがエッジノードにアプリをデプロイする時に公開ユーザの整合を確認する処理の一例を示すフローチャート図である。
【図２２】第５の実施形態においてアプリがデータ出力を要求したときの処理の一例を示すシーケンス図である。
【図２３】第６の実施形態においてエッジノード管理者が入出力装置の公開範囲を変更した時の処理の一例を示すフローチャート図である。
【図２４】第７の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図２５】第７の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図２６】第８の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【図２７】第８の実施形態においてユーザ端末がエッジノードで動作するアプリにアクセスする場合の処理の一例を示すシーケンス図である。
【図２８】第８の実施形態においてアプリのアクセス権限を確認する処理の一例を示すシーケンス図である。
【図２９】第９の実施形態におけるネットワークシステムの概略構成の一例を示す図である。
【図３０】第９の実施形態においてエッジノードに付属する入出力装置一覧を管理する管理テーブルの一例を示す図である。
【図３１】第９の実施形態においてエッジノードで動作するアプリ一覧を管理する管理テーブルの一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、本発明の実施形態を図面に基づいて詳細に説明する。各図における同一符号は同一物あるいは相当物を示す。また、類似物については、説明の都合上、符号に添え字を追加して区別することがある。また、先にも述べたように、本明細書において、エッジノードへのアプリケーションの投入を、”デプロイ”と呼ぶ。なお、本明細書において、入出力装置という場合、入出力両機能を有する装置のみを意味するのでなく、入力機能のみを有する装置、出力機能のみを含む装置、さらには入出力の両機能を有する装置の何れかを意味するものである点を留意されたい。また、ネットワークノードの処理部で実行される各種のプログラム、またはその一部を、「部」、「ユニット」、「手段」、「機能」等と呼ぶ場合がある。
【実施形態１】
【００１８】
図１は、第１の実施形態に係るネットワークシステムの概略を示したブロック図である。本実施例のネットワークシステムは、ネットワークノードであるエッジノード100、同じくネットワークノードである上位ノード101からなり、エッジノード100には少なくとも一個の入出力装置を備える入出力装置部102と、エッジノード管理者103がアクセスし、上位ノードにはユーザ端末104とユーザ105とネットワークシステム管理者106がアクセスする。
【００１９】
エッジノード100は、処理部である中央処理部（Central Processing Unit：CPU）110、記憶部である主記憶111、インタフェース部であるネットワークインタフェース(Interface：I/F)112、入出力部(Input/Output：I/O)部113、コンソール114を保持し、CPU110と主記憶111間はメモリバス120で接続され、CPU110とネットワークI/F112、CPU110とI/O部113、CPU110とコンソール114間はそれぞれI/Oバス121、122、123で接続される。
【００２０】
I/O部113と入出力装置部102は、入出力装置のI/F124で接続される。入出力装置が接続されるI/O部113とI/F 124の規格は特には指定せず、例えばイーサネット（登録商標：Ethernet）、PCI(Peripheral Component Interconnect)、PCI Express、USB(Universal Serial Bus)、IEEE1394と言った規格が考えられる。エッジノード管理者103はコンソール114に対して直接入力I/F125でアクセスを行う。
【００２１】
上位ノード101は管理ブレード130と機能ブレード131とスイッチ132の組み合わせからなる。
【００２２】
管理ブレード130は、CPU133、主記憶134、ネットワークI/F135、コンソール136を保持し、CPU133と主記憶134間はメモリバス141で接続され、CPU133とネットワークI/F135、CPU133とコンソール136はそれぞれI/Oバス142、143で接続される。
【００２３】
機能ブレード131は、CPU133、主記憶134、ネットワークI/F135を２つ保持し、CPU133と主記憶134間はメモリバス141で接続され、CPU133とネットワークI/F135はI/Oバス142で接続される。
【００２４】
エッジノード100のネットワークI/F112と上位ノード101のスイッチ132はバックボーンネットワーク150で接続される。上位ノード101のスイッチ132と管理ブレード130、スイッチ132と機能ブレード131はそれぞれ装置内ネットワーク151で接続される。機能ブレード131とユーザ端末104はアクセスネットワーク152で接続される。
【００２５】
ネットワークシステム管理者106とユーザ105はそれぞれ上位ノード101のコンソール136に直接入力I/F153でアクセスする。ユーザ105はユーザ端末104に端末I/F154でアクセスする。
【００２６】
エッジノード100のCPU110では、アプリケーションミドルウェア（以下、アプリミドル）160とそれを利用するアプリケーション（以下、アプリ）161、入出力装置登録部162、入出力装置情報公開部163、ユーザ登録部164、アプリケーションデプロイ（以下、アプリデプロイ）受付部165、公開ユーザ整合確認部166などがプログラムとして動作する。なお、これらのプログラムは主記憶１１１などの記憶部に記憶され、必要に応じてCPU110に導入され、実行される。なお、アプリミドル160は、アプリ161が使用するライブラリのセットである。
【００２７】
エッジノード100の主記憶には、その他、入出力装置管理テーブル200、アプリ管理テーブル300、出力先/ユーザ対応テーブル400が保存される。なお、本実施形態では以上の3つのテーブルを保持しているが、管理項目を保持するテーブルの構成は本発明の本質とは無関係であり、別の実施形態として、これらのテーブルが保持する管理項目を1〜2つのテーブルに纏めて保持しても構わない。
【００２８】
アプリ161は、入出力装置部102からの入力を受け取って一次処理を行い、上位ノード101の機能ブレード131へと送信する。
【００２９】
入出力装置登録部162は、入出力装置部102の情報を入出力装置管理テーブル200に登録する機能を所持する。例えばエッジノード管理者103が入出力装置部102に入出力装置を追加する場合に、入出力装置登録部162を使用する。
【００３０】
入出力装置情報公開部163は、入出力装置管理テーブル200の登録内容を、ユーザ105、ネットワークシステム管理者106、エッジノード管理者103に公開する機能を所持する。
【００３１】
ユーザ登録部164は、ユーザ毎の出力先/ユーザ対応テーブル400に登録する機能を所持する。ネットワークシステム管理者106、エッジノード管理者103はユーザ登録部164を使用し、ユーザ毎の使用アドレスを、出力先/ユーザ対応テーブル400に登録する。
【００３２】
アプリデプロイ受付部165は、アプリのデプロイを受付け、アプリ管理テーブル300を更新する機能を所持する。ユーザ105はエッジノード100にアプリを配布する時にアプリデプロイ受付部165を使用する。
【００３３】
公開ユーザ整合確認部166は、入出力装置管理テーブル200に設定された公開ユーザと、アプリ管理テーブル300と出力先/ユーザ対応テーブル400に設定されたアプリの出力先との整合性をチェックする機能を持つ。本実施例では、公開ユーザ整合確認部166は、ユーザ105がアプリデプロイ受付部165を使用してアプリをデプロイする時に、アプリの出力権限の整合性が取れているかどうかを確認するために動作する。
【００３４】
次に、第１の実施形態が適用されたネットワークシステムにおいて、エッジノード100が保持する管理テーブルの構成を説明する。
【００３５】
図２は、入出力装置管理テーブル200を示したものである。図２に示すように、入出力装置管理テーブル200は、入出力装置識別子(Identifier：ID)列201、入出力装置名称列202、接続列203、入出力装置アドレス列204、所有者列205、公開ユーザ列206の各列からなる。
【００３６】
入出力装置ID列201は、入出力装置管理テーブル200で管理する入出力装置のIDを保持する。本実施形態ではDev-1、Dev-2・・・としている。入出力装置名称列202は入出力装置の名称を保持する。本実施形態ではIPカメラ1、IPカメラ2・・・と名称の次にシリアル番号を割り当てている。
【００３７】
接続列203は入出力装置の接続形態を保持する。本実施形態では接続プロトコルの情報としてTCP/IPを保持している。他に入出力装置の接続プロトコルとしては、PCI、PCI-Express、USB、IEEE1394などの規格も考えられる。
【００３８】
入出力装置アドレス列204は各入出力装置のアドレスを保持する。入出力装置アドレス列204は接続列203に対応しており、両者の組み合わせによって入出力装置へのアクセス先が一意に特定可能なものである。例えば本実施形態では接続列203が保持する接続形態はTCP/IP(Transmission Control Protocol/Internet Protocol)であり、入出力装置アドレス列ではIPアドレスとポート番号を保持している。他の接続形態の場合はそれに応じたアドレスを保持することになり、例えば接続形態がPCIバスの場合はバス番号・デバイス番号・ファンクション番号を保持すると考えられる。
【００３９】
所有者列205は入出力装置の所有ユーザを保持する。公開ユーザ列206は入出力装置を閲覧したり、使用する権限を持つユーザ105の一覧を保持する。
【００４０】
図３は、アプリ管理テーブル300を示したものである。図３に示すようにアプリ管理テーブル300は、アプリID列301、アプリ名称列302、デプロイユーザ列303、入出力装置ID列304、入出力装置名称列305、出力先列306の各列からなる。
【００４１】
アプリID列301は、アプリ管理テーブル300で管理するアプリのIDを保持する。本実施形態ではAP-1、AP-2・・・としている。アプリ名称列302は、アプリの名称を保持する。
【００４２】
デプロイユーザ列303は、アプリをデプロイしたユーザ情報を保持する。
【００４３】
入出力装置ID列304は、アプリが使用する入出力装置IDの一覧を保持する。入出力装置名称列305は、入出力装置ID列304で参照する入出力装置の名称の一覧を保持する。
【００４４】
出力先列306は、アプリの出力先を保持する。本実施例では、アプリの出力はTCP/IPによる上位ノード101の機能ブレード131への送信を想定しており、IPアドレスとポート番号を保持している。
【００４５】
図４は、出力先/ユーザ対応テーブル400を示したものである。図４に示すように出力先/ユーザ対応テーブル400は、登録ID列401、ユーザ列402、出力先列403の各列からなる。
【００４６】
登録ID列401は、出力先/ユーザ対応テーブルが管理する出力先/ユーザ対応の組み合わせのIDを保持する。本実施例では＃１、＃２、＃３・・・としている。ユーザ列402は出力先/ユーザ対応の組み合わせにおいて、ユーザを保持する。
【００４７】
出力先列403は出力先/ユーザ対応の組み合わせにおいて、ユーザ列402で示すユーザが登録する出力先を保持する。出力先は必ずしも１通りではなく、１ユーザが複数の出力先アドレスを使用する場合も考えられる。本実施形態ではユーザ毎のIPアドレスのユーザのポート番号を保持している。
【００４８】
次に、第１の実施形態が適用されたネットワークシステムの動作を説明する。
【００４９】
図５は、エッジノード管理者103が入出力装置を追加するときの動作を示したシーケンス図である。図５に示すように、本動作には、エッジノード管理者103、入出力装置登録部162、入出力装置管理テーブル200が関連する。
【００５０】
まず、エッジノード管理者103は、S501でエッジノード100に入出力装置を接続する。次に、エッジノード管理者103は、コンソール114を使用して、入出力装置登録部162にS501で接続した入出力装置の登録を要求し、それと共に、入出力装置の装置情報（名称、接続、入出力装置アドレス、所有者、公開ユーザ）を伝える（S502）。
【００５１】
次に、入出力装置登録部162は、入出力装置登録テーブル200に格納されているエントリの一覧を取得する（S503）。
【００５２】
次に、入出力装置登録部162は、S504において、S503で取得したエントリ一覧の中に、S502で登録を要求された入出力装置の情報と同一装置のエントリが存在しているかどうかチェックし、登録の可否を判定する。具体的には、同一装置のエントリが存在していなければ登録可能と判定し、同一装置のエントリが存在している場合は、新規にエントリを登録すると入出力装置管理テーブル200のエントリとコンフリクトするため、登録不可能と判定する。
【００５３】
次に、入出力装置登録部162は、S504で登録可と判断した場合は、入出力装置ID列201において重複しない入出力IDを割当て、入出力装置管理テーブル200にエントリを追加する（S505）。
【００５４】
次に、入出力装置登録部162は、エッジノード管理者103に登録要求の結果を返す（S506）。
【００５５】
図６は、ユーザ105が入出力装置管理テーブル200より入出力装置情報を取得する動作を示したシーケンス図である。図６に示すように、本動作には、ユーザ105、入出力装置公開部163、入出力装置管理テーブル200が関連する。
【００５６】
まず、ユーザ105は、管理ブレード130のコンソール136を使用して、入出力装置情報公開部163に、ユーザ105に公開されている入出力装置情報の要求を送る（S601）。
【００５７】
次に、入出力装置情報公開部163は、入出力装置管理テーブル200のうち、公開ユーザ列206にS601を要求したユーザが含まれる入出力装置のエントリを検索して、そのエントリの装置情報である入出力装置ID列201と入出力装置名称列202とを取得する（S602）。
【００５８】
次に、入出力装置163は、ユーザ105に、S602で取得した入出力装置の一覧とその装置情報（入出力装置ID、入出力装置名称）を返す（S603）。
【００５９】
図７は、ネットワークシステム管理者106が出力先/ユーザ対応テーブル400に、エッジノード100を使用するユーザ105と、そのユーザに対応する出力先の登録を行う動作を示したシーケンス図である。図７に示すように、本動作には、ネットワークシステム管理者106、ユーザ登録部164、出力先/ユーザ対応テーブル400が関連する。
【００６０】
まず、ネットワークシステム管理者106は、S701において、管理ブレード130のコンソール136を使用して、ユーザ登録部164に、ユーザ登録の要求を要求し、それと共に、ユーザ情報（ユーザ名、ユーザの使用アドレス範囲）を伝える。
【００６１】
次に、ユーザ登録部164は、出力先/ユーザ対応テーブル400に格納されているエントリの一覧を取得する（S702）。
【００６２】
次に、ユーザ登録部164は、S703において、S702で取得したエントリ一覧の中に、S701で登録を要求されたユーザと同一ユーザのエントリが存在しているかどうかチェックし、登録の可否を判定する。具体的には、同一ユーザのエントリが存在していなければ登録可能と判定し、同一ユーザのエントリが存在している場合は、新規にエントリを登録するとコンフリクトとなるため、登録不可能と判定する。
【００６３】
次に、ユーザ登録部164は、S703で登録可と判断した場合は、登録ID列401において重複しない登録IDを割当て、出力先/ユーザ対応テーブル400にエントリを追加する（S704）。
【００６４】
次に、ユーザ登録部162は、ネットワークシステム管理者106に登録要求の結果を返す（S705）。
【００６５】
入出力装置管理テーブル200に入出力装置部102の情報が登録され、出力先/ユーザ対応テーブル400にユーザ105の出力先が登録された後、ユーザ105はエッジノード100にアプリをデプロイする。
【００６６】
アプリは、指定する入出力装置部102から入力データを取得し、CPU110で一次処理を行い、指定した機能ブレード131へ送信する、一連の動作を行うと想定する。
【００６７】
図８は、ユーザ105がエッジノード100にアプリをデプロイする動作を示したシーケンス図である。図８に示すように、本動作には、ユーザ105、アプリデプロイ受付部165、公開ユーザ整合確認部166、入出力装置管理テーブル200、出力先/ユーザ対応テーブル400、アプリ管理テーブル300が関連する。
【００６８】
まず、ユーザ105は、S801において、管理ブレード130のコンソール136を使用して、アプリデプロイ受付部165に、アプリデプロイを要求し、それと共に、デプロイするアプリの情報を送る。
【００６９】
アプリデプロイ受付部165は、S802において、公開ユーザ整合確認部166に、公開ユーザ整合確認を要求し、それと共に、S801で受信したアプリが使用する入出力装置のIDとアプリの出力先とを送る。
【００７０】
公開ユーザ整合確認部166は、まず、入出力装置管理テーブル200のエントリのうち、入出力装置ID列201がS802で受信したアプリが使用する入出力装置のIDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得する（S803）。S803で取得したユーザ一覧は、アプリが使用する入出力装置の公開ユーザの一覧に相当する。ちなみに、アプリが複数の入出力装置を使用し、それぞれの入出力装置で異なる公開ユーザ一覧を設定している場合も考えられる。その場合、公開ユーザ整合確認部166は全ての公開ユーザ一覧のANDをとったものを使用する。
【００７１】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のエントリのうち、出力先列403にS802で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S804）。S804で取得したユーザは、アプリ出力先に対応するユーザに相当する。
【００７２】
次に、S805において、公開ユーザ整合確認部166はS803で取得した公開ユーザ一覧と、S804で取得したアプリ出力先に対応するユーザとの整合を確認し、アプリデプロイ受付部165に結果を伝える（S806）。
【００７３】
次に、S806の確認結果が整合であれば、アプリデプロイ受付部165は、S807でアプリをデプロイし、アプリ管理テーブル300に、アプリID列301において重複しないIDを割り当てて、エントリを追加する（S808）。S806の確認結果が不整合であれば、アプリデプロイ受付部165は、S807とS808に示す、アプリデプロイとアプリ管理テーブル300の更新は実施しない。
【００７４】
次に、アプリデプロイ受付部165は、ユーザ105にデプロイ要求結果を返す（S809）。
【００７５】
以上のように、ユーザ105がアプリのデプロイを要求したときに、アプリ出力先に対応するユーザが、アプリが使用する入出力装置の公開ユーザ一覧と整合しているかチェックすることで、アプリの出力先は入出力装置が設定した公開ユーザに従っていると保証可能となる。
【００７６】
図９は、エッジノード100がアプリデプロイを受け付ける時に、CPU110でプログラムとして動作する公開ユーザ整合確認部166が行う処理を示すフローチャートである。
【００７７】
まず、公開ユーザ整合確認部166は、図８のS802に示すように、公開ユーザ整合確認の要求を受け、それと共に、アプリ情報（アプリが使用する入出力装置のID、アプリの出力先）を受信する（S901）。
【００７８】
次に、公開ユーザ整合確認部166は、図８のS803に示すように、入出力装置管理テーブル200から、入出力装置ID列201が、S901で受信したアプリが使用する入出力装置IDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得して、公開ユーザ一覧とする（S902）。
【００７９】
次に、公開ユーザ整合確認部166は、図８のS804に示すように、出力先/ユーザ対応テーブル400から、出力先列403にS802で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S903）。
【００８０】
次に、公開ユーザ整合確認部166は、図８のS805に対応して、S903で取得したユーザが、S902で取得したユーザ一覧に含まれているかどうかを確認する（S904）。
【００８１】
S904の結果がYesであれば、アプリ出力先が対応するユーザは、アプリの使用する入出力装置の公開ユーザ一覧と整合しているので、整合確認部166は、公開ユーザは整合であることを返信する（S905）。S904の結果がNoであれば、公開ユーザ整合確認部166は、公開ユーザが不整合であると返信する（S906）。
【００８２】
以上説明した第1の実施形態では、エッジノードからのネットワークインタフェースは１つである。しかし、複数ユーザでネットワークシステムを共有するにあたり、管理系の操作と業務系の操作で別々のパスを使用したり、業務系の操作でも各ユーザが別々のパスを使用して、操作の独立性を保証してセキュリティを高めた運用形態が考えられる。
【００８３】
図１に示すネットワークシステムにおいて、管理系と業務系で別々のパスを使用する運用形態を行うためには、ネットワークI/F112、スイッチ132、バックボーンネットワーク150を論理的に分割することで、エッジノード100間と上位ノード101間に複数のパスを構成するアプローチが考えられる。
【００８４】
具体的なアプローチの例を説明する。まず、エッジノード100は、VLAN（Virtual Local Area Network）を用いて、1つのネットワークI/F 112を、仮想的に複数のネットワークI/Fであるように見せる。次に、上位ノード101のスイッチ132は、VLANを適用することにより、1つのスイッチ132を仮想的に複数のスイッチであるように見せる。最後に、ネットワークI/F112とスイッチ132との間をVLANに対応するバックボーンネットワーク150で繋ぐことで、エッジノード100のネットワークI/F 112と上位ノード101のスイッチ132の間に、仮想的な複数のパスが張られる。
【００８５】
また、仮想的なアプローチだけではなく、必要なパスに応じて、複数の物理ネットワークI/F112やスイッチ132を所持するようなネットワークシステムを構築することも考えられる。
【００８６】
このように、複数のパスを使用するためには、仮想的なアプローチと物理的なアプローチの2通りが考えられるが、効果は同様である。
【実施形態２】
【００８７】
次に、第２の実施形態として、エッジノード100と上位ノード101間に、複数の物理的パスを持ち、管理系と業務系のパスを分割可能とするネットワークシステムを考える。
【００８８】
図１０は第２の実施形態を適用したネットワークシステムの概略を示すブロック図である。
【００８９】
まず、第２の実施形態におけるエッジノード1000について、第１の実施形態との差分を説明する。エッジノード1000は、接続先である管理ブレード130と機能ブレード131の数に応じてネットワークI/F1010を所持する。CPU110とネットワークI/F1010はI/Oバス1011で接続される。
【００９０】
次に、第２の実施形態における上位ノード1001について、第1の実施形態との差分を説明する。上位ノード1001は接続先のセグメント毎にスイッチ1012を所持する。
【００９１】
バックボーンネットワーク1020の構成は、インタフェース部であるネットワークI/F1010やスイッチ1012の構成に依存する。具体的には、ネットワークI/F1010、1010(2)、1010(3)やスイッチ1012、1012(2)、1012(3)が物理的に複数存在する場合は同様に物理的に複数存在し、ネットワークI/F1010やスイッチ1012が論理的に分割されている場合は同様に論理的に分割される。
【００９２】
第２の実施形態では、ネットワークシステム管理者106とユーザ105は別々のパスを使用する。そのため、エッジノード1000の公開ユーザ整合確認部1034は、アプリの動作権限の確認のみでなく、管理操作の要求を受信した際に管理操作の要求元が管理操作を行う権限があるかどうかを使用パスによって判断可能である。具体的には、入出力装置登録部1030、入出力装置情報公開部1031、ユーザ登録部1032、アプリデプロイ受付部1033は、ネットワークシステム管理者106或いはユーザ105より管理操作の要求を受けた時に、公開ユーザ整合確認部1034に管理操作を行う権限の確認を要求し、権限の有無によって管理操作を受け付けるかどうか決定する。
【００９３】
図１１は、第２の実施形態におけるアプリ管理テーブル1100を示したものである。図１１に示すように、アプリ管理テーブル1100は、アプリID列1101、アプリ名称列1102、デプロイユーザ列1103、入出力装置ID列1104、入出力装置名称列1105、出力先列1106に加え、使用パス列1107の各列からなる。
【００９４】
これらの列のうち1101〜1106は、第１の実施形態におけるアプリ管理テーブル300と同様であるため、差分である使用パス列1107のみ説明する。
【００９５】
使用パス列1107は、アプリがデータ出力時に使用するパスを保持している。それぞれのパスは、エッジノード1000のネットワークI/F1010、バックボーンネットワーク1020、上位ノード1001のスイッチ1011までの経路を指す。使用パス列1107の名づけルールは、本実施形態では業務パス-1、業務パス-2・・・としている。
【００９６】
図１２は、第２の実施形態における出力先/ユーザ対応テーブル1200を示したものである。図１２に示すように出力先/ユーザ対応テーブル1200は、登録ID列1201、ユーザ列1202、出力先列1203、使用パス列1204の各列からなる。
【００９７】
これらの列のうち1201〜1203は、第１の実施形態における出力先/ユーザ対応テーブル400と同様であるため、差分である使用パス列1204のみ説明する。
【００９８】
使用パス列1204は、ネットワークシステム管理者106やユーザ105が使用するパスを保持する。ユーザ105と使用パスの組み合わせはポリシーによるが、セキュリティを重視する場合は、エントリ1220〜1222のように、ユーザ105毎に別々の業務パスを割当て、通信における他ユーザからの干渉を防止する適用形態が考えられる。
【００９９】
第２の実施形態における出力先/ユーザ対応テーブル1200は、ユーザ105が使用する業務パスのエントリ1220〜1222だけでなく、ネットワークシステム管理者106が使用する管理パスのエントリ1210も保持している。
【０１００】
第２の実施形態における公開ユーザ整合確認部1034は、出力先/ユーザ対応テーブル1200を参照して、管理要求元が管理パスに含まれるかどうかを判断可能である。
【０１０１】
図１３は、公開ユーザ整合確認部1034が、管理操作要求元の権限をチェックする動作を示したフローチャートである。
【０１０２】
まず、入出力装置登録部1030、入出力装置情報公開部1031、ユーザ登録部1032、アプリデプロイ受付部1033は、ネットワークシステム管理者106から管理操作の要求を受信すると、公開ユーザ整合確認部1034に管理権限の確認を要求し、それと共に、管理操作要求元のアドレスを伝える（S1301）。
【０１０３】
次に、公開ユーザ整合確認部1034は、出力先/ユーザ対応テーブル1200から、使用パス列1204が管理操作権限のある管理パスであるエントリを探し、そのエントリのユーザ列1202を取得する（S1302）。
【０１０４】
次に、公開ユーザ整合確認部1034は、出力先/ユーザ対応テーブル1200から、S1301で受信した管理操作要求元アドレスが、出力先列1203に含まれるユーザを取得する（S1903）。
【０１０５】
次に、公開ユーザ整合確認部1034は、S1303で取得した管理操作要求元に対応するユーザが、S1304で取得した管理パスの対応ユーザの一覧に含まれているかどうかを判断する（S1304）。
【０１０６】
S1304の結果がYesであれば、公開ユーザ整合確認部1034は、管理操作を実行する権限ありと返信し（S1305）、S1304の結果がNoであれば、公開ユーザ整合確認部1034は、管理操作を実行する権限なしと返信する（S1306）。
【０１０７】
なお、本実施例ではネットワークシステム管理者のみに管理権限がある想定だが、ユーザ105にも一部の管理権限を与えて、ユーザ105が各動作部1030〜1034に管理要求を送った時にこのシーケンスと同様に権限を確認する実施形態も考えられる。
【０１０８】
第２の実施形態において、ユーザ105毎に別々のパスを割り当てた場合、ユーザ毎の通信内容は干渉しない。この実施形態において、DHCPサーバとDNSサーバにより、パス毎にドメイン名とIPアドレス領域を設定して自動的にIP割り振ることで、IPアドレスの設定や解決を省略可能であり、出力先の整合性確認のステップも簡略化可能となる。
【実施形態３】
【０１０９】
そこで、DHCPサーバとDNSサーバによってIPアドレスの設定や解決を自動化する、第３の実施形態を考える。
【０１１０】
図１４は、第３の実施形態を適用したネットワークシステムの概略を表すブロック図である。第２の実施形態との差分を説明する。
【０１１１】
上位ノード1401にはDHCPサーバ1402とDNSサーバ1403が存在し、ネットワークシステム管理者106とユーザ105が使用するパスにおいて、IPアドレス設定やホスト名の解決を行う。
【０１１２】
DHCPサーバ1402とDNSサーバ1403はパス毎に1つずつ存在しても良いが、スイッチ1011がリレー機能を適用可能ならば、1つのDHCPサーバ1402とDNSサーバ1403で複数のパスを担当可能である。図１４はスイッチのリレー機能を適用する想定図であり、1404はリレーの接続を表している。なお、図１４の構成は一例であり、これらのDHCPサーバ1402とDNSサーバ1403は上位ノード1401中に存在する必要はなく、上位ノード1401が接続されるネットワーク上に存在しても良い。
【０１１３】
さて、エッジノード1400では、構成変更に伴って、入出力装置登録部1410、入出力装置情報公開部1411、アプリデプロイ登録部1412、公開ユーザ整合確認部1413の機能と、入出力装置管理テーブル1500、アプリ管理テーブル1600の保持する内容が変化する。
【０１１４】
図１５は、第３の実施形態における入出力装置管理テーブル1500を示したものである。図１５に示すように、入出力装置管理テーブル1500は、入出力装置ID列1501、入出力装置名称列1502、接続列1503、入出力装置アドレス1504、所有者列1505、公開ユーザ列1506の各列からなる。
【０１１５】
これらの列のうち1501〜1506は、第１の実施形態における入出力装置管理テーブル200と同様であるため、差分である公開出力先ユーザ列1507のみ説明する。公開出力先ユーザ列1507は公開ユーザ1506に登録されたユーザが使用可能なドメインを格納している。
【０１１６】
図１６は、第３の実施形態におけるアプリ管理テーブル1600を示したものである。図１６に示すようにアプリ管理テーブル1600は、アプリID列1601、アプリ名称列1602、デプロイユーザ列1603、入出力装置ID列1604、入出力装置名称列1605、出力先列1606、出力先ユーザ列1607の各列からなる。
【０１１７】
これらの列のうち1601〜1605は第１の実施形態におけるアプリ管理テーブル300と同様であるため、差分である出力先列1606と出力先ユーザ列1607のみ説明する。
【０１１８】
出力先列1606は、アプリの出力先として、ホスト名＋ドメイン名で表されたIPアドレスとポート番号を保持している。出力先ユーザ列1607は、出力先列1606に対応するユーザを保持している。
【０１１９】
入出力装置管理テーブル1500とアプリ管理テーブル1600から分かるように、第３の実施形態では、DHCPサーバ1402とDNSサーバ1403によって、ユーザ毎に使用可能なドメインとそのセグメントが割り振られるため、ユーザを指定すればその公開ユーザを決定できる。従って、第１の実施形態のように出力先/ユーザ対応テーブルに登録しなくとも、出力先のIPアドレスとユーザの対応を行うことが出来る。
【０１２０】
図１７は、第３の実施形態において、エッジノード管理者103が入出力装置を追加するときの動作を示したシーケンス図である。図１７に示すように、本動作には、エッジノード管理者103、入出力装置登録部1410、入出力装置管理テーブル1500が関連する。
【０１２１】
まず、エッジノード管理者103はS1701において、入出力装置をエッジノードに接続する。
【０１２２】
次に、エッジノード管理者103は、コンソール114を使用して、入出力装置登録部1410にS1701で接続した入出力装置の登録を要求し、それと共に、入出力装置の情報（名称、接続、入出力装置アドレス、所有者、公開ユーザ、公開ユーザのドメイン名）を伝える（S1702）。
【０１２３】
次に、入出力装置登録部1410は、入出力装置登録テーブル1500に格納されているエントリの一覧を取得する（S1703）。
【０１２４】
次に、入出力装置登録部1410は、S1704において、S1703で取得したエントリ一覧の中に、S1702で登録を要求された入出力装置の情報と同一装置のエントリが存在しているかどうかチェックし、登録の可否を判定する。具体的には、同一装置のエントリが存在していなければ登録可能と判定し、同一装置のエントリが存在している場合は、新規にエントリを登録すると入出力装置管理テーブル1500のエントリがコンフリクトするため、登録不可能と判定する。
【０１２５】
次に、入出力装置登録部1410は、S1704で登録可と判断した場合は、入出力装置ID列1501において重複しない入出力IDを割当て、入出力装置管理テーブル1500にエントリを追加する（S1705）。
【０１２６】
次に、入出力装置登録部1410は、エッジノード管理者103に登録要求の結果を返す（S1706）。
【０１２７】
第３の実施形態において、ユーザ105がエッジノード1400の入出力装置102の情報を取得する時の動作は、第１の実施形態における図６に示すシーケンスと同様である。
【０１２８】
図１８は、第３の実施形態において、ユーザ105がエッジノード1400にアプリをデプロイする時の動作を示したシーケンス図である。図１８に示すように、本動作には、ユーザ105、アプリデプロイ受付部1412、公開ユーザ整合確認部1413、入出力装置管理テーブル1500、アプリ管理テーブル1600が関連する。
【０１２９】
まず、ユーザ105は、管理ブレード130のコンソール136を使用して、アプリデプロイ受付部1412に、アプリデプロイを要求し、それと共に、デプロイするアプリのアプリ情報（アプリが使用する入出力装置のIDとアプリ出力先）を送る。本実施形態では、アプリ出力先は、IPアドレスではなく、ホスト名＋ドメイン名で表される（S1801）。
【０１３０】
アプリデプロイ受付部1412は、公開ユーザ整合確認部1413に、公開ユーザ整合確認を要求し、それと共に、S1801で受信したアプリが使用する入出力装置のIDとアプリの出力先とを送る（S1802）。
【０１３１】
公開ユーザ整合確認部1413は、入出力装置管理テーブル1500のエントリのうち、入出力装置ID列1501がS1802で受信したアプリが使用する入出力装置のIDであるエントリを探し、そのエントリの公開ユーザのドメイン名列1506の内容を取得する（S1803）。本シーケンスで取得したドメイン名一覧は、アプリが使用する入出力装置の公開範囲の一覧に相当する。ちなみに、アプリが複数の入出力装置を使用し、それぞれの入出力装置で異なる公開ドメイン名一覧を設定している場合も考えられる。その場合、公開ユーザ整合確認部1413は全ての公開ドメイン名一覧のANDをとったものを使用する。
【０１３２】
次に、公開ユーザ整合確認部1413は、S1804において、S1803で取得した公開ユーザのドメイン名一覧と、S1802で取得したアプリ出力先との整合を確認し、アプリデプロイ受付部1412に結果を伝える（S1805）。
【０１３３】
以降、S1806〜S1808のステップは、第１の実施例におけるアプリデプロイのシーケンスS807〜S809と同様である。
【０１３４】
以上のように、第３の実施形態では、公開ユーザ整合確認部1413は、ドメイン名の解決によって、出力先に対応するユーザが判別出来るため、入出力装置管理テーブル1500が保持する情報のみで公開ユーザの整合の確認を行うことが可能となる。
【０１３５】
図１９は、第３の実施形態における、公開ユーザ整合確認部1413の動作を示すフローチャートである。
【０１３６】
まず、公開ユーザ整合確認部1413は、図１８のS1802に示すように、公開ユーザ整合確認の要求を受け、それと共に、アプリ情報（アプリが使用する入出力装置のIDとアプリの出力先）を受信する（S1901）。第３の実施形態では、アプリの出力先はホスト名＋ドメイン名の形態で知らせられる。
【０１３７】
次に、公開ユーザ整合確認部1413は、図１８のS1803に示すように、入出力管理テーブル1500から、入出力装置ID列1501が、S1901で受信したアプリが使用する入出力装置IDであるエントリを探し、そのエントリの公開ユーザのドメイン名列1507の内容を取得して、公開ドメイン名一覧とする（S1902）。
【０１３８】
次に、公開ユーザ整合確認部1413は、図１８のS1804に示すように、S1901で受信したアプリ出力先のドメイン名が、S1902で取得したアプリが使用する入出力装置の公開ユーザのドメイン名一覧に含まれているかどうかを確認する（S1903）。
【０１３９】
S1903の結果がYesであれば、アプリ出力先が対応するユーザは、アプリの使用する入出力装置の公開ユーザ一覧と整合しているので、公開ユーザ整合確認部1413は、公開ユーザは整合であることを返信する（S1904）。S1903の結果がNoであれば、公開ユーザ整合確認部1413は、公開ユーザが不整合であると返信する（S1905）。
【実施形態４】
【０１４０】
次に、第４の実施形態について説明する。第１の実施形態では、アプリデプロイ受付部165がデプロイを受け付けた時に、アプリの出力ユーザとアプリが利用する入出力装置の公開ユーザの整合が取れていなかった場合はデプロイを拒否していたが、第４の実施形態ではアプリの出力ユーザを制限することでアプリの利用する入出力装置の公開ユーザとの整合を保証し、その上でデプロイを実行する。
【０１４１】
第４の実施形態は、第１の実施形態と物理的な構成は同様であり、動作のみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１４２】
図２０は第４の実施形態においてユーザ105がデプロイを要求した場合の動作を示したシーケンス図である。図２０に示す通り、本動作には、ユーザ105、管理ブレード130、アプリデプロイ受付部165、公開ユーザ整合部166、入出力装置管理テーブル200、出力先/ユーザ対応テーブル400、アプリ管理テーブル300が関連する。
【０１４３】
本シーケンスのS2001〜S2004までは、第１の実施形態におけるアプリデプロイのS801〜S804と同様である。ここまで、公開ユーザ整合確認部166は、S2003でアプリが使用する入出力装置に対応する公開ユーザ一覧を取得し、S2004でアプリの出力先に対応するユーザを取得している。
【０１４４】
次に、S2005において、公開ユーザ整合確認部166はS2003で取得した公開ユーザ一覧と、S2004で取得したアプリ出力先に対応するユーザとの整合を確認する。もし不整合であった場合、公開ユーザ整合確認部166は、整合性が得られるようにS2002で取得したアプリの出力先を制限する。また、S2003で取得した公開ユーザ一覧と、S2004で取得したアプリ出力先に対応するユーザとが、全く共通点が無い場合、アプリの出力先を制限しても整合性が得られないと判断する。（S2005）。
【０１４５】
次に、公開ユーザ整合確認部166は、整合結果と共に制限後のアプリ出力先をアプリデプロイ受付部165に返す。なお、S2005でアプリの出力先を制限しても整合性が得られないと判断した場合は、整合結果は不整合で出力先の修正は不可能であると伝える（S2006）。
【０１４６】
次に、アプリデプロイ受付部165は、S2006で受信した確認結果が整合であれば、アプリのデプロイを実行し（S2007）、アプリ管理テーブル300に、アプリID列301において重複しないIDを割り当てて、エントリを追加する（S2008）。アプリデプロイ受付部165は、S2006で受信した確認結果が不整合で、それと共に、制限後の出力先を受信した場合は、アプリデプロイ受付部165は、受信した制限後の出力先に従ってアプリのデプロイを実行し（S2007）アプリ管理テーブル300に、アプリID列301において重複しないIDを割り当てて、エントリを追加する（S2008）。アプリデプロイ受付部165は、S2006で受信した確認結果が不整合で、それと共に出力先の修正は不可能と受信した場合は、S2007とS2008に示す、アプリデプロイとアプリ管理テーブル300の更新は実施しない。
【０１４７】
次に、アプリデプロイ受付部165は、ユーザ105にデプロイ要求結果を返す（S2009）。
【０１４８】
図２１は、第４の実施形態におけるアプリデプロイ時の、公開ユーザ整合確認部166の動作を示したフローチャートである。
【０１４９】
まず、公開ユーザ整合確認部166は、図２０のS2002に示すように、公開ユーザ整合確認の要求を受け、それと共に、アプリ情報（アプリが使用する入出力装置のID、アプリの出力先）を受信する（S2101）。
【０１５０】
次に、公開ユーザ整合確認部166は、図２０のS2003に示すように、入出力装置管理テーブル200から、入出力装置ID列201が、S2101で受信したアプリが使用する入出力装置IDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得して、公開ユーザ一覧とする（S2102）。
【０１５１】
次に、公開ユーザ整合確認部166は、図２０のS2004に示すように、出力先/ユーザ対応テーブル400のエントリから、出力先列403にS2101で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S2103）。
【０１５２】
次に、公開ユーザ整合確認部166は、図２０のS2005に示すように、S2103で取得したユーザが、S2102で取得したユーザ一覧に含まれているかどうかを確認する（S2104）。
S2104の結果が完全に包含関係であれば、アプリ出力先が対応するユーザは、アプリの使用する入出力装置の公開ユーザ一覧と整合しているので、整合確認部166は、公開ユーザは整合であることを返信する（S2105）。S2104の結果が一部のみの包含関係であれば、整合確認部166は、S2101で受信したアプリ出力先を、包含されている部分のみに制限し（S2106）、公開ユーザは不整合である結果と共に制限後のアプリ出力先を返信する（S2107）。S2104の結果が全く包含関係に無いならば、整合結果は不整合であり、修正は不可能であると返信する（S2108）。
【実施形態５】
【０１５３】
次に、第５の実施形態について説明する。第１の実施形態ではアプリデプロイ受付部165がアプリデプロイを受け付けた時に、公開ユーザ整合確認部がアプリの公開ユーザの整合を確認していたが、第５の実施形態では既にデプロイされて動作中のアプリが外部出力を行おうとした時に公開ユーザの整合を確認して、出力するかどうかを決定する。
【０１５４】
第５の実施形態は、第１の実施形態と物理的な構成は同様であり、動作のみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１５５】
図２２は、第５の実施形態において、アプリ161が外部出力を行おうとした時の動作を示すシーケンス図である。図２２に示すとおり、本動作には、アプリ161、アプリミドル160、公開ユーザ整合確認部166、アプリ管理テーブル300、入出力管理テーブル200、出力先/ユーザ対応テーブル400が関連する
まず、アプリ161は、外部への出力を行おうとした時は、アプリミドル160に外部送信の要求を行い、出力先とデータを指定する（S2201）。
【０１５６】
次に、アプリミドル160は、公開ユーザ整合確認部166に、公開ユーザ整合の確認を要求し、それと共にS2201で指定された出力先とS2201を要求したアプリのIDを送信する（S2202）。
【０１５７】
公開ユーザ整合確認部166は、アプリ管理テーブル300のエントリのうち、アプリID列301がS2202で取得したアプリIDであるエントリを探し、そのエントリの入出力装置ID列304の内容を取得する（S2203）。
【０１５８】
次に、公開ユーザ整合確認部166は、入出力装置管理テーブル200のエントリのうち、入出力装置ID列201がS2203で取得した入出力装置のIDであるエントリを探し、そのエントリの公開ユーザ列206の内容を取得する（S2204）。
【０１５９】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のエントリのうち、出力先列403にS2202で受信したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402の内容を取得する（S2205）。
【０１６０】
次に、S2206において、公開ユーザ整合確認部166は、S2204で取得した入出力装置の公開ユーザ一覧と、S2205で取得した出力先が対応するユーザの一覧との整合の確認を行う。具体的には、第１の実施形態で行う公開ユーザ整合確認と同様、図９のフローチャートのS904と同等の評価を行う。
【０１６１】
次に、公開ユーザ整合確認部166はアプリミドル160に整合性確認結果を返信する（S2207）。
【０１６２】
アプリミドル160は、S2208において、S2207の整合確認結果に問題が無ければ外部出力を実行する。S2207の整合確認結果に問題がある場合は外部出力を中止する。
【０１６３】
次に、アプリミドル160は、アプリ161に外部出力結果を返す（S2209）。
【０１６４】
第５の実施形態によれば、アプリデプロイ後でも、アプリ動作中に公開ユーザの整合確認が可能となる。アプリデプロイ時に、アプリの出力先を取得できない場合は、第１の実施形態は不可能であるため、第５の実施形態が有力である。
【実施形態６】
【０１６５】
次に、第６の実施形態について説明する。第６の実施形態は、エッジノード管理者103が、アプリ161が使用している入出力装置の公開ユーザを変更するものである。
【０１６６】
第６の実施形態は、第１の実施形態と物理的な構成は同様であり、動作のみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１６７】
図２３は第６の実施形態において、エッジノード管理者161が入出力装置の公開ユーザを変更する時の動作を示すシーケンス図である。図２３に示すとおり、本動作には、エッジノード管理者161、入出力装置登録部162、公開ユーザ整合確認部166、アプリ管理テーブル300、入出力装置管理テーブル200、出力先/ユーザ対応テーブル400が関連する。
【０１６８】
まず、エッジノード管理者103は、コンソール114を使用して、入出力装置登録部162に、設定を変更する入出力装置IDと設定変更後の公開ユーザを伝える（S2301）。
【０１６９】
入出力装置登録部162は、公開ユーザ整合確認部166に、公開ユーザ整合性確認を要求し、それと共に、入出力装置IDと変更情報後の公開ユーザとを伝える（S2302）。
【０１７０】
公開ユーザ整合確認部166は、アプリ管理テーブル300のうち、入出力装置ID列304にS2302で取得した入出力装置IDが含まれるエントリを探し、そのエントリの出力先列306を取得する（S2303）。
【０１７１】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のうち、出力先列403にS2303で取得したアプリ出力先が含まれるエントリを探し、そのエントリのユーザ列402を取得する（S2304）。
【０１７２】
次に、S2305において、公開ユーザ整合確認部166は、S2306で取得したアプリ出力先に対応するユーザ一覧と、S2302で取得した変更後の公開ユーザとを比較して整合性を判断する。具体的には第４の実施形態の図２１のS2104〜S2108と同様の判断を行う。すなわち、S2304で取得したアプリ出力先に対応するユーザが、S2302で取得した変更後の入出力装置の公開ユーザの範囲に包含されているかどうか比較し（2305）、包含されていない場合は包含されるようにアプリ出力先を制限してアプリ管理テーブル300の出力先列306を変更する（S2306）。なお、アプリ管理テーブル300の変更に伴って、アプリの出力先を制限するためには、第５の実施形態と同様の手法を適用する必要がある。
【０１７３】
次に、公開ユーザ整合確認部166は、入出力装置登録部162に、整合確認結果とS2306でのアプリ管理テーブルの変更結果を伝える（S2307）。
【０１７４】
次に、入出力装置登録部162は、入出力装置管理テーブル200のうち、入出力装置ID列201がS2301で受信した入出力装置IDであるエントリを探し、そのエントリの公開ユーザ列206をS2301で受信した変更後の公開ユーザに更新する（S2308）。
次に、入出力装置登録部162は、エッジノード管理者103にS2306の変更結果を返す（S2309）。
【実施形態７】
【０１７５】
次に、第７の実施形態について説明する。第７の実施形態では、入出力装置単位で公開ユーザを設定するのではなく、入出力装置が提供するAPI（Application Program Interface）毎に公開ユーザを設定可能とするものである。
【０１７６】
第７の実施形態は、第１の実施形態とは、入出力管理テーブル200とアプリ管理テーブル300が異なるのみで、他の物理的な構成や動作は同様である。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１７７】
図２４は第７の実施形態における入出力装置管理テーブル2400を示したものである。
【０１７８】
図２４に示すように、第７の実施形態における入出力装置管理テーブル2400は、入出力装置ID列2401、入出力装置名称列2402、接続列2403、入出力装置アドレス列2404、所有者列2405、API列2406、公開ユーザ列2407の各列からなる。
【０１７９】
これらの列のうち、2401〜2405は、第１の実施形態における入出力装置管理テーブル200の201〜205と同様である。
【０１８０】
API列2406は、入出力装置が提供するAPIを保持する。例えば本実施例では、入出力装置のIPカメラは画像取得APIと方向変更アクチュエータAPIを提供する。
【０１８１】
公開ユーザ列2407は、API列2406で公開するAPI毎に公開を許可するユーザを保持している。本実施例では、入出力装置IDがDev-1の IPカメラ1のAPIは、画像取得APIと方向変更アクチュエータAPI共にユーザAのみへの公開だが、入出力装置IDがDev-2のIPカメラ2は、画像取得APIはユーザAとユーザBへ公開し、方向変更アクチュエータAPIはユーザAのみへの公開としている。
【０１８２】
図２５は第７の実施形態におけるアプリ管理テーブル2500を示したものである。
【０１８３】
図２５に示すように、第７の実施形態におけるアプリ管理テーブル2500は、アプリID列2501、アプリ名称列2502、デプロイユーザ列2503、入出力装置ID列2504、入出力装置名称列2505、API列2506、出力先列2507の各列からなる。
【０１８４】
これらの列のうち、2501〜2505と2507は、第１の実施形態におけるアプリ管理テーブルの300の301〜305と306と同様である。
【０１８５】
API列2506はアプリが使用する入出力装置ではなく、APIを保持する。本実施例によれば、アプリIDがAP-11とAP-12のアプリはそれぞれIPカメラ1とIPカメラ2の画像取得APIを使用するが、方向変更アクチュエータAPIは使用しない。
【実施形態８】
【０１８６】
次に、第８の実施形態について説明する。第８の実施形態では、アプリ161は機能ブレード131に出力するのみではなく、ユーザ端末104が機能ブレード131を使用してアプリ161にリクエストのためにアクセスする機能を保持しており、リクエストのためのアクセス時に公開ユーザ整合の確認を行うものである。例えば、ユーザ端末104が希望するタイミングでエッジノード100からデータを取得する場合や、ユーザ端末104が図２４の第７の実施形態における入出力装置管理テーブル2400に示す方向変更アクチュエータAPIを使用するアプリ161にアクセスして、方向変更アクチュエータAPIを動作させる場合への適用が考えられる。
【０１８７】
第８の実施形態は、第１の実施形態と物理的な構成は同様であり、入出力装置管理テーブル200と動作シーケンスのみが異なる。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０１８８】
図２６は第８の実施形態におけるアプリ管理テーブル2600を示したものである。
【０１８９】
図２６に示すように、第８の実施形態におけるアプリ管理テーブル2600は、アプリID列2601、アプリ名称列2602、デプロイユーザ列2603、入出力装置ID列2604、入出力装置名称列2605、アクセス許可ユーザ列2606の各列からなる。
【０１９０】
これらの列のうち、2601〜2605は第１の実施形態におけるアプリ管理テーブル300の301〜305と同様である。
【０１９１】
アクセス許可ユーザ列2606はアプリにアクセスを許可するユーザ名を保持している。
【０１９２】
本実施例で稼動するアプリは、リクエスト元であるユーザがアプリにアクセスしてアプリが記録した画像をリクエストして取得する（PULL）タイプの画像レコーダを想定する。
【０１９３】
図２７は、第８の実施形態においてユーザ端末104が、リクエストを受信する手段や機能を有するアプリ161に、リクエストであるPULL要求を行う時の動作を示したシーケンス図である。図２７に示すように、本動作には、ユーザ端末104、アプリミドル160、公開ユーザ整合確認部166、アプリ管理テーブル2600、出力先/ユーザ対応テーブル400が関連する。
【０１９４】
まず、ユーザ端末104は、機能ブレード131とスイッチ132とネットワークI/F112を介して、PULL要求とアプリIDを送信する。PULL要求とアプリIDはアプリミドル160で受け付けられる（S2701）。
【０１９５】
アプリミドル160は、公開ユーザ整合確認部166に、公開ユーザ整合の確認を要求し、それと共に、リクエスト元のアドレスとS2701で受信したアプリIDとを渡す（S2702）。
【０１９６】
公開ユーザ整合確認部166は、アプリ管理テーブル2600のうち、アプリID列2601がS2702で取得したアプリIDであるエントリを探し、そのエントリのアクセス許可ユーザ列2606を取得する（S2703）。
【０１９７】
次に、公開ユーザ整合確認部166は、出力先/ユーザ対応テーブル400のうち、出力先列403にS2702で取得した要求元IPアドレスが含まれるエントリを探し、そのエントリのユーザ列402を取得する（S2704）。
【０１９８】
次に、公開ユーザ整合確認部166は、S2705において、S2703で取得したアプリにアクセス可能なユーザと、S2704で取得した要求元IPアドレスに対応するユーザとの整合を確認する。具体的には、第１の実施形態における図９のS904と同様の判断を行う。
【０１９９】
次に、公開ユーザ整合確認部166は、アプリミドル160に、整合確認結果を返す（S2706）。
【０２００】
S2706の確認結果に問題が無ければ、アプリミドル160は、アプリにS2701で受信した要求を実行させ（S2707）、実行結果をユーザ端末104まで返す（S2708）。S2707において、S2706の確認結果に問題があった場合は、アプリミドル160は、S2701で受信した要求は実行せず（S2707）、公開ユーザが不整合であったことをユーザ端末104まで返す（S2708）。
【０２０１】
図２８は第８の実施形態における公開ユーザ整合部166の動作を示したフローチャートである。
【０２０２】
まず、公開ユーザ整合部166は、図２７のS2702に示すように、公開ユーザ整合の確認要求を受信し、それと共に、要求元のアドレスとアプリIDとを受信する（S2801）。
【０２０３】
次に、公開ユーザ整合部166は、図２７のS2703に示すように、アプリ管理テーブル2600のうち、アプリID列2601がS2801で受信したアプリIDであるエントリを探し、そのエントリのアクセス許可ユーザ列2606を取得する（S2802）。
【０２０４】
次に、公開ユーザ整合部166は、図２７のS2704に示すように、出力先/ユーザ対応テーブル400のうち、出力先列403にS2801で受信した要求元IPアドレスが含まれるエントリを探し、そのエントリのユーザ列402を取得する（S2803）。
【０２０５】
次に、公開ユーザ整合部166は、図２７のS2705に示すように、S2803で取得した要求元アドレスに対応するユーザと、S2802で取得したアプリにアクセス可能ユーザとの整合を確認する。具体的には、第１の実施形態における図９のS904と同様に、要求元ユーザがアクセス可能ユーザ一覧に含まれているかどうかをチェックし（S2804）、含まれているならば整合と返信し（S2805）、含まれていないならば不整合と返信（S2806）する。
【実施形態９】
【０２０６】
次に、第９の実施形態について説明する。第９の実施形態では、エッジノードは、管理機能モジュールとアプリ動作モジュールの2つのモジュールから構成されており、1つの管理機能モジュールで複数のアプリ動作モジュールを纏めて管理可能とするものである。
【０２０７】
図２９は第９の実施形態を適用したネットワークシステムの概略図を示したブロック図である。
【０２０８】
第９の実施形態は、エッジノード100が管理モジュール2900とアプリ動作モジュール2901に分かれて上位ノード101のスイッチ132との接続が変更となった以外は、第１の実施形態と同様である。従って、以下では第１の実施形態と異なる分部についてだけ説明し、同じ部分については説明を省略する。
【０２０９】
管理モジュール2900は、CPU 2910、主記憶2911、ネットワークI/F 2912、コンソール2913を保持する。CPU 2910と主記憶2911はメモリバス2920で接続される。CPU 2910とネットワークI/F 2912、コンソール2913は、それぞれI/Oバス2921、2922で接続される。
【０２１０】
CPU 2910上では、入出力装置情報公開部2930、入出力装置登録部2931、ユーザ登録部2932、アプリデプロイ受付部2933、公開ユーザ整合確認部2934が動作する。
【０２１１】
主記憶2911上には、入出力管理テーブル3000、アプリ管理テーブル3100、出力先/ユーザ対応テーブル400が置かれる。
【０２１２】
CPU上で動作する各動作部2930〜2934は、動作は第１の実施形態における各動作部162〜166と同様であるが、主記憶上2911の入出力管理テーブル3000とアプリ管理テーブル3100の変更に伴って、扱うデータは変化する。
【０２１３】
アプリ動作モジュール2901は、CPU 2940、主記憶2941、ネットワークI/F 2942、I/O部2943を保持する。CPU2940と主記憶2941はメモリバス2950で接続される。CPU2940とネットワークI/F 2942、I/O部2943は、それぞれI/Oバス2951、2952で接続される。
【０２１４】
CPU2940上では、アプリミドル2960とそれを使用するアプリ2961が動作する。
【０２１５】
管理モジュール2900とアプリ動作モジュール2901は、それぞれ２つのネットワークI/F 2912を所持している。片方のネットワークI/F 2912は、バックボーンネットワーク2970に接続され、上位ノード101のスイッチ132に繋がる。もう片方のネットワークI/F 2912はエッジノード内部ネットワーク2971に接続され、エッジノード内管理ネットワーク2972で集約される。管理モジュール2900は、エッジノード内部ネットワーク2971によって、アプリ動作モジュール2901に管理操作を行うことが可能となる。
【０２１６】
なお、第２の実施形態と同様に、2つのネットワークI/F 2912は、管理モジュール290及びアプリ動作モジュール2901が物理的に2つ所持しても構わないし、1つのネットワークI/FをVLANなどによって論理的に2つに見せても構わない。
【０２１７】
図３０は第９の実施形態における入出力装置管理テーブル3000を示したものである。
【０２１８】
図３０に示すように、第９の実施形態における入出力装置管理テーブル3000は、アプリ動作モジュール番号列3001、入出力装置ID列3002、入出力装置名称列3003、接続列3004、入出力装置アドレス列3005、所有者列3006の各列からなる。
【０２１９】
アプリ動作モジュール番号列3001は、アプリ動作モジュールの番号を示している。本実施例では、Func-1、Func-2・・・としている。
【０２２０】
列3002〜3007は、第１の実施形態における入出力管理テーブル200の列201〜205と同様である。
【０２２１】
図３１は第９の実施形態におけるアプリ管理テーブル3100を示したものである。
【０２２２】
図３１に示すように、第９の実施形態におけるアプリ管理テーブル3100は、アプリ動作モジュール番号列3101、アプリID列3102、アプリ名称列3103、デプロイユーザ列3104、入出力装置ID列3105、入出力装置名称列3106、出力先列3107の各列からなる。
【０２２３】
アプリ動作モジュール番号列3101は、図３０に示す入出力装置管理テーブル3000のアプリ動作モジュールの番号列3001と同様、アプリ動作モジュールの番号を示しており、表記も同様にFunc-1、Func-2・・・としている。
【０２２４】
列3102〜3107は、第１の実施形態におけるアプリ管理テーブル300の列301〜306と同様である。
【０２２５】
第９の実施形態では、入出力管理テーブル3000とアプリ管理テーブル3100がアプリ動作モジュール番号列3001、3101を所持することで、管理モジュール2900は、複数のアプリ動作モジュール2901を識別してそれぞれ管理することが可能となる。
【０２２６】
以上本発明の種々の実施形態を詳述してきたが、本発明はこれらの実施形態に限定されるものではなく、例えば、図１、図１０、図１４、図２９に示したネットワークシステム構成の様に、ネットワークノードが二層に構成された場合のみならず、上位ノードの更に上位にデータセンタ等の最上位のノードがネットワークを介して接続される様な三層、あるいはそれ以上の階層に構成されたネットワークシステムにも適用可能であることは言うまでもない。この場合、ネットワークシステム管理者は、データセンタのサーバ等、より上位の階層のノードのサーバや管理ブレード等から種々の情報を入力することも可能であることは言うまでもない。
【産業上の利用可能性】
【０２２７】
本発明は、工場監視用のセンサコントローラ、画像監視システムを、複数のユーザで共用する時の権限管理に適する情報処理システムとして有用である。
【符号の説明】
【０２２８】
100、1000、1400…エッジノード
101、1001、1401…上位ノード
102…入出力装置部
103…エッジノード管理者
104…ユーザ端末
105…ユーザ
106…ネットワークシステム管理者
110、133、2910、2940…CPU
111、134、2911、2941…主記憶
112、135、1010、2912、2942…ネットワークI/F
113、2943…I/O部
114、136、2913…コンソール
120、141、2920、2950…メモリバス
121、122、123、142、143、1011、2921、2922、2951、2952…I/Oバス
124…入出力装置部ネットワーク
125、153、154…入力I/F
130…管理ブレード
131…機能ブレード
132、1012…スイッチ
150、1020、2970…バックボーンネットワーク
151…上位ノード内部ネットワーク
152…ローカルネットワーク
160、2960…アプリミドル
161、2961…アプリ
162、1030、1410、2930…入出力装置登録部
163、1031、1411、2931…入出力装置情報公開部
164、1032、2932…ユーザ登録部
165、1033、1412、2933…アプリデプロイ受付部
166、1034、1413、2934…公開ユーザ整合確認部
200、1500、3000…入出力装置管理テーブル
300、1100、1600、3100…アプリ管理テーブル
400、1200…出力先/ユーザ対応テーブル
1402…DHCPサーバ
1403…DNSサーバ
1404…リレーネットワーク
2900…エッジノード管理モジュール
2901…エッジノードアプリ動作モジュール
2971…エッジノード内ネットワーク
2972…エッジノード内管理系ネットワーク。
【特許請求の範囲】
【請求項１】
ネットワークノードであって、
１つ以上の入出力装置からデータの入力を受け付け、前記入出力装置から入力されたデータを処理して出力するアプリケーションが稼動する処理部と、
前記入出力装置の公開範囲を保持するための記憶部とを備え、
前記処理部は、
前記アプリケーションの投入を受け付ける場合に、前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記アプリケーションの投入の受付可否を判断する、
ことを特徴とするネットワークノード。
【請求項２】
請求項１に記載のネットワークノードであって、
前記アプリケーションの投入を受け付けるために使用するインタフェース部と、
前記アプリケーションがデータを出力するために使用するインタフェース部を別々に備える、
ことを特徴とするネットワークノード。
【請求項３】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認する際、
前記出力先と前記入出力装置の公開範囲のドメイン名を解決することによって判断する、ことを特徴とするネットワークノード。
【請求項４】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記アプリケーションの投入を受け付ける際、
前記アプリケーションの出力先を、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲に包含されるように制限する、
ことを特徴とするネットワークノード。
【請求項５】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記投入されたアプリケーションがデータ出力を行う場合に、
前記出力先が、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認して、データ出力の可否を判断する、
ことを特徴とするネットワークノード。
【請求項６】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記入出力装置の公開範囲が変更された場合に、
前記入出力装置のデータを処理するアプリケーションの出力先を、前記変更後の公開範囲に包含されるように制限する、
ことを特徴とするネットワークノード。
【請求項７】
請求項１に記載のネットワークノードであって、
前記入出力装置が提供する機能毎に公開範囲を設定する、
ことを特徴とするネットワークノード。
【請求項８】
請求項１に記載のネットワークノードであって、
前記アプリケーションは情報のリクエストを受信する手段を備え、
前記処理部は、
前記アプリケーションが前記リクエストを受信した場合に、リクエスト元は前記アプリケーションにデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記リクエストを受け付けるかどうかを判断する、
ことを特徴とするネットワークノード。
【請求項９】
請求項１に記載のネットワークノードであって、
前記アプリケーションの投入を受け付ける第１のノードと、
前記第１のノードとは物理的に分かれ、前記入出力装置を所持し前記アプリケーションが動作する第２のノードから構成される、
ことを特徴とするネットワークノード。
【請求項１０】
複数の入出力装置と前記入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードとを有する情報処理システムであって、
前記ネットワークノードは、
前記ネットワークノードに前記入力装置の公開範囲データを保持でき、
前記アプリケーションの投入を受け付ける際に、保持した前記公開範囲データに基づき、前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記アプリケーションの投入の受付可否を判断する、
ことを特徴とする情報処理システム。
【請求項１１】
請求項１0に記載の情報処理システムであって、
前記ネットワークノードは、
前記アプリケーションの投入を受け付けるために使用するインタフェース部と、
前記アプリケーションがデータを出力するために使用するインタフェース部を別々に備える、
ことを特徴とする情報処理システム。
【請求項１２】
請求項１0に記載の情報処理システムであって、
前記ネットワークノードは、
前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入力装置の公開範囲の包含関係にあるかどうかを確認する際、
前記出力先と前記入出力装置の公開範囲のドメイン名を解決することによって判断することを特徴とする情報処理システム。
【請求項１３】
請求項１0に記載の情報処理システムであって、
前記ネットワークノードは、
前記入力装置が提供する機能毎に公開範囲を設定する、
ことを特徴とする情報処理システム。
【請求項１４】
請求項１０に記載の情報処理システムであって、
前記ネットワークノードは、
前記アプリケーションの投入を受け付ける第１のノードと、
前記第１のノードと物理的に分かれ、前記入出力装置を所持し、前記アプリケーションが動作する第２のノードとから構成される、
ことを特徴とする情報処理システム。
【請求項１５】
１つ以上の入出力装置からデータの入力を受け付け、前記入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードにおける情報処理方法であって、
前記ネットワークノードに前記入出力装置の公開範囲データを保持しておき、前記アプリケーションの投入を受け付ける際に、前記公開範囲データに基づき、前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記アプリケーションの投入の受付可否を判断する、
ことを特徴とするネットワークノードにおける情報処理方法。
【請求項１】
ネットワークノードであって、
１つ以上の入出力装置からデータの入力を受け付け、前記入出力装置から入力されたデータを処理して出力するアプリケーションが稼動する処理部と、
前記入出力装置の公開範囲を保持するための記憶部とを備え、
前記処理部は、
前記アプリケーションの投入を受け付ける場合に、前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記アプリケーションの投入の受付可否を判断する、
ことを特徴とするネットワークノード。
【請求項２】
請求項１に記載のネットワークノードであって、
前記アプリケーションの投入を受け付けるために使用するインタフェース部と、
前記アプリケーションがデータを出力するために使用するインタフェース部を別々に備える、
ことを特徴とするネットワークノード。
【請求項３】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認する際、
前記出力先と前記入出力装置の公開範囲のドメイン名を解決することによって判断する、ことを特徴とするネットワークノード。
【請求項４】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記アプリケーションの投入を受け付ける際、
前記アプリケーションの出力先を、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲に包含されるように制限する、
ことを特徴とするネットワークノード。
【請求項５】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記投入されたアプリケーションがデータ出力を行う場合に、
前記出力先が、前記アプリケーションが処理するデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認して、データ出力の可否を判断する、
ことを特徴とするネットワークノード。
【請求項６】
請求項１に記載のネットワークノードであって、
前記処理部は、
前記入出力装置の公開範囲が変更された場合に、
前記入出力装置のデータを処理するアプリケーションの出力先を、前記変更後の公開範囲に包含されるように制限する、
ことを特徴とするネットワークノード。
【請求項７】
請求項１に記載のネットワークノードであって、
前記入出力装置が提供する機能毎に公開範囲を設定する、
ことを特徴とするネットワークノード。
【請求項８】
請求項１に記載のネットワークノードであって、
前記アプリケーションは情報のリクエストを受信する手段を備え、
前記処理部は、
前記アプリケーションが前記リクエストを受信した場合に、リクエスト元は前記アプリケーションにデータを入力する前記入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記リクエストを受け付けるかどうかを判断する、
ことを特徴とするネットワークノード。
【請求項９】
請求項１に記載のネットワークノードであって、
前記アプリケーションの投入を受け付ける第１のノードと、
前記第１のノードとは物理的に分かれ、前記入出力装置を所持し前記アプリケーションが動作する第２のノードから構成される、
ことを特徴とするネットワークノード。
【請求項１０】
複数の入出力装置と前記入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードとを有する情報処理システムであって、
前記ネットワークノードは、
前記ネットワークノードに前記入力装置の公開範囲データを保持でき、
前記アプリケーションの投入を受け付ける際に、保持した前記公開範囲データに基づき、前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記アプリケーションの投入の受付可否を判断する、
ことを特徴とする情報処理システム。
【請求項１１】
請求項１0に記載の情報処理システムであって、
前記ネットワークノードは、
前記アプリケーションの投入を受け付けるために使用するインタフェース部と、
前記アプリケーションがデータを出力するために使用するインタフェース部を別々に備える、
ことを特徴とする情報処理システム。
【請求項１２】
請求項１0に記載の情報処理システムであって、
前記ネットワークノードは、
前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入力装置の公開範囲の包含関係にあるかどうかを確認する際、
前記出力先と前記入出力装置の公開範囲のドメイン名を解決することによって判断することを特徴とする情報処理システム。
【請求項１３】
請求項１0に記載の情報処理システムであって、
前記ネットワークノードは、
前記入力装置が提供する機能毎に公開範囲を設定する、
ことを特徴とする情報処理システム。
【請求項１４】
請求項１０に記載の情報処理システムであって、
前記ネットワークノードは、
前記アプリケーションの投入を受け付ける第１のノードと、
前記第１のノードと物理的に分かれ、前記入出力装置を所持し、前記アプリケーションが動作する第２のノードとから構成される、
ことを特徴とする情報処理システム。
【請求項１５】
１つ以上の入出力装置からデータの入力を受け付け、前記入出力装置から入力されたデータを処理して出力するアプリケーションが稼動するネットワークノードにおける情報処理方法であって、
前記ネットワークノードに前記入出力装置の公開範囲データを保持しておき、前記アプリケーションの投入を受け付ける際に、前記公開範囲データに基づき、前記アプリケーションの出力先が、前記アプリケーションが処理するデータを入力する入出力装置の公開範囲の包含関係にあるかどうかを確認して、前記アプリケーションの投入の受付可否を判断する、
ことを特徴とするネットワークノードにおける情報処理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【公開番号】特開２０１１−１６５１１５（Ｐ２０１１−１６５１１５Ａ）
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願番号】特願２０１０−２９８９８（Ｐ２０１０−２９８９８）
【出願日】平成２２年２月１５日（２０１０．２．１５）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２１年度、総務省、セキュアクラウドネットワーキング技術の研究開発 委託事業、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２３年８月２５日（２０１１．８．２５）
【国際特許分類】
【出願日】平成２２年２月１５日（２０１０．２．１５）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２１年度、総務省、セキュアクラウドネットワーキング技術の研究開発 委託事業、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]