Development of Massive Data Transferring Method for UPnP based Robot Middleware

Transcription

1 Development of Massive Data Transferring Method for UPnP based Robot Middleware Kyung San Kim, Sang Chul Ahn, Yong-Moo Kwon, Heedong Ko, and Hyoung-Gon Kim Imaging Media Research Center Korea Institute of Science and Technology (KIST) 39-1 Hawolgok-dong, Sungbuk-gu, Seoul , Korea Abstract The research to utilize UPnP as a network based robot middleware platform is in progress. For networked robot components, there is a need to transfer massive data such as multimedia contents. However, since the UPnP technology is using SOAP messages, it is not efficient to send bulky binary data in UPnP messages. In order to overcome the weak point, this paper proposes UPnP-MTOM, MTOM (message Transmission Optimization Mechanism) implementation over UPnP, as an effective way for bulky data transmission with UPnP messages. This paper presents our implementation method and experimental results of UPnP-MTOM implementation. Keywords Robot Middleware, UPnP, SOAP, MTOM 1. Introduction There are many ongoing researches for advanced robot technologies in various industrial and research fields. Accordingly, robot technologies have increasingly become technology-intensive and high performance-oriented more and more. Of all the robot technologies, robot middleware is the one of the most significant research domains for integrated robot system development. It is because many robot researches have adopted component based programming approach for integration of robot technologies, and that middleware is at the core of the integration. In many cases, a robot that is composed of many components is making itself distributed environment. Components can be added or disappear dynamically in the robot system. UPnP is a middleware that assists dynamic service connection and interoperation based on distributed, open networking architecture. These characteristics of UPnP are suitable for robot system and service operating environment, and there is a research to use UPnP technology for robot middleware[1,2]. The components of intelligent service robots or humanoid robots, such as object recognition, voice recognition, 3-dimensional image processing, sensor data processing and data logging, usually generate massive multimedia data. When robot software components {kskim,asc,ymk,ko,hgk}@imrc.kist.re.kr communicate each other, massive data need to be transferred for their communication at any time. According to the UPnP Forum, original UPnP protocol, however, was obviously designed for communication of control signals between UPnP components. Namely, UPnP middleware architecture presumes that when communicating with each other, sending and receiving data are not massive binary data but small data that can be easily encoded into XML texts. Instead, if data is bulky, we can use UPnP AV style mechanism, where the bulky data is transferred by another protocol while UPnP control is used for transmission control. Therefore, it follows that it is inefficient to transfer massive binary data by original UPnP's transporting mechanism. In this paper, we propose to utilize MTOM technology over UPnP based robot middleware platform as an optimized data transfer mechanism for handing large binary data used in robot components. The MTOM technology, recommended by W3C, is an optimized approach for transferring huge data over SOAP, as a standard for binary data transmission over web service since In this paper, we describe our implementation method and implementation result of UPnP-MTOM components. 1.1 UPnP The UPnP (Universial Plug and Play) technology is middleware architecture that extends former PNP(Plug-and-Play) conception to network-based dynamic service linkage. The UPnP architecture provides non-fixed, distributed computing infrastructure for UPnP components: control point and device. Once UPnP components appear on a network, one component can recognize one or more counterparts without additional configuration and communicate with other components. UPnP networking stages consist of six phases. Through Addressing, Discovery, and Description stages, UPnP components come to end initial recognizing state. After that, the components realize RPC mechanism for services, or they retrieve and present the current status of the services by repeating Control/Eventing/Presentation stages. 185

2 UPnP architecture is designed by using standardized protocols and web technologies such as TCP/IP, UDP, SSDP, SOAP, GENA, HTMP, and XML. Of these component technologies, SOAP (Simple Object Access Protocol) and XML based standard web technology to substantiate RPC mechanism, is independent of any programming language, system platform, and it is embodied over HTTP. In UPnP control stage, Control Points and Devices use the SOAP technology[3]. Figure 1 reveals the underlying protocol of communication at UPnP control stage. XML message into XOP packages. The other procedure is to bind the XOP package with HTTP protocol layer. The MTOM encoded message, the result of those procedures, is classified into four segments: 1)HTTP Binding Header, 2)MIME Root Header, 3)XOP XML Document, and 4)binary stream area. Figure 2 depicts the MTOM encoded message. MTOM decoding procedure is composed of reverse two stages. First, a receiving UPnP component recognizes an MTOM encoded message, and compares the arriving message with predefined HTTP header to perceive whether the message was encoded as MTOM form. If it is an MTOM encoded message, XOP message is extracted. Second, for the XOP message, deserialization procedure is executed, which separates SOAP envelope message with binary data area. Fig. 1 UPnP Control Stage Protocol Stack 1.2 MTOM MTOM (Message Transmission Optimization Mechanism), proposed and announced in January 2005 by W3C (World Wide Web Consortium), is a mechanism for transferring massive binary data upon SOAP. The MTOM introduced its own data encoding methodology to optimize the process of binary data transferring, using SOAP and MIME technology[4] as its component techniques. In the ordinary SOAP binary data attachment mechanism, binary data that need to be sent must be encoded into text data before starting transmission[5]. However, the MTOM technology has got rid of such dispensable workload. Serializing ordinary SOAP into XOP(XML-binary Optimized Package) form, MTOM not only appends XML information that describes the binary data's property such as unique identifier and data size, but also encapsulates attached binary data in MIME format[6]. 2. UPnP-MTOM In this paper, we enhance original UPnP by adding MTOM mechanism for large binary data transmission, and will call it "UPnP-MTOM"(Extended UPnP with Optimized-Binary Data Attachment) in the following text. With the UPnP-MTOM, UPnP components come to have the ability to process large data being sent and received in control stage. 2.1 MTOM-ENCODING/DECODING MTOM encoding procedure consists of two procedures. The procedures are implemented by any UPnP component, namely a control point or a device, which is going to send massive binary data. The first procedure is called "Serialization". This procedure changes original SOAP Fig. 2 MTOM Encoded Message XOP Serialization/Deserialization As we partly mentioned above, XOP Serialization is the process of transforming original SOAP XML messages into a XOP package. As a UPnP-MTOM component commences the transferring of massive data, a XOP message will be generated with the XOP serialization procedure which encodes sending data hierarchically by passing through UPnP, SOAP and HTTP. Deserialization process disintegrates the XOP message into original SOAP. Figure 3 abstracts these concepts. 186

3 Fig. 3 XOP serialization/deserialization[6] The XOP package consists of three segments: MIME Root Header, XOP XML Document, and binary data stream. In each segment, particular information is involved as the unique identifier of the data being attached. First, In the MIME root header segment, some notations must be written during XOP serialization. Table 1 describes such notations. Fig. 4 MTOM deserialization Flowchart HTTP MIME BINDING Table 1 MTOM MIME ROOT Header notations MIME Field content-type type content-transfer-encoding content-id Value application/xop+xml application/soap+xml(soap 1.2) text/xml (SOAP1.1) Binary must be identical with the 'start' field of HTTP head Second, in the XOP XML Document segment, new XML element, attribute, xml namespace information must be appended into ordinary SOAP message. In the information, <INCLUDE> XML element involves the describing information of binary data. <INCLUDE> element involves both an XML namespace and an attribute. Dedicated XML namespace must be specified on the element as ' 'HREF' XML attribute presents unique ID about the data. Lastly, binary stream data segment follows. This segment involves boundary field, MIME data header, and binary data area, repeating as many as attached data chunks. Ordinary binary data are not altered at all. When XOP Package data arrive to the receiving component, the receiver parses XOP XML document, and extracts attached binary data through XOP deserialization process. With the procedure of the XOP deserialization, it is possible to obtain information such as the number of attached data and unique ID (CID). Later, such information is used to extract binary data from optimized content segment. Figure 4 describes MTOM deserialization procedure in a flowchart form. Like Original SOAP, MTOM also utilizes HTTP protocol for transmission. For MTOM encoding data communication, all values of HTTP header field must be the same to the predefined constant values. Table 2 presents the set of HTTP binding rules to transfer data with MTOM while building SOAP message. Table 2 MTOM HTTP Binding Field content-type Type startinfo boundary start Value multipart/related application/xop+xml application/soap+xml (for SOAP 1.2) text/xml (for SOAP 1.1) MIME boundary string SOAP start tag location 2.2 MTOM implementation upon UPnP In the implementation we decided to attach the MTOM mechanism to UPnP control messages. In UPnP Control stage, UPnP Components which comply with UPnP-MTOM should be able to deal with massive binary data. UPnP Control stage comprises ActionRequest and ActionResponse procedures using SOAP. In the ActionRequest procedure, a control point requests the execution of an action to a device. In the ActionResponse procedure, the device executes the requested action, and returns the result of the execution to the control point. Figure 5 exhibits SOAP XML envelopes for ActionRequest and ActionResponse. If UPnP components send bulky binary data, MTOM encoding procedures will be applied by UPnP-MTOM middleware to the SOAP XML message not only of ActionRequest but also of 187

4 ActionResponse. The message will be encoded by means of XOP SERIALIZATION and HTTP binding mentioned above. Then, the MTOM encoded message is transferred to a counterpart by below protocols such as HTTP and TCP/IP. When UPnP-MTOM middleware at the counterpart component receives data chunks through HTTP, it checks up the content-type field within HTTP header and analyzes whether the message is MTOM encoded data or not. For MTOM case, the middleware proceeds to XOP deserialization procedure, and extracts actual binary data. At last, the extracted data are delivered to the user program as binary data. Figure 6 shows the location of MTOM processing in the data transmission. 3. IMPLEMENTATION AND EXPERIMENT This section describes the experiment of data transfer with UPnP-MTOM. We have developed UPnP control point and device using UPnP-MTOM to test data communication. The test environment is described in Table 3. Table 3 Test System Specification Control Point OS Fedora 5(Linux Kernel ) CPU Pentium Dual Core 3GHz Memory Network I/F 1GB Gigabit Ethernet NIC Device OS Fedora 5(VM,Linux Kernel ) CPU Memory Network I/F Pentium 2.4GHz 512MB Gigabit Ethernet NIC Fig. 5 SOAP XML envelopes for ActionRequest (upper) and ActionResponse (lower) Fig. 7 Request-response diagram between UPnP-MTOM components Fig. 6 The protocol stack of UPnP-MTOM communication When we implemented MTOM mechanism, we needed to consider SOAP version since there are two schemes of MTOM according to SOAP version. Originally the W3C published MTOM over SOAP/1.2 version. But, later the specification to adopt MTOM over SOAP/1.1 version was released[7]. We chose to implement MTOM over SOAP/1.1 because it is of better interoperability[8] We estimate time interval over and over between the start of sending ActionRequest message by the control point and the end of processing ActionResponse message on the control point. Figure 7 describes this process. To illustrate, at first, the control point sends ActionRequest to the device, then the device receives the message and sends a response message, ActionReponse, with 15MByte data. The data is encoded by MTOM. Then, the control point receives the message, and decodes MTOM message for extracting meaningful binary data. Lastly the accessible binary data moves up to application program at the control point side. Average response time of this experiment was seconds. We also performed three more similar 188

5 experiments, two of which are uni-directional cases and the other is bi-directional case. In all the experiments, our UPnP-MTOM works well and bulky binary data were transferred successfully. Therefore, we could confirm successful implementation of the UPnP-MTOM combination. 4. DISCUSSION AND CONCLUSION Due to its dynamic, service-oriented characteristics the UPnP technology is appropriate for distributed middleware of adaptable robots where components can be dynamically changed. In the meanwhile, some distributed robot components can create bulky binary contents like Audio/Video data. These data should be transferred among robot components for proper processing. In order to obtain high-performance processing, the data transmission should be optimized. However, since the UPnP technology is using SOAP messages, it is not efficient to send bulky binary data in UPnP messages. To circumvent it, we have proposed to combine the UPnP architecture with MTOM mechanism. The MTOM is a method to send binary data with a SOAP message. Actually MTOM mechanism was suggested by W3C and has been used in web services which suffered from similar problem. We have implemented UPnP-MTOM middleware, which makes it possible to attach binary data directly to UPnP control messages. In the UPnP control stage, UPnP-MTOM components are able to send and receive massive binary data. Building a SOAP request or response message of a device s action, a UPnP-MTOM component encodes massive data into the MTOM message form through XOP serialization and HTTP binding procedures. Once the MTOM encoded message arrives a counterpart UPnP component, the binary data are extracted through inverse operation. By combining the UPnP architecture with MTOM mechanism, we could make up for the weak point of the UPnP as robot middleware while preserving strong points. Acknowledgements This work is supported in part by Korea MKE through Development of Robot S/W Framework Technology Project and the Intelligent Robotics Development Project, one of the 21st Century Frontier R&D Programs. References [1] Sang Chul Ahn, Jin Hak Kim, Kiwoong Lim, Heedong Ko, Yong-Moo Kwon, and Hyoung-Gon Kim, "UPnP Approach for Robot Middleware," ICRA 2005, Apr [2] Sang Chul Ahn, Ki-Woong Lim, Jung-Woo Lee, Heedong Ko, Yong-Moo Kwon and Hyung-Gon Kim, Requirements to UPnP for Robot Middleware, IROS 2006, OCT [3] Michael Jeronimo, Jack Weast, UPnP Design by Example, Intel Press, 2003, P.111. [4] RFC2045, [5] IBM, htm [6] W3C, [7] W3C, [8] W3C,