Not every effort at standardization catches on, but sometimes conditions are ripe for new ideas.
In the world of business applications, standards-based efforts are gaining momentum. Web services implementations are growing as users migrate to the middleware that enables and simplifies Web application-to-application connectivity. In addition, users are warming to the idea of a service-oriented architecture (SOA) to connect applications across a network in a way that fosters code-sharing and reuse.
The technologies have a symbiotic relationship: Web services can be deployed in an SOA. Together they constitute the next incarnation of enterprise applications, which experts say will act as loosely coupled, modular network services that developers can link to create complex business processes without much custom coding.
The move to a less brittle, more flexible distributed application model complements similar efforts to distribute server and network resources in data centres. “The common theme is virtualization,” says Jason Bloomberg, a senior analyst at ZapThink LLC. “Storage virtualization handles storage, grid computing virtualizes processor power. A services-oriented architecture essentially virtualizes software application functionality.”
Returning to favour
The current SOA buzz isn’t indicative of a new technology, but rather the next iteration of an old concept. Earlier attempts at popularizing SOAs, such as Common Object Request Broker Architecture, were hindered by a lack of standard middleware and APIs. Web services might be the missing link that brings SOAs mainstream, observers say.
“The reality is this might be the right time for us to be thinking about loosely coupled distributed computing, in part because of the movement to do it based on standards as opposed to proprietary integration technologies,” says Ron Schmelzer, another ZapThink senior analyst. “At the same time, there’s enough infrastructure in the IT environment — application servers and whatnot — that we can actually afford to implement Web services and SOAs without having to build a Big Bang kind of project.”
Additionally, as companies tackle new data center initiatives aimed at maximizing use of IT resources, they have to consider how these distributed computing projects mesh with applications. For example, from an application perspective, technologies such as grid computing depend on having location-independent services, Schmelzer says. “The system won’t work if it requires that one application, running on one server, be available. Services have to be distributed, and the only way to make that work in a grid capacity is to implement an SOA.”
An SOA doesn’t replace existing infrastructure, Schmelzer says. Rather, it serves as a layer on top of application servers and databases in multi-tiered or client-server architectures, he says. “SOAs provide networked, location-independent services that are themselves just interfaces to other systems.”
Neither do SOAs require application overhauls, says Scott Cosby, manager of WebSphere Business Integration at IBM Corp. SOAs aren’t about changing applications, but about providing an interface into an application so certain functionality can be exposed. For example, a company might expose the employee verification function in a human resources application as a Web service. Other applications then can make use of that service via an SOA.
The allure of Web services and SOA was strong enough for Wall Street Access to replace a three-year-old Microsoft Corp. C++ platform that was too monolithic, says Peter Underwood, vice-president of software development at the New York brokerage firm. Built with kind of a black-box approach, the platform had no API to get to. As a result, the firm wasn’t able to easily expose necessary steps in executing a trade to customers, partners and traders, he says.
Wall Street Access built a new services-based trading system, called AccessPoint, using IBM’s WebSphere Application Server and WebSphere Business Integration software. The system integrates and aggregates stock market information from nearly 20 data providers.
“The natural shoo-in for all this stuff is Web services,” Underwood says. “There are only a couple of different ways to ask for account information or purchase histories. So (we said,) “Let’s just build a framework in the most abstract way we can, and then expose it to an application layer.'”
Now with middleware, the firm can provide traders on the desk and customers the same service, Underwood says. “Everybody is seeing the exact same data in the exact same way.”
One issue the AccessPoint application has raised is the need for addressing and enforcing service expectations, Underwood says. One Web page exposed to a client might require three service calls — to a news provider, a market data feed and an exchange, for example. If one of those content providers is down or running slow, AccessPoint is effected, he says.
“We’ve had to get smart in terms of writing contracts and service-level agreements because it directly impacts our performance,” Underwood says.
Testing, too, has become an important issue because a single code modification to an AccessPoint interface can affect multiple networked applications. “We’ve invested a lot more money in testing because when we make a change under the covers it’s far sweeping,” Underwood says.
Because an SOA can layer on top of existing development technologies, platform vendors such as BEA Systems Inc., IBM, Microsoft, and Sun Microsystems Inc. are working to make it easier for users to build SOAs with built-in tools and wizards. “But it’s a shell game,” Schmelzer says. “Complexity doesn’t go away, it just goes somewhere else. And in this case, the complexity is the architecture itself.”
In addition, migrating to Web services and SOA requires long-range thinking about how to build useful services as opposed to mere APIs. A common mistake is to underestimate how difficult it can be to establish consistent methods of evoking and using services.
So far, a lot of companies are opting to build Web service interfaces simply because doing that is easier and less expensive than using proprietary tools such as MQ Series to link applications, says Anne Thomas Manes, vice-president and research director at Burton Group.
“Only a small number of companies are enlightened enough to recognize that ‘OK, I need to follow certain design patterns when I build this particular interface so I make sure that it’s loosely coupled so it’s flexible, adaptable and reusable,'” Manes says.
Coming in waves
According to Ben Watson, national marketing manager, developer and platform group for Microsoft Canada Co. in Toronto, Web services deployment is coming in waves — two waves, to be exact.
The first, he says, is that deployment which is happening internally within the walls of Microsoft’s customers and partners.
“Most of our big customers and big partners are engaged with some form of internal development or internal uses of Web services,” Watson says. “It’s very quickly become the preferred way of accessing data because if I’m going to go through the development curve of building a data-bound applications, it’s actually easier to do it using Web services, and also enables easier modification of the platform down the road.”
Watson adds that this form of development is being seen in governments, banks, manufacturing, logistics, retail, transportation and other sectors.
The second wave is happening, in Watson’s terms, “outside the firewall.” This external form of development can allow developers to do one of two things, he says.
“One, they can allow me to integrate with my supply chain, my partners and my customers automatically. Secondly, I may be selling this Web service as a service, like on a per-use or on a subscription basis.”
Watson says Microsoft Canada is seeing examples of both internal and external Web services development in this country, but adds that the number of external examples are “nowhere near the utilization that we’ve seen in behind the firewall applications.”
The network application platform
What users need, but can’t get today, are APIs that are agnostic to operating systems, application servers and programming languages, Burton Group’s Manes says. “When you build something with .Net or Java, you wind up using a bunch of infrastructure services that are built into the platform. That lets you build a nice, tightly integrated system — as long as you stay within the specific platform,” she explains.
Manes advocates building a network application platform that makes low-level infrastructure services available directly at the network layer rather than as part of the language-specific application platform. For example, companies should use a network level-based security framework rather than language-specific security services such as Java Authentication and Authorization Service, she says. Likewise, network-level transaction services make sense. Otherwise users will be forced to do complicated programming to enable cross-platform operations, she says.
“The only way that users can actually make the whole concept of orchestrated, composite application systems, running in many different types of platforms, crossing all kinds of logical and physical boundaries, work is if they’re actually providing all these services at the network layer,” Manes says. “It’s a long-term objective. [ellipse] But Web services certainly is going to enable it.”
Along these lines, BEA Systems recently unbundled an application security framework from its WebLogic platform so it can run on its own in front of application servers from any vendor. “That’s a really interesting tactic for BEA to take,” Manes says. Conversely, she notes, IBM’s security framework requires a company to use Tivoli and WebSphere.
On the business applications front, vendors have a role to play in helping companies realize a new application architecture as well.
“For Web services to work, you really have to break down big applications into discreet functional components and make those components available in a building block model,” Greenbaum says. “For most vendors that means a re-architecture of at least the interfaces to the different business functions in their applications, if not to the entire applications architecture itself.”
SAP AG, which is turning its proprietary BAPI interfaces into more generalized XML interfaces, is a great example, Bloomberg says. “SAP realized that the old way of doing things — the large number of modules that are tightly linked to each other — has to change. SAP is revamping (around) a service-oriented approach.”
That said, no one expects the changes to happen overnight.
“These guys move slowly,” Schmelzer says. When the Web really became potent in the mid-1990s, it took the enterprise application vendors a while before they added Web interfaces to their products — Siebel Systems was a client-server application until 1998 or 1999, he points out.
“Many of the big applications vendors are beginning to understand the ramifications, but they have other very pressing agenda items, such as maintaining their control over an account,” Manes says. “That tends to be a real driving force for most of these vendors, and they are always reluctant to really open things up to the level that the customer wants.” They’re all talking about it, but it will be a long process, she says.
When more open business applications platforms do exist, they will propel the development of new applications designed with the assumption that standard business information embedded in core ERP systems are readily available, says Greenbaum, pointing to Rubicon Group’s demand forecasting software, which helps companies match product availability and price to market demand.
“That’s an application that takes for granted the fact that there are demand numbers available from a company’s supply chain management system, from its ERP system, from its sales force and from its distributors,” Greenbaum says. “The software vendors know that information is out there and increasingly are going to use Web services to grab that stuff and provide a layer of functionality on top.”
