IKANGAI Solutions. e.u.

T F G+ E

Tweetflows Specification – Version 1.1

March 21st, 2011 by Martin

Tweetflows is a lightweight language for the creation of mobile workflows. The design goal is to provide a language which is builds upon SOA principles – applied the mobile domain with regard to crowd sourcing.

Main Concepts

Tweetflows are designed to work in a crowd setting, i.e., they provide structural elements, but do not control the actual execution of the workflow.
Another characteristic of Tweetflows is the treatment of Apps as a services which can be discovered and executed in the crowd. Thus, each mobile phone user becomes a service provider in the crowd.

Language syntax

The syntax of the language is geared towards human readability and operates within the limit of Tweets, i. e., 140 characters. This limits leads to a concise syntax, which matches a simple “Subject Verb Object” command syntax. For example, the Tweet

@ikangai proofread.WebPage http://http://www.ikangai.com/tweetflows-specification-version-1-0

asks the user ikangai for the execution of a (human-provided) “proofread” Service. The input of the Service is the link to the Web page.

Invoking Apps/Services with Tweetflows

The basic syntax to call a service with Tweetflows consists of an optional user name, the name of the operation, the name of the service and input data:

@user operation.Service someurl

Tweetflow emphasize the human readability of Tweetflow Tweets: the basic service invocation syntax translates roughly into a command like sentence like ”Service provider do something with some data if a condition is true”. The example below asks the user johannes2112 to proofread a blogentry which can be found on the ikangai web page http://www.ikangai.com//blog:

@johannes2112 proofread.blogEntry http://www.ikangai.com/blog

The actual service can also be provided by an App that is available to the user on the mobile phone. In such a setting, the user acts as proxy that can be considered as wrapper for Apps. For example, a user might have recommendation App for restaurants on his/hers mobile device. A Service request for a restaurant recommendation triggers the manual execution of such an App:

@cerridan recommend.Restaurant https://maps.google.com/?q=vienna,austria

As shown in the examples above, Service invocations are able to handle single Web resources as input or can use data encoded as query string for input:

inputdata := url | querystring

In contrast to url encoded query strings, Tweetflows do not contain “?” as delimiter of the query string and the service invocation.

Conditional Expressions in Tweetflows

Tweetflow Tweets can make use of simple conditional expressions that are evaluated locally on the device of the user. The expression is simply added after the keyword on in the Tweet. For example, the Tweet:

@cerridan on time=20:00 recommend.Restaurant

asks the user @cerridan (acting as Service provider) for a restaurant recommendation if the user @ikangai is available.

Tweetflow Variables

As in any programming language, variables are used to store values which can be accessed by a symbolical name. Tweetflows provide two types of variables, explicit and implicit. Explicit variables are defined by the user with the following syntax (VA = variable assignment):

VA varname value

value can be assigned with any kind of value, including a link to an external resource. Other users can access the value of the variable using the following syntax:

@user.varname?

In Tweetflows, the combination of service and operation name is treated as an implicit variable. Implicit variables contain the result of the last value of a service operation and can be accessed with the following syntax:

@user.operation.Service?

The Tweet queries the state of the execution of a Service.

@johannes2112.proofread.blogentry?

asks the user @joahnnes2112 to re-tweet the last result of the blogentry proofread service.
Variables can also be created dynamically if users receive a request containing variable names that were previously not in use. For example the request

@ikangai.state?

queries the value of a variable with the name state of the user @ikangai. In this case, the variable is not known to the user, and the user creates a variable representing “state”. It is important to notice that variables are not typed and the interpretation of the value is up to the requestor.

Return Values of Service Invocations and Variables

The service request and variable Tweets return Tweets that contain either the value of the service invocation or the value of the variable. Upon completion, a Tweet containing the SF qualifier with the name of the operation (with the prefix “did”), the name of the service and the result (url or querystring) is posted. The Example blow shows the result of the execution of the proofreading of an ikangai blog entry:

SF @ikangai didProofread.Blogentry http://www.ikangai.com//blog #tweetflows #specification

Status of Service Invocations

The state of long running service operations can be queried by users.

Composing Services with Tweetflows

Open Sequences
Open sequences are consecutive Tweets that contain invocations of services. Each Tweet contains a single invocation of a service. The example below shows an example for an open sequence that consists of four service invocations.

first @cerridan recommend.Restaurant?location=Vienna&date=today&time=20:00
then @ikangai get.ParkingInfo?location=Vienna&date=today&time=20:00
and @johannes2112 get.Availability?location=Vienna&date=today&time=20:00
and @redali75 get.Availability?location=Vienna&date=today&time=20:00

The execution sequence of Services in open sequences is not per-determined. In the example from above, the Services can be executed in any order, since there are no dependencies between them.

Closed Sequences

In contrast to open sequences, closed sequences impose a execution order and a dependency between the Service invocations. Furthermore, closed sequences are able to implicitly pass data from one Service to the next. This is inspired by Unix pipes, where data is passed from one stage to the next:

“[" (Service Request)+ "|" (Service Request)+ "]“

Note that each stage of the Service pipeline can contain more than one Service request. Incoming data is an aggregation of all Services of the predecessor, outgoing data is an aggregation of the execution of all Services of the executing Service pipeline stage.

The example below shows a simple concatenation of two Services, a restaurant recommendation and a availability Service.

[SR @ikangai recommend.restaurant?location=Vienna&date=today&time=20:00 |
SR @johannes2112 get.Availability ]

Strictly speaking, the use of multiple Services in one Service pipeline stage is a combination of closed with open Sequences. In the example below, the recommendation Service is concatenated with two getAvailability Services, which are defined as open sequence and thus can be executed in any order:

[SR @ikangai recommend.restaurant?location=Vienna&date=today&time=20:00 |
SR @johannes2112 get.Availability
SR @ikangai get.Availability]

Service Meta Tweets

Tweetflows provide a set of meta Tweets that can be used for the discovery, publication, delegation and logging of Services.

Service Logging

The Service logging Tweetflow syntax follows the existing Service request/Service response syntax closely. In fact, Service Logging is a mix of both syntax elements. The basic syntax is as follows:

LG @user did[verb]operation.Service [outputdata|inputdata] [expression] #hashtags

@user, verb, input and outputdata as well as expression are optional elements of the Service Logging Tweet. Verb is used to denote the state of the execution of a Service and consists of a set of predefined verbs which define the state of the Service operation:

Begin – The Service has just been invoked and the operation has begun its execution.
Finish – The Service operation has completed its execution. This verb is optional and can also be omitted for brevity.
Cancel – The Service operation has been canceled by the Service provider.

Service Publication
The publication of Services consists of announcing, i.e., tweeting, the availability of a new Service. The corresponding Tweet has the following structure:

SP operation.Service #hashtags

For example, a proofread Service for scientific blogs (in English and Japanese) can be announced as follows:

SP proofread.Blog #science #grammar #english #japanese

Service Discovery

Discovering Services utilizes the Twitter social network structure. The basic idea is to use the Twitter forwarding mechanism (Retweeting) for spreading Service requests. Upon receiving a Service request, the user can decide by analyzing the hashtags if the Service request can be fulfilled or to who the Service request can be forwarded. The syntax is as follows:

RT @user operation.Service inputdata [expression] #hashtags

The @user is optional: it is possible to retweet a Service request without addressing a particular user. This corresponds to undirected spreading of the Service request into the Twitter follower network. If @user is present then the Service request is directed to another Twitter follower.

The example below shows how a proofread Service request is be forwarded to the user johannes2112:

RT @johannes2112 proofread.blogentry http://www.ikangai.com/blog

Service Delegation

The Service delegation principle for Tweetflows bears resemblance to the discovery mechanism. The subtle difference to retweeting Service requests is that delegating Service request is always directed to a particular user that has some obligation to fulfill the Service request.

DS @user operation.Service inputdata [expression] #hashtags

The example below shows how a proofread Service request is be delegated to the user johannes2112:

DS @johannes2112 proofread.blogentry http://www.ikangai.com/blog

Service Rejection

Tweetflows support a rejection mechanism which allow users to simply reject Service requests. In high load situations, users can reject a Service request:

RJ @user operation.Service inputdata [expression] #hashtags

Service Cancellation

It is possible to cancel the invocation of a Service in a Tweetflow. This is done by simply tweeting the original Service request data:

CS @user operation.Service inputdata [expression] #hashtags

Service Replacement

Replacing a Service in a Tweetflow is similar to delegating a Service. The main difference is that the Service (operation) is mapped to another Service (operation):

RS @user operation1.Service1 >> operation2.Service2 inputdata [expression] #hashtags

The @user is optional: if a user name is present, the Service replacement is valid only for the user that is being addressed, otherwise the Service replacement is valid globally.