WebSphere Service Registry and Repository topologies explained

WebSphere Service Registry and Repository can be configured in a number of different topologies. This article describes a common scenario where you move from an evaluation system, to a sandbox system, to a full production system. The article also describes basic design considerations when deploying for deploying a WebSphere Service Registry and Repository solution.


Mandy de Belin (debelin@uk.ibm.com), Information Developer, WebSphere Service Registry and Repository, IBM

Photo of Mandy de BelinMandy de Belin is an Information Developer on the WebSphere Service Registry and Repository team at the IBM Software Lab in Hursley, United Kingdom. You can contact Mandy at debelin@uk.ibm.com.

Stephen Rea (stephen_rea@uk.ibm.com), Software Engineer, WebSphere Service Registry and Repository Development team, IBM

Photo of Stephen ReaStephen Rea is a Software Engineer on the WebSphere Service Registry and Repository team at the IBM Software Lab in Hursley, United Kingdom. His development expertise includes modeling, messaging, parsing, and consumability. Since joining the Lab as an experienced hire in 1999, Stephen has worked on numerous Websphere products, including WebSphere MQ, WebSphere Message Broker and WebSphere Service Registry and Repository. You can contact Stephen at stephen_rea@uk.ibm.com.

11 May 2011

Also available in Chinese


This article provides an overview of common deployment topologies and configurations for IBM® WebSphere® Service Registry and Repository (hereafter referred to as Service Registry).

Deployment topologies represent how Service Registry is configured to support your governance process, with runtime registries corresponding to specific life cycle stages or activities, such as evaluation, development, test, and production. Deployment configuration patterns represent the physical Service Registry installation required to support such topologies. Because Service Registry is a J2EE application based on WebSphere Application Server, its available configuration patterns are driven by those available to WebSphere Application Server. (If you are unfamiliar with WebSphere Application Server, see WebSphere Application Server concepts at the bottom of the article.

This article is for newcomers to Service Registry who have the responsibility to deploy the product to meet an enterprise's needs. It is structured around the stages of the Service Registry deployment life cycle, and describes the topologies you might adopt at each stage and the pros and cons of common deployment configurations. This article uses the term life cycle in two contexts. The services that you are governing have a life cycle, as they are modelled, assembled, deployed, and managed. And your implementation of Service Registry also has a life cycle, as you move from evaluation to implementation.

Typical Service Registry life cycles:

  • Evaluation and training -- used for proof-of-concept, prototyping, general product evaluation, and educational workshops.
  • Development and testing -- used for development and testing of governance and promotion processes.
  • Full production -- used for staged testing and final deployment to production systems.

Overview of Service Registry

The main function of Service Registry is to act as a repository for service-related data, and for descriptions of this data. Service Registry is used to store the physical documents related to the description of a service. For example, you might want to store the WSDL file that defines a service, XSD files describing the message format of expected incoming requests and outgoing responses from that service, and any Web service-related policy documents describing policies that are applied to that service.

When you import these files into Service Registry, it parses the file contents and breaks it into constituent parts, or entities in a process is known as shredding. Shredding creates physical entities, representing real objects such as the actual files, and logical entities, representing information contained in the files. Each of the entities can be modelled in a logical form beyond the physical boundaries of the files that describe them. As part of this import process, additional metadata is created and tied to these newly created logical and physical entities within Service Registry. This metadata helps describe, classify, and relate the entities to their origin. Thus the entities all have standard properties associated with them.

The entities derived when documents are imported make up the logical model of Service Registry. The logical model supports entities such as port type, port, and message (related to WSDL files), and complex type or simple type (related to XSD documents). These entities each have properties and relationships that represent their characteristics, as defined in the source document. For example, a physical WSDL document entity has values assigned to standard properties, such as its assigned name, a specific namespace group it belongs to, and an initial version number. A logical WSDL service entity also has a namespace property and a relationship to the ports it contains.

All individual results of document shredding are aggregated into one logical model that represents not only the content of individual documents, but also relationships between content in different documents. Logical entities cannot be individually versioned, because they are derived from a physical document (which can be versioned) and cannot therefore be independently manipulated. However, as described above, both logical and physical entities can be assigned predefined metadata describing their relationship to other stored entities and classified as belonging to one or more grouping systems. Service Registry has configuration profiles that provide predefined property, relationship, and classification definitions. You can use the configuration profiles provided with Service Registry, or produce customized configuration profiles to reflect your organization's needs.

For an overview of the Service Registry content model, see Content model overview in the Service Registry information centre.

Service Registry design considerations

Two types of operations are performed in Service Registry:

SOA development involves publishing new services, governing services throughout their life cycle, and querying Service Registry to find services that can be used to develop a new business process.
An application or enterprise service bus (ESB) interrogates Service Registry to discover an appropriate service to use at run time, or to make routing or data transformation decisions. You may have multiple runtime environments in your Service Registry deployment. For example, there may be two or more ESB domains, perhaps as a result of an acquisition or merger.

Many Service Registry implementations incorporate both a governance function and a runtime function, but there are also governance-only and runtime-only implementations. This article assumes a dual-purpose Service Registry system.

Many implementations of Service Registry involve multiple service registries: a governance registry in which governance operations take place, and one or more runtime registries, which are populated from the governance registry by promotion. Promotion occurs when governed objects reach a certain defined state in their life cycle.

Actions involved in governing a service

Here is the sequence of actions involved in governing a service in Service Registry:

  1. Publish the service to the governance service registry, or discover the service from another application environment (such as WebSphere Application Server) using the Service Registry service discovery mechanism.
  2. Govern the service through the development life cycle.
  3. Deploy the service to production. The service is promoted automatically to the runtime service registry.
  4. Retire the service. The service is re-promoted to the runtime service registry to update its life cycle state.
  5. Delete the service from the runtime registry.

Synchronization of life cycle states

When governing a service, you move it through various life cycle stages. For example, you might be governing a version of a service as a service version object in Service Registry. During its life cycle, the service version progresses through the model, assemble, deploy, and manage phases, and each of these phases has a number of life cycle states that the service version transitions through. In the case of the deploy phase, the object transitions through staging review, staged, certification review, certified, operational review, and operational states. Changes to life cycle states must be performed only in the governance service registry. After changing the life cycle state of a service in the governance registry, it is promoted (or re-promoted) to the runtime service registry to update its life cycle state there. This promotion ensures that the life cycle states remain synchronized for the separate copies of the same service that exist in the governance service registry and any runtime registries, preventing any negative impact on business runtime operations. Part of your design is deciding at what point in the life cycle the object is promoted. For example, you may decide to promote a service version object when it reaches the operational state, and not before.

After a service has reached the end of its useful life, and you have updated the life cycle state in the governance registry and re-promoted the service to synchronize the change with runtime service registry, you will eventually delete the service from the runtime registry as part of general cleanup operations.

Configuration profiles

Service Registry supports configuration profiles, which can be loaded and activated in your Service Registry installation and control the capabilities of Service Registry. For example, if you want to implement service governance, use the Governance Enablement Profile (GEP). Otherwise, for a runtime-only service registry with no governance, you might use the Basic Profile. You can design and load your own configuration profiles. For example, if you want to implement a life cycle model different from those implemented in the GEP, Service Registry Studio provides a graphical interface for doing so. Do not confuse configuration profiles with WebSphere Application Server profiles, which are explained under WebSphere Application Server concepts at the bottom of the article.

You must consider which configuration profiles to activate in each of the service registries in your deployment. Typically, the service registries support different sets of operations. For example, the runtime registry might not support life cycle transitions, depending on promotion from a governance registry to implement state changes. You might configure your runtime registry to be read-only. Alternatively, you might have a legitimate reason to update your runtime service registry, for example, to support IBM Tivoli Composite Application Manager (ITCAM) for SOA, which can monitor a running service, and update the metadata for the service entry in Service Registry.

Policy management

You can use Service Registry to manage policies, which specify the requirements that must be met so that a service can be consumed by a client. For example, a Web service may require that all messages are digitally signed and encrypted; in this example, the requirement for signature and encryption is the policy and the Web service itself is referred to as the subject of the policy. Service Registry provides a central point of management for such policies. A policy has its own life cycle and must be promoted from the governance service registry to the runtime service registry at the required point in that life cycle.

You can discover policy sets from WebSphere Application Server or WebSphere Message Broker and govern them in the governance service registry. Then, at the required point in the governance life cycle, you can publish them automatically to other WebSphere Application Server or WebSphere Message Broker instances. You can also modify the policies themselves and then replicate back the changes. (This example involves WebSphere Application Server in a wider context, not just in the role of application server for Service Registry).

WebSphere DataPower Appliances can, at run time, pull policies from the runtime service registry that are attached to Web Service Definition Language (WSDL) elements, or obtain a complete WSDL file, containing policy attachments, for processing.

Evaluation and training

If you are a potential user of Service Registry, and want to quickly install and evaluate it to confirm that it meets your requirements, start with a stand-alone deployment topology. If you are an experienced Service Registry user who is tasked with training other users, then the stand-alone deployment topology is also recommended.

Stand-alone deployment topology

In a stand-alone Service Registry deployment, all service metadata is stored in a single service registry. It must be configured to achieve the right degree of separation between development and runtime usage, so that changes made to services in the service registry during development cannot harm business runtime operations, and so that publish and governance operations do not degrade runtime performance. Therefore, a stand-alone deployment is not suitable for pilot or production use for any but the smallest implementations. Instead, use this deployment configuration for:

  • Proof of concept
  • Proof of technology
  • Prototyping
  • General product evaluation
  • Educational workshops

The stand-alone deployment will help you understand the issues of your production environment relating to segregation of service registry content, and to plan the most appropriate deployment configuration to use for production. To achieve segregation in a single service registry, you must use additional metadata to identify which environment applies to each service.

If you have more than one runtime domain, the configuration of your registry service metadata must discriminate between these domains. For example, the same service may be defined in two or more different domains, with different endpoints. Figure 1 summarizes how the stand-alone registry provides support for the development and runtime environments:

Figure 1. Separate development and runtime environments in a stand-alone deployment
Separate development and runtime environments in a stand-alone deployment

Segregation of data in a single service registry

The recommended method for segregating data within a single service repository is by using classifications. The classification system is a form of pre-defined metadata that can be tagged to entities within your service repository to offer a method of data segregation. For example, the GEP defines a governance profile taxonomy -- a system of hierarchical types that can be used to describe entities. The types are expressed in a class and subclass system, which is a base classification used in part to describe different environments that services might be deployed to. The top-level class of Environment enables you to segregate different services or versions of a service across environment boundaries. You can assign your service to one of the following pre-defined subclasses in this type hierarchy: Development, Test, Staging, and Production.

You can use the same approach if you have more than one runtime domain. Again the configuration of your registry service metadata must discriminate between these domains. For example, the same service might be defined in two or more different domains, with different endpoints. As before, the classification system described in the pre-supplied governance profile taxonomy can be applied to your services. In addition to defining an Environment type system, a base business domain class system is also described, providing the following predefined sub-classes:

  • Finance
  • Insurance
    • Insurance Account Management
    • Insurance Claims Processing
  • Sales and Marketing

The GEP provides other classification systems, and you can also design your own if you define a custom configuration profile.

Stand-alone deployment configuration

A stand-alone deployment configuration has WebSphere Application Server, Service Registry, and the Service Registry database on the same node. A common variant is to have WebSphere Application Server and Service Registry on the same node, and a remote Service Registry database on a separate system. If required, you can install several stand-alone Service Registry systems on the same node, but each stand-alone Service Registry is administered from its own dedicated WebSphere Application Server admin console (in WebSphere Application Server terminology, each Service Registry is in a separate cell).

Stand-alone system with local database

In this configuration, WebSphere Application Server, Service Registry, and the Service Registry database are installed on a single node (a single computer):

Figure 2. Stand-alone system with local database
Standalone system with local database

Stand-alone system with remote database

In this configuration, WebSphere Application Server and Service Registry are installed on one computer, and the Service Registry database on a different one:

Figure 3. Stand-alone system with remote database
Standalone system with remote database

Development and testing

If you are a new user of Service Registry looking to develop and test a governance view of service metadata before going live with a production system, then the pilot deployment is recommended. You can use a pilot deployment system to develop and test the administration of service metadata, to develop life-cycles, and to perfect a promotion strategy. The emphasis in a pilot deployment system is developing and testing your implementation of Service Registry. It provides a sandbox for you to prototype and test your service management processes as well as any components that you develop, such as custom configuration profiles, or Business Space environments tailored to different end users.

The pilot environment does not contain real service metadata, and service metadata does not move between the pilot environment and the full production environment. You are effectively testing the configuration profile in the pilot environment, and you can move the configuration profile into production. Again, this recommended deployment is applicable even if only a governance registry and repository is required. Runtime registries illustrated in this deployment can be removed.

Pilot deployment

The pilot topology described here contains two separate governance service registries and one runtime service registry. The pilot is used for customization of registry governance life-cycles and profiles. There are two governance service registries, because one is used for developing the governance processes and the other is used to test the governance processes before deploying content to the production instance. Figure 4 shows this topology:

Figure 4. Overview of pilot deployment system
Overview of pilot deployment system

In the pilot deployment system, users work in the development and test governance service registries only, and content is promoted automatically to the runtime service registry at the appropriate point in the governance life-cycle. Although not primarily intended for production use, this topology can be used in production for a small-scale SOA environment.

This section has described the second stage in a typical registry life-cycle, the piloting of the purchased technology. It has described the recommended multi-registry deployment topology, providing physical segregation of data into separate registry repositories. Each registry manages content at different levels of completeness associated with different phases of the SOA life-cycle. The next section describes the recommended deployment configuration to support this topology. Again, you will see that the suggested configuration patterns closely mirror what is permissible under WebSphere Application Server.

Pilot deployment configuration

A pilot deployment configuration has three independent registries and associated databases installed under a single WebSphere Application Server installation. Four variations of this configuration are shown below:

  • A typical configuration would have all these on the same node: that is, multiple application server profiles within one WebSphere Application Server installation:
    Figure 5. Pilot deployment configuration on a single node -- single WebSphere Application Server
    Pilot deployment configuration on a single node -- single WAS
  • As above but using remote registry databases held on a separate system or systems:
    Figure 6. Pilot deployment configuration on a single node -- single WebSphere Application Server, remote database
    Pilot deployment configuration on a single node -- single WAS, remote database
  • Multiple stand-alone application servers existing on a single machine, but through independent installations of WebSphere Application Server. Again, with or without remote database hosting:
    Figure 7. Pilot deployment configuration on a single node -- multiple WebSphere Application Server
    Pilot deployment configuration on a single node -- multiple WAS
  • Multiple stand-alone application servers all existing as independent installations of WebSphere Application Server on separate nodes. Again, with or without remote database hosting:
    Figure 8. Pilot deployment configuration on multiple nodes
    Pilot deployment configuration on multiple nodes

Full production

When you are ready to go live with your system, you need to manage a series of staging environments, using one registry for each. You can focus and support the various stages of the service development and testing life cycle in an isolated manner prior to final deployment to the production runtime registry. This section describes topologies for a full production deployment.

Full production deployment topology

The full production deployment is used to support staged testing and final deployment to production systems. In this topology, information from the single governance service registry is promoted to a series of staging environments for different levels of testing before final deployment to the production runtime service registry. Figure 9 shows a full production deployment, with the numbers representing the promotion sequence to various environments.

Figure 9. Full production environment
Full production environment

A service can pass through a series of environments between its initial development and its release into production -- for example, development, test, staging, and production environments. In a full production deployment, there is one registry for each environment that you want to test in an isolated manner.

The number and types of environments depend on the nature of your development process. Keeping the service metadata for your development, testing, and staging environments in separate registries provides fine-grained control, letting you more effectively mirror what will happen when a service goes into production. Typical registries found in this deployment topology include:

Governance master
Development teams share access to the content in this registry, typically segregated according to department. All discovery, development, and governance operations are performed here.
Runtime staging
One registry for each staging environment -- for example, integration, acceptance testing, and pre-production.
Runtime production
A limited set of content from the governance registry is promoted to this registry when services are ready to go into production, using the registry promotion feature.

A typical set of runtime testing environments, each having its own service registry, includes:

Integration testing
Testing in the integration environment ensures that the service functions correctly when integrated with the component or components that depend on it, or on which it depends. For example, a service may be consumed by an application, and the service and application may be owned by different departments and therefore have been developed and tested independently.
Acceptance testing
Acceptance testing ensures that the service, together with all integrated components, meets the stated business need.
Pre-production testing
The pre-production environment is an exact replica of the production system, and therefore testing in it ensures that the service will function as required in production.

Service promotion and synchronization

You move services through the different environments via promotion. Conceptually, a service moves from one environment to the next when it reaches the appropriate life cycle state as a result of governance operations. In practice, all governance operations are performed on the service in the governance service registry, and promotion is used to promote a copy of the service to the next staging service registry in the sequence and, ultimately, to the production service registry. This promotion ensures that the life cycle states and metadata remain synchronized for the separate copies of the same service in the service registries.

Configuration profiles

In a production environment, you can load and activate different configuration profiles on the service registries. You can use the configuration profile to lock down functionality in your staging and runtime service registries to ensure that life cycle state changes and associated metadata changes are confined to the governance service registry.

Full production deployment configuration

A full production deployment configuration will have multiple independent service registries and their associated databases. For high availability (redundancy) in the production environment, each service registry is replicated across multiple nodes in a cluster system (a horizontal cluster with cluster members on multiple nodes across many machines in a cell). Each service registry uses remote registry databases held on separate systems. This configuration is shown in Figure 10:

Figure 10. Full production configuration
Full production configuration

Other variants for each registry are:

  • Multiple stand-alone application servers on a single machine, but through independent installations of WebSphere Application Server, again with remote database hosting.
  • Multiple node, multiple application server profiles with remote database
  • Multiple node, multiple stand-alone application servers with remote database

Migrating between topologies

Special considerations for runtime service registries

A runtime registry is any non-governance service registry. Runtime registries are satellite service registries (such as Test, Pre-production, and Production) that get populated by promotion of objects from a governance service registry. You can add further runtime registries or remove existing ones at any time. When creating a new runtime registry, it is populated from the governance registry.

Communication between a governance registry and runtime registries can vary from direct network connectivity, to no direct connection, to the use of a DMZ. Runtime registries do not necessarily follow the same security model as the governance registry -- in fact, a runtime registry is likely to have more restrictive security policies.

When following recommended practice and using the GEP in the governance registry, everything from capability version downwards is typically promoted and stored in a runtime registry. You do not promote the actual physical documents (such as WSDLs, XSDs, and policies), but rather the objects that are derived from these documents, and which define the service. Although you can customize and configure the GEP, keep changes to a minimum as to avoid complications with promotion.

When possible, lock down runtime registries with as few unneeded processes running as possible. Guidelines include:

  • Tighten access permissions -- there is no need for wide access to create/update/delete. Establish set security permissions, such as for Administrator, ITCAM, and UDDI.
  • Turn off some plug-ins, but consider those that should run when updates occur. For example, ITCAM can require update access and promotion will cause creates/updates. Consider using the governance policy validator.
  • Disable e-mail notification and scheduled tasks.
  • Ensure that the correlator plug-in is not enabled.
  • Disable promotion to other registries.
  • Consider using a different user interface for your runtime registries. For example, use Business Space instead of the Web UI.
  • Disable JMS. (However, if you want to synchronize your runtime registry with UDDI, you need JMS enabled.)
  • Possibly disable activity logging. (Not strongly recommended as such logging is more relevant for a runtime registry.)

Evolving your deployment topologies

Having created the stand-alone evaluation and training topology described in this article, you might want to use it as the basis of a pilot development and testing topology. Or you might want to use your pilot topology as the basis of a full production system. Evolving between topologies in this way involves the creation of additional service repositories:

  • When moving from a stand-alone deployment configuration to a pilot deployment configuration, you move from having a single service registry to having separate governance and runtime service registries.
  • When moving from a pilot deployment configuration to a full production deployment configuration, you require additional runtime registries so that you have separate service registries for staging and production (and you might require multiple staging registries for different testing phases).

To establish additional runtime registries in support of such a migration, take the following steps:

  1. Identify services and objects that should be present in the target runtime service registry. Since promotion occurs on a transition, it is not sufficient to assume anything in a specific state has been promoted. You must also be sure that the only way to have arrived at the state concerned, within the life cycle, was along the transition that would have caused promotion. If this assumption can be made, then you can identify which services or objects should be in the repository based on the state they are in.
  2. Establish how to re-trigger the promotion to the newly created runtime registry you wish to populate. Temporarily modify the life cycle for the states you identified in Step 1. Add a re-promote transition and then add these re-promote transitions to the promotion configuration with the new runtime registry as the target.
  3. Consider the order objects get transitioned to trigger re-promotion. Ideally you should follow the governance enablement profile process and re-promote entities in the same order as they were initially promoted, in order to avoid potential promotion issues on the target. The actions (updates) that promotion takes completely depends on what already exists within the target registry. In theory, re-promoting the highest level object (for example, service version) will result in everything else getting created if it does not already exist.

Promotion is only a snapshot in time. The runtime registry only holds objects as they were at the point in time the transition caused promotion. Any attempt to re-promote later to recreate a runtime registry will not necessarily re-promote the exact same metadata. So a runtime registry created from day one and a runtime registry later re-created via this mechanism are not guaranteed to be identical. The differences would correspond to changes permitted within the GEP while the service is in a state identified in Step 1. Additionally, policies do not get automatically promoted across with service documents to which they apply as part of the standard process modelled by the GEP, because policy attachments relate to all objects to which they apply (whether ready for promotion or not). So for example, promotion of a WSDL will not result in its policy attachments being included.

WebSphere Application Server concepts

You need to be familiar with some key WebSphere Application Server terms and concepts:

A node is a logical grouping of managed application servers. A node usually corresponds to a logical or physical computer system with a distinct IP host address. Nodes cannot span multiple computers. The node name is based on the host name of the computer, such as mandsrv01. Nodes can be managed or unmanaged -- an unmanaged node does not have a node agent or administrative agent to manage its servers, whereas a managed node does. An application server can be on unmanaged or managed nodes.
WebSphere Application Server can be configured so that several nodes can be associated together in a cell, which is implemented by having a Deployment Manager that administers the nodes in the cell. All of the components in the cell are administered from a single WebSphere Application Server administrative console. There can be only one registry installed in a cell (although it can be replicated across the nodes in a cluster system – see definition of cluster).
Distributed (or federated) node
WebSphere Application Server supports a distributed configuration, where a deployment manager controls several application servers distributed across several nodes. Each node can have different resources and capabilities, but all are in the same cell and are controlled from a single administrative console. Because of the limitation of having only one registry in a cell, this configuration is not applicable when you require multiple, independent registry installations.
Clusters are like distributed systems where application servers are managed together, but the aim is to provide high availability or workload balancing. Servers that belong to a cluster are members of that cluster set and must all have identical application components deployed on them. (The physical machines do not have to be identical). A vertical cluster has cluster members on the same node or physical machine. A horizontal cluster has cluster members on multiple nodes across many machines in a cell. You can configure either type of cluster, or have a combination of vertical and horizontal clusters. For high availability, you need a horizontal cluster.
A WebSphere Application Server profile defines the runtime environment. The profile includes all the files that the server processes in the runtime environment, and that you can change. An administrator can define multiple such runtime environments under one installed copy of WebSphere Application Server. Administration is enhanced when using profiles rather than multiple product installations. Not only is disk space saved, but updating the product is simplified when you maintain a single set of product core files. Also, creating new profiles is more efficient and less error-prone than full product installations, enabling you to create separate profiles of the product for development and testing. WebSphere Application Server provides different profile types. (Do not confuse a WebSphere Application Server profile with a Service Registry configuration profile. A Service Registry configuration profile is loaded and activated in Service Registry after installation, and configures its capabilities).


This article described some recommended topologies when deploying Service Registry. It provided a view of Service Registry deployment over time, moving from a simple stand-alone evaluation system, through a development and test sandbox, to a full production system.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=WebSphere Service Registry and Repository topologies explained