Components
Overview of components
A Human Service is comprised of six major components:
A. Factory service
B. Instance service
C. Assignment service
D. Worklist service
E. Notification client
F. Data Entry client
The execution of a Human Service has five major steps:
- Instantiation
- Assignment
- Retrieval
- Data entry
- Completion
The overall relationship between these components and steps is shown in Figure 2. We will discuss each of these major components and major steps in sequence.
Figure 2 Overall pattern of Human Services
Factory service and instance service
Asynchronous Service Access Protocol (ASAP) makes Human Services feasible. ASAP is designed to overcome the instant gratification barrier of HTTP. Normal web services must respond within 60 seconds, or the HTTP connection times out. Many services, such as data mining and chained services, require more than 60 seconds to generate a response. Each service in a chain may individually take less than 60 seconds, but when the services are chained together they the time limit. Most certainly, anything involving a human decision will take more than 60 seconds, as anyone who has stood in line at a coffee shop can attest.
ASAP allows a service to respond to a request, “Where would you like me to send the result when I am done?” There are three types of endpoints to an ASAP service: a Factory service, an Instance service and an Observer service. The requestor sends a request to a Factory service. The Factory service responds with the URI of the Instance service. If the requestor implements the Observer endpoint type (otherwise known as an interface in object oriented parlance), then it can add itself as an observer to the Instance service to receive notification of any change of state, most notably completion. When the Instance service is complete, it sends the results to the Observer service. If the requestor cannot implement the Observer endpoint type, then the requestor can continually poll the Instance service for its state.
Figure 3 The ASAP endpoint types
A Human Service is an ASAP service. As such, a Human Service has as its first two components a Factory service and an Instance service. What makes it human are the other four components.
Assignment service and worklist service
An Instance service requests an assignment of the task to an individual from an Assignment service. The Assignment service can be very simple and assign all instances of a particular Factory service to a single individual, or it can be complex and balance the assignment of tasks across a pool of individuals. To the Instance service, there is no difference. The Instance service submits its URI to a well known Assignment service and the Assignment service acknowledges the request. By well known, I mean that the association between the Instance service and the Assignment service is specified either in the code of the Instance service or in the Instance service deployment environment. Note that the Assignment service implements the ASAP Observer endpoint so that it receives notification of the completion.
The Assignment service notifies a Worklist service of its assignment decision with the URI of the Instance service. The implementation of the Worklist service can be very simple or very complicated, depending on the needs of the deployment, but the interface itself is very simple.
The Assignment service and Worklist service form a decoupling of the user interface from the service. This decoupling even enables multiple user interfaces to be used for the same Human Service.
Notification client and data entry client
The last two components of the Human Service comprise the user interface. The Notification client is any user interface that notifies the human user that he or she has a task to complete. For instance, the Notification client could be a POP email application, an XMPP instant messaging client or a Java portlet. The Human Service does not care so long as the Notification client can communicate with the Worklist service endpoint.
The Notification client has only the URI of the Instance service. It is up to us how we build the connection between the Notification client and the Data Entry client. We may have the notification and data entry inside a Java-based web portal, or we may have it as a simple LAMP application, or maybe we build it all as an Eclipse Rich Client Platform. In fact, we could build all three implementations for the same task if we so desired.
The Data Entry client is really where the rubber meets the road. It is the objective of Human Services for us to integrate this user interface into the SOA. Some readers might be frustrated by how openly I have defined the user interface implementation. The point is that the user interface is now decoupled from the service. Using the Human Service pattern we can put any user interface into a SOA so long as it conforms with the basic endpoints specifications.