Managing the Building Blocks

You could have hundreds of Web services. Here's how to make sure you can organize, catalog, find and reuse them.

Danske Bank A/S's trailblazing work to build a service-oriented architecture had gotten so advanced that it exposed more than 1,000 services from its mainframes and application servers. But the Copenhagen-based bank found itself in a frustrating predicament.

"We couldn't find them," says Claus Torp, the company's chief architect.

The problem threatened to wipe out one of the main benefits of service-oriented architectures (SOA)—reuse. So Danske set about revising its concept of a service, refining its repository and establishing a governance process to enforce best practices.

The result was a collection of 140 services that is far more manageable.

An in-depth look at several SOA pioneers shows that the steps Danske Bank took are key to a company's ability to reuse code, build applications with greater speed and efficiency—and ultimately save money.

But it's not easy, and the implementation sequence is important. Sun Microsystems Inc., for instance, built a registry and set up an architecture review board. But the IT department is just now circling back to do a closer examination of Sun's 80 to 100 Web services.

Karen Casella, an IT director at Sun, recommends that a company starting down the SOA path first look at its business requirements and identify which Web services are needed. "We learned the hard way," she says. "We put some of the infrastructure in place before we completely understood what we needed to have in play."

The Services

Companies need to figure out which business processes can be turned into services, carefully design and define the services and distinguish them from components.

When Danske Bank began building standard interfaces to expose its legacy programs, it defined a service as "one function." Now it describes a service at a higher level, as a logical grouping of functionality and data, such as "customer" or "account." The company's 140 services are each composed of about 10 "operations," or components, that are essentially more granular services. There are currently more than 1,365 operations. Danske expects to eventually have 250 services.

How well a company can break down its business processes and application functions into services will determine the level of flexibility and reuse it gets, Torp says.

Danske uses modeling tools to develop logical maps of the functional building blocks and business processes. Then it matches the business processes to the services to make sure it has solved the right problem.

"A lot of doing service-oriented development is making sure you can run different business processes on top of the same service building blocks," says Torp. "If you want to be effective, you have to make sure there is only one place to do the same function."

Cendant Corp.'s Travel Distribution Services division spends a considerable amount of time determining the optimal granularity of its services and service components, according to Chief Technology Officer Robert Wiseman. A service is something that can be called externally through Cendant's business domain model, dubbed Rosetta Stone. A service component, such as logging, is called only internally.

So a "get hotel" service might call several low-level services, such as a latitude/longitude "destination finder" that the company makes available to customers. But Cendant's currency converter is a component, since it currently isn't exposed to customers.

Cendant expects an ongoing project to extract components from monolithic applications to have a big payoff, Wiseman says. For instance, passenger name record (PNR) is a basic unit of data used by booking engines and global distribution systems such as Cendant's Galileo. By making "Super PNR" available as a service, the IT department won't have to maintain six or seven instances of PNR in different applications. The Hartford Financial Services Group Inc. built pockets of Web and other services over three years ago, but its enterprise-scale SOA work didn't start until 18 months ago.

A good candidate for an enterprise service is one that two or more applications need, says Benjamin Moreland, manager of application infrastructure delivery at the Connecticut-based insurance company. "But not everything should be a service," Moreland warns, noting the potential performance hit from exposing services.

Establishing the Registry

Vendors may have expected Internet-based registries based on the Universal Description, Discovery and Integration (UDDI) standard to spread like wildfire. But early SOA adopters care more about internal registries.

That doesn't mean UDDI is dead, though. UDDI was so important to The Hartford that it chose its registry based on the product's conformance to UDDI 3.0. (Officials declined to name the product due to a company policy against endorsing vendors.) The registry includes metadata describing the services and the means to connect to services via particular transports.

But the UDDI registry isn't meant for everything. Departments continue to maintain local registries for some services they create, because The Hartford is selective about what goes into its enterprise registry.

"We don't want to create a junk drawer of services," says Moreland. "What we feel should be in the enterprise UDDI are services that will give us leverage and flexibility across the enterprise."

Providence Health System uses the Infravio Inc. management framework for its service library, and much to the surprise of company skeptics, its developers are actually reusing services, now that they can find the Web Services Description Language (WSDL) files defining the interfaces. "We commonly refer to this as 'Google-izing' Web services," says Michael Reagin, Providence Health's Portland, Ore.-based director of research and development. "They can reuse services with minor modifications in a couple of hours. People are more productive. Everyone's happy." Providence Health's greater concern these days is managing its growing number of Web services and SOA framework from an operational standpoint. The company has close to 50 composite services, each one comprising one to 20 more granular subservices.

Early adopters that couldn't find a registry to suit their needs built their own. Danske Bank maintains separate repositories for components from its mainframes and J2EE- and Microsoft .Net-based application servers. The repositories replicate between each other, forming one logical repository that essentially is a superset of a UDDI registry, adding operational parameters for functions such as load balancing, says CIO Peter Schleidt. A service integrator agent dynamically selects the most efficient way to call a service, using SOAP over HTTP or more efficient, proprietary protocols.

Danske also has a structured library for its services and their corresponding interfaces. The library also houses information about the relationships between its functional and process models. There's even a librarian that developers can call for help. But the library didn't launch until a year ago—"a lot later than we should have been doing that," Schleidt says.


When push comes to shove, a governance body can help a company stick to its SOA principles. Danske Bank has steering committees in 18 different business areas for product, process and IT development. But when business managers are anxious to beat the competition, they're sometimes tempted to forgo the generic SOA approach if it takes longer to complete. "You need a governance process where you can handle situations like that," says Schleidt. "We always have the time to change things afterwards, so why not try to turn it around and do it right the first time?" The quick-hit approach can have long-term consequences. Danske now has two personalization engines, four interactive customer communication services and four payment-handling applications, Torp says.

Two years ago, The Hartford formed a central group called the Property and Casualty Architects Collective to examine how it would adopt a SOA across the enterprise. The group put together a reference architecture outlining recommended approaches, practices and products to be used in a particular context.

"It's about shared architectural thought and reuse of thought processes. That's where the hard work and value is," says James McGovern, an enterprise architect at The Hartford.

A separate application infrastructure delivery group is responsible for selecting and implementing the management platform, business process engine and UDDI registry, as well as making sure the WSDL files used to describe service interfaces conform to standards. An architect not involved with a particular project reviews the project's application design to make sure services aren't duplicated.

At Cendant, project managers have that responsibility. The service name and input and output fields are accessible through an XML-based layer in its Rosetta Stone business domain model. A single group is responsible for updating the business domain model.

"This is how we control reuse," Wiseman says.

If a business domain owner spots a service already in the registry, the service is flagged as a candidate for reuse. A SOA governance board, largely consisting of IT managers, then takes over. Developers need not apply.

"The programmer is the last person that should make the decision," says Wiseman. "They will always want to write something new."


Four Challenges

The development of service-oriented applications requires the following steps:

1 UNDERSTANDING which processes can be turned into services. 2 BUILDING a foundry of application processes. This will come increasingly from business applications that are designed as a set of services. 3 ESTABLISHING the granularity of services at the right level to ensure that services are effectively reusable. Too much granularity makes services too specific to be used; too little granularity makes them too general to be used. 4 FOSTERING a reuse culture is essential to consistent, repeatable success in capturing and using business processes. It enables an organization to deliver processes as a well-defined set of services and to make those services easily available to developers.

Source: Daryl Plummer, analyst, Gartner Inc., Stamford, Conn.

Special Report

Web Services Hurdles

Stories in this report:

Copyright © 2004 IDG Communications, Inc.

Shop Tech Products at Amazon