國立臺灣大學電機資訊學院資訊工程學系 博士論文
Department of Computer Science and Information Engineering College of Electrical Engineering and Computer Science
National Taiwan University Doctoral Dissertation
智慧家庭中的情境感知普及服務管理機制 Context-Aware Pervasive Service Management
in Smart Home Environments
廖峻鋒 Chun-Feng Liao
指導教授：傅立成 博士 Advisor: Li-Chen Fu, Ph.D.
中華民國 100 年 6 月
June, 2011
誌謝
博士學位對我來說不但曾經是一個遙不可及的夢想，攻讀的過程也充滿了艱辛。
這樣一個艱鉅的任務，若沒有許多人的指導、支持與協助，是不可能完成的。首 先，要特別感謝指導老師傅立成教授在這幾年的耐心指導，讓我在研究及專業知 識上得以漸入佳境。其次是擔任博士論文口試委員，同時也是碩士班指導老師的 李蔡彥教授，在攻讀學位過程許多重要的基本功是在李老師的指導之下才得以建 立基礎，此外，從碩士班畢業後，老師也持續地給予許多鼓勵與關心。感謝林風 教授、馮明惠所長、陳良弼教授、郭耀煌教授、曾煜棋教授、蘇豐文教授與逄愛 君教授，在百忙之中抽空擔任我的博士論文口試指導委員，並給予許多建議與指 導。也感謝許永真教授、朱浩華教授、林風教授與逄愛君教授擔任論文提案審查 委員，並在撰寫過程中給予許多意見與協助。感謝台大智慧生活科技整合與創新 研究中心劉佩玲主任、陳俊杉副主任與李劍峰博士，讓我有機會將論文中的技術 實際應用到真實的智慧生活空間。此外，也要感謝政大資科系的陳恭教授，論文 在發展初期老師對於方向給予了許多建議和協助。
同時也要感謝實驗室曾給予鼓勵的許多學長與學弟妹，特別是世勳學長，在 口試前還特地抽空遠從高雄來台北幫我進行預演。此外也要感謝博士班學長與同 學們，尤其是兆麟、敬互、益銘、士恒、勇成、宇傑，在與你們互動的過程獲益 良多。亞文和觀音先後與我一同進行研究，為本論文的主要核心奠立紮實的基 礎。此外，宗翰、羽君、慧文、雨喬、茂源及學鴻在論文完成的最後階段協助分 擔、處理了許多繁重的專案與研究事務。
最後要感謝數年來始終在背後支持我的家人，尤其是爸爸、媽媽、佳虹、珮 如、俊璟及佳虹的家人們。也要謝謝小女兒翊亘，總是帶給家人和我無限的希望 與動力。
摘要
智慧家庭主要的願景為透過科技使人們的日常生活更加豐富。此一類型的智慧居 住空間具備推測居住者意向並據以提供適切智慧居家服務的能力。大部份的智慧 居家服務都由許多高異質性的元件所組成。本論文主要的研究目標即在於設計一 組服務管理機制，使得智慧居家服務能夠具備高彈性、強健性、高效能及一致性 的特色。
首 先 ， 系 統 的 彈 性 與 否 大 部 份 取 決 於 其 底 層 之 架 構 型 式 (Architectural Style) ， 在 比 較 過 相 關 系 統 與 文 獻 之 後 可 發 現 訊 息 導 向 中 介 軟 體 架 構 (Message-Oriented Middleware, MOM)是最具備彈性且適合佈署於家庭網路之架 構型式。在另一方面，雖然許多文獻都指出強健性為智慧家庭系統不可或缺之一 環，但可發現在現存研究中對於加強訊息導向架構系統強健性著墨較少。因此，
本論文提出一個兼具彈性與強健性的服務管理架構。本研究以嚴謹的正規程序代 數(Process Algebra)的方式定義了一個可支援自主型組合、錯誤偵測及錯誤回復 之訊息導向服務模型與其通訊協定，並對此一服務模型與協定進行強健性的正規 驗證及實際的回復率與效能測試實驗。
其次，在智慧家庭中，無目錄式服務管理協定(如通用型隨插即用協定)被認 為是較為適合管理智慧家庭服務的機制。此類協定大都以 IP 群播加以實現，但 經常造成網路擁塞的問題。因此，基於前述之訊息導向服務模型，本研究提出一 套可有效降低冗餘封包數量，進而提昇網路效能的機制來改善無目錄式服務管理 協定所造成之網路擁塞的問題。經過分析與網路模擬實驗，可發現二者之間具有 相當高的一致性，且均具備大幅提昇網路效能的效果。
近年來，有不少研究著重於普及服務的組合議題。在組合普及服務之前，使 用者必須先行提出偏好(Preference)，但使用者之偏好不確定性高且可能彼此衝 突。由於居家環境經當變動，也很可能造成所啟動之服務之間的相互衝突。為了
解決這些問題，本研究提出一組可同時表達列舉/可數及必要/可商議概念之偏好 表示式(Preference Expression)。此一機制配合本研究所發展之一套可驗證的邏輯 結合規則(Unification Rules)，可將不一致的使用者偏好表示式整合為一致的表示 式。接下來並提出一套以模糊邏輯為基礎的方法，基於環境式情境資訊，評估已 啟動服務間相互衝突之嚴重程度。經過實驗可發現，藉由整合上述機制，可同時 維持相當高的服務組合之品質及成功率。
最後，本研究整合上述機制進行實作，並實際將多個智慧居家服務佈署於二 個不同智慧實驗屋，以驗證所提出之各項機制之可行性。
關鍵字: 普及計算、通用型隨插即用協定、簡單服務管理協定、智慧家庭、服務 模型、服務發現架構、IP 群播、服務系統、服務組合、使用者偏好。
ABSTRACT
The concept of Smart Home envisions a technology-enriched living space that is capable of anticipating intensions of occupants and providing appropriate services ac- cordingly. Most of the services in such space are context-aware and are realized by an assemblage of heterogeneous components. The objective of this thesis is to design a suite of service management mechanisms that makes such context-aware services flexible, robust, efficient, and consistent.
The flexibility heavily depends on the underlying architecture style. After a thor- ough review on existing representative pervasive systems, it is concluded that the Message-Oriented Middleware (MOM) is one of the most flexible architecture styles for the Smart Home. Meanwhile, robustness is one of the key challenges for the Smart Home, but few researches have been done to improve the robustness of Message- Oriented Smart Home systems. Hence, this research work attempts to propose a flexible and robust service management framework by formally defining an MOM-based ser- vice application model and protocols that facilitate autonomous composition, failure detection and recovery of services. The proposed approach is evaluated by first proving the reliability property and then conducting experiments on recovery rate as well as performance.
Decentralized service management protocols such as UPnP are believed to be more suitable for Smart Homes. These protocols are usually realized by using IP multicast, which, if not carefully designed, often suffer from network flooding problems. This research proposes several efficiency boosting techniques that reduce the replications of unnecessary messages. The analytical predictions agree well with the simulated and experimental results, which show that the traffic can be greatly reduced by the
proposed approaches.
Pervasive service composition also attracts increasing interests. When composing services, the criteria for scoring and electing services are usually specified by users, which tend to be vague and subjective. Moreover, the deployment of services in smart homes is usually not as well-planned as that in traditional enterprise environments.
Hence, the criteria can be contradictory and the activated components can interfere with one another. This thesis addresses these issues by first proposing the Preference Expression that is capable of specifying both enumerative/numeric as well as manda- tory/negotiable preferences. Then, a set of unification rules for unifying conflicting preferences is presented. Finally, this thesis proposes a Fuzzy-based approach to esti- mate the degree of interference based on available context information. By incorporat- ing the above-mentioned mechanisms, an integrated service composition framework is presented. Experiments that evaluate the effectiveness of the proposed framework are also conducted and reported.
Keywords: Pervasive Computing, UPnP, SSDP, Smart Home, Services Models, Services Discovery Architecture, IP Multicast, Service Systems, Service Composition, Feature Interaction, User Preferences.
TABLE OF CONTENTS
Acknowledgements (In Chinese) i
Abstract (In Chinese) iii
Abstract v
Contents vii
List of Figures x
List of Tables xiii
1 Introduction 1
1.1 Research Challenges and Objectives . . . 3
1.2 Contributions . . . 5
1.3 Research Scope . . . 7
1.4 Research Process . . . 8
1.5 Organization . . . 10
2 Background and Related Work 11 2.1 Pervasive Systems . . . 13
2.1.1 The Context Toolkits (CTK) . . . 14
2.1.2 Universal Plug and Play (UPnP) . . . 16
2.1.3 The Gaia Meta-Operating System (Gaia OS) . . . 19
2.1.4 The Aura Platform . . . 21
2.1.5 CoBra (Context Broker Architecture) . . . 23
2.1.6 SOCAM (Service-Oriented Context-Aware Middleware) . . . 24
2.1.7 Tuple Spaces . . . 25
2.1.8 Message-Oriented Middleware (MOM) . . . 26
2.2 Pervasive Service Discovery . . . 29
2.2.1 Service Discovery in CTK . . . 31
2.2.2 Service Discovery in GaiaOS . . . 33
2.2.3 CoBra/JADE Service Discovery . . . 36
2.2.4 Aura/Jini . . . 39
2.2.5 Service Discovery in One.world . . . 41
2.2.6 Bluetooth SDP (Bluetooth’s Service Discovery Protocol) . . . . 42
2.2.7 Simple Service Discovery Protocol (SSDP) . . . 43
2.3 Pervasive Service Composition . . . 46
2.3.1 Unifying Inconsistent User Preferences . . . 47
2.3.2 Dealing with Inconsistent Service Effects . . . 49
2.4 Summary . . . 50
3 Flexible and Robust Service Management in a Smart Home 56
3.1 Pervasive Service Application Model (PerSAM) . . . 58
3.1.1 The Pervasive Communities . . . 61
3.1.2 The Pervasive Managers . . . 66
3.2 Pervasive Service Management Protocol (PSMP) . . . 68
3.2.1 Presence Announcement, Leave Announcement, and Life-cycle Management . . . 70
3.2.2 Service Composition and Activation . . . 71
3.2.3 Failure Detection and Recovery . . . 76
3.2.4 Security . . . 82
3.3 Evaluation . . . 86
3.3.1 Robustness . . . 87
3.3.2 Recovery Rate . . . 89
3.3.3 Performance . . . 93
3.3.4 Discussion . . . 95
3.4 Summary: A Running Scenario . . . 96
4 Efficiency Boosting Schemes for UPnP-based Smart Home Networks 98 4.1 Assumptions and Term Definitions . . . 100
4.2 Decomposing the Multicast Traffic . . . 104
4.3 Service-based Node Searching . . . 108
4.4 Reducing the Heartbeat Traffic . . . 110
4.5 Evaluation . . . 113
4.5.1 Communication Complexity . . . 114
4.5.2 NS-2 Simulations . . . 117
4.5.3 Experiments . . . 125
4.5.4 Discussion . . . 128
4.6 Summary . . . 130
5 Consistent Service Composition in a Smart Home 132 5.1 Overall Architecture . . . 134
5.1.1 Capabilities and Preferences for Service Composition . . . 135
5.1.2 The Enhanced Architecture for Pervasive Service Composition . 140 5.1.3 Dynamic Contextual Node Re-binding . . . 141
5.2 Specifying and Unifying User Preferences . . . 142
5.2.1 Enumerative Preference Expressions . . . 143
5.2.2 Numeric Preference Expressions . . . 154
5.3 Type-based Node Searching . . . 166
5.4 Candidate Scoring and Selection . . . 168
5.4.1 Estimating the Degree of Interference . . . 169
5.4.2 Scoring Candidate Worker Nodes . . . 175
5.5 Evaluation . . . 179
5.5.1 Application Scenario . . . 179
5.5.2 Quality Metrics . . . 181
5.5.3 Performance . . . 189
5.6 Summary . . . 190
6 Implementation 191
7 Conclusion and Future Work 199
7.1 Summary of Contribution . . . 199 7.2 Future Work . . . 202
Bibliography 205
LIST OF FIGURES
1.1 Providing a context-aware service in the Smart Home . . . 2
1.2 The vertical architecture of a smart home and the scope of proposed research . . . 8
2.1 The layered architecture of Context Toolkits . . . 15
2.2 The layered architecture of Context Toolkits . . . 17
2.3 The MPACC Service operation architecture in Gaia . . . 20
2.4 Aura’s overall architecture (source: [125]) . . . 22
2.5 A typical message-oriented pervasive system . . . 27
2.6 Overall structure of OWL-S . . . 30
2.7 CTK service discovery architecture . . . 31
2.8 The hierarchical structure of CTK Discoverers . . . 32
2.9 Discovering and invoking service components in Gaia . . . 34
2.10 Presence management in Gaia . . . 35
2.11 Overall architecture of CoBra/JADE . . . 38
2.12 JADE service discovery architecture . . . 39
2.13 Jini service discovery architecture . . . 40
2.14 The protocol stack of UPnP . . . 44
3.1 A taxonomy of PerNode . . . 58
3.2 The message-oriented pervasive system . . . 59
3.3 The states of a PerNode . . . 60
3.4 The structure of a PerNode and a Worker Node . . . 61
3.5 The Pervasive Service communities . . . 64
3.6 The Pervasive Host communities . . . 64
3.7 The structures of PSM and PHM . . . 66
3.8 The projection of PerSAM to UPnP Device Architecture . . . 69
3.9 PSMP service composition . . . 72
3.10 PSMP failure detection . . . 77
3.11 Registering the public key and acquiring the secret key in PSMP . . . 84
3.12 Sending and receiving data in PSMP . . . 85
3.13 The PS recovery rates of Aura PIP and PSMP under various failure rate (NT=25) . . . 90
3.14 The PS recovery rates of Aura PIP and PSMP under various failure rate (NT=50) . . . 91
3.15 Performance of PSMP service composition . . . 93
3.16 Performance of PSMP failure detection and recovery . . . 94
4.1 Packet loss rate with various number of nodes in a typical UPnP-based local area network . . . 99
4.2 Sequence diagrams of PA/LA and node searching protocols: (a) Orig- inal PA; (b) PA after applying DMT; (c) Original node searching; (d) Node searching after applying SNS . . . 107
4.3 Sequence diagrams of heartbeat protocols:(a) Original heartbeat proto- col; (b) After applying DMTH; (c) After applying ODH. . . 110
4.4 Traffic generated by presence announcement, before and after applying
DMT (¯λ = 1 and ¯ℓ = 4) . . . 118
4.5 Traffic reductions of presence announcement after applying DMT . . . 118
4.6 Traffic generated by the node discovery protocol, before and after ap- plying SNS and DMT (¯λ = 1 and ¯ℓ = 4) . . . 119
4.7 Traffic reductions of node discovery after applying SNS and DMT . . . 119
4.8 Heartbeat traffic in a light-loaded system, before and after applying ODH (¯λ = 1 and ¯ℓ = 4) . . . 120
4.9 Heartbeat traffic in a light-loaded system, before and after applying DMTH (¯λ = 1 and ¯ℓ = 4) . . . 121
4.10 Heartbeat traffic in a heavy-loaded system, before and after applying ODH (¯λ = n(S) and ¯ℓ = 4) . . . 122
4.11 Heartbeat traffic in a heavy-loaded system, before and after applying DMTH (¯λ = ¯ℓ = n(S) = n(W )) . . . 123
4.12 Traffic reductions of heartbeat after applying ODH when ¯ℓ = 4 and ¯λ = 1123 4.13 Traffic reductions of heartbeat after applying DMTH when ¯λ = ¯ℓ = n(S) = n(W ) . . . 124
4.14 Evaluating the proposed schemes in a real home network, where ¯λ = 1 and ¯ℓ = 2, when only PA and LA are enabled. . . 125
4.15 Evaluating the proposed schemes in a real home network, where ¯λ = 1 and ¯ℓ = 2, after enabling PA, LA and node searching. . . . 126
4.16 Evaluating the proposed schemes in a real home network, where ¯λ = 1 and ¯ℓ = 2, after enabling all protocol capabilities. . . 127
5.1 A general service composition architecture . . . 134
5.2 Modifying Worker Node structure to facilitate more sophisticated Per- vasive service composition: (a) Original Worker Node structure, (b) Enhanced Worker Node structure . . . 136
5.3 Modifying PSM structure to facilitate more sophisticated Pervasive service composition: (a) Original PSM structure, (b) Enhanced PSM structure . . . 138
5.4 Refined service composition architecture for Pervasive environments . . 140
5.5 Dynamic contextual node re-binding . . . 141
5.6 Reducing < x∨ < y when (a) x > y, (b) x < y, and (c) x = y. . . 159
5.7 Reducing > x∨ < y when (a) x > y, (b) x < y, and (c) x = y. . . 160
5.8 Reducing > x∨ > y when (a) x > y, (b) x < y, and (c) x = y. . . 160
5.9 Reducing == x∨ < y when (a) x > y, (b) x < y, and (c) x = y. . . 160
5.10 Reducing == x∨ > y when (a) x > y, (b) x < y, and (c) x = y. . . 160
5.11 Reducing == x∨ == y when (a) x > y, (b) x < y, and (c) x = y. . . . 160
5.12 Reducing ! = x∨ < y when (a) x > y, (b) x < y, and (c) x = y. . . 161
5.13 Reducing ! = x∨ > y when (a) x > y, (b) x < y, and (c) x = y. . . 161
5.14 Reducing ! = x∨ == y when (a) x > y, (b) x < y, and (c) x = y. . . . 161
5.15 Reducing ! = x∨! = y when (a) x > y, (b) x < y, and (c) x = y. . . 161
5.16 Reducing the first term of (5.15): ! = s∧ (> a∨ < b). . . 165
5.17 The Effect ontology in a Smart Home . . . 170
5.18 Fuzzy sets of ”distance” . . . 173
5.19 Fuzzy sets of ”intensity” . . . 174
5.20 Fuzzy sets of ”similarity” . . . 174
5.21 Fuzzy sets of ”interference” . . . 176
5.22 Success Rate of Composition (SRC) . . . 183
5.23 Success Rate of Matching (SRM) with different number of Worker Nodes184 5.24 Precision of Composition (PoC) with different number of Worker Nodes 186 5.25 Precision of Composition (PoC) with different ratio of constrained at- tributes . . . 186
5.26 F1 Score with different number of Worker Nodes . . . 188
5.27 F2 Score with different number of Worker Nodes . . . 188
5.28 Turnaround time of service composition . . . 189
6.1 The drag-and-drop code generating service . . . 192
6.2 The code template generating wizard . . . 192
6.3 The toolchain for constructing PerNode . . . 194
6.4 PerNode Code/Project generator configuration file . . . 195
6.5 The NTU Attentive Home . . . 196
6.6 The NTU INSIGHT Living Lab . . . 197
LIST OF TABLES
2.1 Sources for state of the art survey of the representative Pervasive systems 12 2.2 Architectural styles and service management functionalities of Pervasive
systems . . . 53
2.3 Detailed comparisons among Service Discovery mechanisms of Pervasive systems . . . 54
2.4 Detailed comparisons among Service Composition mechanisms of Per- vasive systems . . . 55
3.1 Summary of acronyms . . . 61
3.2 Summary of notations . . . 62
3.3 The Operations of a Pervasive Service Manager . . . 67
3.4 The Operations of a Pervasive Host Manager . . . 68
3.5 Summary of CSP notations used in PerSAM/PSMP . . . 71
4.1 Notations for communication complexity analysis . . . 105
4.2 Additional acronyms used in this chapter . . . 105
4.3 Traffic Reductions after applying the Decomposing Multicast Traffic . 115 4.4 Traffic Reductions after applying Service-based Node Searching . . . . 115
4.5 Traffic Reductions after applying On-Demand Heartbeat . . . 117
4.6 Traffic Reductions after applying the Heartbeat by Decomposing Mul- ticast Traffic . . . 117
5.1 Possible pairwise combinations between two numeric p-terms . . . 158
5.2 Reduction rules for deriving compact forms . . . 158
5.3 General forms for disjunctive clauses . . . 161
5.4 Compact forms for disjunctive clauses . . . 163
5.5 Compact forms derived form > a∨ < b ∨∨ i (== xi) . . . 164
5.6 Unification rules for N egotiationExpr . . . 166
5.7 Membership functions for Fuzzy sets of ”distance” and default param- eter values . . . 172
5.8 Membership functions for Fuzzy sets of ”intensity” and default param- eter values . . . 172
5.9 Membership functions for Fuzzy sets of ”similarity” and default param- eter values . . . 173
5.10 Membership functions for Fuzzy sets of ”interference” and default pa- rameter values . . . 175
6.1 Implemented Pervasive Services . . . 196
6.2 Implemented PerNodes . . . 198
7.1 Enhancements of service model and service management . . . 201
Chapter 1 Introduction
In recent years, the rapid emerging of Pervasive and Ubiquitous Computing [138], Context-Aware Computing [104], and Service Computing [147], and Machine Learning [30] have brought the concept of a ”Smart Home” into reality. The concept of a ”Smart Home” was first proposed officially in 1984 by the American Association of House Builders, which envisions a technology-enriched living environment that anticipates the needs and intensions of occupants and provides services accordingly to promote comfort, convenience, security, entertainment, and therefore an improved quality of life for them [21, 68]. Most of the services in the Smart Home have to be ”context- aware” since ”contexts” are essential information used to infer needs and intensions of inhabitants. A service is context-aware if it uses contexts, or it adapts to contexts [46], where a ”context” is any information that can be used to characterize the situation of an entity which can be a person, place, or objet that is considered relevant to the provision of service [47].
Figure 1.1 depicts the relationship among occupants, the environment, contexts and the context-aware services in a Smart Home. In such environment, contexts are usually inferred from the environmental data gathered by sensors. According to the contexts, applications infer the user situations and then perform appropriate actions, such as to turn on a light or to play a media file. We can observe that the data flow discussed above forms a feedback loop between the environment and the context aware service (see Figure 1.1). In summary, Figure 1.1 reveals that providing a context-aware service in a Smart Home is a four-step procedure: 1) gathering context data from sensors, 2) inferring users’ situations based on gathered context data, 3) anticipating users’ needs or intensions based on their situations, and 4) determining and performing the most
Figure 1.1: Providing a context-aware service in the Smart Home
appropriate actions such as manipulating appliances or displaying information to fulfill user’s needs. It is important to observe that, a context-aware service is reactive (event- driven) by nature, since these services react to contexts or situations by performing desired actions.
In addition, heterogeneity is also a key feature of Smart Home services since a service in the Smart Home is realized by an assemblage of heterogeneous service components such as wireless sensors, networked appliances, and intelligent agent software that collaboratively offer context-aware habitual supports to residents. Moreover, these service components are usually interconnected by different wired or wireless protocols.
Because of the context-awareness and heterogeneity of Smart Home services, a set of service management mechanisms are obviously required which composes services by discovering and selecting service components as well as makes the services work consistent and durable. It is worthy to point out that Bedrouni et al. [26] also reported the same observation that among all emerging issues associated with building services in ambient systems, none is more fundamental, challenging, and complex than the need to dynamically ensure adequate management of activities attributed to a large number of heterogeneous entities.
It can be concluded from the above discussions that service management is a core
issue in the Smart Home. However, managing services in such a complicated envi- ronment is not a trivial task. The objective of this thesis is therefore to investigate effective and efficient approaches for dealing with challenges of service management in the Smart Home. In Section 1.1, the challenges and users’ expectations identified by related literatures are first discussed. Based on these challenges and expectations, this section also motivates the desired qualities, that is, flexibility, robustness, consistency, and efficiency. After that, Section 1.2 presents the contributions of this work and then in Section 1.3 the research scope is identified. Section 1.4 explains the research process of this work. Finally, Section 1.5 introduces the organization of this thesis.
1.1 Research Challenges and Objectives
This section examines challenges of service management in Smart Homes. Based on these challenges, several desired technical qualities of Smart Home service management that serve as the objectives of this research are then discussed.
Contrary to other smart environments such as Smart Offices or Smart Campuses where there are significant efforts in planning in advance, the deployments of services in Smart Homes are usually not well-planned and are upgraded incrementally. Hence, the design of a smart home is not benefited from holistic, ground-up approaches [53].
As a result, a context-aware service management platform is apparently required [17], that is, 1) flexible enough to be modified without affecting other interacting parts, and 2) is able to detect/resolve the service inconsistency arising from conflicting effects of appliances or conflicting user preferences. Moreover, due to the heterogeneous nature of Smart Homes, the platform must be interoperable so that heterogeneous hardware and software, incompatible wiring protocols are able to interoperate with one another [72, 62]. As a result, flexibility, consistency, and interoperability are essential qualities of the Smart Home.
In addition, Edwards et al. also observe that robustness is a paramount concern of Smart Home users [53, 62], since most of the domestic technologies are expected to work 24-7. Unlike in other types of smart environments, the Smart Home is in lack of professional system administrator [53]. What is more, the occupants of Smart Homes are usually non-technical users. The persons setting up and maintaining the home services are everyday consumers, with little or no knowledge of networking technologies.
Since the consumers would be unable to pinpoint the source of failures [50], the service management platform must be highly reliable and be able to detect and to recover from failures autonomously. Note that the detection and recovery procedures have to be carried out in a minimal amount of time. Otherwise, the failures can lead to a very frustrating user experience and bad marketing perception for the vendors of home services. Consequently, a robust service management platform in the Smart Home has to be self-diagnosable, self-recoverable, and efficient.
It should be concluded, from what has been mentioned above, that a service man- agement platform for a Smart Home with the following qualities is apparently required.
1. Flexible: The service management platform must be designed carefully by fol- lowing an appropriate architectural style so that the platform is flexible enough for incremental deployment and is able to support impromptu interoperability.
2. Robust: The Smart Home services have to be available durably. The failures should be detected and recovered as soon as possible.
3. Consistent: The service management platform must be able to detect and to resolve conflicts arising from effects of appliances and user preferences.
4. Efficient: The proposed mechanisms that realize the qualities mentioned above have to be completed in a minimal amount of time.
1.2 Contributions
As discussed in the previous sub-section, the overall objective is to design a man- agement platform for Smart Home services that are flexible, robust, and consistent.
In addition, the proposed platform has to carry out service management mechanism efficiently. In order to meet the objective, this sub-section reports several technical contributions that have been achieved so far which serve as important milestones of this research. The contributions of this work are listed below.
1. Message-oriented architecture for the Smart Home: This work suggests that the message-orient architecture, or so-called publish-subscribe architecture, is one of the most appropriate architecture for the service management platform in Smart Homes among existing ones. The rationales behind this suggestion are reported and its superiority over comparable alternatives is also presented.
2. Verifiable service application model for the Smart Home: This work pro- poses a service application model, namely, Pervasive Service Application Model (PerSAM), that specifies the overall logical organization of the Smart Home from the point of view of its use or design. The proposed model is formally presented by using process algebra so that it is verifiable by mathematical proofs. This ap- proach facilitates the analysis of communication complexity (see Item 4 below).
3. Robust service management protocol for the Smart Home: Based on PerSAM , this work proposes Pervasive Service Management Protocol (PSMP) which is a service management protocol that realizes autonomous failure diction and recovery by utilizing Universal Plug and Play (UPnP), a well-known home service network standard [15]. PSMP inherits the rigorous nature of PerSAM so that it can be mathematically validated to guarantee the service robustness.
4. Boosting the efficiency of home service network: Although the approach mentioned in Item 3 makes Smart Home services more robust, the UPnP-based service management protocol is usually realized by using IP multicast, which, if not carefully designed, often suffers from network flooding problems due to replications of too many unnecessary messages. Hence, boosting techniques that avoid replications of unnecessary messages are proposed here. The analytical predictions agree well with the simulated results, which show great improvements on efficiency.
5. Service composition algorithms that ensure consistency: Smart Home services usually have to allow user-in-the-loop service composition which is ab- sent in most of the traditional enterprise service composition mechanisms. More specifically, the criteria for selecting and ranking services are usually specified by users, which tend to be vague and subjective. The criteria can be contra- dictory and the activated services can interfere with one another. This research addresses these issues by defining the Preference Expression (PE) that is capable of specifying both enumerative/numeric as well as mandatory/negotiable user preferences. A set of unification rules for possible conflicting preferences is also presented. Finally, it is suggested that the degree of interference be modeled and estimated by using a Fuzzy reasoner. A preference-guided and interference- aware service composition framework can therefore be obtained by incorporating the above-mentioned mechanisms. Experiments that evaluate the effectiveness of the proposed approaches are conducted and reported as well.
6. Development support and rapid prototyping: To enable the rapid and correct development of home services, a Java-based object-oriented application framework that provides design time supports is devised, which is composed of a set of reusable libraries, interfaces, and default implementations. One of the
salient features of this application framework is that it supports attribute-based programming [36], which implies that the resulting code becomes intuitive and more comprehensible. In addition, this framework provides template-based as well as drag-and-drop code generation services by a set of interactive wizards, which are realized as plug-in modules of the Eclipse IDE.
1.3 Research Scope
To date, Smart Home is still an emerging research field which requires technologies from several related fields such as communications, artificial intelligence, human-computer interfaces, service computing, and pervasive computing. The definition of a Smart Home, or more concretely, the smartness of a Smart Home is still a controversial concept. Inspired by Mann et al. [97] and Aldrich et al. [19], this thesis suggests a vertical architecture that tries to reflect the smartness of a Smart Home, as depicted in Figure 1.2.
One of the most essential characteristics of the Smart Home is the deployment of interconnected devices (see Figure 1.2, Level 1) so that they can be controlled and be mediated by computer programs (Level 2) to provide appropriate services to occupants.
In order to facilitate more intelligent behaviors, it is necessary to design a management platform that can integrate, configure, and maintain devices as well as programs dis- tributed over the home network (Level 3). Based on the platform, the Smart Home is able to be aware of the environment and occupants by analyzing contexts gathered by sensors (Level 4). Furthermore, by aggregating contexts and by employing machine learning mechanisms, the Smart Home can be aware of situations which are at higher level of abstractions than contexts [92] such as the behaviors of occupants (Level 5).
The highest level should be the Attentive home which tries to infer deeper and unob- servable situation of occupants, for example, emotion or intension of people, and thus
Figure 1.2: The vertical architecture of a smart home and the scope of proposed research
provides service in more attentive ways.
As revealed in Figure 1.2, this research focuses on service management issues. In other words, the issues and challenges posed by this thesis fall into level 2 and level 3. Note that in order to enhance the efficiency, this research also concerns some of the network issues (Level 1). For similar reasons, it is also necessary to take context information (Level 4) into account in order to resolve consistency problems in the Smart Home. To sum up, the primary interests of the proposed research lies in levels 2 and 3, while network and context-awareness issues lying in levels 1 and 4, respectively, are also within the scope of this research work.
1.4 Research Process
As Herbert A. Simon pointed out in the highly influential book The Sciences of the Artificial [122], the research field on information and communication technology (ICT) actually falls into the domain of Design Science. The research discipline of Design
Science is obviously different from Natural Science in view of ontology, epistemology, methodology, and axiology. More concretely, the research outcomes of Natural Science refer to a body of knowledge about objects or phenomena in the world that describes and explains how they behave and interact with one another. On the other hand, the goal of Design Science research is to obtain a body of knowledge about artificial (human-made) objects and phenomena designed to meet certain desired goals [135].
In this respect, the artificial object of interest in this work is the Smart Home service management platform which is designed to meet several desired qualities including flexibility, robustness, consistency, and efficiency. The rationales and motivations of setting up these objectives are explained in Section 1.1. The knowledge on how to design service mechanisms to achieve these objectives is therefore presented in the rest of this thesis.
Vaishnavi et al. [135] observed that Design Science research has a long history of knowledge building through making. The research process forms a general design cycle [130] which involves the construction of artifacts and the evaluation of artifact perfor- mance following the aforementioned construction. It is also important to note from the above discussion that every fragment of the research outcomes is valid only in certain situations [101] which is called the circumscription of research. The Design Science research is usually performed by iteratively proposing new methods that deals with the problems arising from the relaxation of circumscription of the previous research.
Consequently, this research follows the process mentioned above in which assump- tions or restrictions are made in the earlier phase of research. After that, some circum- scriptions are removed by enhancing the original research outcomes iteratively.
1.5 Organization
The rest of this thesis is organized as follows. Chapter 2 discusses backgrounds and re- lated works, and Chapter 3 introduces the proposed mechanisms that facilitate flexible and robust service management in Smart Homes, namely, PerSAM and PSMP. After that, Chapter 4 proposes several efficiency boosting techniques to reduce the traffic of service management. Then, Chapter 5 concentrates on consistency issues among user preferences. Chapter 6 presents the implementations of the proposed mechanisms.
Finally, in Chapter 7, conclusions and future works are provided.
Chapter 2
Background and Related Work
Mark Weiser [138] envisioned that due to the rapid advances of technologies, computing devices will become so small and so cheap that they can be embedded in everyday objects scattered over the living environment. In such an environment, computing devices become pervasive or ubiquitous. The technologies that facilitate this vision form a new emerging research domain, namely, Pervasive or Ubiquitous Computing.
Therefore, the living environments equipped with Pervasive Computing devices is also known as pervasive environment, given that a collection of hardware and software components that cooperate to provide services in a pervasive environment is called a pervasive system. Pervasive systems are difficult to design and maintain because they involve heterogeneous hardware, software, wiring protocols, and programming paradigms. Moreover, services in pervasive environments are highly dynamic. Many pervasive systems have been proposed to deal with the above problems since the rise of Pervasive Computing. It is important to note that the Smart Home is a pervasive environment so that many existing works with previously developed architectures for pervasive systems are also applicable to a Smart Home. Hence, the purpose of this chapter is to provide backgrounds and the state of the art of the pervasive systems that are closely related to this work.
In this chapter, 11 representative Pervasive systems are investigated in detail (see Table 2.1). Primary issues concerned in these investigations are the contributions and methodologies of these works. For contributions, this work primary focuses on the architectural styles, service management functionalities, and the qualities obtained through the proposed systems, namely, flexibility, reliability, efficiency, and consis- tency. As for the methodologies, special attentions have been paid to the theoretical
Table 2.1: Sources for state of the art survey of the representative Pervasive systems
Name Ph.D.
Thesis
Journal Conference Source code
Context Toolkits X 2 3 X
UPnP (UPnP specifications) X(Reference Implementation)
Gaia OS X 2 3 -
Aura X 2 4 Partial
CoBra X - 3 X
SOCAM X - 3 X
One.World X 2 - X
Event Heap X 1 2 Archive file damaged
LIME X 1 2 X
SOLAR X 1 3 X
MIRES - - 1 -
underpinnings and the evaluation methodologies.
Before turning to further discussions, it is helpful to clarify the meanings of several terms used throughout this thesis precisely. A service in a pervasive environment is an assemblage of distributed components that collaboratively provides supports to a given user’s intention. A service is also referred to as an application [15, 46, 114]
or task [125] in some literatures. For example, a media-follow-me service is capable of choosing the most appropriate displays for playing media files according to user’s current location. Under such a service, the user’s intention is to listen to music or to watch a movie; the ingredients of a media-follow-me service include control programs, smart floors, all LCD displays and speakers that are capable of adapting to the user’s location change cooperatively. Each of these ingredients is called a ”service component”
or simply ”component” in the sequel. In some pervasive systems [48, 115, 58], there is also a ”service manager” for each service that is responsible for managing service components belonging to the service.
Although numerous pervasive systems have been proposed so far, however, most of them do not deal with the service management issues of a system. These works either rely on the existing general-purpose service management mechanisms, or leave these issues un-handled. For example, CoBra (Context Broker Architecture) [39, 40]
and SOCAM (Service-Oriented Context-Aware Middleware) [64, 65] leave service man- agement issues to their underlying platforms (i.e. JADE (Java Agent DEvelopment Framework) [27] and OSGi (Open Service Gateway Initiative) [11], respectively. Con- sequently, this research investigates the pervasive systems from both architecture and service management’s points of view.
The following section concentrates on providing a bird’s eye view for architectures and service management mechanisms of representative Pervasive systems. Deeper in- vestigations of service management issues are then introduced consecutively in Section 2.2 and 2.3.
2.1 Pervasive Systems
Based on the architectural styles, pervasive systems can be classified into two categories:
process-centric and data-centric [141]. In a process-centric system, the distributed components collaborate by invoking sequences of remote procedures. The flows of calls are controlled by software programs, which search services in a centralized service registry and invoke services in a synchronized way. The Context Toolkits [116, 46], UPnP [15], Gaia [115, 114], Aura [58, 125], CoBra (Context Broker Architecture) [39, 40] and SOCAM (Service-Oriented Context-Aware Middleware) [64, 65] fall into this category.
Due to synchronous and centralized nature of the process-centric systems, they suffer from many reliability issues. First, the distributed components of these platforms are usually tightly coupled since they are usually bound to a static network address.
Hence, the components must start in a strict order. Moreover, if a service consists of a chained call sequences, all intermediates must be restarted when one of them fails.
The failed services are hard to recover because all components must be shut down and then be restarted in a strict order. Finally, the distributed components communicate synchronously. Hence, both service provider and service user both must be ready to communicate at the same time. The caller gets stuck when the callee fails or when it is heavily-loaded.
Recently, more loosely-coupled and asynchronous data-centric architecture such as Tuple Space (TS) [59] and Message-Oriented Middleware (MOM) [24] are proposed.
TS is essentially an associative virtual shared memory storing serialized objects. Dis- tributed clients can read, write or take serialized objects from TS server. The Event Heap [76], One.world [61, 63], and LIME/TinyLIME [105, 42] fall into this category whereas SOLAR [87] and MIRES [127] is two of the few Pervasive systems based on MOM.
The succeeding sub-sections present the design and evaluation of the most fre- quently cited pervasive systems. Service management issues will also be briefly men- tioned when these systems are presented, while the details will be discussed in Sections 2.2 and 2.3.
2.1.1 The Context Toolkits (CTK)
The Context Toolkits (CTK) is one of the earliest research works that attempt to propose a general architecture for Pervasive systems. In typical window-based desktop applications, a ”widget” is a sub-component of a window such as a button, drop-down
Figure 2.1: The layered architecture of Context Toolkits
list or a text area. Inspired by desktop applications, Dey et al. suggest a ”widget”
abstraction for sensors and actuators in pervasive environments [116, 46].
Figure 2.1 reveals the overall architecture of CTK. For each sensor, there is a com- ponent called a ”widget” that is responsible for interacting with the sensors physically and then turning raw data into meaningful representations, referred to as ”context”. In CTK, a piece of context information is represented by a key/value pair that describes the situation of an entity. A service is called an ”application” which operates by inter- acting with remote networked socket servers such as widgets, interpreters, aggregators, and the discoverer. Note that CTK provide three types of core services based on wid- gets. The aggregator is essentially a context query agent that gathers context data from several widgets according to certain criteria. For instance, a location context ag- gregator gathers all context information in a specific location. The context interpreter analyzes contexts and then transforms them into higher level contexts. For example, context information provided by location widgets can be used to infer human activities.
Finally the discoverer is a directory service by which the applications find appropriate widgets, aggregators, or interpreters as context sources.
According to [46], abstracting sensors by using widgets has two benefits. First,
widgets hide the complexities of interacting with heterogeneous sensors such as floor sensor, pressure sensor, light sensor, and RFID from application developers and provide a uniform way for accessing them. Second, the widgets also become reusable building blocks. The most significant contribution of CTK is the sensor abstraction which sepa- rates the tasks of writing application logic from context gathering. This design not only relieves developers from the burdens of dealing with heterogeneous sensors, but also de- couples context providers (e.g. sensors, interpreters, or aggregators) from context users (e.g. applications). Also, CTK provides development support with an object-oriented application framework written in Java. Developers of widgets can greatly reduce their efforts by inheriting template classes provided by the framework. Besides, the commu- nication among CTK components rely on XML-based (eXtensible Markup Language) message, making CTK thus potentially interoperable, since CTK provides neither an XML schema nor DTD for defining the formal syntax of messages. In addition, a new component still needs to understand the semantics of the XML-based messages before interacting with CTK components.
The major limitation of CTK is that it lacks of sophisticated service management mechanisms, since it primary deals with context handling and leaves most of service management issues to the developers. More precisely, CTK only provides na¨ıve service discovery mechanisms and leaves these burdens to developers. In real world cases where there are tens or hundreds of components, it is tedious and error prone to maintain the states and life-cycles of these components. More discussions on CTK service discovery can be found in Section 2.2.1.
2.1.2 Universal Plug and Play (UPnP)
The UPnP Device Architecture [15], revealed in Figure 2.2, is a well-known ISO/IEC standard for home network. The service component is called an UPnP Device in an
Figure 2.2: The layered architecture of Context Toolkits
UPnP network. Each UPnP Device is composed of a set of “UPnP Services”, and each UPnP Service consists of a set of UPnP Actions. It is important to distinguish the term “service”defined above from the UPnP Services mentioned here. An UPnP Service always embedded in an UPnP Device, while a service refers to a collection of components that collaboratively support user’s task.
From Remote Procedure Call (RPC)’s point of view, an UPnP Action is identical to a remote procedure which has a method name, parameters, a return value, and is located by an URL (Uniform Resource Locator). The application logic of UPnP is typically controlled by a Control Point which invokes UPnP Actions remotely. A component that plays the role of Control Point can also be an UPnP Device. It is also legal for an UPnP Device to contain another UPnP Device (see Figure 2.2, the bottom right block), which also contains a set of UPnP Services and UPnP Actions.
Despite the absence of sophisticated service management mechanisms, the service operation architecture of UPnP is very similar to that of CTK in the following aspects:
1. Device abstraction: Akin to CTK’s widgets, UPnP abstracts sensors, appliances, or software programs by ”UPnP Devices”.
2. RPC-based: The Control Points of UPnP as well as CTK applications are both responsible for serially invoking remote procedures.
3. HTTP (Hyper Text Transfer Protocol) and XML-based wiring format: The wiring format of UPnP remote invocations is based on SOAP [12], a widely adopted XML-based for remote invocation standard, while CTK uses a propri- etary XML-based wiring format. Besides, widgets and UPnP Devices are both implemented by embedding an HTTP server and an HTTP client.
UPnP provides more sophisticated support for service management than CTK. As mentioned earlier, the management of UPnP Devices is carried out by SSDP. Unlike CTK, SSDP is a decentralized protocol that does not require a dedicated discoverer. At first glance, it seems impossible to manage the presence of service components without a centralized broker. However, UPnP overcomes this issue by relying on the underlying network infrastructure. Specifically, UPnP eliminates the need for a centralized broker by using the IP multicast mechanism which is supported by the most low-end switches or home gateway. Hence, from the network layer’s perspective, the multicast service provided by the switch becomes the centralized broker which is transparent to the service components in the application layer. Since multicasting is the realization of publish-subscribe style communication in the network layer, it is interesting to note that UPnP adopts the process-centric architecture for service operation and the data-centric architecture for service management, while CTK uses the process-centric architecture for both.
To sum up, the service management of UPnP is superior to CTK in both inter- operability and reliability because that the encoding format of UPnP, that is, SOAP, is more widely recognized than the proprietary protocol proposed in CTK and that UPnP does not require a centralized broker.
2.1.3 The Gaia Meta-Operating System (Gaia OS)
The Gaia meta-operating system (Gaia OS) is proposed by Roman et al. [115, 114].
Compared with other pervasive systems, Gaia focuses more on large scale pervasive environments (or called Active Spaces in the literature) such as museums, office build- ings or campus, where the deployment of a dedicated centralized high-end server is reasonable. Gaia OS takes a monolithic approach and aims to become a pervasive op- erating system, so that it addresses a wide range of issues such as distributed context file system, distributed event service, security policy, remote invocation, and databases.
As a result, the design and implementation is based on CORBA (Common Object Re- quest Broker Architecture) [1], a full scale industrial standard for enterprise distributed systems.
The service operation architecture of Gaia OS is inspired by both CTK and MVC (Model-View-Controller), a programming paradigm widely used in window-based desk- top applications [115]. Roman et al. also propose a Model-Presentation-Adapter- Controller-Coordinator (MPACC) as standard service operation architecture for Gaia to fit the needs of Active Spaces which is describe in detail in [114]. The overall archi- tecture of MPACC is depicted in Figure 2.3, a service is managed by a Coordinator.
The Gaia OS’s is responsible for composing a service, that is, to discover and to select most appropriate components for the service according to the predefined application description documents. An Application Generic Description (AGD) prescribes the default preferred types and attributes of a service, while an Application Customized Description (ACD) describes the user preferences. It is worthy to note that ACD is implemented as a script called LuaOrb [37] to facilitate rapid prototyping of services.
Each device in the Active Space is controlled by a controller, where the function of a controller is akin to a widget in CTK or an UPnP Device in UPnP. After a con- troller reads from or writes to a device, the signals are then transformed by Adapters
Figure 2.3: The MPACC Service operation architecture in Gaia
into standard format used in Gaia. The actual application logic is embedded in the Model component which determines an appropriate output and then delegates to the Presentation component.
Similar to UPnP Device Architecture, the architecture of Gaia is process-centric.
Service management in Gaia relies on CORBA’s event notification service. Each service component declares its presence by emitting heartbeats to CORBA’s event notification service periodically [145]. However, Gaia considers neither service recovery nor service consistency issues.
The major criticism of Gaia comes form its dependency on CORBA. Although Gaia benefits from CORBA by reusing many standard services such as the directory service, shared repository, and event notification service, Gaia remains tightly cou- pled with CORBA. As pointed out by Chappel [38] and Henning [69], the design of CORBA standard is deficient and currently it has been regarded as a failed attempt to
standardized distributed systems: 1) CORBA has incomplete interoperability since it standardizes interface but not the wiring format; 2) The cost of implementing CORBA is high since the specification is too complex; 3) Most of CORBA services can not pass through firewalls. As a result, most of the existing CORBA applications have been replaced by XML-based Web Services in recent years. Besides, taking heavy weight and monolithic approach also makes it hard to be compatible with legacy applications, which makes Gaia infeasible in highly dynamic environments such as the Smart Home [76, 145].
2.1.4 The Aura Platform
Aura [58, 125] is a platform that aims to provide distraction-free services to occupants of pervasive environments by utilizing its service migration mechanisms among hetero- geneous environments. The Aura platform is constructed on top of Linux kernel and is composed of four main building blocks. Specifically, Satyanarayanan et al. [118]
proposed Coda and Odyssey, a file system for mobile user that supports ubiquitous file access with application-transparent adaptation; Spectra [56] is a self-tuned remote ex- ecution mechanism; Prism [109, 125] is a sophisticated service composition system that predicts and adapts to user’s intent inspired by microeconomic model in Economics.
Figure 2.4 shows the overall architecture of Aura. A service is called a ”task” in Aura platform, which is managed by a centralized Task Manager, a Context Observer that provides context information, an Environment Manager (EM), and many Suppliers that provide actual support to the task [125, 126]. Aura is process-centric, since the Task Manager is responsible for initiating, negotiating, and monitoring the progress of
”tasks” in Aura according to pre-specified user preferences.
The developers of Aura recognized the importance of asynchronous communication between components in pervasive environments [125]. Hence, Aura components use
Figure 2.4: Aura’s overall architecture (source: [125])
non-blocking sockets to communicate with one another. As pointed out by Eugster et al. [55], non-blocking sockets facilitate decoupling in time and synchronization. This feature makes Aura platform more robust than other process-centric systems men- tioned in previous sections. However, since point-to-point communication still requires explicit address-binding, the locations of components are still tightly coupled. Sim- ilar to CTK, the communication among Aura components also rely on XML-based messages, hence Aura is also “potentially”interoperable. In addition, Aura adopts the asynchronous process-centric architecture for performing service management. The most notable service management mechanism is the utility-based and task-centric ser- vice composition [126] which will be elaborated in Section 2.3.
Despite the sophisticated service composition mechanism (Prism), Prism does not deal with inconsistency issues between services (tasks). As for the management about components’ presence, Aura relies on Environment Manager as a centralized registry for detecting presences of Suppliers. In [125], the authors claim that current imple-
mentation of Aura can use existing tools such as INS [18] or Jini [20] as its default presence management mechanism. However, as INS only focuses on routing and Jini is tightly coupled by Java, it is not clear that how these mechanisms are applied or customized so that it can fit into the overall architecture. Another limitation of Aura is that although core components such as Environment Manager, Context Observer, and Task Manager are centralized, it does not deal with the single-point-of-failure issues.
2.1.5 CoBra (Context Broker Architecture)
CoBra [39, 40] emphasizes more on context reasoning. At the core of this architecture is a centralized server called Context Broker, which is the mediator of all components in the pervasive system. CoBra is tightly coupled with JADE (Java Agent DEvelopment Framework), a java-based multi agent platform that implements the FIPA (The Foun- dation for Intelligent Physical Agents) specifications. FIPA [10] is an IEEE Computer Society standards organization that promotes agent-based technology and the interop- erability of its standards with other technologies. As a result, a service is composed of a set of collaborative agents, each of which resides in JADE containers.
CoBra delegates the presence management to the Directory Facilitator (DF) of JADE. Hence, the service management architecture of CoBra is process-centric. How- ever, DF does not guarantee the validity of presence information [27], and the service composition mechanism is absent, as well. It can be concluded from the above discus- sion that the CoBra services are neither reliable nor user-centric. Like Aura, agent in- teraction is done by asynchronous peer-to-peer communication which uses ACL (Agent Communication Language) as the wiring format. Another limitation of CoBra is that the design of the Context Broker is purely centralized and lacks of recovery mecha- nism. Furthermore, all components have to be hosted by JADE (or at least conformed to FIPA specification) in order to access CoBra services, and CoBra does not fully uti-
lize the functionalities of JADE which aim to provide general support for multi agent systems. The library of JADE is complex and not easy to learn, and it is very likely that adopting the JADE platform is an overkill for pervasive environments.
2.1.6 SOCAM (Service-Oriented Context-Aware Middleware)
Similar to CoBra, SOCAM (Service-Oriented Context-Aware Middleware) [64, 65] pri- marily focuses on context reasoning. The service management issues are left to its underlying platform, namely, OSGi (Open Service Gateway Initiative) [11]. Note that OSGi is an emerging open standard for deploying services to smart home environments.
Components deployed in the OSGi platform are called ”bundles,” and the bundles can be installed, updated, or removed on the fly without having to disrupt the operation of the device. Bundles are libraries or applications that can dynamically discover other services from the service directory or can be used by other bundles.
The OSGi framework is originally designed for a home gateway. However, the OSGi specification does not deal with the nature of distributed systems which is one of the important characteristics of a pervasive environment. As a result, SOCAM services have to be deployed in the same machine. All OSGi services are deployed locally so that the service management can be greatly simplified: the presence of components can be accurately detected by the OSGi ServiceRegistry service and the recovery of components can also be easily realized by utilizing OSGi ServiceTracker service.
Recent progress in the computing power of embedded systems has made it possi- ble to embed the OSGi platform inside intelligent appliances such as the Interactive Television or home entertainment stations. Wu et al. [142] proposed a distributed architecture that enables interactions among distributed OSGi platforms, which is one of the baseline technologies of this research.
2.1.7 Tuple Spaces
As mentioned earlier, recently data-centric architecture has been proposed to deal with the flexibility and reliability issues of process-centric architecture. Contrary to the interaction style of process-centric architecture, the components in data-centric architecture usually interact with one another in publish-subscribe mechanism so that data-centric architecture is able to addresses the flexibility and reliability problems by enforcing decoupling in space, time, and synchronization [55].
The core idea of these decoupling techniques is to introduce a centralized mediator for all components in the system such as Tuple Space (TS) or Message-Oriented Mid- dleware (MOM). The introduction of a centralized mediator can cause single-point-of failure problem, but it can be alleviated by deploying a cluster of mediators [59] or by delegating the mediating tasks to the underlying network infrastructure [15]. Among the data-centric pervasive systems, Event Heap [76, 77], One.world [61, 63], and LIME [105, 42] are implemented by using a centralized TS server. A TS sever is a remotely accessible associative virtual shared memory storing serialized objects. Therefore, com- ponents can read, write or take serialized objects from TS server.
Event Heap serves as the underlying infrastructure for a larger platform called iROS (Interactive Room Operating System). The service management mechanisms of iROS are carried out by another component called ICrafter [110]. Components announce their presence by a broadcasting mechanism called service bacon. In ICrafter, compo- nents describe themselves by SDL (Service Description Language) which is similar to UPnP service descriptions. SDL is capable of describing the type and supports oper- ations of a component but it does not support attributes. ICrafter provides a naive service composition mechanism for iROS applications. Compared with Prism of Gaia, it lacks of advanced features such as attributed-based filtering and conflicts detection and resolution.
One.world proposes a programming model for TS, in which an application (i.e. a service) consists of a set of ”scoped event handlers” (i.e. service components). The scope of these event handlers regulates their data access authority in the TS server.
However, the application must be written according to specific guidelines and hard to support legacy applications [76]. One.world also proposes a robust presence manage- ment mechanism by an renewable centralized discoverer: upon failure of the discoverer, another new discoverer will be elected and initiated. However, it neither deals with service reliability nor service consistency issues. Finally, LIME emphasizes on cus- tomizing the TS server for applications in the pervasive environments and do not deal with service and service management issues.
The major problem of TS systems is their scalability and performance. As reported by Johanson [76], it is difficult to scale the TS system to large number of simultaneously communicating entities due to performance issues. Moreover, Grimm [61] reported that, LIME, Event Heap, and One.world all tightly coupled with Java, since TS server stores serialized java objects. Hence, the interoperability of these TS systems is poor.
2.1.8 Message-Oriented Middleware (MOM)
Message-Oriented Middleware (MOM) is an event-based mechanism that enables asyn- chronous communication and loosely-coupled integration. Hohpe and Woolf [71] point out that when compared with other paradigms, messaging is considered more imme- diate than file transfer, better encapsulated than shared database, and more flexible than RPC-based invocation. MOM creates a virtual ”software bus” for integrating heterogeneous message publishers and subscribers, namely, the ”nodes”. The logical pathways between nodes are called ”topics”. Based on this architecture, the system provides services by chaining nodes and topics together. For instance, A, C, D, and F in Figure 3.2 collectively provide an ”adaptive air conditioner” service. In this service,
Figure 2.5: A typical message-oriented pervasive system
A is a software adapter of wireless temperature sensors, C is a context interpreter that transforms raw data into high-level context data, D decides the commands to be taken by performing logical reasoning based on the context data, and F is responsible for controlling fans or air-pumps based on messages coming from the COMMAND topic.
MOM has several advantages. First, it comes up with simple and intuitive abstrac- tions of node behaviors. More specifically, all node behaviors can be reduced to three types (to receive messages, to process messages, and to send messages). Second, nodes are easier to ”mock” and test. In Figure 3.2, node E can be tested separately without the presence of node A by using a ”mock” node that feeds dummy sensor messages. In addition, MOM facilitates ”separation of concerns”, that is, since each node is isolated by the topics, developers are capable of concentrating only on the logic of the node to be built without worrying about the interferences with other nodes. Finally, due to the loosely-coupled nature of MOM, failures are isolated. In Figure 3.2, if D fails, the failure is isolated by the topics, but either C or F will be aware of the failure.
MOM and TS have similar advantages, that is, easy to integrate heterogeneous
hardware/software as well as failure isolation. However, they are two different archi- tectures from the technology’s point of view: TS is a way to access shared information across multiple concurrent clients, whereas MOM focuses on message delivery. More concretely, TS combines the concepts of centralized database and message delivery to- gether. TS can simulate the event-driven feature of MOM; however, it tends to be less efficient as they are generally implemented using a remote accessible shared memory, which uses locks with read/writes to entries. Moreover, TS tends to store serialized ob- jects, which is usually a penalty on performance and interoperability. Since that MOM does not enforce the wiring format of messaging content, the performance of MOM is better than TS. Because of the relief of performance and interoperability issues, MOM appears to be a good alternative that keeps the benefits of data-centric architecture and prevents performance and interoperability issues at the same time.
SOLAR [87] and MIRES [127] are two of the few Pervasive systems based on MOM.
SOLAR is an infrastructure for processing context information, the primary application domain of SOLAR is large scale mobile and distributed systems so that P2P techniques such as Distributed Hashtable [23] are used, which is scalable but less efficient. The wiring format of SOLAR is proprietary text-based key-value pairs. It is noteworthy that SOLAR is capable of recover failed service components by restarting the failed ones.
However, it does not support service-level recovery. Contrary to Aura, SOLAR deals with failures by reloading components into memory instead of finding an replacement.
Meanwhile, MIRES is designed mainly for Wireless Sensor Networks (WSN). However, MIRES focuses on the gathering of contexts, and doesn’t address reliability issues or how to compose services by grouping nodes of MOM.
2.2 Pervasive Service Discovery
Service discovery is the process by which an entity on a network (the service manager) is spontaneously notified of the presences of desirable resources (the service components) [52]. The process is usually initiated by issuing a query which contains a set of criteria the desired resources must comply with [136]. Although the idea of service discovery emerges from large scale enterprise systems, it has been extensively used to manage highly dynamic pervasive environments [82]. Typical objectives of service discovery include: 1) getting the locations (e.g. URLs or remote references) of components that meet certain criteria; 2) monitoring the presence or absence of affiliated service components, this is also known as presence management; 3) (optional) trying to recover failed services.
Many service discovery mechanisms have been proposed. They can be classified into three categories: directory-based, non-directory-based, and hybrid [44]. Directory- based systems [20, 3] usually have dedicated registries that maintain information and status of service components, while non-directory-based systems [15, 7] rely on broad- casting or multicasting mechanisms. Some systems support both model mentioned above and are capable to adapt themselves according to the environments [67].
Item 1 mentioned above implies that there is a matching process. To facilitate the matching process, each service component has to be associated with a ”capability de- scriptor” that is to be matched by the ”specification”. Typically, a capability descriptor contains type and attributes of a service component. In a pervasive environment where heterogeneity is a concern, ontology standards such as OWL-S (Web Ontology Lan- guage for Services) [99] are employed to enhance interoperability. Ontology is a set of shared vocabularies used in a specific domain. Sycara et al. [129] suggested an exten- sion of OWL-S for describing the capabilities of a service component. In OWL-S, the capabilities of a service component consist of three parts (see Figure 2.6): 1) Service
