In a pilot deployment, one registry is used to keep a governance view of the service metadata, and a separate registry holds the metadata used by the runtime services in production. This means that you do not change runtime service metadata during the service development lifecycle, and changes to development service metadata do not impact runtime operation; at an appropriate point in the development lifecycle, when you are sure that a service is ready for production use, the service metadata is moved from the governance registry to the runtime registry, and the runtime systems adopt it.
Although not intended, primarily, for production use, this topology might be used in production for a small scale SOA environment.
| Registry | Description |
|---|---|
| Governance | 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 (production) | A limited set of content from the governance
registry is promoted to this registry as and when services are ready
to go into production, using the WSRR promotion feature. Typically, users do not work directly with this registry, and content is mostly read-only, although additional metadata might be added to registry content, to support ITCAM for SOA for example. Instead, users work in the governance registry, and content is promoted automatically to the runtime registry at the appropriate point in the governance lifecycle. This registry is used for business runtime access. |
Synchronization of lifecycle states
Changes to lifecycle states must be performed only in the governance registry. This ensures that the lifecycle states remain synchronized for the separate copies of the same service that exist in the two registries, and prevents the possibility of a negative impact on business runtime operations that might result from a change to a service in the runtime registry.
After changing the lifecycle state of a service in the governance registry, re-promote the service to the runtime registry to update its lifecycle state there.
Deployment profile configuration
Consideration must be given to the profiles used in each registry in the deployment. Typically, they support different sets of operations; for example, the runtime registry might not support lifecycle changes, or changes to service metadata. When you eventually move to a full production deployment, your profile configuration must reflect this; in a pilot deployment, however, you can use the same profile in each registry, but use policies to control operations in each registry.
Runtime registry "cleanup"
- Publish the service to the governance registry, or discover the service from another application environment (WebSphere® Application Server for example) using the WSRR service discovery mechanism.
- Govern the service through the development lifecycle.
- Deploy the service to production. The service is promoted automatically to the runtime registry.
- Retire the service. The service is re-promoted to the runtime registry to update its lifecycle state.
- Delete the service from the runtime registry.
Policy management
A policy has its own lifecycle and must be promoted from the governance registry to the runtime registry at the required point in that lifecycle.
You can discover policy sets from WebSphere Application Server or WebSphere Message Broker and govern them in the governance registry. Then, at the required point in the governance lifecycle, 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.
Datapower can, at runtime, pull policies from WSRR that are attached to WSDL elements, or obtain a complete WSDL file, containing policy attachments, for processing.
Thus, the governance registry provides the central point of governance for all policies.
Summary diagram
The pilot deployment is summarized in the following diagram:
