Module Baselines within a Service Component Architecture

[article]
Summary:
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.

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
arjanbasics07-1jpg

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.
arjanbasics07-2jpg

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

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03