分散 SpectroSERVER 環境（DSS）でサービス モデルを作成する場合は、考慮すべき重要な要素があります。サービス モデルは、他のランドスケープのリソース モデルに関連付けることができます。サポートされている動作は以下のとおりです。

以下の動作が、リソースを定義するためにグローバル コレクションを使用するサービスに適用されます。

CA Spectrum r9.2 では、パフォーマンスが重いクロス ランドスケープ ウォッチは非同期アクション通知に置き換えられるため、SpectroSERVER から負担が一部軽減されます。さらに、MLS が 1 つのランドスケープから別のランドスケープへ 2 層目の通知を転送できる中継メカニズムにより、2 層目のサービスは、別の 2 層目のランドスケープからリソースを監視することができます。

このため、パフォーマンスへの影響に関する懸念が少ないサービスを作成することができます。さらに、リモート リソースが存在するランドスケープで何が必要かを懸念することなく、サービスが論理的に存在するランドスケープ上でサービスを作成することができます。これにより、効率的に設計されたサービス階層の必要性がなくなることはありませんが、柔軟性が実現するため、サービス階層の設計が容易になります。サービス モードがどこで作成されているかにかかわらず、すべてのランドスケープのリソースが表示されます。

以下の図は、リモート リソースの設定に対してサポートされているサービスが表したものです。

どの設定がサポートされているのかを理解するだけでなく、サービス モデルの効率、およびリソース分散の影響を考慮することも重要です。同じランドスケープ内にあるリソースを監視することは、別のランドスケープにあるリソースを監視するよりも効率的です。サービス モデルを作成する際は、リモート ランドスケープ上のサービス リソースの数をできるだけ少なくするようにしてください。以下の例について考えてみます。サービス XYZ には 5 つのリソースがあり、これらのリソース モデルのうちの 1 つが MLS 上にあり、残りの 4 つが SpectroSERVER 1 （SS1）にあります。以下の図には、サービス XYZ で考えられる 2 つの設計が表されています。

ソリューション B は、リモート ランドスケープ上にあるリソースの数が少なくなっているため、より効率的な設計です。サービスをどのランドスケープにも配置できる場合は、大部分のリソースが存在しているランドスケープを選択します。このことは、「大部分のリソースに一番近いところにサービスを作成する」という原則で表すことができます。

状況によっては、サービスが第 2 層の複数のランドスケープ上にリソースを持っており、サービスを MLS 上に配置する必要がある場合があります。このようなシナリオでは、MLS 上の親サービスで監視される 1 つのサブサービスに複数のリモート リソースを連結することにより、さらに効率的なサービス設計を作成できます。

サービスを MLS 上に配置する必要がある場合に作成できる 2 つのソリューションは以下の図のとおりです。

 

ソリューション B は、リモートで監視されるリソースの数を最小限にすることにより、より効率的な設計を表しています。ソリューション B では、SS1 と SS2 で作成されたサービス モデルが MLS で作成されたサービスのリソースになります。ソリューション B に示されているようなサービス階層を作成する際には、各サービスで使用するポリシーに各ランドスケープのリソースの動作を正確に反映させることが重要です。

グローバル コレクションを使用するサービスを作成する際には、グローバル コレクションの使用によるリモート リソースの数を考慮します。いずれかのタイプのコンテナを使用してデフォルトでサービス リソースを指定すると、サービスではコンテナのコンテンツが監視されます。グローバル コレクションには、複数のランドスケープのモデルを含めることができます。

以下の図は、グローバル コレクションの使用によって非効率なサービス設計が作成される可能性を示したものです。

ここでも、ソリューション B は、リモートで監視されるリソースの数を最小限にすることによる、より効率的な設計を表しています。ソリューション B では、SS1 と SS2 で作成されたサービス モデルが MLS で作成されたサービスのリソースになります。ソリューション B に示されているようなサービス階層を作成する際には、各サービスで使用するポリシーに各ランドスケープのリソースの動作を正確に反映させることが重要です。

グローバル コレクションを使用するサービスを作成する場合は、グローバル コレクションの使用によるリモート リソースの数を考慮します。いずれかのタイプのコンテナを使用してデフォルトでサービス リソースを指定すると、サービスではコンテナのコンテンツが監視されます。グローバル コレクションには、複数のランドスケープのモデルを含めることができます。以下の図をもとに、グローバル コレクションの使用によって、非効率なサービス設計がどのように作成される可能性があるかを考えてみてください。

以下のシナリオでは、MLS でサービスが作成されると、そのサービスで 5 つのリモート リソースを監視していることになります。SS2 でサービスが作成された場合、そのサービスで保守する必要があるのは 1 つのリモート リソースだけです。

ただし、このシナリオで効率を改善することは、サービスを SS2 に移行するだけという簡単なものではありません。このサービスではグローバル コレクションを使用してそのリソースを指定し、潜在的に動的なリソース セットをサポートします。さらに 2 つモデルがグローバル コレクションに属している SS1 で作成される場合を考えてみます。

 

グローバル コレクションにすべてのランドスケープのリソースが含まれている場合は、MLS 上にサービスがある必要があります。他の方法としては、同じランドスケープ上にあるグローバル コレクションのローカル コピーを監視する複数のサービスを使用するというものがあります。グローバル コレクションは論理的にはシングル モデルですが、実際には、グローバル コレクションが指定されている各ランドスケープ上にあるモデルの重複モデル セットとして実装されています。

 

このアプローチでは、より効率的なサービスが生成されますが、保守が複雑になり、実装するために CA Spectrum のコマンド ライン インターフェース（CLI）の使用が必要になる場合があります。

別のテクニックとして、1 つのランドスケープにバインドされるグローバル コレクションを複数作成する、という方法があります。この場合、各ランドスケープ上にサービスを作成でき、これらのサービスを監視する親サービスを 1 つ伴います。

 

この設計では動的なコレクションのメリットが見込まれますが、同時に効率的なサービス設計も提供されています。複数のグローバル コレクションをこのような方法で保守するのは適切ではない場合があるため、このソリューションのコストとメリットについて、よく検討する必要があります。