email article printer friendly more resources

Beyond SOA: Principles of Service Engineering
To design reusable services, supplement use cases and event-driven approaches with aspect-oriented modeling
by Mark M. Davydov

August 20, 2004

Measured by industry buzz, services-oriented architecture (SOA) and Web services are becoming the dominant paradigm for software development. In the real world, however, relatively little attention has been paid to the ways development processes must be modified to ensure that SOAs really deliver significant business benefits.

The success of proof-of-concept projects confirmed the ease of building, deploying, and consuming Web services. They contributed significantly to companies' improved ability to deliver complex software systems, but in doing so they created new demands and pressures on software development processes.

Currently, there are two development scenarios where Web services tend to be considered most often: for integrating large, distributed, and diverse systems that have been built up independently over time, and for extending business process functionality to new channels (such as Web and mobile) by front-ending legacy applications with newly built subsystems or components.

In both of these scenarios, ensuring interoperability among components at the interface level is important. Many low-level technical details such as adding SOAP interfaces to already existing components or deciding how data should be transferred inside the SOAP calls are pushed to the top of design concerns. Just consider what people really get heated about in design meetings: How is that exposed over the Internet? How does security work with that? How is that operationally managed? What are the proper naming conventions for XML schemas?

Driven by the Business
The market has focused primarily on supporting the low-level details of Web services development, and on their security, availability, and performance aspects. Analysis of many large-scale SOA/Web services projects have shown that this approach to services orientation gets the job done, but the results fall far short of the hype and business expectations for SOA and Web services. Many factors contribute to subpar results, but one significant element has been the poor reusability and extensibility of services for three reasons.

First, poor verification of reusability potential across business domains results too often in services being developed based on the functional requirements for one project but without proper crossdomain analysis—presumably in the hope that if service interfaces are developed correctly, they will be reused by other projects.

Second, poor service structuring results in services that are not easily reusable in other projects because their structure (composition of components and their relationships) usually tends to be overly dependent on a particular realization of Web services interfaces. Dependencies among components within a service make the service less usable in other contexts. Moreover, when new functional requirements appear, it is difficult to extend the existing interface or to isolate the changes. Also, new interfaces must be put in place, especially when the service control logic is buried in the code that does Web services processing.

Third, poor scalability results when interface specifics are the primary drivers in service design, and the resulting arrangement of component responsibilities is not optimized among distributed processing elements. As a result, services simply do not scale to high-volume levels in a cost-effective fashion.

The other significant factor is the issue of business drivers for SOA. It is important to remember that fundamental advantages of SOA over other architecture styles are realizable only when one of the primary business drivers for SOA is modernizing, optimizing, and/or reengineering business processes across the enterprise. Today such business strategies are concentrated under the umbrella of a new emergent business management discipline—business process management (BPM). To succeed with BPM initiatives, it is mandatory to adopt SOA as an enterprise mainstream.

Clearly SOA has the necessary underpinnings to be the enabling framework for BPM, especially in light of recent activities in standardization and technology introductions such as Web Services Invocation Framework (WSIF), Business Process Modeling Language (BPML), and Business Process Execution Language (BPEL). However, new standards alone won't solve the problem. Even if we had all the necessary Web services-related application and middleware tooling, there still would be a critical need for enterprises to change their approach toward the implementation of SOA and Web services.