Five ways to roll out SOA

Big-name companies from Comcast to United Airlines are jumping into SOA, changing the way organizations plan, develop, and deploy enterprise applications

United is adopting the BEA AquaLogic ESB for its SOA services, because it is a newer platform that Cidambi expects will be more oriented to the newer SOA concept, and a better fit with the WebLogic server environment and Eclipse development environment in use at United. “AquaLogic basically runs on top of WebLogic,” Cidambi says, so there’s no integration effort.

Avoiding unnecessary effort is also why Cidambi isn’t moving the EDA services to AquaLogic; WebSphere does the job quite well, he notes, and moving to a new ESB would inevitably cause disruptions and surprises: United has had seven years to optimize its WebSphere platform and work out operational kinks; moving to a new ESB such as AquaLogic would take effort now and undoubtedly expose new kinks.

Another issue Cidambi faces is the lack of standard XML schemas for EDA, making the messaging effort between EDA and SOA services more complex and labor intensive.

Thomson Financial automates service compliance
Many companies like the SOA concept because it promises faster development times. But some SOA developers have discovered that a key part of service governance can actually slow down development, stealing that promised speed. Financial publisher and information services firm Thomson Financial discovered this unpleasant surprise early in its SOA journey, recalls Vladimir Mitevski, vice president of product management core services.

“To call it an enterprise production asset, a service needs to comply with several methodologies and policies,” Mitevski notes. Many are very exacting: The names of XML elements can’t be abbreviations and must be real dictionary words, for example, and some items, such as user names and passwords, cannot be hard-coded. When you have just a few services, the enterprise architecture team can usually keep up and also catch any issues, he says. But soon enough, the reviewers become a bottleneck and even begin missing problems due to the workload.

Thomas Financial has thousands of services – fine-grained, coarse-grained, and everything in between – and a small architecture staff, so it quickly felt the pain. “No matter what the granularity, each service goes through this process,” Mitevski says. Only then is it entered in the service registry. Likewise, changed services need to be evaluated for compliance before the new version is registered and thus available for production use. “But the architecture office was a bottleneck due to the scale,” Mitevski says.

Reducing the compliance requirements was not an option, given the critical nature of the applications involved, such as single sign-on services, Web services that deliver financial markets information to analysts and traders, and Web-based financial analysis and charting services accessed through Microsoft Office.

Thomson’s solution to the compliance workload issue was to turn to automation, using policy evaluation tools from WebLayers. “The tools are more efficient and don’t miss violations,” Mitevski says. It did take some time to create the policies that the tools gauge compliance against, and it’s critical that architects review the tools’ analyses to see if certain issues arise repeatedly that might indicate lack of understanding of key policies by developers or ambiguity in the architecture, he notes. “It helps show us what to do better, and some policies do need to be adjusted” Mitevski says, though he has found that most violations are due to developers taking shortcuts. Architects also decide when developers are granted exceptions for any compliance violations, something that happens only rarely, he notes, and the exceptions are noted in the registry for other users to be made aware of.

For Thomson Financial, the results of service compliance automation are dramatic, Mitevski says: “It used to take 20 people in a highly orchestrated process across various groups to go live [with a service]. Now it takes just a single person.”

Jabil Circuit simplifies customer integration
A company that focuses on manufacturing services needs to accommodate a wide range of customer integration, such as for billing, forecasting, and order systems across the many systems in use by its customers. But it’s very hard to manage all those point-to-point communications as your customer base grows and evolves its own systems. That’s why many manufacturers have moved to third-party providers of transaction hubs, called VANs (value-added networks); each supplier and customer worry just about the one connection to the VAN, and for each customer-supplier pair.

But this approach fails when you have custom processes with your customers that the standard VANs don’t accommodate. Jabil Circuit, a custom electronics manufacturer, faced this dilemma the hard way: by manually maintaining all those custom applications and interfaces. Jabil has more than 5,000 trading partners, though most could be handled using the VAN approach. But 50 customers needed special communications mechanisms or business processes that the Sterling Commerce VAN was designed for. Often there were several such custom connections per customer, compounding the effort, recalls Lowel Gilvin, the company’s e-commerce manager. Something had to change, so Jabil adopted SOA principles to replace most of these custom connections with service-based ones that let common functions be reused.

The first step was to separate the business processes -- such as order-to-cash management, forecasting, and inventory consignment -- from the communications processes. Jabil now has standard services for most of the communications mechanisms in use, such as AS1 (Applicability Statement 1), AS2 (Applicability Statement 2), and FTP, as well as separate data-handling services such as for XML, flat-file, Excel, and SAP iDocs formats. It composes the appropriate communication service, data-handling service, and business service for each of these customers, using tables and metadata to automate the composition in most cases. In some cases, customers use more than one mechanism, perhaps based on which division is involved, and the tables account for these multiple mechanisms, Gilvin notes.

The SOA concepts of abstraction, modularity, and service composition usually work as is, Gilvin notes. In some cases, special requirements can’t be met by combining services, so Jabil still has some one-off integrations to maintain. But even here, Jabil can often use the SOA approach for part of the integration. As one example, certificates for XML and SSL validation can’t be handled as standard services, since the certificates are unique, but Jabil can compose the appropriate communications and business services with a hard-wired data-handling service, keeping the reuse and consistency benefits of SOA in two of the three integration aspects, Gilvin says.

Rather than use an ESB to manage the messaging, a registry to manage the services repository, or a SOA-oriented development environment to develop the services, Jabil uses Sterling Commerce’s Gentran Integration Suite for all three purposes. The suite is designed for supply-chain interactions, which is all that Jabil is trying to manage. This limited scope lets Jabil rely on the toolset’s embedded architecture rather than create its own. “We have a small set of standard business processes,” Gilvin notes.

To comment on this article and other InfoWorld content, visit InfoWorld's LinkedIn page, Facebook page and Twitter stream.
| 1 2 Page 5
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.