Programming in the Large based on OSIRIS-PRO (Master Thesis, Finished)
Author
Florian Zeller
Description
OSIRIS can be seen as cloud system that consists of peers which are organized as a peer-to- peer (P2P) network. When more power is needed, more peers can be added to the network. More specifically, OSIRIS is a middleware that allows combining different distributed services into processes. In OSIRIS, a process consists of a set of activities. Each activity corresponds to an invocation of a service. Processes are executed in a decentralized way on the P2P network with each peer running an OSIRIS instance. A peer has a certain set of activities it is able to run. After completing an activity, it forwards the whole process description (a state) to another peer which offers to process the next activity in the process definition. The concept of process composition is also known as “programming in the large”. To do so, a process engineer needs a way to create the process, a process composition language. Today, the predominant composition language in service oriented systems is Web Services Business Process Execution Language (WS-BPEL). Since version 2.0 (2007), it is maintained by the Organization for the Advancement of Structured Information Standards (OASIS). Initially, WS-BPEL (at that time known as BPEL4WS) has been manifested by Microsoft, IBM and others in 2003 [3]. OSIRIS-PRO is an extension of OSIRIS developed at the University of Basel. It consists of a new process execution engine which fits into the OSIRIS environment. A custom programming language to define processes was created and Scala code was introduced which is able to parse these process descriptions. Some of the items discussed in this proposal will influence the custom language, its parsing and execution. This thesis will address the following three areas which will be tightly integrated into OSIRIS Glue Services: The idea of glue services is to be able to generate on-the-fly activities in the process definition. Some activities might be very simple (e.g. one-liners), it would be a bit of an overkill to go the normal way: Create and deploy a component that implements the desired line and finally call it. Instead, the functionality could be embedded inline in the process definition. Inter-branch communication with DHT: OSIRIS-PRO shall be extended with a distributed hash table (DHT) component. This DHT needs to be transactional, i.e. must be able to deal with concurrent access to the same data. Exception handling: To cope with exceptions, exception handling needs to be added to OSIRIS PRO. On the process definition level, an equivalent concept as try/catch from Java could be used to mark critical sections.
Start / End Dates
2011/01/17 - 2011/07/16