Tasks
Planning for resource scope use
Resource scope is a powerful concept to prevent duplication of resources across lower-level scopes. For example, if a data source can be used by multiple servers in a node, it makes sense to define that data source once at the node level, rather than create the data source multiple times, possibly introducing errors along the way.
If the data source definition needs to change (maybe due to changes to an underlying database), the data source definition can be changed once and is visible to all servers within the node. The savings in time and cost should be self-evident.
Some thought needs to be put toward outlining what resources we will need for all the apps to be deployed and at what scope to define each. You select the scope of a resource when creating it.
The following list describes the scope levels, listed in order of granularity with the most general scope first:
Cell scope
The cell scope is the most general scope and does not override any other scope. IBM recommends that cell scope resource definitions should be further granularized at a more specific scope level. When we define a resource at a more specific scope, we provide greater isolation for the resource. When we define a resource at a more general scope, we provide less isolation. Greater exposure to cross-app conflicts occur for a resource that we define at a more general scope.
The cell scope value limits the visibility of all servers to the named cell. The resource factories within the cell scope are defined for all servers within this cell and are overridden by any resource factories defined within app, server, cluster, and node scopes that are in this cell and have the same JNDI name. The resource providers that are required by the resource factories must be installed on every node within the cell before apps can bind or use them.
Cluster scope
The cluster scope value limits the visibility to all the servers on the named cluster. The resource factories defined within the cluster scope are available for all the members of this cluster to use and override any resource factories that have the same JNDI name that is defined within the cell scope. The resource factories defined within the cell scope are available for this cluster to use, in addition to the resource factories defined within this cluster scope.
Node scope (default)
The node scope value limits the visibility to all the servers on the named node. This is the default scope for most resource types. The resource factories defined within the node scope are available for servers on this node to use and override any resource factories that have the same JNDI name defined within the cell scope. The resource factories defined within the cell scope are available for servers on this node to use, in addition to the resource factories defined within this node scope.
Server scope
The server scope value limits the visibility to the named server. This is the most specific scope for defining resources. The resource factories defined within the server scope are available for apps that are deployed on this server and override any resource factories that have the same JNDI name defined within the node and cell scopes. The resource factories defined within the node and cell scopes are available for this server to use, in addition to the resource factories defined within this server scope.
Application scope
The app scope value limits the visibility to the named app. Application scope resources cannot be configured from the Integrated Solutions Console. Use Rational Application Developer Assembly and Deploy V7.5, or wsadmin to view or modify the app scope resource configuration. The resource factories defined within the app scope are available for this app to use only. The app scope overrides all other scopes.
We can define resources at multiple scopes but the definition at the most specific scope is used.
When selecting a scope, the following rules apply:
The app scope has precedence over all the scopes.
The server scope has precedence over the node, cell, and cluster scopes.
The cluster scope has precedence over the node and cell scopes.
The node scope has precedence over the cell scope.
When viewing resources, we can select the scope to narrow the list to just the resources defined at the scope. Alternatively, we can select to view resources for all scopes. Resources are always created at the currently selected scope. Resources created at a given scope might be visible to lower scope. For example, a data source created at a node level might be visible to servers within the node.
A common source of confusion is the use of variables at one scope and the resources that use them at a different scope. Assuming that the proper definitions are available at a scope the server can see, they do not have to be the same scope during runtime.
However, consider the case of testing a data source. A data source is associated with a JDBC provider. JDBC providers are commonly defined using variables to point to the installation location of the provider product.
The scope of the variables and the scope of the JDBC provider do not necessarily have to be the same to be successful during runtime. However, when using the test connection service to test a data source using the provider, the variable scope and the scope of a JDBC provider must be the same for the test to work.