Embedded Platforms to Deliver Messages with Publish and Subscribe Protocol Chung-Min Huang, Chien-Tang Hu Institute of Information Science Academia Sinica Taipei, Taiwan Chi-Sheng Shih ,Hsin-Yi Chen, Zi-You Yeh Department of Computer Science National Taiwan University Taipei, Taiwan Good afternoon everyone. Today I am so glad to represent our team including Prof. Shih, Mr. Huang, Mr. Chen, and Ms. Yeh to share with you our work, called “Embedded platforms to deliver messages with publish and subscription Protocol.

Existing Pub/Sub Service To begin with, I would like to share with you a few existing service on the internet called PubNub and PUSHER. They provide pub/sub service for users to send messages. Thus, using the service, users can easily develop their own applications or systems with publish and subscribe protocol.

Problems of Centralized Service Pub/Sub Service Provider Internet However, these two services rely solely on centralized architecture. The service which is centralized is not suitable for disaster management application. Because , when disaster occurs, there are many factors making users unable to access the servers. For example, when earthquake happened, a falling object would maybe damage the hardware thereby causing the servers to crash. In this case, users cannot access the service anymore. So, this indicates the centralized service is not the solutions for disaster management application. In order to deal with this problem, we built the distributed architecture service so that we can assure users of the reliability of our service. And our service also can provide users to deliver message with Pub/Sub protocol. Publisher & Subscriber Several situations like hardware damage and disaster striking will make users unable to access the service.

Building Brokers with Distributed Architecture Data Source PubSubHubbub Publisher Subscriber So, we built the brokers. As you can see, our broker can be allocated with distributed architecture. I will illustrate it later. Now, I want to introduce our broker. Each broker consists of two components including QPID and Pubsubhubbub or PuSH in short. We use QPID to construct the QPID network by making QPID connect to each other so that users can deliver messages through its networks. Also it provides several client application programming interfaces for users to utilize, but it lacks of the most popular way hypertext transfer protocol, to transfer data. So, This is where PuSH comes in. PuSH provides publish and subscribe service over hypertext transfer protocol. So, to provide the friendly user interface, we combine them as our broker. Broker is designed to deliver messages for different networks. Broker also provides publish and subscribe service.

Deploy Brokers into Different Platforms Cross-compiler As I indicated above, our brokers can be easily allocated with distributed architecture. We just need to deploy our broker into different platforms for distribution of our service and let the platforms to connect to each other to form the QPID network. Until now, QPID already can be run on personal computers. However, There is not any case that run QPID on embedded platforms. In addition, we think embedded platforms are also good solutions to distribute our service because of its advantages like low-hardware cost, low power consumption and easy implementation. We just need to cross-compile the several software like QPID and BOA web server so that we can easily deploy our brokers into embedded platforms. Low hardware cost Low power consumption Easy Implementation

Overview of Broker’s Structure HUB PubSubHubbub Our work middleware Now, I want to talk about how we combine QPID and PuSH together. This is the overview of our broker’s structure. We did not revise the original QPID and PuSH too much. Instead, we take advantages of QPID and PuSH respectively to build our broker. So our team focuses on the development of the middleware. Through this middleware, we can enable PuSH to communicate with QPID. So after finishing this combination, we can use the PuSH’s friendly user interface and QPID’s network to deliver message with Pub/Sub Protocol.

Demonstration of Our Work Data Source Publisher PubSubHubbub This slide shows an example that how we use our service. We use embedded platform to be our broker. It also serves as a subscriber. As you can see, publisher use our QPID network to deliver common alert protocol (CAP) message, and subscriber receives the message through PuSH protocol and it will parse the message and then take the adaptive actions based on the content of the message. For example, the embedded platform displays the information of the disaster on the screen. Embedded platform could be a broker and serve as subscriber. The Broker receives common alert protocol (CAP) message in XML format through QPID network.

Future work Integrate our service with Z-Wave device to automatically control home appliances for safety of people. To sum up, now, we have already used QPID network to deliver CAP message to inform people of coming disaster. And we believe time is critical during emergency time. Therefore, we plan to integrate our service with Z-wave device to automatically control home appliances like power controller or gas meter so that people will have more time to escape when disaster occurs.

If you have any questions, please feel free to contact us Thank You If you have any questions, please feel free to contact us http://openisdm.iis.sinica.edu.tw/ Charles Huang charles.huang@citi.sinica.edu.tw Tom Hu tomhu@iis.sinica.edu.tw That’s all my report. Thank you for your listening.