Skip to main content

Human-Powered Web Services

Posted by johnreynolds on November 18, 2006 at 11:13 AM PST

As SOA has become a more mainstream IT concept... you might even say a more mundane IT concept... there has been a lot of thought put forth on the creation of Composite Applications.... collections of distinct Services that are orchestrated and choreographed together (using BPM technologies) to implement some "higher-level" business functionality.

Many of these Composite Applications need user-interfaces, just like "normal" applications, but fortunately the transition from building a UI on top of objects (often EJBs) to building a UI on top of Services (often Web Services) is generally not that hard for programmers to make. Perhaps the biggest adjustment is in moving from a world where pass-by-reference was possible to a message-oriented world where everything is pass-by-value... but that's not really much of an obstacle for good programmers.

A more subtle aspect of user-interfaces and Composite Applications becomes apparent when you start to consider the Services that make up the applications. Most of the folks that I talk with tend to think of Services as automatons... fully automated tasks carried out by machines. This is especially true when I use the term Web Services... Everybody knows that a Web Service has nothing to do with people, it's just a machine at the "other" end of the line.

I'm going to suggest that conceptually limiting Web Services to automatons is a mistake that has hampered our ability to benefit from all that SOA has to offer. Our shared belief that Web Services are "always" automatons has impacted our conception of Composite Applications and has even impacted the design of most of our development environments (IDEs).

That's a pretty strong statement, so I'd better try to explain myself. Perhaps an example is in order....

Let's say that you are building a Composite Application to process an Order of some sort. Also assume that your customers speak many languages, and that it's necessary to translate each order to a common language before it is processed. To make this process pretty darn simple, let's also assume that Services are available to translate the orders from one language to another. Piece of cake... just funnel the order through the Language Translation Service and you're done.

Any good Service-Oriented IDE (such as NetBeans with the Enterprise Pack ) can handle the above process with ease. The IDE's tools make it relatively simple to orchestrate the process using BPEL, and relatively simple to build a UI on top of the BPEL (it's a Web Service after all). In short-order, you've created your Composite Application and all is well in the world.

So where's the beef? What's wrong with this picture?

Nothing really... until you start to consider the creation of the Language Translation Service with your IDE. Our conception of Web Services as automatons causes few problems when consuming the Services, the problem becomes evident when creating them.

I picked Language Translation on purpose... It's hard. Go out to any of the free translation services, translate this page to another language and back again, and you will see what I mean. Language Translation (at this point in time) is better performed by a person than by a machine.

Here's the previous paragraph translated to Spanish and back to English:

"I chose the translation of the language in intention

Related Topics >>