Moving Web Services From Minds to Applications

My son’s favorite book is Richard Scarry’s What Do People Do All Day? It brings to life dozens of disciplines, from coal mining to bread making, with charming illustrations. After reading this book for the 80th time, I wondered: What if you could drill down into each step of what people do, including all the procedures when things go awry?

Sadly, Scarry never went that far, so we’re left to document our own business processes?in detail?for developers. Either that or someone in IT tries to match those requirements against shrink-wrapped enterprise software.

Everyone yearns for a perfect middle ground between build and buy. And increasingly, you hear about Web services and service-oriented architecture (SOA) as that ground: Just assemble prebuilt services into enterprise apps and satisfy endless needs. This is, of course, a fairy tale. People are building Web services and creating SOAs, but it’s fantasy if you think you can create an entire enterprise application infrastructure simply by stringing together a bunch of Web services.

Yes, Web services contains business logic, and some even include Web services description language (WSDL) code to tell other programs what that logic will do. But today, Web services usually serve as integration points to full-blown applications, in much the same way application adapters connect proprietary middleware from companies such as Tibco Software, WebMethods and Vitria Technology. There are exceptions, but the true SOAs I’ve seen so far tend to involve fairly narrow applications and employ Corba or Java or COM components, not Web services.

There are two main reasons why Web services isn’t there yet. Most obvious is performance?Web services protocols incur much more overhead than binary communications. Another issue is that homogenous development environments already have lots of tools for modeling business logic. Such tools are at a very early stage for Web services. And there’s a debate in the industry over whether we need business process modeling for Web services at all. Some say that modeling and deploying business logic to orchestrate Web services introduces hopeless complexity.

With a towering stack of draft Web services protocols already making developers dizzy, the “how much more can we take?” question is valid. Business process execution language (BPEL)?the answer proposed by BEA Systems, IBM, Microsoft, SAP and Siebel Systems?takes a page out of conventional EAI solutions, which provide tools for building business logic at a level above that of the apps to be integrated. BPEL (pronounced “beeple”) is now chugging its way through Oasis and purports to give developers a cross-platform method of pulling Web services together into larger, composite Web services applications.

BPEL provides a way to describe the Web services involved in a large, distributed Web services app, plus whatever XML schemata, WSDL, fault handling and constituent processes may be involved. All the big software players have indicated they will eventually build in BPEL support, but among startups, Collaxa stands out: Its BPEL Server 2.0, which should be shipping by the time you read this, is the first BPEL commercial product available. The company also has a visual design tool that functional analysts can use to model business processes and generate BPEL scripts to be consumed by the orchestration server.

BPEL will indeed add complexity at first, and I’m sure that whatever code is generated by Collaxa’s or anyone else’s products will serve largely as a starting point for composite Web services apps?a way for business analysts to explain what they need without writing a book. Without such tools, though, we’ll never realize the promise of Web services as an infrastructure where services can be quickly rolled into apps that actually reflect what people do.