In-Depth

SOA’s up

• By Colleen Frye
• August 1, 2004

The buzz surrounding Service-Oriented Architecture (SOA) is that it will more closely align business and IT and in so doing, make organizations themselves more agile, flexible and thus more competitive. In a SOA, applications communicate via a common service layer. While the notion is far from new, it is another step in the evolution of component-based development. From a technology perspective, isolating application functionality into separate, reusable (and replaceable) components speeds development and deployment, and reduces the cost and effort of maintenance. What has changed is that Web services are enabling the alignment of business components with the underlying IT components, according to Michael Liebow, IBM Global Services Web services vice president.

From a developer’s perspective, though, SOA is more about the connections than the components. “Flexibility is in the connections between components, not in component code,” said Hans Vynckier, application architect at systems house Datakor, part of the major Belgian software group CCS. “The more connections you have, the more flexible you are.”

In other words, SOA is about the lines, not the circles, said Dan Foody, CTO at Actional Corp., Mountain View, Calif. “SOA is about trying to consolidate, reuse and eliminate redundancy. As you move toward a SOA, you look to simplify your architecture by sharing services, say by eliminating unnecessary hardware, infrastructure and management.” If you think of it in terms of a network graph, said Foody, “you’re decreasing the number of circles but increasing the number of lines.”

What does this mean to a developer? Datakor’s Vynckier said it means designing an application with an additional layer, or what he terms “mid-level design.” Datakor, in a major rewrite of its Synchro ERP product, developed a best practices development framework comprising the use of Web services and component-based development in a SOA.

“The main difference in developing software in our SOA ... is an extra layer. In what I call the ‘mid-level design,’ we try to translate functional specifications to implementation prescriptions.” As a result, Vynckier said Datakor, in its development framework, is “very focused toward components based on functionality rather than objects based on technology. An immediate result of this is an increase of communication between components.”

He explained: “In our previous applications one had a good program if it was a ‘thick’ one. It served the better glory of the programmer who could make those complex things and so was inevitably needed to maintain it. Now we say make your program responsible only for the first-line functionality it has been given and delegate all the rest to other components. Now one has made a good program if it communicates with a lot of components bringing in their piece of functionality.”

Strategy shift to SOA
Like many organizations, Datakor began its project before SOA became one of the industry’s hottest new acronyms. For most organizations, the implementation of Web services -- a way of integrating Web-based applications using standards such as XML, SOAP, WSDL and UDDI -- was typically a tactical project to solve an integration or interoperability issue, usually at the departmental level. Now, however, “in North America we see more companies looking at Web services in a more strategic manner; strategy meaning moving on to SOA,” said Sophie Mayo, director of Web services implementation services research at IDC, Framingham, Mass.

But Mayo said there are few companies implementing SOA today -- just over 100 worldwide at the end of 2003. “The majority of companies today looking at this are in the assessment/planning phases,” said Mayo. However, the SOA-related market is poised for growth. According to a recent IDC study, services firms’ worldwide Web services-related revenue is expected to increase exponentially in 2004 to $3.4 billion, from $1.1 billion worldwide in 2003, said Mayo. And IDC expects that number to reach $16.6 billion by 2008. Despite the growth trajectory, put in perspective, Mayo said, it represents just a small fraction of the overall IT services market.

Still, “we’re at the beginning of the SOA story,” said Mayo. “What companies have been trying to resolve with Web services is more tactical. With SOA, it’s more a corporate-type decision; there are more cross-functional and cross-disciplinary decisions. Web services is focusing on one function in an enterprise, like financial, HR or marketing. I see SOA going across these dimensions and more quickly involving external partners. SOA is a driver of Web services; once you use a SOA approach you will start building more Web services.”

For Datakor, SOA was simply a logical step. “There was no real decision to implement SOA,” said the firm’s Vynckier. “We started the development of our ERP application before anybody spoke of SOA and haven’t changed our opinion on development since. Given the technical goals, the application goals and [Compuware’s] Uniface to implement them, what is now called SOA was a logical way to implement it.”

The technical goals included component-based development, client/server, components for Web applications, maximum inheritance, a standard look and feel, and a standard way of programming. Among the application goals, giving customers “a fully integrated place in the supply chain” contributed the most to the service-oriented approach, said Vynckier. “Supporting Web services allows companies to take a more real-time position in the supply chain. Communications between companies tend to go faster on fewer data.”

Datakor began the rewrite using Uniface 8.3, which the company chose because it met the needs of an “extended application” exposed to customers through Web services. Datakor specifically cited Uniface’s inheritance mechanism, and its identical approach for internal and external (Web-related) development. Compuware recently rolled out Version 8.4, which provides the ability for Uniface to “consume” Web services from other technology, whereas 8.3 could “provide” Web services.

SOA products emerge
Compuware is among the numerous software vendors rolling out SOA-related products, services and blueprints. According to IDC, worldwide spending on software in support of Web services-based projects will reach $11 billion by 2008 vs. $1.1 billion in 2003. While there is growth in all segments of Web services software, “there is a lot of focus now on building out the infrastructures and hubs” for SOAs, said Sandra Rogers, director for Web services software and integration at IDC. As a result, tools for development and deployment are growing the fastest, with database and security products picking up as well. That growth will shift toward the mid- to latter end of the cycle, she said, with management tools picking up steam.

The percentage of companies that have actually moved from utilizing Web services for a tactical need to expanding it to the enterprise with SOA is unclear at this point, and an area IDC plans to study, said Rogers. “There is frustration in interoperability and integration, and the ability to meet today’s business requirements vs. yesterday’s. There is a lot of focus being spent on architecture now, which is very promising.”

Indeed, the big platform and infrastructure vendors are all positioning for the SOA market. IBM, for example, is building its SOA strategy around WebSphere Application Server and integration software, and Tivoli’s infrastructure management and security software. The company recently announced WebSphere Business Integration Server Foundation, which offers native support for the Business Process Execution Language (BPEL), as well as the IBM Assessments for Services-Oriented Architectures from IBM Global Services. The strategic push is all part of IBM’s “On Demand” computing vision, said the firm’s Liebow.

Miami-Dade County in Florida is working with IBM Global Services as it develops its SOA. “The relationship with IBM started a few years ago,” said Carmen Suarez, the county’s systems support manager. “We didn’t have a lot of Java programmers, and we wanted to jumpstart our Java development.” Then, Suarez explained, “we decided it was time to look at the architecture as the big picture. We had a lot of big projects that required interoperability. The best way for interoperability was to adopt a service architecture and go the Web services route.”

The initial goal was an enterprise-level platform for Miami-Dade’s Internet public access applications to allow citizens to apply for permits online, renew licenses, pay fees and so on. “Some portions existed before, using other interoperability tools that were cumbersome and hard to maintain in an infrastructure environment,” said Suarez. “We had done a lot of screen scraping and attempts at database integration, which required that we duplicate business rules on different platforms. We wanted another way for interoperability with legacy applications. We decided to try a SOA approach.”

IBM Global Services “was helpful in trying to steer the architecture. They helped to determine which tools were best to implement, what platform, etc.,” said Suarez. Miami-Dade standardized on WebSphere and AIX machines, and then chose ClientSoft’s ServiceBuilder for the creation of Web services via legacy applications. The county uses IBM MQSeries products for guaranteed message delivery.

The ROI, said Suarez, “is going to be the speed with which we can make our applications interoperable. And reusability is a big deal; we’re seeing benefits of that now, too.”

At the annual TechEd conference last spring, Microsoft pushed its own SOA plan to developers. In fact, Microsoft Architect Don Box told ADT that “we have a new way of thinking about software that we call service-orientation.” Like others, Box sees benefits to this approach vs. just plain coding, or the not-so-plain object software methods in vogue way back in the 1990s.

The move was influenced, some observers say, by the Microsoft development community’s experience with Microsoft message queuing software in the late 1990s. For Microsoft developers, Box noted, the move to service-orientation “was informed by their experience with message-oriented middleware and distributed object legacy.”

With the services approach, one tries to establish contacts of sorts with software objects, to agree to a set of XML and (increasingly) message-based protocols, and to restrict dependencies between Web services components.

Increasing IT’s responsiveness
Indeed, increasing IT’s responsiveness is the driver behind BEA Systems’ SOA initiatives and its long-term vision, what the company has dubbed “Liquid Computing.” It is the vision of a “fluid enterprise, increasing IT’s responsiveness from months to minutes,” said BEA’s Peter Linkin, senior director of integration product marketing. “Today there is a lot spent in the IT budget just integrating. The platform approach we have is addressing the IT gap, or time lag in responsiveness, caused by the complexity of integrating. What we’re talking about is more capability on demand than capacity -- IT’s capability to do better/faster/cheaper development. It’s a pure software approach.”

BEA recently announced BEA WebLogic Server Process Edition, which Linkin calls a “premium edition of WebLogic server for quickly building service-oriented composite applications.” It allows J2EE developers to leverage business process management (BPM) tools and frameworks. BEA has also launched three SOA-related initiatives: a SOA Technology Center; the SOA Blueprints Initiative (SOABI) in conjunction with The Middleware Company and BEA dev2devLive; as well as the availability of new controls that are reusable components designed for use with well-known platforms like Amazon and eBay.

The driving idea, said Linkin, is to take an enterprise compatibility approach rather than an integration approach. “If you got people to take a compatibility approach, i.e., service interfaces, you would get more economy of scale, serviceability, etc. We know the applications vendors aren’t there yet, but we can promote it from standards efforts,” he said.

BEA customer USF Corp. laid the groundwork for a SOA two years ago using BEA’s WebLogic Server application server and BEA Portal products, and utilizing XML. USF Corp., based in Chicago, is the holding company for a $2.29 billion group of companies that provides supply-chain management and logistics solutions. At the time the company designed its employee-facing and public Web sites, “a services architecture was not really in the picture,” said Kumar Ramachandran, product and development manager, USF E-Business Group. “We definitely used XML in a lot of interesting ways; everything was an XML form, but not Web services. Our architecture had all of the fundamental ingredients to move into Web services. We didn’t realize we wanted to go there, but it made it easy to move to SOA.”

USF Corp. built the sites using the 7.0 versions of BEA, and rather than migrate to the 8.0 versions, which Ramachandran said would have required a lot of effort, “we chose not to migrate, but just reuse components using SOA. We don’t have to keep migrating or building; we can keep the components where [they] are, and just face them with services.” Ramachandran said they are doing this for their external-facing applications now.

Service-oriented platforms
Platform players like BEA and IBM are also moving toward the traditional middleware and enterprise application integration (EAI) auspices with process management functionality and plans around enterprise service buses (ESBs). In April, IBM announced that it would be rolling out products around its ESB strategy, and BEA in May detailed Project QuickSilver, an XML-based technology that will converge the capabilities of an ESB with Web services management (WSM).

Middleware vendors are also strengthening their positions. Sonic Software, for example, recently announced Sonic ESB 5.5, which incorporates Sonic Continuous Availability Architecture (CAA) to deliver highly available communications between apps in an enterprise SOA. Key capabilities include hot failover to ensure the integrity of in-process transactions, and an “out-of-the-box” software-based configuration that eliminates the need to configure and deploy specialized hardware.

“The application platforms are moving in a service-oriented direction, to service-enable applications so that those applications are ready to interoperate. The ESB is the other pillar, responsible for moving data between applications,” said Gordon Van Huizen, Sonic’s CTO. “An ESB can help to isolate you from differences in how applications are built. An ESB is a coherent, service-oriented layer that sits between message-oriented middleware and the application, so you’re no longer building applications that are messaging-aware, but simply event-driven.”

Tibco, which built its business around the idea of a service bus, is strengthening its process offerings with the recent acquisition of Staffware, a provider of BPM software and solutions. Tibco has also put together a collection of best practices -- dubbed the Enterprise Reference Architecture (ERA) -- for developing, assembling and managing a SOA.

“SOA is what we’ve been doing ever since we were a company,” said Ed Zou, general manager for business integration. “We don’t want you to rip out what you have in place, but rather turn those things into services, and recombine those apps into composite apps.”

Management challenges grow
And while the number of composite applications in production is small today, there is no doubt that the number will grow, and that the components and Web services will need to be managed. Expect traditional systems management suppliers to offer this capability, as well as startups like Actional. Web services create some new management challenges, said Actional’s Foody. One is the notion of interdependence. If several apps share a component, say a bond yield calculator, all those applications will be affected if that component fails. So, said Foody, “you need to start addressing the additional risk of failure, and proactively architect so failure is less likely to occur.”

Versioning and security will also need to be handled differently in a SOA, Foody said. Development will also be subtly different. “With a traditional application you know what is required for that service. With SOA, it’s almost the opposite. You know the initial requirements from the initial consumers, but the goal is to have more consumers, so new requirements are added after production,” he explained.

The notion of response time will also change, he said. “The traditional look at response time is that the service has a response time of ‘x.’ This works great if there’s not a lot of different consumers, but once you start sharing the service among different apps, each app has a different pattern of usage, so the response time will be different for each one.”

Going back to his “circles vs. lines” metaphor, Foody said, “a traditional product will tell you about circles, but not lines. Web services management needs to discover the interdependencies and track them.”

The Web services management market is nascent, and the early Web services tend to be simple, but as the use of SOA grows, so will complexity, said Steve Garone, managing partner at The AlignIT Group LLC, Newton, Mass. “The time to look [for Web services management products] is now,” he said. “To go toward a services-based approach to developing/deploying/maintaining software, to a complex environment that spans the enterprise, you have to think about how you’re going to manage that from day one.”

Carl Ansley, CTO at Clarity Payment Solutions, New York, agrees. “The number one challenge for a company getting into the Web services space is deciding how you’re going to manage it.” Clarity’s technical infrastructure makes extensive use of XML Web services for host-to-host integration with both clients and vendors. Clarity is using the Systinet Server for Java “to expose a subset of internal services to the outside world to our clients. It’s a gateway between the internal structure and external Web services infrastructure,” said Ansley. While Systinet provides the firm with some management capability, Ansley would like to see Systinet offer more in that area. “I’d like to see a tighter integration between the SOAP stack and management,” he said.

Still, it is early, and SOA is a journey, said BEA’s Linkin. “There are implications for IT organizations in the way they’ll build applications in the future, and governance comes into this. What granularity level do you go down to? Which services do you expose? It’s a service that’s always on. You can’t take the system down in North America because this could be a live service in Australia. It’s a different culture for a lot of IT companies.”

Please see the following related stories:

“What to look for in Web services management” by Colleen Frye

“NetJets flies with Web service-free SOA” by Rich Seeley