Columns

Service-oriented Architectures: Tool time for service-oriented architectures

• By Alan Radding
• January 1, 2006

Download the pdf version of this Special Report.

"Can companies use their old tools for SOA? Probably, but to get the most benefit and [take advantage of] the new thinking, you really want to consider new tools," says Ted Farrell, VP and chief architect for Oracle's app dev tool group.

When it comes to SOAs, deciding what tools are required is more complicated than it appears. Developers will continue to use their Java IDE, C++ and other tools, that's for sure. What's new is how app dev for SOA expands the idea of who builds apps.

"With SOA, you want to let everyone contribute to the development," Farrell says. "In addition to the low-level programmers, you want the high-level business users and even the system administrators." It's these folks who will need different kinds of tools to support a new way of thinking about apps and how they're built.

Programmers will continue to build the low-level plumbing and code required to process data and move information. While a different type of developer, one who is more like a business analyst, assembles apps by calling services and defining rules and policies to support a business process, without touching or even understanding the plumbing underneath.

New look at tools
SOAs will also put greater focus on deployment tools. Today orgs build new apps for each business need. In an SOA environment, services will be combined, assembled and deployed-- possibly at run time--to meet changing business needs. Ideally, a small set of functional services will be continuously reassembled and deployed, requiring only minimal amounts of new code.

App managers can meet their SOA dev needs with an array of tools. The hot SOA market is attracting companies, from established players retrofitting their existing tools, to upstarts that didn't exist 6 months ago. The challenge is figuring out which of your existing tools can continue to do the job and what new tools you need.

New code of conduct
SOA for many developers is simply the latest take on the old concept of invoking specific app functionality over the network. It is CORBA or component-based development couched in the terminology of services and supported by a better defined and more widely embraced set of standards and interfaces, with XML, SOAP and WSDL allowing otherwise incompatible pieces to work together.

The functionality often exists in legacy apps. This functionality needs to be broken out and wrapped up in the appropriate SOA interfaces. The new app consists of services calling other services and exchanging data in XML format. All this activity is orchestrated according to business process rules and policies. The services can be reused any number of times as they are recombined with other services and orchestrated under different policies, depending on the intended use.

SOA doesn't care how the functionality of the service actually works as long as it can be invoked in a standard way. It can be built using any technology as long as it can be wrapped in the appropriate SOA interface. That's why developers don't need special tools to build SOA services. "You don't need to replace your existing tools," says Michael O'Rourke, VP at BuildForge. "You can keep using your IDE. Where you need new tools is to tie all the pieces together so they can share."

Tying services together

and coordinating them is often referred to as orchestration. "With SOA, business policies and business processes become big issues," says Robin Bloor, partner, Hurwitz & Associates, a research and consulting firm. "You need tools that will let business people create the business policies based on business processes and tie them together to make the application. It is a new approach to handling business activity. With SOA you specify the workflow, not workflow as we used to do it, but more like process flow." These kinds of tools will allow business users to specify the apps in terms of policies and processes without having to write code.

Speaking the same lingo
Processia, a consulting firm, is involved in a large project that calls for it to integrate major legacy packaged apps including an ERP system and a PLM system which predate Web services and SOA. But it doesn't matter. "The applications were not built as Web services, so we are wrapping them as Web services," explains Scott Liu, the consultant leading the effort.

Web services alone are not enough to ensure seamless integration. To make the system function smoothly, the team turned to Business Process Execution Language "to translate the business processes into something the systems can use to perform the task," Liu explains. BPEL provides a formal specification of business processes and business interaction protocols that extend the Web services interaction model and enable it to support business transactions. In the process, it defines an interoperable integration model for automated process integration.

The Processia developers turned to a BPEL tool from Active Endpoints to provide the business process translation and orchestration that would enable the Web services to take data from one system, process it, then pass it to the next step in the process.

All kinds of tools
With SOA such a hot topic, vendors are slapping the SOA label onto almost every development and deployment tool they offer. Often vendors are doing little more than adding support for XML and other SOA standards. In other cases, new companies are rushing to market with tools that address specific SOA issues, such as management, policy and business process. Even the established players in the market, Actional, Amber- Point, Infravio and Systinet, are relatively young and small. At the other end of the scale, the app dev tool heavyweights such as IBM and Oracle are bringing out SOA toolsets.

"If you have some sort of integration middleware, you are already a step ahead," says Steve Craggs, president of Saint Consulting and vice chairman of the Integration Consortium, a non-profit organization that aims to influence the integration industry.

Who, what, when and where
The basic SOA toolkit, according to Craggs, starts with the registry or services repository. This is where the reusable services and the accompanying metadata describing when, where and how to use the service are stored. UDDI (universal description, discovery and integration) is the accepted industry standard for services registries.

Infravio and Systinet are the most visible registry tool providers. These vendors enhance the core UDDI standard with a variety of features that make it easy for developers to find services and figure out how they should be used. They also pack the registry with additional information about service contracts and business policies.

Although Craggs puts the registry first, it's only needed if the intent is to reuse services. Liu's client, for example, does not intend to reuse the integration services he is building because it's a one-time effort.

An org may create a homegrown repository using something as simple as Microsoft Excel or a commercial configuration management system, says David Butler, VP of product strategy at Systinet. The result will not be a UDDIcompatible directory, "but it will work at the early stage of an SOA effort if you don't care to be 100-percent standardscompliant," he points out. You also don't need a registry if you only build a handful of services, he adds.

Michael Burnett, principal architect at Blueprint Technologies, is building reusable services for the NASA-sponsored ECHO project using Microsoft's Visual Studio and tools from Eclipse. For the registry, the company opted for Systinet. "We use the registry to publish, find and bind," Burnett says. "Those are the fundamental interactions you want from the registry. I guess we could roll our own using an XML database, but there is value in adopting something UDDI-compliant."

By going with a standards- based registry, Blueprint's compliant tools can interoperate. "It also saves me from having to think of everything on my own," Burnett explains. "It's all there in the tool."

Mediate and then operate
After the registry, orgs need some kind of integration middleware, gateways and adapters. Typically, this tool set consists of messaging-oriented middleware or EAI technology. "You need this for your existing components," Craggs notes. Increasingly, companies are looking at ESB technology for this functionality.

Mediation services encompass a large range of SOA tools. "These are the tools you use for the transformation of data and for the enrichment of data," Craggs says. He also puts business process, BPEL and orchestration tools in this category. After mediation services, orgs need to look at operational tools. These address such issues as governance, security, management and performance tuning. These tools help developers define rules at a high level for such things as security or governance, then actively monitor SOA activity as services are invoked and run. For example, a developer might define a rule that allows employee Social Security numbers to be used within the company but not go past the firewall. Governance, management and security tools let you do this centrally across all services all the time, even as they are reused in different circumstances.

Starwood Hotels and Resorts Worldwide is following an SOA strategy to move from mainframe systems inherited from its mergers to a new open systems environment. The goal is to eliminate the mainframes. The result will be a complex SOA environment that Starwood expects to handle high volumes. "We will probably end up with hundreds of services," says Israel Del Rio, the hotel's senior VP of technology solutions.

The company opted for Actional's SOA management tools. "We have to manage a very complex services environment," Del Rio says. "We will need something that will let us redirect services as needed, do load balancing, apply policies and do versioning of services." Part ofActional's appeal is its ability to follow transactions end to end, even as they disappear into traditional systems. It also provides DelRio with the ability to monitor and govern the SOA.

Starwood's SOA tool stack consists of OpenView for alerting and monitoring, Introscope to view Java app performance and identify bottlenecks in the J2EE environment, MQ for messaging and Systinet as the repository. Actional provides the mediation services layer. Starwood's developers built the services using their standard IDEs, SOAP, WebSphere development tools and WSDL.

There is no single tool or tool family for developing apps in an SOA environment. "Most companies today are adopting a best-of- breed approach and combining tools as needed," Craggs concludes. By complying with SOA standards, this approach should not present problems, he says. In addition, the SOA tool rush will accelerate as Eclipse, IBM and several other vendors start releasing new tools.