CONCEPTS SUCH AS BPM (business process management), federated computing, and Web services would not exist were it not for
reliable, low-latency networks. Such service-oriented architectures entail calling out to multiple systems. But what happens
when a system or network loses its connection, overloads, or hands back garbled data?
Standard contingency planning is coarse-grained: an entire site, server, or application is failed over. After fail over,
existing sessions (such as database queries and credit card authorizations that were already underway) are usually dropped.
But the coarse-grained contingency model runs aground in a service-oriented design. One server might run five applications
that publish a total of 30 Web services interfaces. If three of those interfaces fail, the availability solution may not know
the application is in trouble.
Database managers and messaging systems use distributed transactions to guard against data loss. It's one thing to roll
back a five-step transaction that fails at step three; but it's quite another to report failure on a 50-step business process
that hangs at step 49. The failure-handling models built into the BPM systems I've used are primitive; rollback is not an
option, and if the state of the entire process is lost (because the orchestration or directory server goes down, for example),
the outcome is unpredictable.
Like the Web itself, Web services should be stateless by design. But already, distributed applications expect servers to
save data from one call to the next. I see plenty of Web services apps that use callbacks to make the application less sensitive
to latency. A callback says, "I'm not going to wait; you call me back when you're done processing my request." It's great
that the application can do other things instead of looping along, awaiting a response, but a Web service can't call you back
if the server fails over before it gets a chance to answer. If the client hiccups and loses its state before the return call,
it won't know what to do with the callback when it arrives. These are critical issues, but tools, infrastructure, and developers
often leave them to chance.
One solution is to use these technologies with their natural limitations in mind. A lengthy BPM workflow should be broken
into subprocesses so it doesn't always have to restart at step 1, and each subprocess' business logic should provide the equivalent
of rollback in the event of failure. All saved state information must be verifiably replicated across redundant servers; a
state-dependent Web service shouldn't report success until replication completes. In other words, applications have to take
ownership of contingency planning.
An alternative, which I actually prefer, is to include complete state data -- even the entire process flow -- in every call.
A callback would have all the data needed to rebuild the state of a restarted client. If it looks like that's too much data
to push around your network, maybe that's a sign that your application is too complex and too dependent on state.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
