Solaris 環境では、ネームサービスは、ファイルシステム、ネットワーク情報サービス、メールシステム、カレンダサービスなどの他のサービスに統合されます。たとえば、ファイルシステムには、ファイルとディレクトリ用のネーミングシステムが含まれます。NIS+ サービスでは、ネーミングシステムと特殊な情報サービスを結合します。
FNS がない場合、Solaris 環境のユーザーは、整合性のない複数の名前を使用して、オブジェクトを参照しなければなりません。たとえば、jsmith@admin という名前を使用して Joan にメールを送り、jsmith@altair という名前を使用してカレンダにアクセスし、/home/jsmith/.cshrc という名前を使用して、彼女のホームディレクトリにあるファイルに到達しなければなりません。このため、ユーザーが名前を形式化するのが困難になります。また、アプリケーションがユーザーに代わって名前を自動生成することも難しくなります。FNS ポリシーでは、これらのオブジェクトをネーミングする一貫した方法を定義します。
アプリケーションもネームサービスを必要とします。Solaris 環境のアプリケーションでは、多くのネームサービスインタフェースを処理する必要があります。1 つのアプリケーションが、Solaris 環境の外部にある各種の互換性のないネーミングシステムと関わる場合もあります。ローカルネットワークと広域ネットワークでは、異機種の複数のハードウェアとオペレーティングシステムが接続されているので、各種のインタフェースが混在する可能性が高くなります。これらのネーミングインタフェースは大幅に異なるだけでなく、基本的なネーミング操作も通常明確ではありません。
FNS は、これらの問題を次の 2 つの方法で解決します。
基本ネーミング機能に単一の標準インタフェースを提供して、開発者がアプリケーションで使用できるようにする
既存のアプリケーションを変更しなくても、ネットワークのネームサービスの変更や追加ができるようにする
アプリケーションによっては、複合名を使用して、Solaris 環境のオブジェクトにアクセスするものがあります。コマンドの mail と rcp は、このようなアプリケーションの一例です。
rcp は、sirius:/usr/jsmith/memo などの複合名を使用します。これは、ホスト名 sirius とファイル名 (パス) /usr/jsmith/memo の 2 つの構成要素からなります。 mail プログラムは、jsmith@altair などの複合名を使用します。これは、ユーザ名 jsmith とホスト名 altair の 2 つの構成要素からなります。
各アプリケーションは、独自の名前作成規則を定義し、複合名を構文解析して、複合名を解決します。複合規則は、通常、アプリケーションごとに異なります。
FNS がない場合、ユーザーは、どのアプリケーションで複合ネーミングが可能であり、どれが可能でないかを覚えておく必要があります。たとえば、複合名 sirius:/tmp/saleslist は、rcp コマンドでは受け入れられますが、cp コマンドでは受け入れられません。
FNS がない場合、ユーザーは、アプリケーションごとに使用される異なる作成規則も覚えておく必要があります。独自の複合名をサポートするアプリケーションは、小さい特定のネーミングシステムしか使用できません。また、新しいタイプのネーミングシステムが追加されるたびに変更する必要があります。
複合ネーミングの一貫したポリシーを、コンピューティングプラットフォームに組み込むと、どのアプリケーションでも一貫した方法で複合名をサポートできます。アプリケーションは、1 つの名前を 1 つのインタフェースに渡します。
FNS ポリシーには、次の原則があります。
「特定のオブジェクトに対応して他のオブジェクトをネーミングする場合、そのオブジェクトはネーミングコンテキストとなる。」
たとえば、ユーザーに対応してさまざまな事柄をネーミングする場合、ユーザーオブジェクトがネーミングコンテキストになります。
「共通構成要素を使用した名前の作成が可能。」
これにより、ユーザーが覚える必要がある名前の数が減り、アプリケーションとユーザーによる、共通構成要素とその論理構成に関する知識に基く名前の作成が容易になります。
「名前は視覚的で自明のものでなければならない。」
たとえば、FNS 名 /user/wong/service/calendar は、ユーザー Wong によって使用されるカレンダサービスを明示します。これに対して、カレンダ名 wong@deneb は、Wong のカレンダサービスが提供されるホスト (deneb) を表します。ただし、ホスト名は余分であり、検索しにくく覚えずらいので、他のユーザーにとって、このユーザーのカレンダとホストの間に明確な関連性はありません。
「1 つのコンテキストで間に合う場合には、2 つのコンテキストを使用しない。」
上記の例では、メールアドレス、カレンダ、ファイルのディレクトリを、ユーザー Wong に対応してネーミングした方が効果的です。コンテキストとその名前を共有すると、ネーミングの整合性が高まり、管理が簡単になります。