John Reynolds's Blog

November 2006 Archives

Human-Powered Web Services

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:

Try building a Human-Powered Web Service with your IDE. You can do it, but it's tough. You're going to have to cobble together something that links together a human-oriented application with a Web Service, and it's probably not going to be pretty. This "ugliness" really shouldn't be a big surprise, because we've never thought of doing such a thing (maybe "never" is a bit strong... but not very often).

Now that I am spending much more time as a Business Process Guy, I'm finding the need for Human-Powered (Web) Services isn't rare at all. All of the good BPM suites (like Lombardi and Fuego) erase most of the distinctions between creating Human-Powered Services and creating Autonomous Services because most business processes are a mix of both types of Services.

Unfortunately, at this time there aren't widely-adopted standards for Human-Powered Services (HPS)... the BPM suites are proprietary and the concept of a "stand-alone" HPS seems alien. There's a good reason for that... when an HPS is invoked, the Human has to "know" that there is work to be done and that implies a notification mechanism like a task list or email.

I don't want to imply that it will be "easy" to come up with standards for Human-Powered Services... just look at all of the turmoil surrounding "BPEL for People"... but it is time for us to start addressing this class of Service in our IDEs. In this blog entry I have focused mostly on the creation of the HPS... but there are also some issues of consumption (people tend to be much slower than machines).

What it all really boils down to is wider awareness of Process-Oriented concerns... business processes are made up of automated and human-performed tasks, and we need to be able to implement both types of tasks in a manner that allows them to be consumed by a multitude of applications. That's what SOA was really all about in the first place.

The Era of Process-Centric Design

If you follow my postings, then you won't be surprised to learn that I think we are at the dawn of a new era in programming. As with all previous eras... nothing is really new, it's just a point in time where existing good ideas rapidly ascend to a pervasive level of acceptance.

During the Object-Oriented Era, encapsulation, polymorphism, inheritance and reuse were king.... all excellent ideas... But not enough to insure the creation of agile applications... applications that can easily be adapted to meet changing requirements.

Quite frankly, adapting to changing requirements is tough and unless you set some limits and constraints it's never going to get easier... and that's where Process-Centric design comes in.

On our desktops, most of the applications that we know and love are not process-centric. Our word processors, spreadsheets, paint programs and games are marvels of ad-hoc creation where our own whims and preferences guide composition rather than any pre-ordained process. The Object-Oriented paradigm was perfect for creating these sorts of applications, because the OO paradigm sets very few constraints on the developer. Imagination and creativity are the OO developers only limitations.

Imagination and creativity are wonderful things... but a huge percentage of the applications that the world needs are not concerned with creativity and imagination... they are concerned with implementing mundane processes.

Implementing processes within the guidelines OO paradigm is not by itself particularly difficult to do... but the flexibility of OO does not force the developer to implement the process in a manner that will make it relatively easy to modify the process in the future.

Processes constantly change. As businesses grow, as business conditions change, as the whims of the population at large ebb and flow... processes need to change, and the applications that implement the processes are often the limiting factor in how quickly the processes can change.

Get a group of Java EE architects in a room, not the R&D infrastructure and product guys, but the ones who build applications for business groups, and listen to their war stories. We all seem to have the same story about the project from hell which required each developer to know half a dozen diverse technologies to simply modify a screen... JSP or JSF (with embedded AJAX) on top of Struts (but we're migrating to Spring) on top of EJBs on top of a Relational DB (except for the part that uses Hibernate) and the use of JMS at one point and Web Services at another... And by all means don't forget the custom rules-engine and half-a-dozen XML-to-Java-to-SQL libraries.

We've all implemented scores of business processes, but we've implemented them as a loose confederation of somewhat related "point" applications that each implement some aspect of the process (with ad-hoc mechanisms for passing information and process flow), or we have implemented them as uber-monolithic behemoths that are a mess to maintain.

That's where the Process-Centric paradigm "comes to the rescue". It's not a general purpose paradigm, like OO, but it's just as significant. The Process-Centric paradigm imposes order. It is a domain-specific paradigm that first and foremost establishes the Process as the leader. A project may still incorporate diverse technologies, but those technologies have to comply to the dictates of a Process-Centric architecture. If you won't play by the rules, then you can't play.

In the Process-Centric paradigm the Process Definition is decoupled from the Activities that are brought together to implement the Process. Communication between the Process and the Activities, and between the Activities themselves, is through well defined message-oriented interfaces. In essence, the activities are implemented as Services (as in SOA)... but some of the Services are automated, and others are human-powered. Once in the realm of Service implementation, programmer imagination and creativity can once again assert themselves to perform the task in the optimum manner... as long as this creativity doesn't try to short-circuit the process framework.

The end-result should be truly process-centric implementations that are primed for the inevitable process level changes. The programmers do give up significant freedoms, but they end up with fewer hassles down the road, and probably a much improved relationship with their business colleagues.

Both Business and IT folks are tired of the status quo where each side feels besieged by the other... By our very natures there will always be a disconnect between the two sides (we're very different types of people) , but hopefully by introducing an intermediary that we both understand (the process definition) life in the Process-Centric era will be better for all of us.

This work is licensed under a Creative Commons License.