About this task
The catalog service process can run in a
WebSphere Application
Server process.
For the base
WebSphere Application Server, the catalog service runs in the application
server process. By default, it is not enabled to start automatically.
For
WebSphere Application Server
Network Deployment, the catalog service runs
in the deployment manager process automatically, but you can configure
it to run in one or more node-agent or application-server processes.
Defining
the catalog.services.cluster property
By defining the catalog.services.cluster cell,
node or server custom property, you can customize your catalog service
environment. The environment can consist of a single catalog server
or a cluster (grid) of catalog servers. A single catalog server is
recommended for a development environment, and a grid of catalog servers
for a production environment. This key-value pair identifies which
server process will be enabled.
Set the value of the custom
property in the following form:
catalog.services.cluster ::= hosted_endpoints
hosted_endpoints ::= serverName ":" endpoints {"," hosted_endpoints}
endpoints ::= hostName ":" clientPort ":" peerPort ":" listenerPort
Each
attribute for the custom property value is defined as follows:
- serverName
- Specifies the fully qualified name of the WebSphere process, such as the cellName,
nodeName, and serverName of the server that hosts the catalog service.
If the serverName is not the local process, clients and containers
use this information to connect to the catalog service.
The following is an example for a remote catalog
service cluster:
server1:host.local.domain:6601:6602:2809,server2:host.local.domain:6601:6602:2809
- hostName
- Specifies the name of the hosting server.
- clientPort
- Specifies the port that is used for peer catalog grid communication.
- peerPort
- This is the same as the haManagerPort.
Specifies the port that is used for peer catalog grid communication
and can be anything you choose in a WebSphere Application
Server environment.
- listenerPort
- The listenerPort must match the BOOTSTRAP_ADDRESS value that is
defined in the WebSphere server
configuration.
A process that matches the serverName property
enables the catalog service on that server process.
Ensure that
you do not collocate the catalog service with eXtreme Scale containers
in a production environment. Include the catalog service in multiple
node agent processes or an application server cluster that is not
hosting an eXtreme Scale application.
Restriction: You
cannot have servers in a WebSphere Application Server environment
with the same name when the servers are using the ORB to communicate
with each other. You can resolve this restriction by specifying the
system property -Dcom.ibm.websphere.orb.uniqueServerName=true for
the processes that have the same name. The following are examples:
When servers with the name server1 on each node are used as a grid
of catalog services, or where multiple node agents are used to form
a grid of catalog services.
Examples:
- For a non-clustered catalog service, define a single value on
an example server1 as follows:
cellA\node1\server1:<hostname>:<clientport>:<peerport>:<listenerport>
- For a clustered catalog service as in the following example with
3 servers, define the property in a comma-delimited list:
cellA\node1\server1:<hostname1>:<clientport>:<peerport>:<listenerport>,
cellA\node2\server1:<hostname2>:<clientport>:<peerport>:<listenerport>,
cellA\node3\server1:<hostname3>:<clientport>:<peerport>:<listenerport>
In
the previous example, server1 is defined on all 3 hosts: hostname1,
hostname2, and hostname3. This property specifies the fully qualified
name of the WebSphere process, such as the cellName, nodeName, and
serverName of the server that hosts the catalog service. Also, clientport
and peerport are non-conflicting ports and listenerport must match
the BOOTSTRAP_ADDRESS for the servers.
With some exceptions, the catalog.services.cluster custom
property is similar to the -catalogServiceEndPoints parameter
that is used when starting a stand-alone catalog server with the addition
of the -listenerPort parameter.
Remember: The format and requirements for the custom property
file are similar, but depending on your WebSphere Application Server
deployment (base or Network Deployment), you must choose a different
menu path to set the parameters, as follows.
- Starting a catalog server in base WebSphere Application
Server
When
WebSphere eXtreme Scale is integrated into a non-federated WebSphere
Application Server profile, the catalog service will not automatically
start except in the following two circumstances:
- An application that is configured to automatically start an eXtreme
Scale container: Both the catalog service and container will start
automatically. See Starting eXtreme Scale containers automatically in WebSphere
eXtreme Scale applications for more information.
- If the catalog.services.cluster custom property
is defined.
If you need to start the catalog service without installing
an application, define the custom property catalog.services.cluster to
activate the service.
To create the custom
property in the administrative console select .
For Version 6.x, select .
In either version, specify the name
of the new property as catalog.services.cluster and
the value in the appropriate form using the defined attributes as
described previously. This configuration only supports a non-clustered
catalog service. Only a single value can be defined for this property.
For more information, see the topic on starting containers
in a WebSphere Application Server environment.
This feature
simplifies unit testing in development environments such as Rational®
Application Developer because you do not need to explicitly start
a catalog service.
- Starting a catalog service grid in WebSphere Application Server
Network Deployment
If WebSphere eXtreme Scale is installed on WebSphere Application Server
Network Deployment, the catalog service automatically
starts in the deployment manager process if it is augmented to allow
for quick development out of the box.
An eXtreme Scale catalog server grid
can be explicitly defined on a deployment manager, node agent, or
application server process using the catalog.services.cluster custom
property, which is set in the WebSphere Application
Server cell,
node or server configuration.
Attention: Do not
collocate the catalog services with eXtreme Scale containers in a production
environment. Include the catalog service in multiple node agent processes
or an application server grid that is not hosting an eXtreme Scale application.
To
create the custom property in the administrative console click . Specify the name as
catalog.services.cluster and
the value in the appropriate form, using the defined attributes. The
following is an example of a valid value:
cellA\node1\nodeagent:host.local.domain:6600:6601:2809,cellA\node2\
nodeagent:host.local.domain:6600:6601:2809
After
you set the custom property, you must restart each identified server.
When you restart these servers, the catalog service grid automatically
starts.
The catalog grid uses the core group mechanisms of WebSphere Application
Server. As a result, the members
of a catalog grid cannot span the boundaries of a core group, and
a catalog grid therefore cannot span cells. However, eXtreme Scale can span cells by
connecting to a catalog server across cell boundaries, such as either
a stand-alone catalog grid or a catalog grid embedded in another cell.
Remember:
You can define the
catalog.services.cluster property
for a cell, node or server. Cell and node properties are used for
WebSphere Application Server Network Deployment. Server properties
are used for Network Deployment and base WebSphere Application Server.
If multiple locations are set, the server properties override the
cell and node properties, and node properties override the cell property.