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.
Back to top
|