Services and service discovery


One of the basic concepts in the Spaceify ecosystem is service. Services are the access point to the applications and the methods they expose to the outside world. In Spaceify, connections to the services are preferred to be implemented with WebSockets and messaging with JSON-RPC (JavaScript Object Notation Remote Procedure Call). Applications and spacelets should document their connection methods and protocols whether they use WebSocket JSON-RPC or some custom connectivity or protocol.

Services can either be required or provided. Applications and spacelets do not have to provide or require services. Applications define their provided and required services in their manifests provides_services and requires_services fields. The number of services or the number of methods a service can expose is not limited. A single service can provide all the methods or there can be a separate service for each method.

Services should be named distinctively to avoid name collision. However, same names for provided services can be used among applications and spacelets. When the same service name is used, it should provide the same service regardless of the underlying implementation. The service names must therefore be well documented. Lets say a service name is documented and two applications implement it. Both of these applications should provide the same indoor navigation service but the underlying implementation can be different (e.g. different hardware is used).

There are some security restrictions and exceptions in using WebSocket connections and JSON-RPC requests. See Security model subsection for futher information.

Service discovery

Service discovery in the Spaceify ecosystem is embedded to the Spaceify core. The services can be discoverd directly from the core with the JSON-RPC API or with the methods in the SpaceifyCore class.

The Spaceify ecosystem defines the services as JSON service objects. A service object has the following fields:

service_name: string,
service_type: string,
port: string,
securePort:: string,
ip: string,
unique_name: string,
type: string
Field Desription
service_name Name of the service.
service_type Type of the service.
port The port clients can use to connect to the service.
securePort The secure port clients can use to connect to the service.
ip IP of the container running the application or spacelet exposing the service.
unique_name Unique name of the application or spacelet exposing the service.
type Applications or spacelets type as defined in the manifest type field.

After a service object is discovered it can be used to establish a connection to the application or spacelet providing the service. The IP in the service object is not required to be used to connect to the services. Using the returned port (unsecure or secure) and edges IP is sufficient. Below is a pseudocode example of how a service might be discovered and used to call a RPC method.

service = getService("");
communicator = new RpcCommunicator();
connection = communicator.connect("", service.port);
location = connection.callRpc("getLocation", []);
copyright © 2014