In-Depth
Addressing SOA's Vulnerability
Get beyond the myths of service-oriented architecture. Learn how to leverage WCF to successfully implement SOA design patterns that can help deliver on the promises of SOA.
The question of whether service-oriented architecture (SOA) is more hype or essential gets quite a bit of coverage these days. It's a complex area that is getting more widespread attention across industries looking to make business processes more efficient, streamlined, and flexible. One aspect of software design that is becoming extremely important for the development community is the way in which services are built to deliver on the SOA promises of easier interoperability and integration.
Arguing that much of what was learned years ago from working with distributed object-oriented architectures has become today's antipatterns for trying to achieve the goals of SOAs, Rob Daigneau, director of architecture for Monster.com, told attendees at his VSLive! presentation, "Implementing SOA Design Patterns with WCF," that "WCF addresses the Achilles' heel of SOA."
And what is SOA's Achilles' heel? Daigneau said that essentially, it's the hype around its promises of business agility, high availability, and reusability. Daigneau's opening comments on SOA reinforced his published material at "Design Patterns for .Net" Web site that states the SOA architectural approach doesn't inherently ensure adaptability, productivity, efficiency, or reusability.
"Writing software is prone to error and very complex," Daigneau said. "It's not easy. We have the toolkits, but there is a lot to think about," and what is required is revolutionizing the manner in which developers architect solutions by giving thought to the complexities that are inherent in SOA to create software that delivers business requirements without breaking.
As Daigneau pointed out, developers have been hearing about reuse since the days of objects and before, and there are several good examples of business reuse in packaged applications from SAP, Siebel, and so on. However, in practice a lot of customization is required, and if service reuse is too generic, it might not be practical. High availability, Daigneau said, depends on the deployment architecture, and performance can be better optimized by co-locating services near consumers.
Daigneau assured his nearly standing-room only VSLive! audience that there are important benefits to SOA that warrant the discipline required to leverage Windows Communication Foundation (WCF) for architecting solutions in a new and different way. Among those benefits are separating concerns, independently evolving services and consumers, having smaller builds and memory footprints for applications, and emphasizing the need for IT governance.
Among the antipatterns that occur with today's approaches to design, Daigneau said, are services that are too much like objects and operations that appear to be the properties inherent in "chatty" interfaces. Also among this group are database table-oriented operations that expose database schemas and are tightly coupled to those schemas.
SOA Is All About the Contract
One way to employ best practices in services design, Daigneau said, is to think of services as gateways. Services, Daigneau said, are like conductors or mediators for business objects and are therefore "complementary." Instead of putting business logic in the services, he emphasized thinking of the service layer exclusively as the gateway to business logic and provide for the independent evolution of the service gateway from the logic and data.
To illustrate, Daigneau provided a slide of the service layer pattern. Daigneau pointed out that patterns for SOA can be thought of as a label for best practices for design solutions. One of the biggest challenges that developers face in architecting solutions is managing versioning, and Daigneau said that WCF provides the beginnings for addressing this challenge through the ability to version and extend message types. In defining data contracts, Daigneau expressed the advantages of message types that can be "amended" with new data types that emerge by adding them to the end of the messages. The messages can be used multiple times for different service operations, making them in effect "pluggable" and available for deferred processing.
Daigneau provided a simple but eloquent demo of a travel service application for retrieving and selecting flight and cost information to illustrate the way WCF can work with performance issues through different deployment mechanisms. As he moved through the different coding examples within the application he was able to show how the reusable data types served as the building blocks for the way in which the contracts are defined and exposed.
Daigneau capped his presentation by spending some time discussing versioning issues around strict or lax validation on the consumer and services side and multiple breaking changes that could influence minor releases versus major releases. He acknowledged that versioning isn't easy to manage and recommended avoiding deploying a major release for breaking changes, if possible. However, if that option isn't possible, then issue a major release by creating a new namespace and end point, deprecating older operations possibly, and distributing a new proxy.
Services, Daigneau said, are about how we manage objects for business, and leveraging the WCF can help developers create extensible, versioned, and easily maintainable services.