The Anatomy of Human Powered (web) Services

Human Powered Services (HPS) are the piece of the puzzle that meshes BPM with SOA... With HPS in the mix choreographing Human and Autonomous services is seamless, without HPS in the mix choreographing Human and Autonomous services is a pain.

I've blogged about HPS before...

Human Powered Services are chimeras that combine the features of "Normal" applications with Web Services.

From the perspective of the service consumer, a Human Powered Service (HPS) is just like any other asynchronous web service. The service is invoked, and then at some later time a response is received.

From the perspective of the Human who will provide the service, an HPS is just like any other web-enabled application except for one important detail; HPS applications are always oriented towards satisfying a specific request.

To understand the anatomy of an HPS, it's helpful to compare them to the way we currently use email to implement processes... When someone (like our boss) wants us to do something, they assign us a task by sending us an email request. Our email client notifies us that a new message has arrived, or we check our inboxes for new mail. We open the email, process the request, and then reply to the sender with a result.

The human service provider's interaction with an HPS is essentially the same, except the formats for the request and the response are formally defined... It's similar to receiving a predefined form (such as a PDF form) as an email attachment... or of receiving an email with an embedded link to a web application.

Esther Dyson came very close to defining HPS when she expounded her views on Meta-Mail, but she stayed in the realm of human-only workflow. HPS belongs to the realm where service delivery is immaterial... Human or Autonomous should not matter to the process designer. A more subtle distinction between HPS an meta-mail involves the designer of the service. In the case of emailed tasks, the sender generally designs a one-time service that the receiver should perform... I might create a survey and send it by email to a list of people to get their responses. In HPS, the service provider generally defines the service to be performed, and offers this service to a wide audience. As I said, this is a very subtle distinction, and their is no reason why both models cannot coexist.

To implement an HPS, you need to assemble something like the following conglomeration of parts:

• An asynchronous web service to receive requests.
• A queuing mechanism to keep track of each requests until it is processed.
• An application that a human can use to see the list of pending requests... inclusion of a mechanism for notifying a human (such as email) is a nice touch, but not strictly necessary.
• An application that a human can use to process a specific type of request.
• A mechanism for transferring the results of the processing application back to the asynchronous web service, for delivery to the original requester.

The experienced programmer will note that there is nothing "new" on this list of parts... in fact there are a number of options for implementing each part. It's simply a matter of "some assembly required" and you can roll your own HPS system.

For those of us who are not inclined to reinvent what someone else has probably already invented, the good news is that many workflow and BPM suites have assembled these parts for us... We can easily create processes that include both Human and Autonomous services.

The bad news is that the Human Powered services developed within BPM suites are often imprisoned by those suites. It's often rediculously simple to publish Autonomous services for use outside a specific BPM or Workflow suite... but next to impossible to publish any Human Powered service for external consumption. I dare you to try to create a composite application that choreographs multiple Human Powered Services hosted by competing BPM suites... in fact it's often hard to choreograph multiple HP Services within a single vendor's suite unless they all hosted on a single server cluster.

I suspect that the reason for this lack of support for "free-range" hp Services has more to do with initial focus rather than any technical limitations; Most BPM and Workflow Vendor's focus on implementing processes within a single organization... and you don't really need to develop a "free-range" HPS to solve those problems.

Now imagine a world of where business processes cross organizational boundries. In that world services are performed by many companies, and each company hosts its own services. As a service provider in that world my customers shouldn't care about the user interfaces that my employees use (if any), and I shouldn't care about the user interfaces that my customer's employees use (if any). That's the world where "free-range" HPS makes sense... and I predict that the BPM vendors are going to shift focus to that world very soon... and the pain of implementing an HPS will greatly diminish.