SOA: Under Construction
- 12 December, 2006 14:50
Ask anyone in charge of constructing an SOA (service-oriented architecture), and they'll tell you that the hardest part isn't the technology; it's redrawing the business processes that provide the basis for the architecture -- and the often contentious reshuffling of roles and responsibilities that ensues.
Many SOA practitioners say that, so it must be true. But the technology part isn't necessarily easy, either. After all the planning and strategising is complete, services and their messaging infrastructure must be provisioned and managed, alongside whatever platforms, applications, and systems are already in place.
The ultimate objective of SOA is a supremely agile infrastructure, where IT develops composite applications atop of a layer of abstraction that spans multiple platforms and domains across the enterprise. But nobody can "boil the ocean" and achieve that goal all at once. Practical SOA initiatives begin with a related set of business processes that would clearly benefit from greater flexibility -- where market conditions are in constant flux, for example, or new services must be deployed on the fly for competitive reasons. At some point that top-down approach meets the bottom-up reality of existing software assets and infrastructure.
When that rubber meets the road, technologists must make key decisions about the platforms on which to build services, as well as how those services will be exposed, managed, and mediated. Some companies may opt for an ESB (enterprise service bus) to connect services, whereas others may focus on standards-based services designed for maximum reuse. Examining the decisions companies make in the real world provides valuable lessons for those who actually need to build -- rather than just talk up the benefits of -- an SOA.
Building, exposing, and monitoring services
Choosing a platform on which to build services is probably the easiest decision IT faces. When cooking up services from scratch, most organisations simply go with their developers' strength, as Web service creation tools have matured across all the major development platforms, from Java app servers to .Net on Windows to COBOL on z/OS. When exposing the functionality of existing applications as services, however, some companies also use ESBs as a platform because services can be provisioned via configuration rather than coding.
What matters from the start is building services in accordance with Web services -- and in some cases Java -- standards, says Martin Moseley, chief architect of integration architecture solutions at Intuit. Standardising on XML and SOAP means that you can use the widest possible range of tools to orchestrate services. John Turato, vice president of technology at car-rental company Avis Budget Group, is on the same page. As he puts it: "We avoid the add-ons and stick to the vanilla."
After a service has been built and tested, developers publish it in a registry so authorised folk can discover it and other services or applications can consume it. Today, most registries are coupled with repositories that point to metadata about services -- including policies governing service development, such as security design rules, and run-time governance parameters, such as SLAs or expected load.
"We recognised at the outset that we needed a repository tool," says George Glass, head of strategy and architecture at BT (formerly British Telecom). But repository tools didn't really exist when BT's SOA efforts started, so the company used its Borland design tools as the repository, exposing the services to business analysts through a Web interface it created from scratch.
The Hartford publishes available services in a UDDI registry but uses Excel spreadsheets and a database for its repository, says Ben Moreland, director of foundation services at The Hartford, an insurance company. As part of its enterprise-wide reference architecture effort, The Hartford is looking at a more formal repository system. Moreland is glad his company waited because current registry/repository products now handle metadata effectively. "So now we can create a better solution than if we jumped in early," he says.
"Much faster than you thought [after you deploy services], you'll have people using them," says James Barrese, vice president of systems development at eBay. "So you need the basic infrastructure in place: a central directory of consumers and publishers, detailed logging of operations, and operations monitoring technology like dashboards."
Repository metadata about services generally describes what should happen rather than what's actually going on. In an SOA, real-time service performance, availability, and usage must be monitored -- often with the help of service management products provided by vendors such as Actional (recently purchased by Sonic Software), AmberPoint, or Blue Titan (recently acquired by SOA Software). These solutions also support version control, fail-over, and message logging, providing a centralised view to gauge the overall health of a network's worth of services.
eBay includes QoS parameters in its service templates, so rate-limiting and logging are built in. As Barrese puts it, this functionality is "abstracted from the engineers" to ensure it's implemented universally and consistently. Dashboard services monitor logs to detect performance issues, and services that are overburdened know it and can request that a clone service be initiated or an IT analyst be notified.
BT follows a similar approach. "All services have measuring and monitoring built in within the XML message set. All transactions are traced, so we can measure at every stage," BT's Glass says. A combination of homegrown and commercial monitoring tools analyse the data "footprints" generated by services, alerting BT when mission-critical services fail to meet service-level commitments. The services' built-in logging functions can be turned on or off, allowing BT to monitor services more closely when desired, such as when first deployed or when performance issues crop up. IT can also perform historic analysis on service logs using BI tools.
On or off the bus?
The care and feeding of services is relatively straightforward. The most confusing SOA decisions involve how services communicate and what sort of mediation should sit between them.
In an ideal world, each service in an SOA would be a standards-compliant Web service, robust and directly accessible by the broadest number of authorised applications or services that need the functionality or XML payload that service delivers.
But on the ground, enterprises need to deal with legacy systems that use proprietary protocols from MQ to AS2. And many argue that Web services messaging won't achieve enterprise-class reliability levels until draft Web services protocols such as WS-ReliableMessaging are fully baked and widely implemented.
So, in rushes the ESB - the one product category now most closely associated with SOA. An ESB is a messaging bus and service platform that makes it relatively easy to hook up legacy systems and manage and orchestrate services. As do EAI (enterprise application integration) products, ESBs also transform and route messages. ESB vendors make a big deal about their products being standards-based, although most use JMS (Java Message Service) or some proprietary messaging protocol in order to deliver the necessary reliability.
Proponents like the way ESBs allow them to provision services and manage their communications. After several years without one, ADP recently introduced a distributed ESB because "it's difficult to maintain a bunch of one-to-one messaging", says Bob Bongiorno, CIO of employer services at the payroll-processing giant. The company's number of services grew from nine to more than 30, but along the way, "the management complexity has far more than tripled", he says.
"We're now selecting an enterprise service bus, but we would have wanted one if it had existed three or four years ago," says Paul Kaptur, system architect at General Motors. "We're doing that today because the products are becoming mature."
ESBs work well for long-running processes that need to be orchestrated, such as order processing, where steps must be done in a certain sequence and validations performed along the way, Intuit's Moseley says. For example, an order process might need to validate a customer's address before calculating shipping costs or authorising a credit card (because the address is often needed to validate a credit card), and all steps must be taken before a bill of goods can be sent to shipping. Intuit's order-processing system uses such a mediated services approach.
But there are those who see ESBs as warmed-over EAI - and feel they defy the open nature of SOA. "EAI is fundamentally different than SOA," says Anne Thomas Manes, an analyst at Burton Group. "EAI is about bridging business process silos; SOA is about breaking them down." She has no problem with using an ESB to provision a service, or even to orchestrate fine-grained services into a widely accessible coarse-grained service. But she bridles at the notion of a bus as the gateway to all services, especially when conversion to and from an ESB message transport incurs additional overhead.
Manes also finds fault with the notion that, without an ESB, difficult to- manage "point-to-point" services are held up as the spaghetti-like alternative: Point-to-point is an integration metaphor, whereas the idea of SOA is to expose services that can be reused by many applications or other services. And that needn't mean lack of control. One alternative to the ESB approach is to use XML appliances - also called gateways - to route messages, handle transformation and mapping, and proxy services so they can be governed and secured effectively.
Performance, security and run-time governance
The question of whether to use an ESB devolves to the individual needs and inclinations of each organisation. 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 virtualising 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 centralised 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 authorisation 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 behaviour, 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 authorisation, 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 standardise 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 of 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 "enterprise-wide 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 standardising 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 recognising 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.