| Abstract: |
Agility is the ability to be “quick-moving, nimble, and active” [COD]. These were exactly the characteristics exhibited by the scenarios presented in the first article in this series. This article describes the concepts that can enable such agility. We first discuss the specifics of the “software extension” described in Scenario 2, where service implementations were able to be quickly extended. We then outline further agile capabilities, both run-time and development-time, that can add significantly to agility in an SOA environment.
|
| Backgrounder: |
The first article in this series presented two scenarios, set in the near future, that illustrated an agile service-oriented environment. The architecture implied by these scenarios is characterized by a component-based architecture (for best-practice modularization along business lines) with clear dependency management patterns applied, the use of web services for all component interfaces, development using MDA/MDD, an ESB, a ubiquitous notification service, and clear traceability between the deployed services and the “business model” or “requirements”. Together, these provide significant synergy, and form the basis for an agile service-oriented IT environment.
The first scenario was about agility through a number of user-oriented services and capabilities. In particular, traceability from business model through services to their implementations was featured. The second scenario, where a developer called Jim Fredrickson “extends” an existing component without touching the already-deployed code, was about build-time agility.
The previous article in this series focused on scenario 1, and showed how dependency management could be achieved through a service granularity scheme that exploited CBSE collaboration concepts, and supported clear traceability between a business model (requirements) and the deployed system.
In this article we examine scenario 2, and show technically how the agility described could work in practice. First, we look carefully at the extent to which web services are really loosely-coupled, and conclude that there is still work to be done. Second, the specific examples of agility shown by scenario 2-where Jim Fredrickson "extends" an existing component without touching the already-deployed code-are discussed. Finally, we draw back from the details of a specific example, and summarize the various ways in which agility in service development and also in deployed services themselves can be realized |
Home