SOA Demystified

Intuitive Function

The function--or operation, in SOAP (Simple Object Access Protocol)-speak--of your services should be intuitive and based on their names, such as submitPurchaseOrder or validateCustomerAccounts. With an SOA, unlike a typical application infrastructure, only one service should be authoritative for any given business function. Although enterprise applications usually contain the same snippets of business logic or even reuse particular objects, such as a customer order, with an SOA you make only one instance of a business function available. That way, you can reuse the functionality in multiple applications and rapidly change business logic to adapt to changing market conditions, which is the biggest benefit of an SOA.

When you represent one instance of a business function within the larger SOA, any changes to the business rules or storage mechanisms get updated automatically in all applications that rely on that function. So any alterations to pricing or discounting rules, for example, are applied to all your applications. This reduces the time needed to implement a change and lets you react rapidly to changing market conditions.

Similarly, any change to the infrastructure behind the services remains transparent to the applications using the services. If you migrate from one version of a database to another, for example, only the services affected by this change are modified. And the applications in an SOA only reference the services, so they aren't even aware of any changes in the infrastructure. In the past, changes to middleware or databases meant an interruption throughout the enterprise, including to desktop applications accessing this software.

But one of the trade-offs of SOA is reliability, especially with Web services/SOAP most often transported over HTTP. Because HTTP is stateless and inherently unreliable, critical transactions transported over HTTP aren't guaranteed. Two relatively new competing standards--WS-RM (Web Services Reliable Messaging) and WS-R (Web Services Reliability)-- were created to remedy this problem, but today's SOA implementations use more conventional methods, such as an ESB (Enterprise Service Bus), to ensure reliability.

ESB middleware can serve as the backbone of your SOA, providing message reliability, exception handling and publication-subscription model capabilities. It's akin to legacy store-and-forward middleware messaging technologies, such as IBM's MQ Series, Tibco's EMS and the open-standard JMS (Java Message Service) specification. Services housed in endpoints act as a doorway into the ESB, enabling asynchronous service mechanisms and guaranteeing message delivery. An ESB also can serve as an integration point, offering multiple applications access to the same transaction across the enterprise.

The second component of a well-planned SOA is a centralized repository that contains a directory of all services available across the enterprise, cataloged by whatever taxonomy makes the most sense for your organization. This could include groupings by business function, business unit, data source or even a source-code version. Use a taxonomy that will let your developers easily find the services they need to incorporate into new applications.

The mechanism that provides this functionality in an SOA is a registry. Registries are based on the UDDI (Universal Description, Discovery and Integration) standard, which is considered the yellow pages of Web services. It lists companies and their associated services (UDDI, WSDL and SOAP are all managed by OASIS). This registry can be made accessible to your business partners, ultimately enabling rapid integration with their applications.That's a sweet-sounding dream, but the reality is that partner- or consumer-facing services are often composed of multiple services in a "composite Web service" and UDDI is an integral component for developing that. UDDI can provide the means to integrate services among trading partners and supply chains, for instance.

UDDI registry software, including Infravio's Registry, SOA Software's Service Manager and Systinet's Business Service Registry, functions as the central intelligence hub through which SOA services are cataloged, accessed and, in some cases, managed (for more on Systinet's application, see "Systematic Capitalization of SOA,").

Manage and Secure

Last but not least is the ever-present need to manage and secure the SOA. With hundreds of services waiting to be used, you need a centralized management system through which all available services can be monitored and, more important, secured.

Plenty of agent-based and agentless products enable management of your SOA. Actional's SOAPStation, AmberPoint's Management Foundation, Service-Level Manager and Exception Manager, Reactivity's Gateway and SOA Software's Service Manager are among the most popular options for managing services across the enterprise. And Computer Associates (Unicenter) and Hewlett-Packard (OpenView) both offer products for operational management and monitoring of your SOA, but that's as far as they go.Managing your SOA means monitoring the health of individual services as well as the logging/auditing capabilities needed to meet compliance requirements of Sarbanes-Oxley, California's SB 1386, GLBA (Gramm-Leach-Bliley Act), HIPAA (Health Insurance Portability and Accountability Act) and other laws. SOA management software also eases deployment by automatically tracking down elusive connectivity and interoperability problems via its message-capture facilities, which far outstrip conventional network-protocol capture tools.

You can secure your SOA with a general SOAP management product, or separately, depending on your organization's specific needs. NWC Inc., for example, would choose a single solution for both security and management in light of financial considerations, but a large organization could separate responsibility for security and management. All products that provide security and management features for SOA are currently full proxies, and like IP, the more hops a request is required to traverse, the more performance suffers.

Security software, such as DataPower's XS40, ForumSystems' Sentry and XWall, Reactivity's Gateway and Sarvega's XML Guardian, provides a single point of access through which all service requests must traverse. Be sure to carefully consider how you'll set up access to individual services. The basic design of an SOA often groups services according to a type of business object, such as inventory, and it presents interfaces for both accessing and modifying the data. Having access to the endpoint does not guarantee that an application, or specific user should have access to all services, so you must secure services on an individual basis.

It's possible to provide security through the application server hosting the services, but this isn't feasible if your business partners will be interacting with your SOA. An external WebServices or XML security gateway is more flexible for providing partner (or even consumer) access to your SOA without requiring any heavy lifting for your application developers. And considering SOA is all about loosely coupled systems, it makes more sense to decouple the security and management functionality from the services anyway.

Define SOA services across your organization. Determine the services and specific business functions you need (collaborate with business owners). You'll get the most out of your SOA by ensuring the services apply to the widest possible business uses.Build your services. This will be time-consuming, but it will bear fruit if your discovery process was thorough.

Catalog the services. If done in conjunction with Step 2, you can save lots of time. Registries, such as Systinet's Business Service Registry, can monitor the application servers, which run the services, and automatically add them to the registry. This leaves you with only the mundane metadata tagging.

Manage and secure the services. Create default security policies for your SOA services and modify them as needed for business partners and users. Monitor service performance and access daily: Operational statistics are important to showing your ROI from reuse across the organization.

The NWC Inc. Business Applications Lab
in Green Bay, Wis., provides the Network Computing technology team with a real-world environment for testing complex, enterprise-class software. Our networks and servers function as production systems and maintain databases that house financial, inventory, customer and order data to support our fictional widget manufacturer. Our evolving ADS and Exchange implementations maintain a list of employees and access rights. NWC Inc. also operates a thriving online business supported by an Apache, Oracle and Microsoft Web infrastructure. We incorporate many of the products that have won our comparative reviews into the NWC Inc. production environment. When a product earns the NWC Inc. seal of approval, it means we're not just recommending it for our readers--we also want it for ourselves.See the lab live, read about our day-to-day operations at, and order some widgets (our favorite, Widget 170, serves double-duty as both a caffeine dispenser and a robot).

Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].