In one of internal technical review meeting, the coder integrate the service into a existed substance/service, but considering of the scalability of this service, I strongly recommended the developer decouple this service from any substance and made them into a self-contained substance in order to provide the service to more clients in the future.

##SOA in practice In the wikipedia page, SOA was needed to meet the following basic rules.

A service has four properties according to one of many definitions of SOA:

• It logically represents a business activity with a specified outcome.
• It is self-contained.
• It is a black box for its consumers.
• It may consist of other underlying services.

In the resource-limited SoC, it maybe not practical to deploy individual service with one standalone process, but it will be possible deploying partly/all services in one process and multiplexed the service using the different domain/interface id.

ubus in Openwrt

ubus is an daemon process for other process/daemons to register themselfs as well as sending messages. The interface is implemented using Unix sockets and use TLV(type-length-value) messages.

Just for example:

By default, list all namespaces registered with the RPC server:

root@uplink:~# ubus list
network
network.device
network.interface.lan
network.interface.loopback
network.interface.wan
root@uplink:~#

If invoked with -v, the procedures and their argument signatures are dumped in addition to the namespace path:

root@uplink:~# ubus -v list network.interface.lan
'network.interface.lan' @099f0c8b
	"up": {  }
	"down": {  }
	"status": {  }
	"prepare": {  }
	"add_device": { "name": "String" }
	"remove_device": { "name": "String" }
	"notify_proto": {  }
	"remove": {  }
	"set_data": {  }
root@uplink:~#

Besides, ubusd define others message handlers as followings:

static const ubus_cmd_cb handlers[__UBUS_MSG_LAST] = {  
[UBUS_MSG_PING] = ubusd_send_pong,  
[UBUS_MSG_ADD_OBJECT] = ubusd_handle_add_object,  
[UBUS_MSG_REMOVE_OBJECT] = ubusd_handle_remove_object,  
[UBUS_MSG_LOOKUP] = ubusd_handle_lookup,  
[UBUS_MSG_INVOKE] = ubusd_handle_invoke,  
[UBUS_MSG_STATUS] = ubusd_handle_response,  
[UBUS_MSG_DATA] = ubusd_handle_response,  
[UBUS_MSG_SUBSCRIBE] = ubusd_handle_add_watch,  
[UBUS_MSG_UNSUBSCRIBE] = ubusd_handle_remove_watch,  
[UBUS_MSG_NOTIFY] = ubusd_handle_notify,  
}; 

how ubus works

The following picture demonstrate the interactive between ubus client 1 and ubus client 2. ubus client 1 register two namespace towards ubusd. In the namespace interface, there are 2 methods getlanip and setlanip for accepting the external actions.

The client can notify all the subscribed clients if the proper event in client need to broadcast.

Practice

License service is a service which provide license information like “what licenses was installed? what capacity did one specified license have?”, and if the license was expired, licenseservice need notify this change to the client, as well as when new license was added. In summary, License service need provide such kinds of services:

1. Get:
   • Service is ready or not.
   • Client can query detailed information on one/several license(s).
2. Set:
   • Add/Remove a license file.
3. Notify:
   • Notify all the registed client(s) about the changes.

During the booting time, coordinator need to start the service firstly, and confirm it’s status is READY, then booting other substances. Each substance need register themselves to the service, some substances only get the license info which they care about, and ready to receive the changes on these licenses.

##END It seems like ubus can’t good support the multi-thread environment, after checking the source code, it was found that it use some global variable to store the value. It need to be re-constructed if used in the multi-thread env.