Stages for Lifecycle Registries

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:

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.