Many are comparing notes on two well-publicized paths to achieving SOA. The bottom-up approach is currently the most common variety, where Web services are created on an "as need" basis to fulfill mostly integration-related requirements. These services are typically application specific and simply re-create traditional integration channels over the open Web services communication framework.

The top-down approach, on the other hand, is one of analysis, deep thought, and patience. Service-orientation is infused into the business process layer so that services can be modeled in alignment with business models. The models themselves may need to be built or further refined in order to fully incorporate service-orientation principles.

Then, of course, there's the middle ground - an approach that tries to balance the requirements of the top-down strategy with the efficiency of the bottom-up approach. Known as the "agile" or "meet-in-the-middle" strategy, this path is somewhat of a roller-coaster ride, and sure to challenge the most seasoned project manager.

This article explores these three approaches to building service-oriented solutions. Before we chart each path, though, let's begin by establishing the common project phases associated with a generic SOA delivery life cycle.

SOA Delivery Life-Cycle Phases
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. Once you dig a bit deeper under the layers of service-orientation, though, you'll find that in order to properly construct and position services as part of a standardized SOA, traditional project cycles require some adjustments.

Looking at Figure 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 this distinction is made is because it is during the analysis and design stages that SOA characteristics and service-orientation principles are actually 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. Let's now explain each of these life-cycle phases.

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 compose a preliminary SOA. (Formal service-oriented analysis and step-by-step service modeling processes are provided as part of Chapters 11 and 12 in Service-Oriented Architecture: Concepts, Technology, and Design.)

Service-Oriented Design
Once 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 also include the orchestration layer, which results in a formal business process definition. (Four step-by-step design processes are provided within Chapters 13 to 16 in Service-Oriented Architecture: Concepts, Technology, and Design.)

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. (SOA support in .NET and J2EE platforms is explored in Chapter 18 of Service-Oriented Architecture: Concepts, Technology, and Design.)

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?