Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Keeping BPM on track

SonicXQ 1.5 offers a strong solution for business process management

By Tom Yager, InfoWorld, 10/04/02

Page 2 of 3

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.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.

 

Improve efficiency with Visual Studio(r) 2010 Beta 2. - Microsoft

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.