Steps to SOA No. 10: Consider orchestration
Orchestration enables business processes to be reflected immediately in new composite applications -- but you may not need it yet
Follow @infoworldEvery 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.”
Read more about applications in InfoWorld's Applications Channel.








