Architect an SOA Using a Services-Network Approach
Scale your SOA globally while avoiding complexity.
by Frank Martinez

December 1, 2004

In my most recent article (see "Avoid Dead-End SOAs"), I asserted that chief architects who begin to build service-oriented architectures (SOAs) to leverage their initial Web services efforts must balance near-term project success with long-term infrastructure reliability and performance. Unless they adopt the proper architectural path, chaos and unmanageable complexity will reign, and the goals of SOA—increased business agility, enterprise-wide process, and data integration—will be lost.

By taking a distributed networking approach to SOA design, you can focus on the core issue: enabling reliable, consistent, and predictable communication between Web services deployed across a distributed network. This approach accomplishes an enterprise architect's goals better than any other because it focuses on global service interoperability and scalability across the enterprise.

To maximize the value of your SOA, you need to architect your infrastructure based on this approach for a true services network that achieves the global benefits of shared Web services. It should be designed on Internet principles (IP networking, DNS, etc.), rather than on a bounded, finite model such as an application server or message broker. Just as the Internet is a shared network of Web sites linked together by many distributed routers, the SOA should be a shared network of Web services linked together by a distributed router network.

Shared Network of Web Services
Web services were designed to enable diverse systems to couple by standardizing their interfaces regardless of underlying heterogeneity. To create a services network, these interfaces must be assembled into an interconnected virtualization layer (an SOA) consisting only of these standardized service interfaces (WSDLs) and the messages that route between them (SOAP) (see Figure 1).

Yet, many vendors have confused the concept of a services network, co-opting the term to define many related solutions that are not actually services networks. For example, Web Services Management products deploy agents into the environment, colocating at service endpoints. These agents exist primarily to extract management-relevant data from the runtime environment and pass it to management servers. Many Web Services Management vendors have marketed these agents as "networks" or "brokers," when in reality they are not. Brokers or networks function as distinct entities that can route messages from anywhere to anywhere as required. The Web Services Management agent does not perform this function—it is "tied" to a specific endpoint or specific endpoints, at most enabling failover between like endpoints when needed or offering policy enforcement such as lightweight transformations or access management.

Another example is the Web Services Registry. Registries are vital to a functioning enterprise SOA, but by themselves they do not create services networks. However, many registry vendors also use the term "networks" to describe their capabilities with the argument that providing global service lookup logically "networks" services together. However, this is not a network, as it provides none of the core routing functionality a network provides.

If you architect a true services network, you can then govern exclusively at the SOA layer, interacting entirely with interfaces and disregarding the diversity of the underlying systems. Using the proper tools, any WSDL can be registered and provisioned into a services network, irrespective of its runtime environment (.NET, J2EE, legacy, packaged, etc.). Once provisioned, the service can be managed through the network and shared across the network, providing a universal way to expose, access, and reuse existing logic, information, or processes.

Distributed Router Network
In a services network, messages are passed between interfaces over a distributed router network, comprised of linked SOAP routers that exist at the edges of the network, intermediating and routing all communication. This network-based messaging backbone links producers to consumers more quickly and reliably, and at greater scale than alternative broker/agent or broker/adapter approaches (see Table 1).

Core Benefits of a Network Architecture
This unique approach enables your SOA to scale infinitely and facilitates the creation of an intelligent network, linking increasingly dumb endpoints. The best path to scale your SOA infrastructure is through a network architecture. After all, the world's largest systems are networks. First, you gain high-capacity routers; second, their inter-networked nature means you can add additional distributed routers on the fly to instantly increase the SOA's scope and scale.

This distributed networking architecture allows you to achieve global enterprise scale with your SOAs so that you can:

• Handle millions of service requests per day.
• Manage and maintain thousands of endpoints and WSDLs.
• Support scores of applications, across disparate lines of business, systems, domains, and geographies.

Distributed routers intermediate all messages, providing an ideal point to incorporate policies. For example, before routing a message to its destination, you can:

• Check credentials and authenticate consumers.
• Ensure that a request is directed to the appropriate version of the desired service.
• Provide load balancing and failover of requests between service endpoints.
• Modify routing destinations on the fly based on network conditions or message content.

During intermediation, these distributed routers can implement any policy, removing the need to hard-code all policies into the endpoints themselves. Ultimately, distributed-router intermediation provides a juncture to build intelligence into the network, allowing for the creation of a smarter network linking dumber endpoints, cutting down significantly on developer burden (see Figure 2).

Services Network vs. Broker/Agent Architecture
This architectural approach is in stark contrast to alternative SOA approaches based on traditional broker/adapter or broker/agent models. Although broker/agent approaches might work fine in initial, limited Web services projects, they have several drawbacks in global SOA initiatives (see Table 2).

Build a Services Network
Architecting your SOA as a services network allows for easy deployment and reliability today, and scalability and flexibility tomorrow. To get started, you must kick off the design phase for your services network, building the proper team to build and deploy it and educating your team members on its importance to both IT and the lines of business.

In the coming months, I'll expand upon this and highlight the advantages and intricacies of a services network and explain why I believe it provides the best path to an SOA.

About the Author
Frank Martinez is the CTO, chairman, and cofounder of Blue Titan Software, a provider of service-oriented infrastructure that helps enterprise architects control, share, and scale applications, driving business innovation across the distributed enterprise.