Standards Are Standing in Way of External SOA
October 27, 2008
The promise of service-oriented architecture (SOA) is a world where everything interoperates seamlessly, pieces of applications are reused endlessly and development of new systems is quick, cheap and easy. But despite some high-profile deployments and the spread of Web services, when it comes to financial firms doing serious business with each other, SOA is being held back by competing standards and varying implementations.
Wall Street firms use SOA internally to integrate applications, create employee portals that bridge silos, and build Web sites for customers that bring in information and tools from a variety of applications, both in-house and from third-party providers.
The problem is that service-oriented architectures are composed of a complex--and ever-evolving--set of protocols. While the low-level standards are well developed, tested and universally used, they are more appropriate for the transfer of information like market data than clients' sensitive transactions.
For Web services that connect to back-end systems, SOAs usually employ Soap, or the simple object access protocol, while Rest (representational state transfer) is used for customer-facing technology such as Web 2.0 applications. Soap is well supported by SOA vendors: Whether software is written in Microsoft's .Net or Java, it can send and receive Soap messages, which are generally simple requests for information such as the price of IBM stock at a particular time.
Companies that use SOA for more complex processes typically select a technology provider's platform and all the high-level standards that vendor supports. Many SOA platforms come with an enterprise service bus (ESB) that helps join Web services together. But firms are leery of opening up their SOA infrastructure to the outside world, preferring to limit interactions to the most basic level.
"Wall Street companies have deployed SOA and have spent a lot of money on it, but nobody has asked us yet to plug our services into their ESB--they're just not there yet," says Stephane Dubois, founder and CEO of Xignite. The San Mateo, Calif.-based company offers more than 60 subscription-based Web services, ranging from market data to interest rates.
According to Dubois, most of Xignite's 400 clients--half of which are in financial services--use Soap or Rest. "But when they use Soap, they use it very simply, no advanced standards, no technology layers," he says. "As far as I know, nobody is relying on the standards for security." Instead, firms protect their data by keeping it behind corporate firewalls or on a virtual private network.
Pablo Grana, chief architect at Globant, a Hopkinton, Mass.-based software outsourcing company, says that data transaction standards are not yet proven. "It would be very risky to base a product or a project on the transaction specifications related to SOA right now," he notes.
Technology giants such as IBM and Microsoft have backed different standards, with smaller vendors falling in line behind. And standards-setting bodies including the Web Services Interoperability Organization, Organization for the Advancement of Structured Information Standards and World Wide Web Consortium each have their own sets. For example, widely adopted standards for security include WS-Security, WS-Trust and SAML (security assertion markup language), and there are dozens more with highly specific purposes, such as partly encrypting a message so that only certain people can read more sensitive information.
When two companies decide to communicate via Web services, they have to agree on a common set of standards. These individual negotiations make it difficult to deploy complex Web services widely. "The standards question is still a moving target," says Mike Curtis, VP of strategy at Dallas-based security vendor Critical Watch.
