Cameo was designed taking into account the disadvantages of CORBA. Unlike CORBA which shares data references through a naming service, Cameo shares application instances. This is a real different approach. Thus the applications have the responsibility to organise the sharing of their data through persistent services where Cameo provides patterns for communication. Internally, a Cameo server is written in pure Java 8 so that it only requires a compatible virtual machine for running. That makes it very portable and easy to install. Moreover Cameo application instances are processes started by the server but they can also be started as standalone processes. We take advantage of the continuous Java improvement in its process API to have a unified way to start and monitor processes on different platforms (Linux, Mac OS X, Windows). To organise the network services, we use the robust and reliable ZeroMQ message queue for which a 100% Java implementation called JeroMQ exists. ZeroMQ is not only an open-source library, it also provides a precise documentation on how to use it in different network contexts. For example we followed the recommendations to implement a real synchronised publisher/subscriber pattern. Internally, we use the Protocol Buffers library to serialise and parse messages exchanged by the application instances. Protocol Buffers offers a portable and fast data encoding and decoding. The main feature of a Cameo server is to start and stop applications on the local system. For that, a Cameo server is configured with a list of runnable applications. Each runnable application has a list of attributes so that an application instance can be seen as an enriched system process. We won’t provide all the available attributes here but we can cite:
- Name: String identifier used by clients to start an application instance
- Multiple: yes or no, no meaning that only a single instance of the application can run
- Restart: An application instance is restarted in case of error termination
- Stream: The application publishes its output and error streams to the clients
- Executable: The path to the executable
- Args: The list of arguments that are always passed to the executable
Note that it is really important to make the difference between an application configuration and its instances. Applications have a workflow state shown in the next figure.
Around the Running state, there are the transitional states Starting, Stopping, Killing, Processing Error and the terminal states Success, Stopped, Killed, Error. Once the process of the application is launched, the application has the Starting state. It becomes Running when:
- it remains alive for a certain time, defined as an attribute of the application or,
- the application itself changes its state to Running.
When a client requests the stop of the application, it immediately becomes Stopping until it terminates. At that moment, its state becomes Stopped. Notice that after the crash of an application (segmentation fault in C++ or exception in Java), its state becomes Error. The state changes are all sent to the clients of the application. The messages that are passed between applications can be of any type. Cameo provides binary messages as well as string messages so that the programmer can choose the encoding that can be Protocol Buffers or JSON. Arrays of integer and floating point number are also provided by convenience to speed up the coding. Theses messages can be used in the different communication contexts:
- return value
The return value of an application is implemented with a publisher/subscriber so that any connected client application receives the result. We provide a client API for C++ Java and a Python API is planned.