Web Services Orchestration Waits for Standards Harmony -- ADTmag

Web Services Orchestration Waits for Standards Harmony

By Alan R. Earls
April 1, 2005

Talking Points
SYMPHONY OF STANDARDS

Web services orchestration is all about creating true Web services collaboration within the framework of an SOA.
Some potential implementers question whether they need WSO despite the biased enthusiasm of vendors and reports from standards groups.
The standard that has gained ground in the industry most recently is BPEL, which is supposed to facilitate interoperability of workflows.

To hear Derek Ireland tell it, you would think his company, Edinburgh, Scotland-based Standard Life Assurance Company, Europe’s largest mutual life assurer, is the poster child for almost everything having to do with service-oriented architectures. Ireland, application design manager, says Standard Life’s SOA has been developed and honed around the concept of reusability and invokable services since at least the mid-1990s and is at a level of maturity that would make almost any organization jealous. Standard Life, a financial services company with £100 billion under management, can now claim some 40 percent of its primary applications are part of an SOA. However, despite its embrace of SOA, what it still lacks is widespread adoption of Web services—and it doesn’t have any Web service orchestration in place at all.

“Although we are more than aware of them, we are not making great use of Web services,” Ireland says. “Much of what we have done over the past five years predates the maturity of Web services standards. We just weren’t in a position to bet the business on them.”

Web services orchestration is all about creating true Web services collaboration within the framework of an SOA. The vision is of a much more interoperable world, but despite the advent of specifications and incipient standards, Standard Life is not alone in steering clear of the technology—it’s still on technology’s sharp edge. To be sure, companies including Standard Life are wholeheartedly pursuing SOA and often accomplishing feats of orchestration within their projects. But for the most part, actual WSO specifications, such as BPEL, remain at best peripheral to what’s actually emerging in development projects. Some potential implementers question whether they need WSO despite the biased enthusiasm of vendors and reports from standards groups.

Step into a world of SOA
According to IDC analyst Sandra Rogers, it is important to understand distinctions between buzzwords. Web services and Web services orchestration are important elements of an SOA, providing capability for workflow and processing of multi-step functions and services. “The common standard that has gained ground in the industry most recently is BPEL, which is supposed to facilitate interoperability of workflows,” she says. The types of products that address this need for interoperability also fall within the genre of business process automation (BPA) and business process management (BPM). To date, most of the technologies out there have been proprietary but even those are now getting morphed to handle Web services and BPEL standards.

“I think the industry is trying to step away from just talking about Web services into the world of SOA, with adherence to Web services standards at many levels as a key aspect of a standards-based SOA,” Rogers notes. Still, she advises, many technologies and capabilities are required to run and optimize a SOA environment—including orchestration, security and management—so it’s not a simple path to go down.

Waiting for the orchestra to begin
Standard Life’s Ireland says although he would value implementing projects across a range of apps and environments, he is still waiting for BPEL to mature. In the meantime, he achieves the kind of orchestration he needs using IBM WebSphere and WebSphere MQ Workflow. Indeed, the company now has more than 70 applications in production on this architecture and a portfolio of more than 250 reusable business services.
Standard Life’s SOA underpins the systems supporting the AdviserZone, a portal which gives nearly 25,000 financial advisers direct access to many business processes and also securely shares with financial advisers’ own IT systems. Standard Life’s recent product launches, the innovative Self Invested Personal Pension product and the online new business system for its Life Protection Series, are two of the many business initiatives delivered on its SOA.

“We have been waiting for more maturity on Web services orchestration tooling...though I really don’t think we have suffered from not having orchestration in there,” Ireland says.

A similar story of enthusiasm for SOA combined with wariness about WSO is told at Fidelity Information Services (FIS), which provides application software, information processing management, outsourcing services and professional IT consulting to the financial services and mortgage industries.

Led by David Spies, senior VP and chief software architect of FIS, a division of Fidelity National Financial, revamped its mortgage processing system to better serve in excess of 35,000 end users. The mortgage processing system is called Empower! and about 25 of the top 100 mortgage lenders in the country use it. Empower! is a loan origination system suite of apps and tools that provides top mortgage lenders in the country the capability to customize the application to support their business processes.

FIS decided to migrate Empower!, built on Delphi software, to a new architecture, and in 2003 turned to Avanade, a Microsoft enterprise platform integrator and its Avanade connected architecture for .NET (ACA.NET) tool. Empower! for .NET uses C# as the development language of choice. Although ACA.NET offers aspect oriented programming with orchestration (AOP), Spies says FIS has not used the feature.
The goal of the .NET-developed Empower! was to improve flexibility by exposing functions in the form of services, automated processes, streamlined data exchange across the enterprise and shared infrastructure services and lower TCO.

According to Spies, although the fundamental fat client/server algorithms originally created in Delphi are re-usable in the .NET app, the many architectural changes to the app made the process more of a re-write than a conversion. “Although it may be appropriate in some cases to skin existing functionality with a service façade, this in our opinion is a stopgap measure that would eventually require a refactoring,” says Spies.
Further, Spies says programming languages that offer new features such as code-based security demand rethinking every line of code in an app, instead of repeating past practices. “To do any less than a full re-factoring would turn our endeavor into no more than a marketing ploy,” he says. The pre-.NET app solved the intended business problem well, which minimized the need for detailed use case elaboration. “Ours is 90 percent a technology upgrade and 10 percent a business function upgrade,” he says.

Although Spies took his own approach, he says orchestration is a fundamental requirement in the financial services arena. There has been a drive within the mortgage industry for some time toward achieving both a “near-zero touch” and “paperless” loan approval process, he says. “Our work toward orchestration requires, in addition to simple routing, the ability to adjust the routing based upon data at any point in the process or business rules,” says Spies. And, he adds, an ideal situation would be a workflow that moves a loan between “human processes” and “machine processes,” repeating these movements as required facilitating the process. In other words, he adds, the ideal situation would be that human intervention in a process be “exception based.”

Standards just never seem to come
Meanwhile, at The Arlington Institute (TAI), a research organization focused on global futures, Web services and WSO, albeit the proprietary kind, are playing a role in delivering a government intelligence research software. Called DIgital ANalysis Environment, DIANE for short, the app is designed to collect, store, extract and analyze data for tracking global trends and potential surprise events.

To automate the research process, the solution needed to integrate multiple preexisting research tools, new automation components, along with human tasks and various human roles. To do that it also needed to accommodate .NET-based Web services, J2EE-based Web services, databases, command-line driven legacy apps and user authentication and authorization mechanisms.

According to Roger Barney, director of engineering at TAI, the firm searched for an EAI tool it could use to integrate all the pieces but later determined the end solution would expose the toolset as Web services using an SOA.

Oak Grove Systems’ Reactor 5 business process engine emerged as the leading choice for creating a comprehensive solution. Reactor 5 was selected for its platform and vendor neutrality, integration ability, and its ability to orchestrate Web services.

“The whole notion of standards in WSO is problematic because they never seem to get any closer,” says Barney. “BPEL has been emerging forever,” he adds. That’s why TAI decided to wait and see how WSO would develop and adopted Reactor 5 with the hope that it would be a sound base for the future no matter what happened with WSO standards.

And just what will happen with Web services orchestration? It’s hard to tell. Even industry analysts are wary when they offer opinions.

Spies at FIS notes that to maintain a properly performing system under SOA, the system should provide for composition of Web services in addition to orchestration. “This, of course, might lead to service bloat, but at the end of the day the most architecturally pure application will remain on the shelf if it does not perform well,” he says. “In my mind, performance is the largest challenge coming out of all these really cool technological moves engendered by Web services.”

Sidebar: No shortage of Web standards acronyms
Sidebar: Business apps with service in mind