The question of whether or not to use an ESB devolves to the individual needs and inclinations of each organization. For example, if orchestration of distributed services is a must-have, that’s pretty tough to do if those services aren’t plugged in to an asynchronous messaging infrastructure. But an ESB does not an SOA make. In an SOA of any significant size, even a widely deployed ESB would not be the only game in town. Multiple message buses may need to be bridged and messages transformed as they travel among them.

That’s an ideal role for the new generation of XML appliances -- designed to secure, govern, and boost the performance of an SOA -- from the likes of Cisco, Forum Systems, IBM DataPower, Layer 7, and Reactivity. These companies sell boxes that route XML messages based on content and rip through XML transformations, routing, and mapping at blazing speed using special processors designed for the purpose.

Depending on the model, these boxes incorporate a range of features, many of which overlap with the capabilities of an ESB. They’re particularly adept at virtualizing services, so that service copies can be created on the fly as performance demands increase -- and so that policies concocted for services can be enforced at run time using centralized management software. And most include a range of XML security features as well.

In fact, the first units sold by these appliance vendors were XML firewalls designed to block XML-based threats and DoS attacks. Now the XML security appliances support encryption/decryption, authentication, identity management, XML schema validation, and more, controlling application access as well as protecting the perimeter.

Such security services are vital as SOAs mature. That’s the case at ADP, which is working on deploying its standard security model delivered as a central process used by all other services. Similarly, technology service provider USi uses the federated model for user identity management. “The service may not even know who the user is,” says Mike Rulf, vice president of advanced engineering, “but it knows that the user has been validated at some point along the service path, since services transmit that validation information.”

“Security doesn’t get enough attention in SOA,” warns Dennis Gaughan, senior analyst at AMR Research. Early efforts tend to focus on defining service and messaging interfaces, or on separating business and data logic from each other and from execution and presentation. But as services become widely used and adopted, retrofitting them to accommodate access control and authorization becomes very difficult -- often requiring wholesale changes because security controls can change both process and data flow.

That’s why it’s better to build in security hooks from the outset, even if your security services and systems are not yet deployed, USi’s Rulf says. At USi, all services have a standard WSDL template that includes security validation and access controls -- as well as error reporting, calling behavior, and data expectations -- to ensure that services are security-enabled from the get-go.

Avis Budget also built security into its initial SOA platform, dubbed Omega. “We’re pretty good with authentication but are still trying to figure out authorization, whether it is handled in a service or on the security side,” Turato notes. The company expects to provide a common security service for all its services and applications. “We will work towards an enterprise LDAP to leverage the security services of the Omega platform,” Turato adds.

The use of LDAP will be key to identity management efforts, and Turato plans to have all services include calls to LDAP lookup. But to prevent every service doing a direct lookup every time it runs, Avis Budget is planning to require lookup at specific stages in a business process and then propagate that validation to later services.