The use of Baselines in a SOA Environment

Customer_Alterations is an example of a service that is being delivered within the Programme

This at the initial baseline of the first delivery of the service and this will contain all three components. This will constitute the baseline Service_Name_1.0.0

However, the parts that can change are the Published Service (PS) and the service.

The most likely scenario is adding more processes to the service or patch changes to the processes within the service.

The next section describes how these changes will be managed.  
       
Updating of the Service

This diagram shows the additional business processes being added to the long lived business process in the service.
 

This will be a service of the same name but a different version, to make sure the PS points to the correct service. This will allow for the PS to point to the modified service while at the same time it will allow for the existing processes in the old service to complete their processing and eventually are not working. This is because when the new service is installed on the server the PS is pointed to the new service allowing new interactions with the service to go the updated service.

An example of a long lived Business Process maybe "Update Customer Details"

Examples of short lived processes maybe:

• Update Customer address
• Update Customer name
• Update
  Contact details  

The newer version of the service will contain all the business processes that are currently in the older version plus additional processes.

The diagram below shows how a service and processes are structured in this case in Subversion.

• Service.person.1_0_0
• Soap.person

Baseline Identification  

To identify those services which are ready for being promoted into testing then a developer will add a baseline to the service that is ready for testing.

{Service_name}_{major.minor.patch}

{Process_Name}_{major.minor.patch}

A suggested baseline format for test environments

{Service_name}_{Test_Environment)_{major.minor.patch}  

{Process_name}_{Test_Environment)_{major.minor.patch}  

For Production releases the format will be

 {Service_name}_{major.minor.patch}

To accommodate this use of baselines the baseline will move on from Service_Name_1.0.0 to Service_Name_1.1.0 as this represents new functionality being introduced.

As the old version comes to an end of its life then this can be removed from the server without affecting the newer version of the server as this has the existing processes contained within it.

Each service will have its own baseline, the implications of this is that if we deliver a number of different services then we will have to delivery a number of different baselines as well.

This model will also assist in the promotional model being used as this will different services to be promoted at different time or dependant services delivered together

Each process in the service needs to be baselined to ensure the files, which make up the process are clearly identified.

Service and Process Baselines

To be able to support the delivery to the environments the delivery baselines will be made up of Service and process.

The definition for the Service baseline is:

To identify the service being delivery to an environment and this will allow for co-existence on the environment of multiple services on the environments at the same time.

The definition for a Process Baseline is:

To identify the components that makes up a process, which is being delivery to an environment.

Tags and versions

Each SCA module is versioned and the components are also version as with any CM system. However the tag or baseline needs to be carried out at different levels at the SCA modules and the components, which are associated with the SCA module and shared components, which will need their own tags.