A technology exec at a major financial conglomerate offers corroboration of this perspective. His company’s asynchronous messaging solution is a well-established EAI product, which among other benefits provides the binary throughput necessary for high-volume transactions. When asked his opinion on ESBs, he replies with a question: “Why should I go for a lightweight JMS solution when I already have a heavy-duty one?”
SOA step No. 9: Deploy service management
If more than a handful of services are up and running, and if any are mission-critical, you need to manage them the way you would any network resource. Several vendors offer dashboardlike solutions that monitor the health of services, maintain service levels, scale performance, set up fail-overs, handle exceptions, and so on. This is made possible by the wonder of XML messaging, which allows intermediaries -- services in themselves, sometimes packaged in appliances -- to tap into message streams.
Intermediaries establish a new slice of functionality between the network layer and the application layer. Among other benefits, intermediaries virtualize services, creating proxies that hide the details of a service’s implementation from clients and thereby add security. They may also throw in XML firewall or acceleration features, as well as the ability to modify large groups of services from a single control panel -- to respond to changes in regulatory statutes, for example, or to meet new security requirements.
Services management is slowly moving toward standardization with OASIS’s approval of WSDM (Web Services Distributed Management) last March. A second specification, WS-Management, which overlaps a bit with WSDM but focuses on managing network hardware rather than on application-level messaging, was submitted to the Distributed Management Task Force by Intel, Microsoft, and Sun Microsystems last June. But today, for all practical purposes, you need to use the same Web services management solution across your SOA deployment if you really want centralized control. As Bob Laird of MCI puts it, “It’s a big mess right now, and we just have to muddle through.”
Interestingly, the pure-plays -- including Actional, AmberPoint, Blue Titan, and SOA Software -- lead the way in Web services management. But the big network management players are catching up: BMC, Computer Associates, Hewlett-Packard, IBM, and Novell are all sponsors of WSDM and are in various stages of incorporating Web services management into their offerings. In addition, Cisco’s AON (Application-Oriented Networking) initiative should soon result in networking equipment with service management capabilities.
“We use AmberPoint,” says Scott Thompson of H&R Block, although he admits he has rolled out that vendor’s solution in a limited fashion. “We’re taking baby steps,” he says, “starting out with basic service-level management monitoring. Then we played with exception monitoring, but we really want to mature the model into managing encryption, decryption, authentication, and authorization types of functions.”
Ben Moreland of The Hartford cites “the ability to be notified when there’s an SLA failure or there is a failure in the service [and] the ability to enforce policies” as reasons his organization deployed a Web service management tool.
Some see centralized policy management as the most important promise of all. It’s relatively easy to check the health of Web services running locally, but to reconfigure thousands of Web services across an organization, you need a standard that works across platforms. The WS-Policy standard is designed to address this, but implementation in products remains at an early phase.
SOA step No. 10: Consider orchestration
Every platform includes some method for orchestrating services. Whether it works well is another question. Ultimately, service orchestration will be vital for whipping up new, process-based composite applications in the dynamic manner promoted by the SOA vision. Few are implementing it today, however, because it’s complex to pull off and because the relatively modest SOA rollouts that generally inhabit the real world don’t really require it.
Randy Heffner of Forrester Reasearch offers some guidelines. “One easy entry point for thinking about orchestration is: I have one request coming. … How should I do a full and complete business unit of work?” he asks. “If the answer to that question is, ‘Well, I’ve got to make several things happen in a sequence across multiple underlying applications,’ then you’ve got a scenario for orchestration.” Heffner adds that orchestration also demands some tolerance for latency. “Depending on how many things you need to have happen in lower-level applications, you’re certainly not going to be able to have an orchestration happen in a quarter of the second. You may not even be able to get it to happen in 5 seconds.”
Today, BPEL (Business Process Execution Language) provides the only standardized means of orchestration, although BPM (business process management) solutions have provided proprietary orchestration schemes for years. “Orchestration is trying to codify BPM,” says Lindo, who works at a New York-based development firm. “And that’s just unbelievably complex. If you point it at certain industries like manufacturing, you can focus enough to make the concept manageable. But for general business management, the relationships are so complicated that tackling such a project from a coding or interface perspective is a massive bear.”
Forrester’s Heffner draws a clearer distinction between service orchestration and BPM, which has its roots in end-to-end workflow modeling. “The two are not well-connected,” he says. “In the modeling languages, … there’s no way to have a full view of the complete process where I just say, ‘OK, push these steps down into BPEL.’ I really can’t get that.”
In the opinion of Flashline’s Stack, the failure to accommodate human interaction is a fatal weakness of BPEL. “When the industry was debating BPEL last year, I think the decision to go with the machine-to-machine-only orchestration protocol was a big mistake,” Stack says. “We don’t have any customers that are using BPEL in anything but a trivial, experimental sense,” he adds, including sophisticated Web services customers such as Sabre and Countrywide.
Ben Moreland of The Hartford, however, sees potential in an extension to the BPEL spec jointly proposed by IBM and SAP. “Down the road, we have BPEL4People, which is a standard that a couple of the large vendors are now pushing because they recognize that efficiency of workflow within the BPEL specification,” he explains. “I think that those two layers, the BPEL orchestration and the BPM workflow, are going to consolidate.”
Meanwhile, it won’t hurt to explore proprietary BPM solutions, as Scott Thompson of H&R Block has discovered. Ironically, working with Tibco’s BPM tool has helped SOA gain traction in his company. “Until we started to orchestrate various services together to form a business process, we didn’t have outright adoption of our SOA,” he says. “It was more of a low-level IT type of project.”