IKANGAI Solutions. e.u.

Designing an “intelligent software Service” (component) that asks for external help has some interesting implications. First and foremost, the actual idea is a variation of the Amazon Mechanical Turk scheme, but with a twist: instead of replacing a Service with a person, we complement a software Service with a person, or as in our case with a crowd of persons. This requires the Service to be member of a certain class of Services which (a) do not require fast responses (in terms of (mili-)seconds) and (b) should be called asynchronously to avoid blocking the caller.
So, where can we find such a type of Service? One example are financial Services that provide the requester with rating information about companies. Calling such a Service can either result in a quick response (the data in the database was just updated and is “good”) or the Service needs to access updated information first, before returning the result to the requester. In the latter case, if the Service “realizes” that it cannot fulfill the request and it “simply” asks for human assistance. The human can update the database with information gathered from different sources that cannot be directly integrated into the Service (e.g., information from news papers). After updating the database, the Service is able to send the respond to the requester. Another example for asking for external assistance is to handle a broken database connection. Here, we require someone to fix the database (e.g., by rebooting it), before the Service can be continued.

On a technical level, we need to address several challenges that are related with the state of the execution of the service. The most important aspect is that we must be able to restart the execution of the Service at any internal state. Consequently, we must be able to track the state and resume the execution where the Service has asked for assistance. For example, if the input parameters does not fit the interface, we must persist the request for a (assisted) transformation and then execute the Service. This requires a pipe and filter approach that encapsulates the actual Service functionality in order to handle this kind of mismatches. Also, if such fixes are implemented by transformations (e.g., with XSLT), we require to persist these transformations and to access them if needed.

The overall idea shares some similarities with escalation handling in BPEL. The key difference is that an intelligent service aims to contain problems locally, i..e, within the service. Consequently, the number of exceptions that are needed to be handled outside of the service is minimized. This allows (at least in theory) to treat an intelligent service as black box that simply can be used without needing paying too much attention to exception and fault handling. Granted, this works only to a certain extend: intelligent services won’t be able to reprogram themselves automatically, but they may be able to ask a developer to do so and to use the code. Of course, automated code execution is tricky: we use ensure that the code is not malicious and thus can break the execution of the service.

your ikangai science team

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