But there's life beyond BPEL. From its few remaining detractors, much has been made of the fact that BPEL doesn't include human workflow "support." However, BPEL doesn't say anything about any specific services at all, whether human workflow or systems. But it has very rich asynchronous service support. So we believe a clean approach for technology vendors and customers – while the standards expand to cover this area – is to use an external human workflow service that can be orchestrated by 100% standard BPEL processes. This makes human tasks and manual steps in a process look like any other asynchronous service and lets the BPEL processes remain standard while combining rich workflow capabilities with system integration.

Besides workflow, we recommend defining frequently changing business logic in external business rules. This can be done through any of a number of rules engines on the market today and incorporated into your BPEL processes and J2EE or .NET applications via Java or Web Services interfaces. Most process engines also include a tight coupling to rules engines and those that don't now probably will in the future. But even without specific vendor support, the effort to define an external business rule and call out to it will be well worth it when the rule has to change post-deployment. A loosely coupled interface provides critical flexibility to implement change without going through an entire develop-and- deploy cycle that can be both complex and risky in many production environments. (see Figure 4)

Another area where flexibility is critical is exception handling. We've seen many requirements for processes that need maximum performance but also rich exception handling. These can be conflicting goals because maximum performance is often achieved through simple processes with synchronous, tightly coupled interfaces, but rich exception handling may include asynchronous requirements and human workflow. A design pattern we've found useful for addressing these competing needs is the "error hospital." This pattern provides rich exception handling as a service. For maximum performance the processes are designed as short-lived synchronous processes under the assumption that all will go well. When issues are encountered, messages are published to an error hospital process (this could be a JMS queue or a BPEL process) that can then provide sophisticated exception management, perhaps with humans involved when needed.

The last best practice in the area of process orchestration that we want to discuss is testing. As mentioned, testing is both critically important and particularly complex for long-running, asynchronous processes that orchestrate many external services. Testing a process means not only simulating all the services involved, but also simulating all possible return values from all the services, including exceptions, timeouts, retries, and so on. We've seen organizations that spend three times as much time writing test cases as writing code for SOA projects - and these are the projects that have a good handle on a testing approach. We recommend leveraging a rich testing framework that can do more than just a black box simulation for things like BPEL processes. At Oracle, we've worked for several years on such a testing framework that we're now bundling with our BPEL Process Manager product and independent vendors like Parasoft are now coming out with testing tools that have built-in support for SOA standards like BPEL and WS-Addressing.

Summary
Next month we'll look in detail at the best practices for the final four steps: rich user interfaces, business activity monitoring, security and management, and performance and scalability. In the meantime, we hope that the first part of this series has given you sufficient food for thought, if your organization is considering adopting SOA, about how to achieve its promise while minimizing risk and how to leverage the best practices that are emerging. These are non-trivial tasks and even a two-part article such as this won't get very deep below the surface. However, we hope that these topics will spur an ongoing discussion in the IT community about how to best achieve the promise of SOA.