Lifecycle management is of importance to every enterprise that wants to implement a process-driven SOA with emphasis on adaptability, service reuse and improvement. The lifecycle management (LCM) system for CentraSite helps to:
Assess change impact and manageability across all service consumers;
Ensure service quality through an integrated lifecycle approval process;
Enable a single viewpoint for service stages and their artifacts.
Typically, assets such as web services pass through different states (designing, implementation, testing) before they can be used in a production environment. As the number of objects in a registry grows, it is necessary to introduce stages (Development, Test, Production) to provide adequate operational environments for all parties involved in the lifecycle. Furthermore, an organization may want to add conditions and rules for passing an object through the lifecycle. Therefore the registry should allow administrators to define roles and permissions and connect these to lifecycle steps.
A lifecycle model is a state machine that can be maintained in CentraSite and applied to an asset type. In CentraSite, the lifecycles of assets, policies and also lifecycle models themselves can be managed. Lifecycle models are defined by administrators for their organization.
There are two levels of lifecycle models: system-wide models and organization-specific models. A system-wide model applies to objects that can be owned by any organization, whereas an organization-specific model applies only to objects that are owned by a specific organization. System-wide models have precedence over organization-specific models; when a system-wide model for an object type (set of types) exists, it takes priority over all other models. However, if an organization-specific model already exists and a system-wide model is added, then the organization-specific model still exists and the objects that are in this model will complete their lifecycle without effects. Only new objects will be assigned to the new system-wide model.
Each organization-specific lifecycle model belongs to an organization. System-wide models do not belong to any organization, but apply to all organizations. System-wide models may have organization-specific policies attached to them.
For a given object type (say "Service"), each organization can define and activate its own lifecycle model, so that there are several models that can control the "Service" type. However, per organization only one lifecycle model can be active. When a new "Service" instance is created, then the creating user belongs to an organization, and that organization's active lifecycle model will be used to control the particular "Service" instance.
It is possible to define a lifecycle model which consists of multiple nodes (registries) to make up one overall model. Each node only knows the model for the current node. It also knows the nodes that make up the complete lifecycle model and where they are.
Global models may have organization-specific policies attached to them. Organizational models are technically hierarchical, as organizations may contain sub-organizations.
A lifecycle model can itself be assigned to a lifecycle model, i.e. to enable a lifecycle model it may be necessary to go through a lifecycle model to activate it for usage.
Lifecycle management is possible for the object types that are classified as assets, as well as for policies and lifecycle models themselves.
The following points should also be noted:
Organization-specific models are defined by the administrator of the organization.
An object type may have more than one lifecycle model defined, but only one per organization can be defined as active at any given time.
Most software engineering methodologies define fundamental phases, that start with requirements or needs for a software and end with a productive software. These phases apply to typical lifecycle stages like Analysis, Development, Test, Production. In general these stages are represented by dedicated software and hardware environments like server, repositories and tools. A registry adds benefit to all stages as it references, collects and maintains structured information of relevance in each of these stages. Especially for enterprises following the service oriented architecture, the CentraSite provides registry stages that can be used to take strong control over the lifecycle process the on one hand but allow for loosely coupled stage environments on the other hand.
If we take the example of the stages Architecture, Development, Test and Production, the following tasks could apply to them:
Architecture
If services are developed in a top-down approach, the Architecture
registry keeps track of all planning and preparation information. A service
request triggers design and approval steps that may lead to the implementation
or rejection of the requested service. During the service design process, the
service interface as well as metadata may undergo changes. Only the final
approval by an authorized role marks the service as ready for implementation.
Examples of metadata which may be of special interest in the Architecture stage
are:
Organization and contact responsible for service provisioning;
Date planned to go live;
Planned service consumer; dates planned to consume the service.
Development
For the implementation of the service, it is important that only
approved service descriptions are used. Service consumers often start to
implement their service usage at the same time and rely on the service
description. Multiple instances of Development registries may exist. These
registries may be volatile, because development environments exist for the
duration of one release and can be set up in a different configuration.
Therefore it must always be possible to set up a development registry with the
services that are of interest for the projects using this environment.
Test
In loosely coupled service oriented architectures, the test laboratory
often integrates for the first time different service participants which
previously worked in dedicated environments. Furthermore the test cycle
requires the repeated handover from development to test. The registries can
support these dynamics by providing easy-to-use export and import facilities
for all service related information and components. As the number of service
provider and consumer applications grows, the test environments also get
volatile and its registries need the flexibility to be adapted to the different
combinations of test participants.
Production
Finally, the registry in the production environment is the single
point of truth for all applications requesting service lookup. Objects should
enter this registry only if they have passed defined approval steps and if they
are from a prescribed origin, for example the test registry. Metadata in the
registry can inform about contacts in case of malfunction. Or the registry can
be used to notify contacts in case of planned restrictions in availability.
Given these different tasks and requirements, it is obvious that multiple registries become important for optimal support of specific needs; while the Architecture is interested in services, service versions and participants still in planning, the Production is not. Test registries keep objects and references with physical properties - like endpoints - that are only valid during the test phase and are of no interest either to Architecture or Production. However, it is important that defined transitions exist from one stage to another and that each object can be traced to its current stage.
This four-stage topology is an example for enterprises with a strong top-down approach in their enterprise architecture; simpler or more complex topologies are also possible.
Note:
This four-stage topology is an example for enterprises with a strong
top-down approach in their enterprise architecture; simpler or more complex
topologies are also possible. In practice, any deployment involving more than
two stages leads to significant administrative overhead involved in managing
multiple registries (in particular, creating LCMs and policies across all
instances) and promoting objects from one registry to another.
When a lifecycle model is stored in CentraSite, it must be a valid state machine. This specifically means that all of the following semantic rules must be checked by CentraSite:
There is an initial state. All objects under the control of the lifecycle model are initially in this state.
Each state must be reachable from at least one other state.
A default next state can be defined for each state.
There must be at least one end state. An end state is one that it does not have any next state.
There may be a preferred transition from one state to the next (for the UIs to use).
The registry stages are broken down into states for lifecycle-enabled objects like services. This way the lifecycle process can be split into smaller steps, each supported and controlled by its responsible stage registry. States are connected to each other by allowable transitions. An approval process can define the conditions and activities to set a service from one state to another. CentraSite comes with the following:
A set of object states, associated to each registry stage
A state-transition proposal to control the lifecycle
An example for collaboration management by roles, rights and notifications
By using stages and states, you ensure that the registry object always has one defined state, even if multiple registries exist. State transitions are restricted; this ensures that the registry object had passed the lifecycle process correctly and achieved the required quality.
When moving from one state to the next, the following situations can exist:
The required next state is in the same stage as the current state. In this case, the state change can be performed directly on the registry object from the user interface.
The required next state is not in the same stage as the current state. In this case, the object must be exported (where necessary, along with its associated objects). In the exported archive, the current state remains unchanged. On importing the archive to the new stage, the state is set automatically to the appropriate new state.
You can associate a lifecycle model with one or more asset types. If an active lifecycle model is already associated with a particular type within an organization, you cannot assign another lifecycle model to that type. In other words, a particular object type can be associated with one and only one lifecycle model within a particular organization. If you want to switch an object type to a different lifecycle model, you must disassociate it with the current model and then assign it to the new model.
You can configure a virtual type to follow the same lifecycle model as its base type or you can give the virtual type its own lifecycle model to follow. Whether a virtual type follows the lifecycle model of its base type is determined by the type's Inherit Base Type LCM setting.
When the Inherit Base Type LCM option is enabled for a virtual type, the virtual type automatically inherits its lifecycle model from the base type if the virtual type does not have an assigned lifecycle model of its own. (In other words, the lifecycle model for the base type serves as the default lifecycle model for the virtual type. CentraSite applies the lifecycle model of the base type to the virtual type only when the virtual type has no other lifecycle model assigned to it.)
If the Inherit Base Type LCM option is disabled, the lifecycle of the virtual type is completely independent of the lifecycle of the base type. The virtual type will only have lifecycle model if you explicitly assign one to it.
The following table summarizes how lifecycle model is applied to a virtual type depending on the state of the Inherit Base Type LCM option.
| If the "Inherit Base Type LCM" option is... | And the Base Type... | And the Virtual Type... | Instances of the Virtual Type... |
|---|---|---|---|
| ENABLED | HAS an assigned lifecycle model | DOES NOT HAVE an assigned lifecycle model | Will follow the lifecycle model assigned to the Base Type |
| ENABLED | HAS an assigned lifecycle model | HAS an assigned lifecycle model | Will follow the lifecycle model assigned to the Virtual Type |
| ENABLED | DOES NOT HAVE an assigned lifecycle model | DOES NOT HAVE an assigned lifecycle model | Will not have an assigned lifecycle model |
| ENABLED | DOES NOT HAVE an assigned lifecycle model | HAS an assigned lifecycle model | Will follow the lifecycle model assigned to the Virtual Type |
| DISABLED | HAS an assigned lifecycle model | DOES NOT HAVE an assigned lifecycle model | Will not have an assigned lifecycle model |
| DISABLED | HAS an assigned lifecycle model | HAS an assigned lifecycle model | Will follow the lifecycle model assigned to the Virtual Type |
| DISABLED | DOES NOT HAVE an assigned lifecycle model | DOES NOT HAVE an assigned lifecycle model | Will not have an assigned lifecycle model |
| DISABLED | DOES NOT HAVE an assigned lifecycle model | HAS an assigned lifecycle model | Will follow the lifecycle model assigned to the Virtual Type |
Note:
If a virtual type initially inherits its lifecycle model from the
base type and it later it is assigned its own lifecycle model, instances of the
virtual type that were created while the type was following the lifecycle model
of the base type will continue following that model. Only instances of the
virtual type that are created after the new lifecycle model is assigned to the
virtual type will comply with the virtual type's newly assigned lifecycle
model.
For more information about virtual types and the Inherit Base Type LCM option, see the section What is a Virtual Type? in the document Object Type Management. For information about which predefined types in CentraSite are virtual types, see the section The Predefined Asset Types in CentraSite in the document Object Type Management.
