Pillar 10
Develop for extensibility, scalability, and reliability. These are not service-specific characteristics but they are important for a SOA because they're typical business objectives.

In particular in a business nobody would deal with you if your service wasn't reliable. You're also at the mercy of a competitive service if you can't scale well enough to provide service for a few years into the future. The existence of another service providing very similar functions is one of the realities of the business world, and, so the reality of SOA. It's not a resource or application redundancy that enterprises try to get rid of using services, but it is service redundancy, which is a natural feature of a Business Process that may be modeled in BPEL for SOA.

Extensibility deserves special note. As we know, one of the goals of SOA is to provide an architecture that can easily accumulate and adapt to business changes. This may be done in different ways including different compositions of reusable service components and/or by design for extensions. SOA allows for design for extensions because it can manage the scope of potential extensions, i.e., SOA architects and designers can know upfront what can be extended. In particular, only those extensions are possible (and should be observed in SOA) that can be derived from the enterprise business model. If a required or proposed extension doesn't fit into the business model, this signals that either something is wrong with the proposal or it's time to change the model. The latter can't be done by IT alone because it's a lifetime event in the organization. For example, if an enterprise is in the skating ring business, its business model can be extended to sprint skiing, sprint running, boxing or a swimming pool (inside the ring), but a mountain slalom is certainly outside the scope of the business model.

Pillar 11
Service components development and bottoms-up recycling. This is a service-specific pillar. It relates to the methodology and standards applied at the level of the design of the software components comprising SOA services.

Dealing with enterprise IT assets, the SOA design decomposes existing applications and operational processes to integrate some of them in new way. SOA is supposed to destroy application silos and reuse or recycle only the application features that relate to the business services/processes instead of mummifying existing operations under new interfaces. The emerging Service Component Architecture (SCA) specification (proposed to the standard) addresses target design of the service components. SCA defines coarse-grained business interfaces for the components, i.e., interfaces "with relatively few methods and where parameters and return values are typically document-oriented." Such interfaces may be exposed in any programmatic model, e.g., WSDL or Java, without changing its business orientation.

Service component development can be done in an iterative-incremental manner after the business service/process is defined. Well-known best practices in distributed computing development are the only thing recommended here. For particular service development, the agile methodology is the first candidate. If an agile methodology were combined with a design for potential extensibility, this would be the right development approach to SOA.

Special attention should be paid to the bottoms-up development that I call recycling. Obviously when SOA development starts we can expect that the enterprise already has its applications, legacy systems, even services. These can be effectively reused in the new architecture as they are or partially if they can be converted into the SOA services, i.e., related SCA interfaces and associate SOA service contracts may be defined. While SOA RM says, "A service contract is a measurable assertion that governs the requirements and expectations of two or more parties," we need to notice that the Service contract is consumer-centric. If a legacy asset can operate only in an application-centric manner forcing consumers to become dependent on the application's internal processes and procedures, such an asset might not be the right candidate for transformation into a SOA service.

Pillar 12
Watch for service testing and governance. These are fundamental tasks for SOA design, not only for development, deployment, and runtime. Both of them are rich topics deserving, at least, a few articles each. Being the elements of the SOA implementation technique, they aren't a part of SOA RM but no realistic SOA solution can afford to be put into service without them.

Testing in SOA is similar to testing in a component-oriented architecture. However SOA stresses testing in different execution contexts. Service testing requires the intensive design of test cases and a related test environment (that may be initially unavailable). This includes functional tests for the service itself, tests for its behavior in different aggregation/process flow scenarios, and tests for non-functional and/or service contract obligations.

Acceptance testing of a SOA service is individual to each organization. Its scope is actually limited by the SOA service contract. Even if no new code is released but the service is to be used in a different business context (e.g., the service contract is changed), new test sessions are generally required.

SOA governance is one of the hottest topics of our day. In a nutshell, SOA needs design, development, deployment, and production governance. Governance is based on policy controls, not all of which can be automated. A service contract can help a lot in defining informal business policies but the controls are still required. The issue with SOA services is that not all elements of the service's behaviour can be guaranteed by testing; it's necessary to watch the service at runtime and adjust it.

For example, a very popular IT promise of service reusability is a double-edged sword for the business. On one hand, the more a service is reused the better its ROI gets, and businesses love it. On the other hand, each reuse is subject to a new governance session and new risk validation (in the new context) - both of them costly. If one skips governance because the service hasn't changed, it gets worse for the business because modern industry policies and regulations like SOX require that certain procedures (controls) be in place. If one skips risk validation, an organization can end up in a situation where a service contract disclosures the sensitive information described in another service contract and this problem isn't recognized (and rectified) upfront.

Process Design in SOA
As we know, SOA services can participate in the SOA processes that reflect business processes. Many designers observe the business process first and try to derive business services from it. Designing SOA process is quite important task. However, the current version of the SOA RM touches on this very delicately. "The process model," it says, "characterizes the temporal relationships and temporal properties of actions and events associated with interacting with the service. Note that although the process model is an essential part of this reference model, its extent is not completely defined." Moreover, "The reason that orchestration (and choreography) are not part of the SOA RM is that the focus of the RM is on modeling what service is and what key relationships are involved in modeling service."

It looks like the BPEL standard covers most business needs so far. Before presenting it in the SOA RM, we probably ought to collect and analyze more information about automated business process modeling and its exposure to the aggregated/composed service modeling.

Conclusion
This article elaborated on parts of the SOA RM standard related to the SOA service design. It offered and discussed several SOA design pillars based on the enterprise business model described in part one of the article. The fundamental takeaway was that the SOA service definition and its relationship with other systems, given in the standard, assumes creation of a technical enterprise architecture that can implement core business services and process and ease acceptance of business changes via business-oriented technical services. SOA services start behaving more like business entities running in business execution contexts and having business responsibilities in their service contracts. The shift from IT application silos to business orientation is the proposed way of making IT architecture business agiled in the enterprise.

References
1)  Duane Nickull. "Why We Need the OASIS SOA Reference Model."
www.looselycoupled.com/opinion/2006/nicku-why-arch0104.html.

2)  Satadru Roy. "SOA Infrastructure: Mediation and Orchestration."
www.soamag.com/I1/0906-2.asp

3)  Michael Poulin. "Service Versioning for SOA." SOA-Web Services Journal. Vol. 6 Issue 7.
http://webservices.sys-con.com/read/250503.htm

4)  Alcedo Coenen. "An SOA Case Study: Agility in Practice." SOA Magazine. Issue II. November/December 2006.
www.soamag.com/I2/1106-1.asp

5)  Service Component Architecture, Version 0.9.
www.oracle.com/technology/tech/webservices/standards/sca/pdf/SCA_White_Paper1_09.pdf

sidebars

SOA RM:
SOA does not provide any domain elements of a solution that do not exist without SOA

SOA RM:
A service is opaque in that its implementation is typically hidden from the service consumer except for...
(1)  the information and behaviour models exposed through the service interface and
(2)  the information required by service consumers to determine whether a given service is appropriate for their needs.

SOA RM:
- Service visibility is promoted through the service description that contains the information necessary to interact with the service and describes this in such terms as service inputs, outputs, and associated semantics.

The service description also conveys what is accomplished when the service is invoked and the conditions for using the service.