SOA Clarified

A service-oriented architecture is intrinsically tied to Web services and HTTP, but that's the opposite of what was intended. SOA is a language-, platform- and protocol-agnostic concept that doesn't stipulate where or how services are implemented. An effective SOA requires not only services, but also a means by which those services can be discovered and used, independent of the underlying infrastructure. It's not a product or specification, so you can't just go out and buy a turnkey SOA. Instead, you must strategically build out this architecture with a number of components, including an application server, middleware, a repository and even a centralized SOA management package.

This is not your mother's CORBA implementation, nor is it a repackaged RMI (Remote Method Invocation)-based architecture. The key component of SOA is the services. Although vendors often use the term services to describe the operations a service provides, or as a service endpoint that offers many business operations, services with SOA are business functions, such as validating a purchase order or transferring funds between bank accounts, to orchestrate a larger, composite application. These are the building blocks of business logic used for creating an application. And the endpoint is the application server-BEA Systems WebLogic, IBM WebSphere, Oracle AS or Sun Java AS-where the SOA services reside.

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," page 26).

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.

Step By Step
How to Go SOA

1 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.

2 Build your services. This will be time-consuming, but it will bear fruit if your discovery process was thorough.

3 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.

4 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.