8.2 The HCloud Platform
8.2.4 Key Components Implementation in HCloud
There are three key components addressed here:
• The MQ is a kind of component that provides an asynchronous communication protocol to achieve independence between the mes- sage sender and the receiver. The queue is utilized for storing the event message generated by a sender (publisher), and all of the lis- teners (subscribers) who are interested in this kind of event can fetch this message to process a predefined routine. All communication parties should follow the same protocol (e.g., advanced MQ protocol) and utilize an available MQ API [16] to operate the queue. It is not nec-
essary that two parties must know each other exists. After a message is inserted into a queue, it will be preserved and not deleted from the MQ until the corresponding subscriber reconnects to the system. Messages can be exchanged on the process, application, or even inter- cloud level. The queue resides in the cloud just as an engine to drive the system. In addition, different message heads identify the analysis algorithm and indicate the subsequent behaviors of the cloud. • The plug-in algorithm framework is developed with respect to the extend-
ability of various services, which is based on the publish/subscribe mechanism to provide customized functions conveniently, not only for health care but also for other services. The whole system can reduce the module coupling by adopting this algorithm. For instance, various data-mining algorithms, such as analysis of peripheral vas- cular function, instantaneous heart rate, chaotic characteristics of the power spectral density, and so on, should be adopted to perform automatically according to different analyzed signals. Every differ- ent function can subscribe to the different themes of the message, which is classified by a message head. In other words, using such Publish/Subscribe mechanisms, different mining functions can be called on by listening to the corresponding types of message the func- tion is interested in. Accordingly, we designed an abstract core class named the CoreStubClass, including a private attribute analysisKind and an abstract method handleRequest(int). This class communicates with Message via MQ, and the other kinds of concrete implementation classes extended the CoreInterface (e.g., SignalFilterCore, ECGAnalysisCore and other data-mining classes). Figure 8.5 shows the class framework of the plug-in algorithm.
• Distributed storage is the basis of cloud storage. The structural model of cloud storage is composed of four layers: the storage layer, the platform management layer, the application interface, and the access layer, as shown in Figure 8.6.
The core layer is the platform management layer, which ensures the reli- able storage and efficient access of the large amounts of semistructured or
unstructured health documents, as well as miscellaneous signal files, with the power of NoSQL databases and distributed file systems. A NoSQL database is easy to integrate into distributed file systems. For instance, the Hadoop Distributed File System (HDFS) and Google’s Cluster File System (GlusterFS) all have friendly interfaces to NoSQL databases such as Cassandra, MongoDB, and HBase. Moreover, sharding is another major characteristic of this distributed database to gain increased availability. Redundancy among these pieces of shards and different views of the same data provide consis- tency to a large extent. This mechanism can guarantee the integration of global data and transparency to users. For large and distributed storage, this architecture provides more convenience for data retrieval with better scalability as well as stability and persistency.
Network Access, User Authetication, Rights Management
}
AccessLayer API, Application, Web Service . . .}
ApplicationInterface Distributed File System, Grid Computing Content Distribu- tion, Deletion of Replcated Data, Data Compression Data Encryption, Data Backup, Data Disaster Tolerance}
Platform Management Layer Virtualization, Centralized Management, Monitoring, ...}
Storage Layer Storage DevicesFIGURE 8.6
Four-layer concept model of cloud storage. (Redrawn from Fan, X., He, C., Cai, Y. and Li, Y., in IEEE CloudCom 2012, Taipei, December 3–6, 2012, 705–710.)
...
+handleRequest (in msg: Message) +handleRequest (in msg: Message)
OtherCore PPGAnalysisCore
+handleRequest (in msg: Message) ECGAnalysisCore +handleRequest (in msg: Message)
SignalFilterCore
+handleRequest (in msg: Message) : void
<<interface>> CoreInterface +getMsg () : Message Message msgID : int FIGURE 8.5
Plug-in algorithm framework. (Redrawn from He, C., Fan, X., and Li, Y., IEEE Transactions on Biomedical Engineering 60, no. 1 (January 2013): 230–234.)
A parallel computing framework based on the Map-Reduce framework should be combined with the data stored in the NoSQL database (e.g., MongoDB) to deliver complex analytics, and data processing for such physiological data processing is always bound to the CPU (central processing unit). The map function can be designed to handle part of the data, while the reduce func- tion is to merge the output produced by the map function and then output all of the filtered results. According to our six-layer HCloud, MQ can be uti- lized as a scheduler to cooperate with the Map-Reduce scheme. Generally, data analysis flow on this scheme can be described as in Table 8.1. Please note that this algorithm is a recursive procedure. The constant SIZE is a threshold according to the different scales of physiological data processing, which indicates the Map-Reduce procedure is to merge with the size of data scale. It will not be finished until all files are generated by the threshold of SIZE. Hadoop and the Map-Reduce programming paradigm already have a substantial base in the bioinformatics community [17] (e.g., monitoring of
long-term ECG for individuals). The next section introduces the details of the ECG data process with this paradigm.
TABLE 8.1 Algorithm of MQonMapReduce Input: iSize,oSize Output: Boolean BEGIN initial a thread
while (message from MQ is Null) if (message is DONE) return true;
// DONE is a particular message from MQ else
loop;
load Mapper(message)
// parallel Map function for data processing and analysis according to different message
iSize←sizeof (files of input directory)
//compute the total size of files under input directory if iSize>SIZE
MQonMapReduce(iSize, oSize);
//immerge trivial input files to a larger one else {
oSize←sizeof(output directory)
//compute the total size of files under output directory if oSize>SIZE
MQonMapReduce(iSize, oSize);
//immerge trivial output files to a larger one else
send a message DONE to MQ;
// process of all data are accomplished; } END