エンタープライズ名前空間のポリシー

FNS ポリシーでは、エンタープライズ内の名前空間のタイプおよび配列と、アプリケーションが名前空間を使用する方法が指定されます。たとえば、名前空間が他のどの名前空間と関連するかが指定されます。ここで説明する FNS ポリシーには、XFN ポリシーへの拡張機能があります。これらは、注釈によって明確に定義されます。

デフォルトの FNS エンタープライズ名前空間

FNS エンタープライズのポリシーでは、名前空間内でのエンタープライズのオブジェクトの配列が処理されます。各エンタープライズのオブジェクトは、独自の名前空間を持っています。

デフォルトでは、FNS には 7 つのエンタープライズオブジェクトと対応する名前空間があります。

• 「組織」(orgunit)

  部、センター、課などのエンティティ。サイト、ホスト、ユーザー、サービスには、組織に関連する名前を付けることができる。組織に対する XFN 用語は、「組織単位」となる。初期コンテキストで使用されたときは、識別子 org は、orgunit の別名として使用できる

• 「サイト」(site)

  建物、建物内のマシン、建物内の会議室などの物理的な位置。サイトは、それらと関連するファイルおよびサービスを持つ

• 「ホスト」(host)

  マシン。ホストは、それらと関連するファイルおよびサービスを持つ

• 「ユーザー」(user)

  人間のユーザー。ユーザーは、それらと関連するファイルおよびサービスを持つ

• 「ファイル」(fs)

  ファイルシステム内のファイル

• 「サービス」(service)

  プリンタ、FAX、メール、電子カレンダなどのサービス

• 「プリンタ」(service/printer)

  プリンタの名前空間は、サービスの名前空間に従属する

図 22-1 は、エンタープライズの名前空間が配列される方法を示しています。

図 22-1 FNS ポリシーが配列するもの

ユーザーやホストなどの名前空間には、フェデレートされた名前空間で複数回表示されるものもあります。

これらの名前空間に適用されるポリシーは、表 22-2 に要約しています。

エンタープライズ名前空間の識別子

エンタープライズ名前空間は、フェデレートされた名前空間の原子名によって参照されます。

XFN では、先行する下線 (_) 文字を使用して、エンタープライズ名前空間の識別子が示されます。たとえば、_site となります。FNS では、下線 (_) なしの識別子の使用もサポートされます。下線なしの名前は、XFN ポリシーの範疇には入りません。site および printer のコンテキストも、XFN ポリシーの範疇には入りません。これらの原子名は、表 22-1 に挙げられています。

XFN の用語では、先行する下線のある名前は、「正規」名前空間識別子です。下線のない名前は、Solaris 環境用に「カスタマイズ」された名前空間識別子です。これらのカスタマイズされた名前空間識別子に printer を追加しても、Solaris 以外の環境では認識されません。正規の名前空間識別子は、他の環境でも常に認識され、互換性があります。

構成要素の区切り文字

XFN 構成要素の区切り文字 (/) で、名前空間識別子を区切ります。たとえば、名前空間識別子 orgunit を組織単位名 west.sales とともに作成すると、複合名は orgunit/west.sales となります。

デフォルトの FNS 名前空間

FNS では、次の 7 つの名前空間が提供されます。

• 「組織」(「組織単位の名前空間」を参照)

• 「サイト」(「サイトの名前空間」を参照)

• 「ホスト」(「ホストの名前空間」を参照)

• 「ユーザー」(「ユーザーの名前空間」を参照)

• 「ファイル」(「ファイルの名前空間」を参照)

• 「サービス」(「サービスの名前空間」を参照)

• 「プリンタ」(「サービスの名前空間」を参照)

組織単位の名前空間

組織単位の名前空間では、エンタープライズのサブ単位をネーミングするために階層になった名前空間が提供されます。各組識単位名は組織単位を表す「組織単位コンテキスト」と結合されています。組織単位名は、接頭辞 org/、orgunit/、または _orgunit/ によってネーミングされます。短縮形別名の org/ は、内部コンテキストだけで使用され、複合名の途中では使用されません。「エンタープライズ内のネーミングに対する初期コンテキストのバインド」および、「複合名の例」を参照してください。

NIS+ 環境

NIS+ 環境では、組織単位は NIS+ のドメインおよびサブドメインに対応します。

NIS+ では、組織単位は必ずドメインおよびサブドメインにマップされます。それぞれの NIS+ ドメインおよびサブドメインに組織単位を与える必要があります。ドメインまたはサブドメインに論理、組織ユニットを与えることはできません。つまり、NIS+ ドメインまたはサブドメインを小規模な組織単位に分割することはできません。そのため、NIS+ ドメイン doc.com. と 2 つのサブドメイン sales.doc.com. および manf.doc.com. がある場合は、これら 3 つのドメインに対応する 3 つの FNS 組織単位を持つ必要があります。

組織単位は、ドットで区切られた右から左への複合名を使用してネーミングされます。ここでは、各原子要素がより大きな単位内の組織単位をネーミングします。たとえば、org/sales.doc.com. という名前は、doc.com. という名前のより大きな単位内にある sales をネーミングします。この例では、sales は、doc.com. の NIS+ サブドメインです。

組織単位名は、完全指定の NIS+ ドメインまたは相対名の NIS+ 名のどちらかになります。完全指定名には終端にドットが付きますが、相対名には付きません。そのため、終端のドットが組織名にある場合は、その名前は完全指定の NIS+ ドメイン名として処理されます。終端にドットがない場合は、その組織名は最上部の組織階層に対して相対的に解釈処理されます。たとえば、orgunit/west.sales.doc.com. は、west 組織単位をネーミングする完全指定名で、_orgunit/west.sales は、同じサブドメインをネーミングする相対的な名前です。

NIS 環境

NIS 環境では、NIS ドメインに対応する組織単位は各エンタープライズ 1 つずつあります。この orgunit には、orgunit/domainname という名前が付けられ、ここでの domainname は NIS ドメイン名です。たとえば、NIS ドメイン名が doc.com である場合は、組織単位は org/doc.com です。

NIS 環境では、空の文字列を組織単位の省略形として使用できます。したがって、org// は、org/domainname に相当します。

ファイルベースの環境

エンタープライズレベルのネームサービスがファイルベースであるときには、1 つだけの FNS 組織単位が存在し、サブ単位はありません。ファイルベースのネーミングで許容される唯一の組織単位は org// です。

サイトの名前空間

サイトの名前空間では、物理的位置でそのまま識別される地域名前空間が提供されます。たとえば、これらのオブジェクトには、キャンパスにある建物、ある階のマシンやプリンタ、建物内の会議室とその使用スケジュール、隣接するオフィスにいるユーザーなどがあります。サイト名は、接頭辞 site/ または _site/ で識別されます。

Solaris 環境では、サイトは複合名を使用してネーミングされます。複合名では、各原子名がより大きなサイト内のサイトを表わします。サイト名の構文は、ドット区切りの右から左であり、もっとも一般的な位置記述からもっとも特定の位置記述に配列された構成要素が含まれます。たとえば、_site/pine.bldg5 は、建物 5 にある Pine 会議室を表わし、site/bldg7.alameda は、あるエンタープライズの Alameda にある建物 7 を表わします。

ホストの名前空間

ホストの名前空間では、コンピュータをネーミングするための名前空間が提供されます。ホスト名は、接頭辞 host/ または _host/ で識別されます。たとえば、host/deneb は、deneb という名前のマシンを識別します。

ホストは、「hostname」コンテキストでネーミングされます。ホストコンテキストには、フラットな名前空間があり、ホストコンテキストへのホスト名のバインドが含まれます。「ホストコンテキスト」では、そのホストで見つかったファイルやプリンタなどの、マシンに相対的なオブジェクトをネーミングできます。

Solaris 環境では、ホスト名は Solaris のホスト名に対応します。単一のマシンに対する別名で同じコンテキストが共有されます。たとえば、mail_server という名前がマシン deneb および altair の別名である場合、deneb と altair の両方で、mail_server に作成されたコンテキストが共有されます。

ネットワーク資源は、必要に応じてホストに関連付けてネーミングする必要があります。たいていの場合、組織、ユーザー、サイトなどの構成要素に関連して資源をネーミングした方がわかりやすくなります。ホスト名に依存すると、ユーザーは、あいまいで変更される可能性のある情報を覚えなくてはならなくなります。たとえば、ハードウェアの変更、ファイルスペースの使用、ネットワークの再構成などのために、ユーザーのファイルがあるサーバーから他のサーバーに移動されてしまう場合もあります。さらに、ユーザーは、同じファイルサーバーを共有することが多くなり、ファイルがホストに関連付けてネーミングされた場合に混乱を招きます。しかし、ファイルがユーザーに関連付けてネーミングされた場合は、このような変更はファイルのネーミング方法に影響しません。

ホスト名を使用した方が適切な場合もあります。たとえば、資源が特定のマシンだけで使用可能であり、他の構成要素に関連付けてその資源をネーミングする論理的方法がない場合には、ホストに関連付けてネーミングする意味があります。または、ファイルシステムでは、ファイルが多くのユーザーに共有されている場合、格納されているマシンに関連付けてファイルをネーミングする意味があります。

ユーザーの名前空間

ユーザーの名前空間では、コンピュータ環境内のユーザーをネーミングするための名前空間が提供されます。ユーザー名は、接頭辞 user/ または _user/ で識別されます。

ユーザーは、「ユーザーコンテキスト」でネーミングされます。ユーザーコンテキストには、単一レベルの名前空間があり、「ユーザーコンテキスト」へのユーザー名のバインドが含まれます。ユーザーコンテキストでは、ユーザーに関連するファイル、サービス、資源などのオブジェクトをユーザーに関連付けてネーミングすることができます。

Solaris 環境では、ユーザー名は Solaris ログイン ID に対応します。たとえば、_user/inga は、ログイン ID が inga のユーザーを識別します。

ファイルの名前空間

ファイルの名前空間 (またはファイルシステム) では、ファイルをネーミングするための名前空間が提供されます。ファイル名は、接頭辞 fs/ または _fs/ で識別されます。たとえば、fs/etc/motd という名前では、/etc ディレクトリに格納されているファイル motd が識別されます。

ファイルの名前空間については、「FNS ファイルネーミング」で詳しく説明し、ファイルのコンテキストについては、「ファイルコンテキストの管理」で説明します。

サービスの名前空間

サービスの名前空間では、エンタープライズ内のオブジェクトに使用される、または関連するサービスのための名前空間が提供されます。このようなサービスには、電子カレンダ、FAX、メール、印刷などがあります。サービス名は、接頭辞 service/ または _service/ で識別されます。

Solaris 環境では、サービスの名前空間は階層になっています。サービス名は、スラッシュ (/) で区切られた左から右の複合名です。サービスの名前空間を使用するアプリケーションは、この階層属性を利用し、そのアプリケーションのサブツリーを獲保します。たとえば、プリンタサービスはサービスの名前空間のサブツリー printer を獲保します。

FNS は、サービス名またはリファレンスタイプが選択される方法を指定します。これらは、サービスの名前空間を共有するサービス提供者によって決定されます。たとえば、カレンダサービスは、サービスのコンテキストにある名前 _service/calendar を使用してカレンダサービスをネーミングし、名前 calendar にバインドされたものを決定します。

サービス名およびリファレンスの登録

米国 Sun Microsystems, Inc. は、service の名前空間の最初のレベルにある名前の登録を行います。新規名を登録するには、電子メールのリクエストを fns-register@sun.com まで送信するか、または書面で次の住所までご郵送ください。

FNS Registration
Sun Microsystems, Inc.
901 San Antonio Road.
Palo Alto, CA 94303
U.S.A.

名前の使用目的についての簡単な説明と、その名前にバインドされるリファレンスのフォーマットの説明をお書き添えください。

プリンタの名前空間

プリンタの名前空間では、プリンタをネーミングするための名前空間が提供されます。プリンタの名前空間は、サービスの名前空間に関連 (従属) します。つまり、プリンタのサービスは、サービスの名前空間のサービスの一部です。プリンタ名は、接頭辞 service/printer または _service/printer で識別されます。たとえば、service/printer/laser1 では、laser1 という名前のプリンタが識別されます。

後続スラッシュの意味

後続の / は、次のネーミングシステムにあるオブジェクトをネーミングします。あるネーミングシステムから他のネーミングシステムに移動するときに必ず必要となります。たとえば、名前 org/east.sales/service/printer では、org と east.sales の間のスラッシュは、上で説明した構成要素の区切り文字であり、組織名 (sales/) の最後の要素に続くスラッシュは、service 名前空間を組織単位名前空間から区切ります。したがって、org/west.sales/service/printer では、west.sales という組織単位の printer サービスがネーミングされます。

FNS 予約名

FNS は、表 22-1 に挙げたすべての原子名をそれ自身の使用のために名前空間識別子として獲保します。たとえば、_orgunit、org、_site、site などです。この制限事項は、「エンタープライズ名前空間の構造」にある名前空間の配列で定義されているように、名前空間識別子が現れるコンテキストに適用されます。それ以外の場合は、FNS は、他のコンテキストではこれらの原子名の使用を制限します。

たとえば、原子名 service は、user/fatima/service/calendar のように、ユーザー名に相対的な名前空間識別子として使用され、ユーザー fatima のサービスの名前空間のルートであることを意味します。FNS では、名前 user/ がバインドされるコンテキストは、名前空間識別子にではなく、ユーザー名に指定されるため、user/service のようにユーザー名として名前 service を使用することが禁止されるわけではありません。この場合、service は明確にユーザー名として解釈されます。一方で、/user/mikhail を使用すると、ユーザー mikhail とファイル (またはサブディレクトリ) /user/mikhail の区別がつきにくくなるため、user という名前のディレクトリは作成しないでください。

複合名の例

この項では、FNS ポリシーに従う名前の例を示します。これらのポリシーについては、表 22-2 を参照してください。

組織名、サイト名、ユーザー名、ホスト名、ファイル名、サービス名 (calendar や printer など) の名前は、例として使用されています。これらの名前は、FNS ポリシーでは指定されません。

組織に関連する名前を作成する

組織の名前空間 (_orgunit、orgunit、または org) に関連付けることのできる名前空間は、user、host、service、fs、と site です。

以下に例を示します。

• orgunit/doc.com/site/videoconf.bldg-5 では、組織 doc.com に関連するサイトの建物 5 にある会議室 videoconf がネーミングされる (orgunit に別名 org を使用して、org/doc.com/site/videoconf.bldg-5 を作成することもできる)

• orgunit/doc.com/user/mjones では、組織 doc.com のユーザー mjones がネーミングされる

• orgunit/doc.com/host/smptserver1 では、組織 doc.com に所属するマシン smptserver1 がネーミングされる

• orgunit/doc.com/fs/staff/agenda9604/ では、組織 doc.com に所属するファイル staff/agenda9604 がネーミングされる

• orgunit/doc.com/service/calendar では、組織 doc.com の calendar サービスがネーミングされます。ここでは、組織の会議スケジュールを管理する

ユーザーに関連する名前を作成する

user の名前空間に関連付けることができる名前空間は、service および fs です。

• user/helga/service/calendar では、helga という名前のユーザーの calendar サービスがネーミングされる

• user/helga/fs/tasklist では、ユーザー helga のホームディレクトリにあるファイル tasklist がネーミングされる

ホストに関連する名前を作成する

hosts の名前空間に関連付けることができる名前空間は、service および fs です。

• host/mailhop/service/mailbox では、マシン mailhop と関連する mailbox サービスがネーミングされる

• host/mailhop/fs/pub/saf/archives.96 では、マシン mailhop によってエクスポートされたファイルシステムのルートディレクトリにあるディレクトリ pub/saf/archives.96 がネーミングされる

サイトに関連する名前を作成する

sites の名前空間に関連付けることができる名前空間は、service および fs です。

• site/bldg-7.alameda/service/printer/speedy では、bldg-7.alameda サイトにあるプリンタ speedy がネーミングされる

• site/alameda/fs/usr/dist では、alameda サイトで使用可能なファイルディレクトリ usr/dist がネーミングされる

サービスおよびファイルに関連する名前を作成する

ファイル (fs) またはサービス (service) の名前空間に関連付けることができる名前空間はありません。たとえば、/services/calendar/orgunit/doc.com などの名前は作成できません。つまり、ファイルまたはサービスの名前空間に関連付けた複合名は作成できません。もちろん、/user/esperanza/service/calendar のように、他の名前空間に関連付けてファイル名またはサービス名を作成することは可能です。

エンタープライズ名前空間の構造

FNS ポリシーでは、エンタープライズ名前空間の構造が定義されます。この構造の目的は、統一性のある名前を簡単に作成することです。このエンタープライズ名前空間構造には、2 つの主要なルールがあります。

• 狭い有効範囲のオブジェクトは、広い有効範囲のオブジェクトに関連してネーミングされる

• 名前空間識別子は、ある名前空間から次の名前空間への移行を表すために使用される

表 22-2 は、エンタープライズ名前空間を配列するための FNS ポリシーのまとめです。図 22-2 に、これらの FNS ポリシーに従う名前空間の配置の例を示します。

図 22-2 エンタープライズ名前空間の例

エンタープライズの名前空間は、組織単位の周辺に構成されます。適切な名前空間識別子とオブジェクト名を使用して組織単位名を作成して、サイト、ホスト、ユーザー、ファイル、サービスの名前は、組織単位に関連付けてネーミングできます。

図 22-2 では、エンタープライズの sales 組織の西部事業部のユーザー myoko は、名前 orgunit/west.sales/user/myoko を使用してネーミングされます。

名前空間識別子 user を使用して、orgunit 名前空間から user 名前空間への移行を表していることに注意してください。同様に (適切な名前空間識別子を使用して)、ファイル名およびサービス名も、サイト、ユーザー、またはホストの名前に関連付けてネーミングできます。サイト名は、組織単位名に関連付けてネーミングできます。

簡単に均質な名前を作成することは、この構造を使用して達成されます。たとえば、エンタープライズ (orgunit/west) 内の組織単位名が分かれば、user の名前空間識別子とユーザーのログイン名で名前を作成して orgunit/west/user/josepha などの名前を作成し、エンタープライズに関連付けてユーザーをネーミングできます。

このユーザーのファイルシステムにあるファイルをネーミングするときには、orgunit/west/user/josepha/fs/notes などの名前を使用できます。