Service composition

Proposal

The goal is to make application as DRY as possible and reusability is something important so why not apply this also for services and compose services based on other services to use an existing service and just build on top of that one to add extra tasks or extra events, create a proxy of this service.

Example

Let’s take the example of Ethereum:

We could have one service Ethereum with the following events with the raw data from the ethereum node:

  • onBlock
  • onTransaction
    And the following tasks:
  • sendTransaction

Based on that we could create a service ethereum contract that would listen for the onTransaction event and check the logs to emit the event:

  • onContractEvent
    and have the task:
  • callContract

Also based on this one we could have another service CryptoKitty or whatever dApp service that would use the contract service for a specific contract and have specific events:

  • onKittyPregnent
  • onBirth

    and tasks:
  • buyKitty
  • getKitty

Solution

I see 2 different ways to do that, let’s take this service that we want to use

name: "Ethereum"
events:
  onTx: ...
tasks:
  sendTx: ....
dependencies:
  app:
    image: mesg/ethereum
  ethereum:
    image: ethereum/geth

Configuration inheritance

When we describe the service we can inherit from another service. Inheritance is not always good but in this case the good point is that it will kind of duplicate the service we wants to inherit from in our service.

Kitty Service

name: "contact"
inherits: "Ethereum"
event:
  onKittyDead: ...
dependencies:
  contract:
    image: mesg/contract

this will result of a service like that

name: "Service B"
events:
  onTx: ...
  onKittyDead: ...
tasks:
  sendTx: ....
dependencies:
  app:
    image: mesg/ethereum
  ethereum:
    image: ethereum/geth
  contract:
    image: mesg/contract

The good point is that we don’t have to write write any extra code if we want also to propagate events/task from service A and our service really includes all the technologies inside it’s own service (like it’s own ethereum node for example) but the problem is that we don’t really reuse and this service will need it’s own network

Use another service

In this case the service definition will only be the events and tasks that you want to expose and you will have as a developer in you service code to connect to the other service through MESG core apis and not directly. This adds an unnecessary communication layer and force us to expose for service some APIs like listenEvent or executeTask and maybe sone security issues with one service that call another one without any authorization. The good point in this case is that we really reuse a service and if this service and its network.

We should also make sure to add it in the description and have the following mesg.yml file like that we can automatically start/stop the services that this service need to use.

name: "contact"
use:
  - "Ethereum"
event:
  onKittyDead: ...
dependencies:
  contract:
    image: mesg/contract