A Communication Middleware with Unified Data Transmission Interface

doi:10.4236/cn.2013.51B009

Paper Menu >>

Journal Menu >>

Communications and Network, 2013, 5, 34-38

doi:10.4236/cn.2013.51B009 Published Online February 2013 (http://www.scirp.org/journal/cn)

A Communication Middleware with Unified Data

Transmission Interface

Yu Zhang, Yuanbing Zhang, Xiangyuan Bu, Chao Zhang

School of Information and Electronics, Beijing Institute of Technology, Beijing, China

Email: [email protected]

Received 2012

ABSTRACT

In a Modern communication network, data exchange become a complex problem because there usually exists a various

data formats due to the diversity and complexity of communication devices. In this paper, a communication middleware

with unified data transmission interface is introduced, which acts as the abstract communication layer in the heteroge-

neous distributed private communication network. Devices within the network only need to interact with the middle-

ware, instead of directly communicate with each other by various protocols and interfaces, which can reduce the com-

plexity and diversity of the heterogeneous network. This article describes the structure and features of the middleware,

and analyses the use of “buffer pool” in message sending and receiving process. The applications of this middleware

can reduce the complexity of heterogeneous network interoperation, and improve communication efficiency.

Keywords: Communication Middleware; Buffer Pool; UDP; XML

1. Introduction

With explosive development of telecommunication tech-

nology, a modern communication network is becoming

more and more convenient and powerful. Meanwhile, it

becomes more and more complex, which brings addi-

tional technical difficulties. For a communication net-

work in a local area which integrates multi abilities, in-

cluding the telecommunication, localization and naviga-

tion, we must make the data transmission and exchange

between any two devices smoothly and reliably [1].

Since the network is composed of various devices with

different protocols and physical layer specifications, to

provide the direct connection between devices through

the physical layer becomes very complicated and costly.

Also, because of different data formats, the quick and

correct data format translation is crucial for the network.

To solve this problem, a communication middleware

with unified data transmission interface is introduced in

this article. Combined with the hardware adaptors, the

middleware acts as an abstract communication layer, and

provides an effective and flexible centralized message

service. It can receive messages from source devices, and

transfer them to the destinations accurately. As a result,

multiple devices within the network only interact with

the middleware through messages, and do not need con-

sidering the format converting or data translating process

[2]. The use of this middleware can greatly reduce the

complexity of device interoperation, and furthermore

improve communication efficiency.

2. Architecture of the Network

In this article, the communication middleware with uni-

fied data transmission interface makes the information

exchange between various devices of the network based

on a logical software bus, so the communication-related

devices only need to establish a direct connection with

the middleware, and can achieve communication with

other ones. Thus, the coupling degree between devices

within the network can be significantly reduced, and data

can be transmitted in a unified way. The architecture and

data flow of the entire communication network are

shown in Figure 1. System data are preserved in XML

format, and then transmitted through UDP protocol [3].

The information of various devices is saved in a system

database, so the middleware can obtain message con-

figuration information by querying the database, and then

transmit messages.

3. Basic Function of the Middleware

3.1. Centralized Message Service

*This work was supported in part by the Ministry of Science and Tech-

nology of the People’s Republic of China under Grant 2011BA-

H05B08.

It is the key service of the middleware. As a transmission

middleware of a large number of received messages, it

Y. ZHANG ET AL. 35

cannot transmit them directly at the same time. Therefore,

the middleware creates a cache folder in the local server,

which is used to save th e received messages temporarily,

and transmit them from here as soon as immediately. The

establishment of cache folder is automatic and immediate,

that is, a message is automatically saved in the temporary

folder when sent to this middleware, and its forwarding

and query are both from here.

3.2. XML Format Messages

If the identifiable message formats of various devices are

not the same, a destination must translate data from

source terminals into a format that it can understan d, and

the translation process will cost a lot of system resource.

So the messages within network are all defined in XML

format, which simplifies the complexity of the transmis-

sion and exchange [4]. The XML file is represented by

some hierarchical elements. An element is defined by a

pair of tags, called the start and end tags. Content be-

tween the pair is the element body, which may contain a

set of child elements. The unified-format message is not

only easy to be transmitted, but also conveniently parsed

out according to certain rules when arriving at destina-

tion, and the message itself will not be changed.

3.3. Loose Coupling

This middleware is loosely coupled with other devices,

that is, it has no knowledge of other separate devices’

definitions. Devices and the middleware do not know

each other’s working process, and the communication

between them is completely achieved by the messages

[5]. As long as the message accords with the structure

regulation, the clients’ requests or the servers’ feedback

service can be realized. Also, should the receiver appli-

cation fail for any reason, the senders can continue unaf-

fected, as the messages they send will simply accumulate

in the message queue for later processing when the re-

ceiver restarts. Loosely coupling middleware platform

can make full use of existing system resource and con-

struct flexibly and effectively. Under the premise of no

more than the equipment load, the middleware can access

a large number of devices, in order to meet the require-

ment of large communication networks; it also can pro-

vide a powerful global informatio n organization al ability,

to reduce the error rate of the network.

3.4. Real-Time Transmission and Real-Time

Response

This middleware uses the UDP protocol to transmit mes-

sages. UDP uses a simple transmission model without

implicit handshaking dialogues for providing reliability,

ordering, or data integrity, that is, a kind of connec-

tionless-oriented data transfer protocol [6]. Compared

with TCP, it has higher transmission efficiency, and is

more applicable to the real-time system. Also, UDP's

stateless nature is also useful for terminals answering

small queries from huge numbers of clients. And it sup-

ports packet broadcast (sending to all on local network)

and multicasting (send to all subscribers), which app ly to

the system with various message types and large trans-

mission capacity.

3.5. Persistent Messages Guarantee Reliable

Transmission

As we know, UDP provides an unreliable service and

datagram may arrive out of order, or go missing without

notice. Therefore, both the sending devices and the mid-

dleware itself, use the programmable interval timer (PIT)

when sending messages. The timer’s interval is set as the

repeat sending time of message, so the same message can

be sent periodically after the timer starts, until the re-

ceivers return a finishing flag, then an interrupt is trig-

gered, and the next message can be transmitted. As a

result, a small amount of message loss will not affect the

information transmission.

4. Architecture of the Middleware

In this communication network, each device can be used

as a message sending or receiving terminal. These ter-

minals are able to widely listen for the location informa-

tion, their own state information, and the unexpected

information in emergency, and then transmit the infor-

mation to this middleware periodically. The middleware

will send them promptly, so as to ensu re that the destina-

tion terminals can receive updated information. The key

architecture of the middleware is shown in Figure 2.

Accurate and timely sending and receiving of mass

data is still the main problem the communication mid-

dleware faced with. To solve the problem, the technology

of “buffer pool” is used in this article, combined with

multicast to send and receive messages [7]. It contains

three key services as follows:

Database

…………

Figure 1. The achitcture and data flow of the communica-

tion network.

Y. ZHANG ET AL.

4.1. Monitoring Control

This module completes the monitoring and receiving

functions. Ensuring to receive messages uninterruptedly,

the receiving port of middleware is always on. Messages

will be automatically received to the local server when

coming to the middleware. In the communication system,

the number of message is large while the sen ding time is

uncertain, so the middleware cannot send all messages at

the same time. Therefore, it is necessary to design a

message receiving buffer pool.

First, some memory space is opened up for receiving

buffer pool, and a receiving-operation-related list, Re-

ceive File Manager List, is set here, whose elements are

the message receiving threads. All the threads are defined

as the objects of the receiving class (Receive File Man-

age). The class relationship diagram of receiving buffer

pool is shown in Figure 3.

The Receive File Unit is defined as a message record.

The Receive File Manager is defined as a message re-

ceiving container class, which contains a dynamic array

object. The Receive File Manager List is defined as a

buffer pool class, that is, the message receiving buffer

pool. As is shown, the buffer pool class, Receive File

Manager List, contains 10 Receive File Manager’s ob-

jects, whose dynamic array object is the Receive File

Unit record.

Buffer pool is a kind of FIFO data structure. When a

new message arrives, the list will automatically check

whether the message exists in the buffer pool. If not, the

message receiving thread will be created and added into

the list; if it existed, new thread will be no long er created.

Starting receiving a message means adding a Receive

File Manager object into the buffer pool Receive File

Manager List. Only when the thread object is added, the

Figure 2. The key achitcture of the middleware.

Figure 3. The class relationship of the receiving buffer pool.

whole message receiving process begins, including the

file identification, unpacking, checking and resume bro-

ken transfer. The message can be completely received by

the middleware only when all of the operations men-

tioned-above finished correctly.

According to the time order, all the monitored message

thread objects will join the receiving buffer pool, which

completes the receiving operation one by one. And then

the threads will be released, so as not to take up too much

system resource. If the thread cannot be access to the

buffer pool timely and normally, the list will automati-

cally detect whether the buffer pool reach es its maximum

capacity. If so, it gives a blocking prompt to the message

senders. Using the buffer pool to manage the receptio n of

messages, no matter how large the volume is, can make

sure them received by the middleware platform orderly

and timely.

4.2. Message Configuration

This module configures the corresponding relationship

between the messages and destinations based on the

background database of the middleware. As the middle-

ware is connected with all communication devices in the

network, its background database has saved all their

connection information, such as IP address and port

number. When a message is received, this module will

configure its transmission ro uting acco rding to its tag and

information of the receiver. When the receiver estab-

lishes a connection with the middleware, this message

will be transmitted according to the configured routing.

4.3. Transmission Control

This module completes the message transmission func-

tion. Similar to the monitoring module, it uses connect-

ing buffer pool to manage the terminals. That is, a Udp-

Send List buffer pool is defined to manage all the Udp-

Send objects. The class relationship diagram of sending

buffer pool is shown in Figure 4.

Figure 4. The class relationship of the sending buffer pool.

Y. ZHANG ET AL.

Figure 5. The implementation of the middleware.

When the middleware is connecting with a terminal, it

will create a UdpSend object to package IP address, port

number and any other properties of UDP connection, and

add it to th e UdpSendList buffer pool. The b uffer pool is

conducive for the middleware to judge a terminal is on-

line or not. The terminal’s UdpSend object in the list

means it online, and the next sending operation can start.

When there are relatively fewer receiving terminals,

the UDP point-to-point transmission method can be used,

which means the platform operates the UdpSend object

of the UdpSendList directly. However, when sending

messages to a large number of receivers at the same time,

the multicast technology should be used. Before sending

a message, according to message routing configuration,

the middleware platform adds all the receivers that need

it into a multicast group. When th e middleware sends the

message to this group, all the receivers will get it. This

multicast group is dynamic, and the involved receivers

are changing depending on the message routing. The

middleware has a repeat sending time to ensure every

message can be sent to the corresponding receiving ter-

minals, and avoid the information omission because of

UDP packet loss.

5. Implementation of the Middleware

The implementation of the middleware is show in Figure

5. The implementation of the middleware contains the in-

terface driver control, routing configuration, traffic moni-

toring, user authority management and log recording.

Therefore, the middleware can connect devices within

the network through different interfaces and protocols,

and the messages from them can be configured according

to the routing and then received and forwarded. The

Figure 5 shows the log of data exchange, in which the

entire work process can be recorded. As is shown, a

sender keeps sending messages to this middleware,

which are processed by the internal buffer pool, and the

receiver can get them accurately and timely. The data

traffic is monitored by the middleware, in case of the

information congestion. Also, users signed in are man-

aged strictly. The middleware realizes the functions

above, and ensu res all of the data not delayed or lost.

6. Conclusions

A unified-data-interface communication middleware is

presented in this paper, which has a kind of centralized

message sending and receiving mechanism, and acts as

the abstract communication layer in a heterogeneous dis-

tributed network. Any two communication devices of the

network do not communicate with each other directly,

but through messages exchanged by the middleware,

then complete the communication functions such as

sending request and receiving service. Therefore, the

coupling degree of network is greatly reduced. Also, uni-

fied data format avoids the consumption of format con-

version, accelerates the flow of data, and thereby in-

creases the efficiency of communication process. With

the lower communication complexity, each device can

focus on their respective functions such as data process-

ing. For a communication network with fixed internal

communication requirements, large data traffic and

higher node mobility, the middleware platform is widely

practical.

Y. ZHANG ET AL.

REFERENCES

[1] A. Tsutsui, H. Maeomiti, R. Kawamura and K. Yata, “An

Adaptive Communication Middleware for Network Ser-

vice Coordination,” In Proceedings of 1st IEEE Consumer

Communications and Network Conference, New York:

IEEE, 2004, pp. 406-411.

[2] J. AI-Jaroodi, N. Mohamed and J. Aziz, “Service Ori-

ented Middleware: Trends and Challenges,” In Proceed-

ings of ITNG2010-7th International Conference on Infor-

mation Techonogy: New Generations, IEEE Computer

Society, 2010, pp. 974-979.

[3] L. Caviglione, G. Ciaccio and V. Gianuzzi, “Architecture

of a Communication Midleware for VANET Applica-

tions,” In Proceedings of the 10th IFIP Annual Mediter-

ranean Ad Hoc Network Workshop, New York: IEEE,

2011, pp. 111-114.

doi:10.1109/Med-Hoc-Net.2011.5970474

[4] V. Schuermann, A. Buda and J. F. Wollert, “XML-based

Middleware Approach for Industral Wireless Communi-

cation Systems,” In Proceedings of 13th IEEE Interna-

tional Conference on Emerging Technologies and Fac-

tory Automation, NJ, USA: IEEE, 2008, pp. 632-639.

doi:10.1109/ETFA.2008.4638463

[5] G. Kitagata, J. Sekiba, T. Suganma, T. Kinoshita and N.

Shiratori, “Communication Mechanism of Loose Coupled

Agents in Fames,” In Proceedings of Seventh Iternational

Comference on Parallel and Distributed System, Los

Alamitos: IEEE Comput. Soc., 2000, pp. 467-472.

[6] G. Gehlen, F. Aijaz and B. Walke, “Mobile Web Service

Communication over UDP,” In Proceedings of IEEE 64th

Vehicular Technology Conferrence, VTC-2006 Fall,

IEEE, 2006, pp. 2876-2880.

[7] J.-Y. Chwng, D. Ferguson, G. Wang, C. Nikolaou and J.

Teng, “Goal-oriented Dynamic Buffer Pool Management

for Data Base Systems,” In Proceedings of First IEEE

International Conference on Engineering of Commplex

Computer Systems, Los Alamitos: IEEE Comput. Soc.

Press, 1995, pp. 191-198.