This monorepository contains the following subprojects:
- exocom-server: the actual bus implementation
- exocom-mock-*: mock implementations of the ExoCom server for testing
- exorelay-*: client SDKs for writing services that talk to ExoCom
- exoservice-*: full-stack frameworks for writing micro-services as pure business logic, i.e. as lambda functions
An Exocom application consists of a number of collaborating services. For example, the todo-application consists of a user service for storing user accounts, a todo service for storing todo items, an html service for exposing the application's functionality via an HTML UI, a rest service for exposing it via a REST API, and a chat service for exposing it via a chatbot.
"User" and "todo" are the role that the respective services play in the application. A role can be played by different service types. For example, you could use the FacebookUserService service type to play the role of the user service for your application in production, and you could use a MockUserService to play the same role for local testing. You can also use the same service type for different roles. For example, you could use a generic MongoService as a quick-and-dirty prototype for both the usersService and the todoService role, since they both store data.
To run the application, Exosphere creates an instance of the message bus, plus an instance of the respective service for each role. Or several instances for load balancing. These instances are called clients (because they are clients of the message bus). Clients have unique names to identify them, for example "web #1", "web #2", etc. Clients communicate via the central message bus, played by the Exocom-Server.
The application configuration file (application.yml) defines
which roles the application contains, and links to the services that play each role
in the different environments (production, development, etc).
This link can be a link to a Docker image of the service
or its source code on Github or locally.
Each service type contains a service configuration file (service.yml),
which defines the message types this service type will send and receive.
A message type specifies the title, payload structure,
and semantic meaning for messages.
Combining the roles from the application configuration and the messages from the service configurations creates the routing information for the application. It specifies which role can send and receive which message type. Based on that routing information, Exocom knows to which service instances (clients) messages sent by other services should be forwarded.
To allow for reusable services, Exocom can perform message translation.
For example, the MongoService above listens to add entry and get entry messages.
When used for the usersService role, however,
it needs to respond to add user and get user messages.
The mapping from add user to add entry is specified in application.yml
and performed at runtime by Exocom.
In production, there can be different protection levels for service roles. Public service roles are visible to the internet, while private roles are located in a separate subnet not visible to the outside world. Exocom let's services of all protection levels communicate.
There are some early versions of exorelay written in Haskall, Java, and Scala that may be useful for reference. See here
-
set up dev environment:
- install Morula
- run
morula all bin/setup
-
run tests for all subprojects:
$ morula all bin/spec -
run tests for changed subprojects (when on a feature branch):
$ morula changed bin/spec
- update the
CHANGELOG.md - run
bin/publish <patch|minor|major>- this will update the versions and add a tag - Travis-CI will publish to NPM and DockerHub