Performance, security and run-time governance

When ESBs aren’t enough for your SOA, XML appliances fill in the gaps

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.

The risk to this approach is that someone could spoof the validation by simply passing along a “verified” attribute, so Turato expects to implement the validation attribute as a signature that traces where and when the verification happened in order to ensure the validation happened at the right stage and in the right process.

eBay uses a similar security approach for its customer-facing services, with a security service that other services call when needed. For internal services, eBay follows the enterprise security model, using existing services and applications for each application domain, rather than creating a parallel security service for SOA-based projects, Barrese notes.

Your architectural implementation should also permit security flexibility, ADP’s Bongiorno says. “We’re tying to standardize on a single security model, but we will grant exceptions when the requirements are too heavy,” he says.

Testing and debugging services

Another underappreciated aspect to SOA deployments involves testing and debugging. “In a lot of ways, SOA done properly gives you faster time to market,” ADP’s Bongiorno says. “But you give some of that back in the testing.”

Although the use of stringently defined service interfaces can ease integration testing across pairs of services, the many-to-many nature of service interaction and the variety of hardware and software systems that provision them make testing difficult. “You can’t get your whole enterprise into a QA lab,” says eBay’s Barrese, so you have to scale your test platform as much as the business case warrants.

eBay has built some of its own QA tools for automated regression testing to help test the many execution scenarios inherent to SOA but uses off-the-shelf tools such as the those produced by Mercury Interactive. (ADP also uses automated regression tools from Mercury.) In addition, eBay is evaluating the open source Apache Axis service-testing tools with its BEA and IBM platforms.

Financial transaction processor SunGard requires that test cases for all services be built up front, to ensure that all interactions and requirements are thought-out, says Nils Winkler, technical architect at SunGard. Unit tests are built from these test cases, so they’re available for use in automated regression testing by all service developers whose processes might use the specific service. “You can do the testing with the data you already have,” he says.

A related challenge is version control. As you have more and more services, you have to expect that you’ll have to support multiple versions because you can’t update all your services at once. A registry or repository can maintain version information as part of your services’ standard attributes. This safeguard is important, so other services can adjust their expectations accordingly, Bongiorno says.

The best way to manage version control is to design for it in the first place, The Hartford’s Moreland says. “Go in with the expectation that you will retire it,” he says, such as by setting -- and enforcing -- end-of-life periods for all services. And while you have multiple versions of a service running during the necessary transition time, use translation services wherever possible to map calls to the old service instead to the new one, filling in any new data that can be derived or assumed in the translation.

No amount of testing will catch every error, of course. Transactional errors can be caught as part of the monitoring process. But to identify logical errors in the services themselves at run time, the calling services must look at the returned message to see whether there is a mismatch in format, policy, or other expected attribute, based on the business process specifications, Moreland says.

Staying close to home

The choice of development platforms, registries/repositories, management schemes, messaging systems, security technology, and testing tools is dizzying. It’s easy to get caught up in tactical decisions, such as whether to buy an ESB and from whom. But the approach you pick should come after you have defined your business processes, core services, and overall architecture.

“The alphabet soup discussion is a distraction,” says Bill Adiletta, president of consultancy TekFinancial Solutions. Rather than attempting to evaluate all the possible technologies, see what you already have and exclude whatever doesn’t support your needs. If no internal technologies do the job, then look at vendor offerings. Of the remaining candidates, pick those that fit most closely with your existing technology base and skill set and eschew proprietary technologies as much as possible, he says.

The Hartford takes that approach, too. “Our vendor philosophy is: ‘The easier it is to replace you, the more we like you,’ ” Moreland says.

“Your technology choices should be based on what you already have and what you need that it can’t deliver,” says Judith Hurwitz, president of consultancy Hurwitz & Associates.

“If you have a deep commitment to SAP, for example, then NetWeaver might be worth leveraging,” Hurwitz says. “If you don’t, then take a hard look at your applications before exposing them as services. You have to look at the component parts first, then decide what you need. As the services become clearer, you then look at technologies such as service buses and business process engines to manage them as needed.”

GM, for example, used its J2EE platform for its first Web services efforts in 2001, an online shopping service that consolidated all 14 GM car brands. Hong Zhang, chief architect at GM’s Emerging Technology Group, liked the fact that J2EE had a separate layer for data access, which made it easier to handle the many data sources without creating business process dependencies around them.

But Zhang says he’s not wedded to J2EE or any specific technology. “You need to focus on the services and how they implement the business processes. Technologies come and go and will evolve,” he notes.

In the big picture, specific platforms and technologies represent tactical, not strategic decisions. After all, in SOA, the processes, data flow, data definitions, service interfaces, policies, and so forth should be abstracted so they have no dependencies on specific technologies. Burton analyst Manes describes the challenge as “enterprisewide planning with local implementation. SOA is not middleware.” If properly considered, “it can be done with any middleware,” she adds.

TekFinancial’s Adiletta agrees: “Use the strong governance model to agree on the standards: service definition, naming conventions, utilities, etc. The worst way is to start with the technology and say what it can or cannot do.”

What does matter is engineering your SOA efforts, taking the architecture and business processes and then figuring out the implementation requirements, acceptable trade-offs, likely data and process flows, and management and performance needs. With those understood, you can use whatever technologies you like to construct the actual services and supporting infrastructure.

“SOA deployments should follow a federated model, of incremental deployments in a loose way, but with the same goals and direction,” consultant Hurwitz says. “Start off with a set of rules on how you do SOA, so people have the same philosophy and approach in mind on each project.”

It’s all about the architecture

When down in the trenches, it’s easy to get caught up in tactical decisions such as whether to buy an ESB and from whom. But IT needs to be wary of letting the tail wag the dog. The whole point of SOA is to create an architecture that supports a desired end state of streamlined business processes, but with a level of flexibility in rearranging those processes missing from old-fashioned “re-engineering” projects.

“There’s a fair amount of misrepresentation about what SOA is or is not. But none can be successful without thinking about IT and business together,” says Sohrab Kakalia, vice president at systems integrator Infosys.

The architecture describes the standard aspects of services to deliver those business processes, including governance and policies, process management, the business logic itself, data management and access, definitions within and interfaces between services so they cooperate easily, and a messaging framework -- typically tackled in that order. “These layers should exist in every service,” TekFinancial’s Adiletta says.

And you can’t even worry about the service until you understand the business processes they are delivering. “You have to think about standardizing the business processes first,” Avis Budget’s Turato says.

Britain’s telecom giant BT has developed 14 service platforms. “Each platform has a set of services that have operations associated with them -- like a method in object-oriented programming. A service resides in one and only one platform,” BT’s Glass says. And each platform has an architect assigned to it, who ensures that all services -- whether developed in-house, provided by a partner, or bought from a vendor -- adhere to the architecture. To enforce that compliance, if a BT project doesn’t meet the architecture, the development team loses a quarter of its annual bonus.

To provide business flexibility and consistent process execution, “the architecture is independent of any technology implementation. Newer technologies may come along and be deployed, but the architecture is sustainable; the SOA strategy stays,” GM’s Zhang says.

With a laser focus on the underlying business process, SOA discourages technological dependencies that may later limit a company’s ability to change or add business processes. In addition to a strategic decision about architecture, successful SOA deployment relies on IT routinely recognizing project opportunities for a reusable service or business process.

“It’s not a big bang that we then go off and do,” Avis Budget’s Turato says. Anyone who thinks that the use of a technology such as SOAP or WSDL to deliver a function or integrate applications means they’re doing SOA is missing the point, Intuit’s Moseley says. The technologies are a means to an end, not the end itself.


Copyright © 2006 IDG Communications, Inc.