Services can be deployed on Java application servers, on Windows Server, or provisioned on legacy systems themselves -- and thanks to Web services interoperability, your developers can generally choose their favorite tools and platforms for provisioning. “One of the things that a service-oriented architecture gives you is the benefit of rendering that decision secondary,” says Charles Stack, CEO of SOA registry provider Flashline. “You can change deployment platforms at the service level without affecting your service-oriented architecture. Services abstract that very infrastructure level. It’s much less of a strategic decision than that sort of thing used to be.”
SOA step No. 5: Choose and deploy a registry or repository
Many organizations mark the beginning of their SOA initiative at the point when they deployed a registry as a mechanism for service discovery. At a minimum, a registry prevents duplicative effort, a place where developers can determine whether a service has already been created. As Timothy Vibbert of Lockheed notes, “It could just be a Web site that lists [services]. It may be manual discovery, but they’re discoverable.”
But as the number of services and the applications that use them grow, you’ll need a real registry. “We selected a UDDI registry in 2003 and put it in production in 2004,” says Ben Moreland of The Hartford. “We use it for the dynamic binding capabilities to give us the loose coupling between the client and the producer of the service.”
Most SOA deployments employ some sort of commercial registry or repository that offers deeper functionality than that defined by the UDDI spec, mainly to have a more structured way to store and manage service metadata. To complicate matters, the distinction between “registry” and “repository” is rather slippery. The common definition is that a registry contains data about services -- where they’re located, XML schemas, and so on -- whereas a repository contains the services themselves. In truth, services still run on their deployment platform, so repositories actually contain what amounts to a deeper level of metadata -- plus, registries generally offer repository capabilities. They just don’t call them that.
Choosing a registry may well be the first SOA-specific buying decision you’ll face. And it may also be the first time you encounter the fundamental choice between a single vendor’s offering and best-of-breed SOA solutions. All the big platform players, including BEA Systems, IBM, Microsoft, Oracle, and Sun have their own registries or repositories. But pure-play vendors abound -- including Above All Software, Flashline, Infravio, SOA Software, and Systinet -- all of which boast a unique mix of capabilities. Depending on the product, you may discover a wealth of stuff -- graphic representations of the relationships between WSDL and services, identity-based security that limits access to certain services, a rules engine to help manage service policies, and more.
When it comes to registries or repositories, David Aubrey takes the single-vendor view. “If you’re using any kind of framework, they’ll push a repository,” says Aubrey, senior architect at KomatiSoft, a New York-based financial application startup. “That’s one area, I wouldn’t try and force a third-party alternative unless I absolutely had to. At least not today. The key is interoperability with the framework and its rules engine, and that’s what they’re guaranteeing. Bring in a third-party solution, and you’re putting that whole synergy at risk.”
Not surprisingly, Flashline’s Stack takes the opposite viewpoint. “If you’re building your infrastructure for a service-oriented architecture on a proprietary vendor platform, I think you’re making an enormous mistake,” he says. “We caution all of our customers from the infrastructure standpoint to put a premium on openness, because otherwise you’ll have the worst case of vendor lock-in you’ll ever see.”
SOA step No. 6: Start tackling governance
Registries are more than containers in which services can be described by metadata and discovered by clients and other services. They are also centers of SOA governance, where IT can list human service owners, manage versioning, ensure compliance with enterprise requirements, and more. The sooner you start thinking about how governance will work, the better.
Governance is best defined as a combination of workflow rules -- who is responsible for what services, what happens when quality assurance uncovers problems, and so on -- plus management of service interface definitions. Those definitions become an analogue of an IT org chart gradually transformed by the disruptive effect of SOA. "The strongest way to look at your service interfaces is that they are the design of your business," says Randy Heffner, vice president at Forrester Research. "They deserve attention and governance as much as the design of your business does."
SOA is fundamentally a new paradigm for IT, according to a technology exec at a major financial conglomerate who asked not to be named. "When you increase dependency and complexity, it presents a whole new set of problems," the tech exec says. "The more SOA is successful, the more management becomes a problem." This exec believes that governance should be distributed rather than centralized, in a manner similar to the relationships among federal, state, and local government in a democracy. And he means that literally: He is currently studying The Federalist Papers for insight.
In 2004, The Hartford formed an enterprise architecture group to put a "governance process around projects," according to Moreland. In the beginning, he says, the governance process was all about communication. "We had architects talking together for the first time that were really solving the same problems, but in different lines of business. Now were to the point where we will actually stop a project if it does not conform to the reference architecture or the line-of-business blueprint. And we have the authority from upper management to be able to do that."
Moreland provides a specific example of the types of problems good governance can avoid. Recently, one business unit of The Hartford published a useful service in the proper SOAP format. A different area of the business applied to use that service, but also requested that the service return two additional data values. "The owner of the first service...said, 'I don't have the funding or the budget or the resources to do that. I'm tied up with other stuff,'" Mooreland recalls. In such a case, he says, good governance stipulates that the service in question should be owned by a group with a dedicated team that can maintain and modify it for the enterprise.
SOA step No. 7: Lay your security plans
Years ago, when the industry began promoting Web services, the first objection raised was: What about security? That’s because, back then, the emphasis was on XML integration across enterprise boundaries. By contrast, SOA tends to focus on the architecture of a single enterprise -- or closely related enterprises -- where the underlying assumption is that everything occurs within one, big trusted zone.
“Many people have this sense of, ‘When I’m doing this kind of stuff inside the firewall, based on restricted network segments or whatever else, I’m OK without a deeper sort of use of security in my services environment’,” Forrester’s Heffner says. “But the time when everybody says, ‘I have to do something with security,’ is an external connection.”
Although SOA shifts the emphasis toward internal architecture, B-to-B integration with partners is a natural extension -- and in many cases a core benefit. Across firewalls, the solution can be as simple as a two-way SSL connection. But before you jump to any technology conclusions, Heffner advises that you first decide whether your enterprise is a “hub” or a “spoke.”
Hubs, says Heffner, can simply lay down the law. “If you’re a Wal-Mart, then as a hub, you just say what the architecture is going to be … because everybody’s got to do what you say.” For the rest of us spokes, “you’ve got to look at what your partners, the people you’re going to connect to, what sort of security architectures they are doing. And then decide on the strategy of just pure edge security, so you’ve got an XML security gateway and can do authentication/authorization at that level,” or a deeper level of security, where authentication travels along with XML documents as they move within the enterprise.
Fortunately, the industry has agreed on a simple framework for securing XML messages beyond the time when they’re in flight: WS-Security, which is perhaps the most often used Web services specification after SOAP and WSDL. Today, many enterprises combine WS-Security with SAML tokens to assert user identity through every stage of a multipart transaction -- an especially useful solution for financial services organizations.
Several other security specifications are in various stages of development. WS-Trust is an extension to WS-Security that ensures the service requestor is properly authenticated before security tokens are issued. WS-SecureConversation extends the trust derived from positive authentication to groups of messages. And WS-SecurityPolicy enables services to exchange security policies and to negotiate authentication and authorization without user intervention. None of these three specs, which will be fairly essential in a world where XML messages routinely cross domains, has yet seen widespread use.
“For us, this is another area where we’re struggling through as best we can until new standards and practices emerge to make the job easier,” says Bob Laird, IT chief architect at MCI. Meanwhile, Laird is focusing on solid external defense systems, an effort that includes making his existing infrastructure security managers aware of new traffic flows and transactions, and purchasing dedicated SOA defense hardware such as XML firewalls from Sarvega.
“Something bad has to happen before SOA security tools really start happening,” Laird says. “We’ll see XML-based attacks, maybe even viruses, hitting someone publicly -- and that’s what it’ll take to galvanize the industry.”
SOA step No. 8: Build out your messaging infrastructure
Your next crucial technology choice: how messages will be sent or received among services and applications. With small-scale SOA implementations, you can often get away with direct, synchronous XML (most often, SOAP) connections that essentially assume services will be available 24/7. As deployments grow larger and more complex, however, asynchronous, reliable messaging may be required -- and because different messaging schemes support this in different ways, the danger of lock-in increases.
ESBs (enterprise service buses), EAI middleware from such stalwarts as Tibco or webMethods, and application servers from BEA, IBM, and Oracle enhanced with integration add-ons all provide asynchronous, reliable messaging functionality. All support a range of messaging protocols, including SOAP, JMS (Java Message Service), and MQ (Message Queuing), and offer application adaptors for legacy systems. Today, however, each solution has its own way of ensuring the arrival of messages, a situation that is unlikely to change even with broad adoption of standards such as WS-ReliableMessaging.
ESBs occupy a particularly confusing area. As Ben Moreland of The Hartford says, "if you get 10 architects together, you're going to get probably 11 different definitions of an ESB. Some are going to say that it's an architecture pattern; others are going to say it's a single product. Others are going to say it's a suite of products." Even among ESB products, the InfoWorld Test Center encountered surprising diversity.
Most people have a natural tendency to stick with what they’ve got. Bob Laird at MCI provides a case in point. “We wound up using WebSphere because we already had IBM MQ installed,” he says. “It just made the most sense. Plus, it allows our developers to be eased into SOA concepts through tools with which they’re already familiar.”
Lockheed’s Vibbert says he encounters this tendency all the time. Although he likes the lightweight, standards-based messaging solution offered by the JMS-based Sonic ESB, he doesn’t try to convince clients to switch if they already have a deep relationship with another vendor providing similar functionality.
But some folks, especially smaller shops, take a dimmer view of the single-vendor default. “To us, flexibility is everything,” says Paul Lindo, a 13-year veteran of development at the Federal Reserve and now CIO of a small New York-based development company. “What you get with a messaging system like MQ is a rehash of older proprietary technology with a new SOA spin. For us, sticking to straight Web services standards makes much more sense.”
MCI’s Laird concedes that relying on IBM may limit his choices in the long term, but he is willing to make that trade in order to start with SOA today, enjoy a low initial platform cost, and grow his SOA as IBM’s product set evolves. “And please don’t think we’re closing our eyes to ragged-edge tools,” he says. Laird indicates that MCI actually encourages its developers to try non-IBM tools as they emerge. Those that become popular are purchased in small quantities first and are integrated into specific projects. If they pass that test, they’re rolled out in larger numbers. “This way, we keep our options open while avoiding large-scale compatibility headaches,” he says.
“Most companies that have a message-oriented middleware system in place are more likely than not to leverage what they already have because it makes little sense not to use the robust messaging topologies that many of these companies have in place,” Flashine’s Stack says. “So unless you don’t have one of those, it seems to me that the MOM [message-oriented middleware] solutions are going to be the reliable messaging service -- and most have announced their intent to support the reliable messaging protocols.”