| Title: |
Applying Product Line Techniques to SOA - Part II |
| Author: |
John Butler |
| Publication Date: |
24 May 2006 |
| Report Type: |
Journal |
| Report Class: |
Best Practice |
| Abstract: |
Often separate consumers of a service will follow slightly different processes or require slightly different information for their particular business sector or domain. In addition to loose-coupling, SOA provides the architectural mechanisms to enable many types of variability at both design-time and runtime. But this is also a key driver behind software product lines and application family engineering, two well established software techniques. Part 1 of this series explored methods for identifying reusable components and enabling service variability. Once variability has been introduced, managing configurations becomes critical. This article explores the similarities and differences in configuration management between typical SOA development and the software product line methodologies. |
| Backgrounder: |
Anyone that has been a part of a large software development or system integration organization understands the fundamental need for managing the individual assets that comprise a complex service or system and their overall configuration for each release of that service or system. While small services do not typically require sophisticated configuration management (CM), large scale services or complete application systems often involve many analysts and developers working in parallel on the various artifacts created and modified during the lifecycle of that service or application system. And while we want to strive to limit the rate of change in our services, change is inevitable. In order to prevent accidentally “stepping on each others toes” during the lifecycle a robust configuration management process and tooling infrastructure must be established. As noted in an earlier CBDI report1 “If change control does not exist, as more services are introduced into the enterprise, every weekend or maybe even every day can turn into an experiment in software interaction” – Charlie Bess, EDS.
As if this problem weren’t already difficult enough, SOA introduces additional complications that, if left unaddressed, can eventually swamp a service delivery organization. Part 1 of this series2 talked about the similarities of SOA and Product Line approaches to software development in the area of identifying and enabling variability within services. But while providing a vehicle to enable variability is a key benefit, managing the various configurations that may all be in operation simultaneously significantly increases the complexity of the asset/configuration management process.
|
| Report Size: |
8 pages |
| Report Access Type: |
 | Silver/Gold (Premium) |
|
| Available for separate purchase |
Single copies of recent CBDI Journals may be purchased |
| Login |
|
Home