The Grid Workflow Forum
[ start | index | login ]
start > OSyRIS

OSyRIS

Created by m.frincu. Last edited by m.frincu, one year and 59 days ago. Viewed 743 times. #3
[diff] [history] [edit] [rdf]
labels
attachments
OSyRIS (Orchestration System using a Rule based Inference Solution) is an Event-Condition-Action workflow engine. It allows the composition of remotely located tasks based on the SiLK (Simple Language for worKflows) language.

It was partially supported by the >>GiSHEO ESA PECS project. The engine, together with the language were developed to allow image processing compositions. However due to its generality it has been extended beyond this initial scope(e.g., expressing scheduling heuristics).

Tasks can be either Web Services or simple applications which can be accessed by using Message Queues or other available solutions. The choice is left to the user.

OSyRIS is based on >>Drools and every SiLK rule file is converted to Drools rules before being executed. The programming language when handling OSyRIS workflows is Java.

OSyRIS has several characteristics which include:

  1. A simple and fully customisable interface between the SiLK rules and the tasks to be invoked. When using OSyRIS users need only create the SiLK workflow and customise the Executor class. This class handles the actual invocation of the task to be executed as a consequence of a rule firing. Because the class acts as a middle layer between the rules and the tasks users are free of using their own communication protocols when designing and implementing it.
  2. A simple yet expressive workflow language called SiLK for expressing workflows. The language has only one construct in the form of RHS -> LHS | condition, salience where the RHS (Right Hand Side) is made up of tasks that need to be completed before executing the LHS (Left Hand Side) tasks. For this to happen additional optional conditions need to be satisfied. The salience represents the priority of the rule. Constructs such as: sequence, parallel, decision, loop, synchronised split, etc. can be easily derived from it.
  3. Possibility to distribute the workflow across several resources. The communication is based on >>AMQP and uses >>RabbitMQ as message service. The distributed version is called D-OSyRIS.
  4. Self-healing capabilities in case of engine failure.

SiLK is a rule based language which allows tasks to be linked together through inference rules. The language is loosely based on the >>Gamma formalism.

Its key features are:

  1. Rule firing is inherently parallel and non-deterministic. Sequential rule firing can be achieved by using the salience option.
  2. Rule can be grouped in domains. Only one rule domain can be active at any given moment and only rules inside it can fire. Domains can be switched by specifying in the rule inside which domain should the new task be created.
  3. Tasks can have multiple instances. The number of created instances is specified inside the rule. After a rule has been fired, the RHS tasks get consumed. However there are cases in which this behaviour needs to be overridden. SiLK offers this possibility too.
  4. Tasks have attributes and meta-attributes. The former are mandatory, while the latter, besides a small number needed by OSyRIS, are not. When defining custom meta-attributes it is up to the user to handle them properly.
A loose correlation between the Gamma formalism and SiLK would be:
  1. Tasks are atoms.
  2. Task instances represent the number of similar atoms found inside a solution.
  3. Rules represent the chemical reactions.
  4. Rule domains are chemical solutions or cellular membranes.
An example showing a simple workflow contained in two domains is shown next:

# Task definitions.
A := [i1:input, o1:output="initial-output-A", "processing"="oper-A", "instances"="1"];
B := [i1:input, o1:output, "processing"="oper-B"];
C := [i1:input, o1:output, "processing"="oper-C"];
D := [i1:input, o1:output, "processing"="oper-D"];
E := [i1:input, o1:output="output-E", "processing"="oper-A", "instances"="1"];
F := [i1:input, i2:input, o1:output, "processing"="oper-E"];

# A simple loop here in the default domain A[a=o1] -> B[i1=a]; B[b=o1] -> C[i1=b]; C[c=o1] -> A[i1=c] | c < 10; # This rule switches to domain 2 C[c=o1] -> 2:D[i1=c] | c >= 10;

# A simple synchronised join in domain 2. # Task E already exists as it has been defined as having one initial instance 2:D[d=o1],E[e=o1] -> F[i1=d#i2=e];

Links:

>>http://gisheo.info.uvt.ro/trac/wiki/Workflow

References:

  • M. E. Frîncu and D. Petcu, OSyRIS: a Nature Inspired Workflow Engine for Service Oriented Environments, Scalable Computing: Practice and Experience, vol. 11(1), pp. 81-97, 2010 (online: >>http://www.scpe.org/index.php/scpe/article/download/642/265).
  • M. E. Frîncu, D-OSyRIS: A Self-Healing Distributed Workflow Engine, Procs. ISPDC'11, IEEE Computer Press, accepted.
  • M. E. Frîncu, A Method for Distributing Scheduling Heuristics Inside Service Oriented Environments Using a Nature-Inspired Approach, Procs. ISPDC'10, IEEE Computer Press, ISBN 978-0-7695-4120-4, pp. 211–218, 2010 (online: >>http://portal.acm.org/citation.cfm?id=1848318).
  • M. E. Frîncu, S. Panica, M. Neagul, D. Petcu, GiSHEO: On Demand Grid Service-based Platform for Earth Observation Data Processing, Procs. HiperGRID’09, 26-28 May, Politehnica Press, ISSN 2066-4451, pp. 415–422, 2009.
no comments | post comment
gridworkflow.org | Copyright 2005-2008 Fraunhofer FIRST