This is to explain about the extension of IoTivity for Message Queue.
In the current IoTivity, Message Queue Feature was already applied onto the IoTivity Cloud. but there is no API related MQ in stack API of IoTivity. As we support New API related CoAP over MQ. 3rd Party can use it in both D2S and local(D2D). Here we want to show case how Messsage Queue can be added to make more effective IoTivity solution
The extensions enable publish-subscribe communication using a broker node that enables store-and-forward messaging between two or more nodes. Furthermore the extensions facilitate many-to-many communication using CoAP.
Current MQ API is developed for D2S. Local MQ broker is not supported yet. Local MQ Broker will be supported NEW Feature.
1. MQ Discovery
1) When WITH_MQ=PUB is set in build, the resource server can be worked as MQ Publisher. 2) Subscriber find the Resource which can be published through FindResource(..., “oic/res”, ...). 3) DiscoveryPayload of resource server will have isPublish flag of OCResoureceProperty. 4) run MQ broker Discovery. 5) Topic Discovery from MQ Broker which was discoveried in step 4.
2. Subscribe (if there is no target Topic in discoveried Topics)
1) Create new Topic / Subtopic which went to notify to MQ Broker. 2) Subscribe created(interested) Topic to MQ Broker. 3) Subscriber request to Publish (attribute is "req_pub=true") 4) Publisher(App) should handle "req_pub=true". To make easy of management for publish process. IoTivity defined specific API called "requestMQPublish". Actually, There is no mention that how to notify "publish request" to resource server in MQ spec yet. (https://tools.ietf.org/html/draft-koster-core-coap-pubsub-04) However this API will be help us to save network resource. because it doesn't need to publish unnecessarily. 5) Send Response with 2.04 Changed. 6) Start Publish. 7) Response from MQ Broker. 8) Notify to Subscriber from MQ Broker.
3. Subscribe (if there is target Topic in there)
1) Subscribe created(interested) Topic to MQ Broker. 2) Publisher will send pub message when its data is changed. 3) Response from MQ Broker. 4) Notify to Subscriber from MQ Broker.
1) Subscriber request to unscribe(=cancel observe) to MQ Broker. 2) if MQ broker has no sub-member anymore. Topic will be removed. 3) Publisher will send pub message when its data is changed. 4) since there is no sub-member and Topic. error code 4.04 'Not Found' will be sent. 5) Publisher stop publish to MQ Broker after received upper error code.
All 'Topics' is expressed as resource concept which we nomally know. so you can use MQ API like other API of OCResource.
// SUB - subscribe topic OCStackResult subscribeMQTopic(JNIEnv* env, const QueryParamsMap &queryParametersMap, jobject jListener, QualityOfService QoS); OCStackResult unsubscribeMQTopic(QualityOfService QoS); OCStackResult requestMQPublish(JNIEnv* env, const QueryParamsMap &queryParametersMap, jobject jListener, QualityOfService QoS);
// PUB publish topic OCStackResult publishMQTopic(JNIEnv* env, const OCRepresentation &representation, const QueryParamsMap &queryParametersMap, jobject jListener, QualityOfService QoS);
// PUB, SUB, Broker can use these in common OCStackResult discoveryMQTopics(JNIEnv* env, const QueryParamsMap &queryParametersMap, jobject jListener, QualityOfService QoS); OCStackResult createMQTopic(JNIEnv* env, const OCRepresentation &representation, const std::string &targetUri, const QueryParamsMap &queryParametersMap, jobject jListener, QualityOfService QoS);
Linux, Tizen, Arduino Android - You can find sample app related MQ for android in android/examples/simplebase (simplebase app should be built with TARGET_TRANSPORT=ALL)
IoTivity samples can be built using the build option as WITH_MQ
Ex: scons TARGET_OS=linux TARGET_TRANSPORT=ALL RELEASE=0 LOGGING=1 WITH_MQ=SUB,PUB,BROKER
if you input 'PUB' option. it can be worked as Publisher for all resources. and Resource Server also can be Broker with 'BROKER' Option if there is no option. it will be selected 'OFF' automatically.