This is an ongoing of series of articles about configuration management using baselines in a service-oriented architecture (SOA) environment.
Baselines for the Service Component Architecture (SCA) is one of most difficult areas to understand because SCA uses multi-layer baselines, and also there is also a difficulty of long-lived and short-lived processes.
The definition that has been used in the SOA framework is:
- Short-lived is measured in seconds and minutes
- Long-lived is measured in hours, days and months
So instead of an easier application release which is straightforward as the baseline covers just one cut of the software, this needs to multi layer in its approach. To understand the multi layer approach we need to understand the structure of SCA modules
SCA provides a number of important constructs that are defined as part of an SCA module deployment description.
- SCA libraries - each library provides a number of XSD and WSDL documents that describe the services artefacts that are being reused or referenced within the module.
- SCA module - file - this provides the definition of the module in terms of the internal components used within the module. WSRR does not interpret the internal content information but does identify any externalized dependencies as imports and exports.
- SCA imports - these provide the definitions of the external services that the module depends on. These import files define the interfaces, bindings and endpoints that the module will need to resolve when it is deployed.
- SCA exports - these provide the endpoint descriptions that the module exposes in terms of interfaces, bindings and endpoints.
From this the two most important are the SCA library and module file and this is where the article concentrates on as these provide the complexity of baselines.
The complexity comes in because of if there are shared or unshared libraries then the shared baselines will need to have a baseline of their own. Also, adding to the complexity is determined how the SCA modules are defined and the project I am working on there are defines as the following:
- Long-lived People Processes
- Long-lived Non-people Processes
- Short-lived Processes
This will also have an impact on the releasing of the SCA modules, as it will be described in further articles.
So as it can be seen already there are a number of different items that need to be thought about and we have even got to the baselines methodology that the project is using.
The SCA modules will be baselined to show the versions of the software that may up the module and the same baseline will be used fro unshared components, while the shared will have their baseline, therefore the baseline will look like
- SCA module 1.1
- Unshared module 1.1
- Shared module 2.1
- Shared model 3.2
While this looks quite easy however then the problems come thick and fast this is because there are two ways the baselines can change If the SCA module changed does the baseline well I think most people would take the view that this would change.
The shared modules could change does this mean we have to change the SCA module?
The shared modules could change does this mean we have to change the SCA module? And what does this mean for the rest that uses this shared module do their baselines change as well? And does this mean we have to test all the SCA modules that uses this change?
What is the answer, not mind the question! The answer lies in the type of change that happens in the interfaces. If the changes are not at interface level then in SOA terms this is not a change, if the change is at interface level then this is classed as a change and the will required the top level SCA module baseline to change.
There is an associated problem