Skip to main content

A Pragmatic Application of SOA (Service-Oriented Architecture)

Posted by hiheiss on June 29, 2005 at 10:06 AM PDT

Over at TS-1640 Pragmatic SOA: A Case Study, with developers Ashok Mollin, Ashesh Badani of Sun Microsystems, Inc. and T.N. Subramaniam, Director of Technology at RouteOne LLC Inc. Ed Ort ( and Tim Bray ( of Sun are blogging the session in greater detail. I will be doing a story on this for in a month or two so stay tuned. For now, a sneak preview.

RouteOne provides a web-based Credit Aggregation Management System (CAMS) created to accelerate the automotive finance process for dealers and their finance sources. The session presented “a real-world implementation of an SOA project at RouteOne LLC and helps explain the architecture and various best practices, design patterns, standards, and technologies involved in building an end-to-end business solution.” The presenters define Service Oriented Architecture (SOA) as “an integrated software infrastructure and design approach, leveraging Web computing standards, for delivering business functions as shared and reusable services.”

A lot of people regard SOA as a real challenge, in part because it typically involves both substantial organizational change, in addition to new ways of organizing IT. It seems like a situation in which developers have to be, not only technically sharp, but good listeners who can understand the culture of the company they are working with. Creating a shared service requires technical design prowess — architects have to know who, when, and where in the business process, services will be consumed. And then there is the whole history of ERP enterprise resource planning, in which some CIOs and IT managers experienced a lot of growing pain involving expensive projects that required changing processes across the enterprise as part of automation. It has not always worked out. Some people fear that SOA will bring a lot of pain to companies because it may be bigger than an ERP implementation. So businesses are sometimes understandably cautious. There can be a lot to rethink: development methodology, business impact, infrastructure, budget, organizational design and more.

Another challenge involves creating high-level business components that can be re-used and re-configured. One problem is that the requirements that yielded the original component interface were different enough from the new ones so that they required the re-write of substantial functionality.

The basic approach of Sun’s Ashok Mollin and Ashesh Badani, along with RouteOne’s T.N. Subramaniam, seems sensible and cautious: Projects need to generate ROI in 12-18 months so start small and be opportunistic. Minimize disruption to existing infrastructure; reduce risk with fewer web services initially while climbing the skill curve. Wrap legacy/existing applications using adapters + WS; Java and .NET interoperability. Evolve into a flexible, standardized architecture; does not mean “rip and replace”. Foster cultural change to encourage reuse. Take a top down approach – let the business drive!

They addressed several critical problems:

Single Sign On

Transparent login from lender portal

Get Dealer Information

Accessing volatile dealer information at runtime

Import Credit Application

Start the process on another system – DSP


Maintain state and coordinate document exchange in long running transactions with Lender

A summary of their “Pragmatic SOA wisdom:

Start simple, don’t let the “alphabet SOAup” overwhelm you.

Let business identify the service.

Think XML documents not objects.

Use SOAP as an envelope, but not for binding.

Use WDSL 2.0 for description not code generation.

Think asynchronous conversations.

Use WSBPEL to orchestrate the process.

Use JBI for integration.

Keep learning, this is not finished.

Question as I left: Did the large Java developer audience there come away enthusiastic about SOA? There certainly were a lot of smart, probing questions in the brief, casual q &a after this session, if that's any sign.