If you build a Software Service, you typically build it to satisfy a set of requirements. However, the longer a Service is in use, the higher the possibility that the Service faces different requirements than originally anticipated and eventually fails. Put differently: a Software Service is as intelligent and flexible as the developer wants it to be and is able to foresee its actual application.
A colleague of mine, Daniel Schall, described in his dissertation Human Provided Services (HPS) which are Services that hide people which provide a Service behind a well defined (WSDL) interface. This allows us to integrate people into business processes that can be modeled with dedicated languages like BPEL and later executed with a workflow engine. An important aspect of this approach is that, humans a (normally) intelligent and are able to handle exceptions quite well: they can adapt to new requirements without breaking the Service they provide.
Now, building on the concept of HPS and human flexibility, I’m considering to integrate human assistance into Software Services. This would mean that a Service asks a human for help if it is not able to perform a certain task. To give you an example, suppose you have a Service that calculates the distance between two locations. The Service expects as input two addresses and if one of the addresses happens to be incomplete (e.g., a street name is missing), it does not work. Why is that so? In this case, the designer of the Service didn’t foresee the possibility of having incomplete addresses as input. But, how do we implement a Service that asks for assistance? And, evenly important, which kind of Services can we build this way? Obviously, a Service that needs to respond within fractions of a second is not candidate for asking for assistance, because this process takes a certain amount of time.
In what follows, I’ll briefly sketch how to actually build a Service that is able to ask for help.
Let’s start our brief investigation with the question how to actually implement a Service that asks for human assistance. Intuitively, it is clear that the Service must speak a language that people can understand. Messages that contain error codes are certainly not enough: this has been done in the past and error message like “Error #3480ff8028″ did not exactly spark an interest in the user in determining the cause of the error (other than some frustration ). I propose to use Tweetflows as communication language: they are structured a manner so that people can understand their meaning (for details on the Tweetflow syntax and the generation of meaningful sentence from Tweetflow please look here). For example, if a Service encounters a problem with some input (leading to an exception), we can the Service send a message like “? format.input inputdata dataformat” asking someone to format the input according to some format the Service is able to handle.
This brings us directly to next challenges: first of all, with who does the Service communicate? Who should be able to answer a request from a Service? A potential solution is to use the social network of the Service provider, and ask them to answer the request of a Service. I’ve discussed the idea of using the social network to discover Services in a previous paper of mine, if you like, you can consult this paper for details.
Second of all, how do we implement a Service in a way that exceptions do not lead to cryptic error messages, but to meaningful Tweetflow requests? Unfortunately, I do not have a definitive answer for this question. My intuition tells me that we need to divide the functionality of a Service into several parts and handle problems there. This requires to consider a Service a pipeline of several pieces of software (components) which have dedicated tasks. For example, there might be a software component that handles the input data and checks it against syntactic constraints. Another component might be responsible for the the access to a database or the calculation of some mathematical functions. This points us into the direction of a programming model that is highly modular. Fortunately, I’ve written a paper with colleagues of mine that can help us with this kind of problem. In the paper (called Programming Evolutionary Web Services) we present a programming model that can be used for this kind of purpose.
The final question to answer is how to react on human input to a request for assistance. Again, this is question of the programming model. I’ve to admit that I do not have an answer to this question (yet), but an answer is closely related to a failure model of a Service. If we are able to define a failure model, we can derive (corrective) activities of the Service with the assistance of the human. I’m aware tat this is still rather fuzzy and needs further elaboration .
So, how do we call this type of Service? Since computer science if full of acronyms (e.g., SOAP, TCP/IP, UDP) I was thinking of AWYCDFYSANWYSCDFY which stands for “Ask what you can do for your software and not what your software can do for you”. This is apparently a bit difficult to remember, so I might to call this approach HASE, which is “human assisted service environment”. If you have a better name for it, please let me know.
your ikangai science team