Communication with the executor

• Initiating the Executor interface that takes as parameter a "node"

      {
        "id": 4,
        "name": "le nom",
        "engine": "shell",
        "artifact": "example/script.sh",
        "args": null,
        "output": null
      },

POST and GET have been implemented

By now: no engine, but a ZMQ interface for communication between the drivers and the executor is in the pipe.

• The orchestrator is effectively calling the executor in the Execute function of a node
• The orchestrator now handle the corss node arguments:; for example, consider those nodes:

      {
        "id": 2,
        "name": "Node1",
        "engine": "shell",
        "artifact": "example/script.sh",
        "args": [
          "-e",
          "get_attribute Noeud1:output1"
        ],
        "output": null
      },
      {
        "id": 3,
        "name": " Node2",
        "engine": "shell",
        "artifact": "example/script.sh",
        "args": null,
        "output": [
        output1: "" 
  ]     
},

When Node2 is executed, depending of the engine, a result in placed in output1, then when Node1 is running, the orchestrator does substitute the get_attribute with the correct value from Node1 before sending it to the executor.