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.
Behaviour Problems
There is an associated problem with this is that the SCA module has behaviours that have to be supported in away that can be traced but at the same are treated as a software change which would created a new version of SCA modules which is not what you want.
The idea to support this is a very old idea which I have used many years ago but which fits the build exactly this is the use of information notes. The type of behaviour we are trying to control is the change of business rules, which will change every so often as the business gets the used to the service. As each new information note is issued then the behaviour changes and usually comes thorough the Configuration Manager. This will show the previous and new behaviour that the service has to use, however the information of the
change comes from the Senior business Analyst. The change is as usual is tested in an environment before it goes in to the Production environment and when it is tested to make sure the production environment has change has taken affect.
The information note has work in conjunction with the existing systems as this will provide extra information to the /change request record.
To get his baselining in we have approached this is an two stage method so people can get used to this new method and allow for the main baseline to get in and then look at how we adjust the overall method for the second baseline to put into place and this has to tie up with existing systems.
While this article gives a favour of the problems SOA gives to traditional methods of baselines and how many of the existing systems need to be adapted to the new ways of working.
Another aspect of this work how hard I have had to work on the senior management to make sure that they on board for the changes to the existing systems and making sure I have the budget to make this happen. This has require a great deal of explaining to them and they have been very response and supportive we has made my life a great deal easier.
As it can be seen the considerations that I come across during the construction of the baseline for the project and that as Configuration managers we have to deal with. While information notes are not consider as baseline in the true sense of the Configuration management. It is a type of baseline because it is identifying a controlling artefact of the SCA module
About the Author
Alan Rogers has been working as a Configuration Manager for the last 13 years and been in the IT industry for 17. He has worked on many projects both designing the Configuration Management infrastructure as well implementing it for many large companies for particular projects. A lot of these processes and standards that he developed for the project have in many cases been adopted as corporate standards. He also has an MBA from Henley Management College, which has been very useful when trying to explain Configuration Management to Senior Management, and is also a chartered Manager holding a MCIM.
