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 organizations 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. Standardizing 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 authorized 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 recognized 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 enterprisewide 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 centralized 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 analyze 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.