The SOA ToolBox

Focus on the functions you need, not what to buy

By Robert Scheier

Mike Kronenwetter has big dreams for his service-oriented architecture: He wants it to align his IT efforts more closely with the needs of the business.

But Kronenwetter, vice president of technology management at health insurer Highmark Inc. in Pittsburgh, is building the foundation for that dream step by step. Wherever possible, he wants to build his SOA on newer versions of products he already uses, and is “working on a lot of our strategies around what it means — what are the governance models we need and what are the pilot projects we should be looking at?”

Analysts say Kronenwetter’s approach is the right one. SOA success is determined not by which specific products you buy, but by how well you understand what you need from your SOA and which products pitched as “SOA solutions” meet your needs. This is even more important with SOA than it is when you’re evaluating other new technologies, because SOA is fundamentally not about new technologies, but about new ways to create, manage, share and secure applications. With the right SOA perspective, the systems that companies already use can get them a long way toward their SOA.

An SOA is a radical leap from the conventional model of stand-alone applications consisting of bundles of functions, such as “create customer record” or “create invoice.” In an SOA, each of those functions is represented by a “service” available on the network to any application or user who has the authority to use them.

If all goes well, it becomes easier, cheaper and faster to meet new business needs by creating collections of already-available services than it is to keep building new stand-alone applications and to laboriously write interfaces between those applications whenever they need to share data. Early adopters are doing just that, with a mix of new technologies and products already in-house.

Build on What you have

At Highmark, Kronenwetter didn’t set out to buy an enterprise service bus (ESB) that could help him build his SOA, but he is already using IBM’s MQ Series messaging software. The latest release of that software, as well as IBM’s WebSphere Application Server, could provide the ESB functions Kronenwetter needs as he expands the range of services he deploys.

Many other SOA builders “want to use their existing infrastructure” in the form of existing middleware, as well as application servers running Web applications, says Ronald Schmelzer, an analyst at ZapThink LLC, an IT consultancy in Waltham, Mass.

Kronenwetter chose IBM’s Web-Sphere Business Modeler for upfront service design because it was relatively easy to use, both for business analysts who outline the processes they need to automate and for the systems analysts who use those models to develop actual code. He chose LogicLibrary Inc.’s Logidex metadata repository because of how well it integrated into the WebSphere development environment and how easy it is to search for and use components needed to create services.

Monitoring and management is the last big piece of Kronenwetter’s SOA puzzle. For that, he says, “We’re an [IBM] Tivoli monitoring shop, and we’re looking at how to leverage the monitoring infrastructure we have in place.”

David Llamas, IT director at Harrods Ltd. in London, chose Sun Microsystems Inc.’s Java Integration Suite as the foundation for his SOA. His goals were to make it easier for business users to get a single view of each customer’s actions over the company’s sales channels and to eliminate reliance on internal developers to create and modify interfaces among applications that needed to share data.

Llamas chose the Sun suite because its master data management capabilities make it easier to create and maintain single customer views across multiple systems. It also makes it easy to modify the Java code underlying his services as business conditions change.

UNICCO Service Co., a facilities management company in Auburndale, Mass., has written about 20 services using the Bowstreet Portlet Factory from Tewksbury, Mass.-based Bow-street Inc., which was acquired by IBM in December 2005. UNICCO has no real SOA yet, says Bilal Khokhar, development manager for field applications. But as he prepares to combine services in an “executive dashboard” of critical business information, he says he’ll look for ESB-like functions, such as fault tolerance and guaranteed message delivery.

Building Blocks

Different combinations of the functions you need are provided by a sometimes baffling array of products.

A registry/repository takes care of tracking and managing services and their components. This functionality is needed to ensure that only approved services can run and that services can be updated as needed. In some cases, it helps control which users or applications can access certain services.

A registry is usually responsible for the service components needed at runtime, while the repository is more of a historic library of components originally used to create the services.

Some products handle both types of data and provide sophisticated search capabilities for everything from models used in development to operational reports about the SOA. Some also store security-related information, such as user access rules.

Features to look for, say analysts, include support for standards such as the Universal Description, Discovery and Integration standard, ease of use and application programming interfaces to support key functions such as the ability to subscribe to changes or access the registry.

The modeling function allows business users and systems analysts to define the business processes the service will enable. Based on the process diagram, the modeling tool exports code that can be imported into other design tools or into application servers.

Key features include ease of use, support for key SOA standards and whether the code produced by the modeler fits your development environment. Some customers even use diagramming tools for modeling.

The management and security function can involve monitoring and managing the SOA messaging infrastructure, the services themselves and even business information, such as whether key transactions have been completed. These functions might be carried out by stand-alone applications, other SOA tools, such as ESBs or messaging middleware, and even dedicated security appliances, such as XML gateways.

Usually described as a common platform over which services communicate at runtime as they share messages or data, an eSB can medi-ate or translate among the various data and messaging protocols used by the underlying applications represented by the services.

Some products are more specialized. Sonic Software Corp., part of Progress Software Corp. in Bedford, Mass., sells an XML server to speed XML processing. It also offers the Sonic Collaboration Server, which extends the capabilities of Sonic’s ESB so it can integrate with the systems of external business partners.

CentraSite, a repository developed by Fujitsu Ltd. and Software AG, stores and manages data from SOA integration products such as Fujitsu’s Interstage Business Process Manager and Software AG’s Enterprise Service Integrator and Enterprise Information Integrator.

There’s also a “sizable market” for software that allows data and business rules on mainframes to be presented as services, says Schmelzer.

Microsoft Corp. plans to provide an SOA messaging platform with the Windows Communication Foundation, which is scheduled for release this year as part of Windows Vista.

With such a fast-changing and hard-to-define tool set, some analysts argue that it’s best to begin building services with the tools you need now and look for other SOA functions as you need them.

“If I architect around ‘my platform is such and such,’ I’ve got no sustainability, no flexibility,” says Randy Heffner, an analyst at Forrester Research Inc. “If I get a different product with a different scope of capabilities, I’ve got to redraw my architecture, and I don’t want to do that.”

Scheier is a freelance writer in Boylston, Mass. You can contact him at rscheier@charter.net.