Transient Services

Until now, to run a distributed transient program it was necessary to distribute manually the same copy of the program, compiled for the architecture of the node, then connect each node to a node of the cloud.

A transient program is a single monadic expression that can execute a distributed program seamlessly among many nodes.

This is great for composability, maintainability and readability. But it has two disadvantages:

• It is necessary to distribute, execute and connect manually the application in each computer and
• The program must be almost identical in all nodes, or at least must read the same closure variables which are interchanged to transport closure information (it can even be written in different languages, theoretically)

These two problems are eliminated with transient services. Services can be installed and executed remotely on demand, at runtime by a monitor process. This means that if a program being executed need a service, the cloud will be asked for a suitable node that would install it. If necessary, from sources in a git repository.

After the installation, the application will continue his execution. So the first problem is solved.

A program can invoke services which are completely different programs. So the second problem is solved.

The interaction is with all the effects of the transient monad: It can stream in both directions. A transient service, for example a database, when called by a program, can send messages reactively to the calling program whenever a record is updated. This is not possible with REST services, if not with special web callbacks (webhooks)(*) that must be set at installation time. This generates a callback hell at the distributed level that precludes composability.

This snippet update the register in the remote database and receive a response whenever any node modify it as well:

  do reg <- … 
     reg’ <- callService database reg
     localIO $ putStr “register changed :” >> print reg'

So transient services permits to split an application in independent distributed pieces without loosing power and composability and make fully reactive architectures.

Currently this functionality is under development.

*Note: A REST service with webhooks can be transformed as a transient service by inverting the callback using [react](http://hackage.haskell.org/package/transient-0.4.2/docs/Transient-Base.html#v:react.

The main primitive is callService:

callService:: (Loggable a, Loggable b) => String -> Service -> a  -> Cloud b
callService ident service params 

Service contains the git repository and executable. If this service is running in a know node, it will invoke it. If it is not, It will ask the monitor service (a service in the local machine at a well known port) to install it or to ask the monitor of other node to do it. This depends on the permissions of the node and the ident string. This is a temporal key that must match. It is intended for open cloud environments where people can create ad-hoc clouds weakly coupled.

Successive invocations of the same service can be responded by the service at different locations.