SOA delivery lifecycle phases

The lifecycle of an SOA delivery project is simply comprised of a series of steps that need to be completed to construct the services for a given service-oriented solution.

10.1.1. Basic phases of the SOA delivery lifecycle

Development projects for service-oriented solutions are, on the surface, much like other custom development projects for distributed applications. Web services are designed, developed, and deployed alongside standard components and the usual supporting cast of front- and back-end technologies. When we dig a bit deeper under the layers of service-orientation, though, we'll find that to properly construct and position services as part of SOA, traditional project cycles require some adjustments.

Looking at Figure 10.1, you may wonder why the first two phase names are prefixed with "service-oriented" when the remaining phases have names that begin with just "service." The main reason we make this distinction is because it is during the analysis and design stages that the SOA characteristics and service-orientation principles we've been discussing actually are incorporated into the solution being built. So much so, that they warrant unique analysis and design processes that are distinctly "service-oriented." The service phases are primarily concerned with the delivery of services that implement the results of service-oriented analysis and design efforts.

Figure 10.1. Common phases of an SOA delivery lifecycle.

Let's now explain each of these lifecycle phases.

10.1.2. Service-oriented analysis

It is in this initial stage that we determine the potential scope of our SOA. Service layers are mapped out, and individual services are modeled as service candidates that comprise a preliminary SOA.

A formal step-by-step service modeling process is provided as part of the two chapters (11 and 12) dedicated to the service-oriented analysis phase.

10.1.3. Service-oriented design

When we know what it is we want to build, we need to determine how it should be constructed. Service-oriented design is a heavily standards-driven phase that incorporates industry conventions and service-orientation principles into the service design process.

This phase, therefore, confronts service designers with key decisions that establish the hard logic boundaries encapsulated by services. The service layers designed during this stage can include the orchestration layer, which results in a formal business process definition.

Four formal step-by-step design processes are provided within the four chapters (13 to 16) dedicated to the service-oriented design phase.

10.1.4. Service development

Next, of course, is the actual construction phase. Here development platform-specific issues come into play, regardless of service type. Specifically, the choice of programming language and development environment will determine the physical form services and orchestrated business processes take, in accordance with their designs.

As part of our coverage of SOA platforms, we explore development and runtime technologies associated with the .NET and J2EE platforms in Chapter 18.

10.1.5. Service testing

Given their generic nature and potential to be reused and composed in unforeseeable situations, services are required to undergo rigorous testing prior to deployment into a production environment.

Below is a sampling of some of the key issues facing service testers:

• What types of service requestors could potentially access a service?
• Can all service policy assertions be successfully met?
• What types of exception conditions could a service be potentially subjected to?
• How well do service descriptions communicate service semantics?
• Do revised service descriptions alter or extend previous versions?
• How easily can the services be composed?
• How easily can the service descriptions be discovered?
• Is compliance to WS-I profiles required?
• What data typing-related issues might arise?
• Have all possible service activities and service compositions been mapped out?
• Have all compensation processes been fully tested?
• What happens if exceptions occur within compensation processes?
• Do all new services comply with existing design standards?
• Do new services introduce custom SOAP headers? And, if yes, are all potential requestors (including intermediaries) required to do so, capable of understanding and processing them?
• Do new services introduce functional or QoS requirements that the current architecture does not support?

10.1.6. Service deployment

The implementation stage brings with it the joys of installing and configuring distributed components, service interfaces, and any associated middleware products onto production servers.

Typical issues that arise during this phase include:

• How will services be distributed?
• Is the infrastructure adequate to fulfill the processing requirements of all services?
• How will the introduction of new services affect existing services and applications?
• How should services used by multiple solutions be positioned and deployed?
• How will the introduction of any required middleware affect the existing environment?
• Do these services introduce new versions of service descriptions that will need to be deployed alongside existing versions?
• What security settings and accounts are required?
• How will service pools be maintained to accommodate planned or unforeseen scalability requirements?
• How will encapsulated legacy systems with performance or reliability limitations be maintained and monitored?

Note

Service deployment is specific to the technology platform for which services are developed. Chapter 18 provides various details regarding the physical implementation of services within J2EE and .NET environments.

10.1.7. Service administration

After services are deployed, standard application management issues come to the forefront. These are similar in nature to the administration concerns for distributed, component-based applications, except that they also may apply to services as a whole (as opposed to services belonging to a specific application environment).

Issues frequently include:

• How will service usage be monitored?
• What form of version control will be used to manage service description documents?
• How will messages be traced and managed?
• How will performance bottlenecks be detected?

Note

Service testing and administration are beyond the scope of this book.

10.1.8. SOA delivery strategies

The lifecycle stages identified in the previous sections represent a simple, sequential path to building individual services.

We now need to organize these stages into a process that can:

• accommodate our preferences with regards to which types of service layers we want to deliver
• coordinate the delivery of application, business, and process services
• support a transition toward a standardized SOA while helping us fulfill immediate, project-specific requirements

The last item on this list poses the greatest challenge. The success of SOA within an enterprise is generally dependent on the extent to which it is standardized when it is phased into business and application domains. However, the success of a project delivering a service-oriented solution generally is measured by the extent to which the solution fulfills expected requirements within a given budget and timeline.

To address this problem, we need a strategy. This strategy must be based on an organization's priorities to establish the correct balance between the delivery of long-term migration goals with the fulfillment of short-term requirements. Three common strategies have emerged, each addressing this problem in a different manner.

• top-down
• bottom-up
• agile (or meet-in-the-middle)

These paths differ in priorities and practical considerations. The following three sections provide process descriptions and explore the pros and cons of each approach.

How you approach the creation of a service-oriented environment ultimately determines what you will end up with. The strategies discussed here, therefore, will confront you with some important decision-making. Choosing the right approach will determine the extent to which your service-oriented modeling and design efforts can realize the full potential of SOA.

Note

If you're not interested in learning about the individual steps that comprise each of the following processes at this point, feel free to skip ahead to the Pros and cons part of each section. Knowledge of individual process steps is not required for subsequent reading.