Skip to main content



We have discussed the six major components of a Human Service. Now we will describe the process by which these components interact in five major steps.

The Instantiation step is pure ASAP. The Requesting service sends a request to the Factory service. The Factory service creates an Instance service and responds to the Requesting service with the URI of the Instance. If the Requesting service implements the Observer endpoint type, then it would add itself as an observer to the Instance service.

Figure 4 Instantiation step


In the Assignment step, the Instance service sends an assignment request to the Assignment service. The correlation between the Instance service and Assignment service is completely arbitrary. That is to say, the implementer decides what Assignment service the Instance service calls. It may be hard coded in the Instance service or perhaps determined by the Instance service container.

The Assignment service acknowledges the request and sends an assignment notification to the appropriate Worklist service. The Assignment service contains the internal logic for which Worklist service to assign the Instance service. The Assignment service can be as complex or simple as the implementer needs.

Figure 5 Assignment step


The human user learns what tasks he must complete through the Retrieval process. The user connects to his Notification client which in turn connects to the Worklist service to retrieve the list of Instance service URIs. The interaction between the Notification client and the Worklist service is a simple SOAP exchange. The protocol and user interface technology between the user and the Notification client, however, can be anything and is completely independent of the Human Service pattern.

The user requests a particular item on his worklist. The notification client fetches the list of data entry URIs, picks the most appropriate one and forwards it to the user.

Figure 6 Retrieval step

Data entry

The next step is Data Entry. Using only an Instance service URI from the Notification client, the user should be able to open a Data Entry client. The specific means of translating a data entry URI into the appropriate Data Entry client is completely up to the implementation of the user interface. For example, an AJAX application will execute this important step completely different than a Visual Basic application.

The Data Entry client sends the request for the context data to the Instance service. The request from the client includes credentials of identification. It may be a simple user name login or it may be a public key exchange. The actual validation is up to the implementation. The critical point, however, is that the Instance service does not handle the validation itself. Instance service asks the Assignment service to validate the credentials of the user. If the Assignment service approves the credentials, then the Instance service sends the initial data to the Data Entry client.

Figure 7 Data entry step


When the user has completed entering the data, the Data Entry client submits the result data to the Instance service. Note that with ASAP and Human Services, the context data and the result data is XML. That XML could easily be a Service Data Object (SDO).

The Instance service once again validates the user with the Assignment service. If okay, the Instance service notifies all of its observers that the service is complete. In ASAP, such a notification includes the result data, which in our case would be the data created by the Data Entry client. The Requesting service and the Assignment service should be observers to the Instance service. The very last step is for the Assignment service to notify the Worklist service to remove the URI from its lists of tasks.

Figure 8 Completion step