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. Tweetflows differ from traditional workflows in this regard: strictly speaking, there are constructs that define the begin or the end of a Tweetflow. This is similar to conversations between people. People do not need to indicate the beginning of a conversation – they just start talking to each other. Of course, there are phrases that indicate the begin of a conversation like “hello”, “good morning” or “excuse me”, but are used to indicate the presence of a new speaker and the intention join a conversation with others.
Tweetflows, do not provide this kind of presence operations, because presence is an implicit feature: Tweetflows exploit follower structures thus have already acknowledged the presence of other conversation participants.
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
SR @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 syntax to call a service with Tweetflows consists of a qualifier (SR=service request), an optional user name, the name of the operation, the name of the service, input data and an optional conditional expression in square brackets followed by hashtags:
SR @user operation.Service inputdata [expression] #hashtags
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:
SR @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:
SR @cerridan recommend.Restaurant location=Vienna&date=today&time=20:00
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 attached at the end of the Tweet. For example, the Tweet:
SR @cerridan recommend.Restaurant location=Vienna&date=today&time=20:00 [@ikangai.availability?=true]
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.
SR @cerridan recommend.Restaurant?location=Vienna&date=today&time=20:00
SR @ikangai get.ParkingInfo?location=Vienna&date=today&time=20:00
SR @johannes2112 get.Availability?location=Vienna&date=today&time=20:00
SR @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.