Keeping BPM on track

It’s easy to identify a poorly planned Web services strategy: it emphasizes technical benefits over business objectives. Merely replacing CORBA, COM (Component Object Model), and EJB (Enterprise JavaBean) interfaces with SOAP (Simple Object Access Protocol) accomplishes little more than the fleeting satisfaction of being buzzword-compliant. A smarter way to proceed is to map your business processes, the way information flows through your company, without considering the capabilities of any particular technology. Then apply the mix of technical solutions that satisfies current needs and adapts to changing requirements. That’s the soul of BPM (business process management).

One solution that meshes nicely with this business-focused approach is SonicXQ from Sonic Software. Sonic’s messaging middleware, SonicMQ, is the leading JMS (Java Message Service) provider for J2EE (Java 2 Platform, Enterprise Edition) application servers. SonicXQ 1.5 combines messaging with routing, process flow orchestration, data transformation, and security services to create a scalable BPM infrastructure. What sets this solution apart is its decentralized approach to automation and effective use of Java, XML, Web services, reliable messaging, scripting, and content-based routing.

SonicXQ earns high marks for doing so much so well. We question Sonic’s portrayal of decentralized orchestration as an intrinsically superior approach. We also found that Sonic’s included tools do little to speed learning or development; an XML-aware text editor might do just as well. But overall, SonicXQ provides developers with a solid set of secure, reliable BPM services. It’s a great place for any Java shop to start with BPM.

SonicXQ proves that enterprise-grade solutions need not be complicated. The software installs quickly and requires little attention. Anyone familiar with XML, messaging, Java, and JavaScript can easily grasp its architecture. The only adjustment that might be required relates to SonicXQ’s abstraction of its underlying plumbing. Experienced Java developers might experience some brief initial frustration that SonicXQ flies at a higher altitude than the J2EE and Web services interfaces they’re accustomed to. It helps to remember that backing away from the low-level APIs gives you the freedom to swap components later without rewriting the app. In this time of fluid standards, such freedoms are essential.

We tested a prerelease edition of SonicXQ 1.5 on a PC server with dual AMD Athlon MP processors, 1GB of RAM, and a 180-GB Seagate Barracuda hard drive. So far, SonicXQ has been certified to run on Solaris, HP-UX, and Windows.

To ease evaluation, Sonic provided us with all the software necessary to install SonicXQ on our Windows 2000 Advanced Server test bed. We were intrigued to find that this evaluation did not require a J2EE server. The software in the evaluation kit reflects a growing bond between Sonic and the Apache open source Java project. Most companies will deploy SonicXQ on a commercial J2EE server. But in time, Sonic’s work with the open source community should reduce or eliminate the bonds linking SonicXQ and SonicMQ to J2EE application servers.

Smart messages

Web services are not impeded by boundaries between programming languages and application server types. BPM solutions are a natural fit for this unfettered connectivity. BPM implemented using Web services can, theoretically, go anywhere and talk to any application.

SonicXQ’s approach to orchestration de-emphasizes central control. No conductor or traffic cop fires events in sequence and coordinates calls to remote services. Instead, SonicXQ imbues each step in the process flow with the intelligence it needs to trigger the next step. Sonic calls this itinerary-based routing.

This technique has several advantages: Failure of a central orchestration engine (or loss of communication with it) won’t bring an entire business process to a halt. The scalability of a process is not limited by the coordinating server’s performance. And a business-to-business partnership doesn’t require that Company B’s systems accept the dictates of the orchestration server running at Company A.

Sonic portrays SonicXQ’s approach as unique. In truth, almost any BPM solution can be configured in a similar fashion. For example, instead of having a central Microsoft BizTalk server drive all the stages in a process flow, you could set up a copy of BizTalk on each server involved in the process. Each BizTalk instance would orchestrate only the process stages running locally, with the last stage of every process being a handoff to the next server. Indeed, what Sonic describes as a decentralized system of self-routing messages can be seen as a network of orchestration servers. What SonicXQ does, and relatively well, is mask the complexity of using and managing such a network.

Rules and boundaries

Unlike some business process automation platforms that let business people define processes and rules, SonicXQ’s tools are aimed at developers. You don’t create a SonicXQ process flow by connecting blocks in a diagram. You hack code. Knowledge of XML, XSLT (Extensible Stylesheet Language Transformation), XPath, JavaScript, and Java is required. SonicXQ’s tools are primitive, but the widespread use of XML and JavaScript gives developers the freedom to select their own tools.

SonicXQ stores JavaScript business rules (which Sonic refers to as content-based routing) in its own directory server. That violates the decentralized model; every SonicXQ server involved in a process must have access to that process’s directory server. This complicates processes that involve other companies or departments, or any untrusted entity. Sonic is working to address this limitation.

SonicXQ can involve non-SonicXQ end points in a process flow. Any application that supports Web services, messaging, or remote invocation can become a stage in a SonicXQ process flow. But once a message passes outside a SonicXQ network, its itinerary is stripped, and SonicXQ temporarily loses track of the process. We don’t count this as a design flaw because there is no cross-vendor standard comparable to itinerary-based routing.

BPM and Web services are rapidly evolving concepts, but both offer such compelling benefits that it’s difficult (and potentially expensive) to wait until standards arrive. It’s easy to pick holes in SonicXQ, but its architecture, approach, and implementation are unquestionably sound. We think SonicXQ fulfills an important role. It helps developers implement BPM solutions without cooking up solutions that may run afoul of standards down the road. We judge it to be at an early-adopter stage, but plenty of companies are rushing to adopt Web services and BPM early. SonicXQ is a safe way for Java shops to put these emerging concepts to practical use.

Source: www.infoworld.com