JES Software Bus

JES software bus is the highway of the JES software system. All inter-process communications are managed and handled by the bus. The JES bus is implemented by ‘jbus’. ‘jbus’ defines four roles: publisher, subscriber, requester and replier. ‘jbus’ addresses the communication problems of different processes that run on the same TIYcam. In a good design system, generally there will be no data missing, and we can treat it as a reliable communication mechanism.

The publisher is only responsible to publish the message to the bus, and is not responsible for the successful delivery of the message to the subscriber. The subscriber only subscribes to the messages that it is interested in. Among publishers and subscribers, there are a special publisher and subscriber: BROADCAST (the interface is JBUS_INTERFACE_BROADCAST. When one application wants to broadcast message, it has to create a BROADCAST publisher, and when one application wants to receive the broadcast message, it has to create a BROADCAST subscriber. BROADCAST is defined by ‘jbus’, it implementation is no different from normal publisher and subscriber.

The requester sends request, and waiting for the response from the replier. In implementation, these two steps are separated, so that the application can choose Blocked or unblocked way to receive the response. In most cases, the application needs to finish the request and response in blocked way. This procedure is more like a function call. The replier creates service request and responds to the requester.

jbus interface reference

jbus global operation:

  • jbus_init: initialization of jbus
  • jbus_cleanup: release and clean the resources used by jbus

Operations of the publisher:

  • jbus_create_publisher: create a publisher
  • jbus_destroy_publisher: destroy a publisher
  • jbus_publish: publish

Operations of the subscriber:

  • jbus_create_subscriber: create a subscriber
  • jbus_destroy_subscriber: destroy a subscriber
  • jbu_sub_set_callback: set the callback function of the scubscriber

Operations of the requester:

  • jbus_create_requester: create a requester
  • jbus_destroy_requester: destroy a requester
  • jbus_req_set_timeout: set the timeout of reponse
  • jbus_request: request
  • jbus_req_get_reply: obtain response

Operations of the replier:

  • jbus_create_replier: create a replier
  • jbus_destroy_replier: destroy a replier
  • jbus_rep_set_callback: set the callback function of the replier
  • jbus_reply: reply

Usage example:

For sensing applications, the camera collects temperature, humidity, atmospheric pressure, voltage and current ampere. These data are classified into two classes: environment and electric. The publish message can be published according to these two classes:

Interface: sensor.environment, sensor.electric

Name: temperature, humidity, atmospheric_pressure, voltage, ampere

Create publisher:

jbus_pub_t *sub_env = jbus_create_publish(hdl, "sensor.environment");
jbus_pub_t *sub_ele = jbus_create_publish(hdl, "sensor.electric");

Publish message:

    int ret;
    float value = 25.8; // 25.8°C
    ret = jbus_publish(sub_env, “temperature”, &value, sizeof(value));
    value = 52.6; // 52.6%
    ret = jbus_publish(sub_env, “humidity”, &value, sizeof(value));
    value = 3.3; // 3.3V
    ret = jbus_publish(sub_ele, “voltage”, &value, sizeof(value));
    value = 0.562; // 562mA
    ret = jbus_publish(sub_ele, “ampere”, &value, sizeof(value));

We create two publishers according to the message classes. The subscriber can subscribe to the messages based on the classes. If the application doesn’t care about one class, it just doesn’t subscribe to it. It makes the coding concise by publishing and subscribing according to the data class, rather than according to every data.