3.4 A Reference Architecture for IoTSE
3.4.3 Composition Patterns
service buses and message formats to achieve interoperation between IoTSE component services.
Management Layer
Managementlayer captures the concerns related to monitoring the workflow of an IoTSE instance and performance of its comprising components. It offers monitoring capabilities on the IoTSE instance-wise workflows, as well as performance and quality of services offered by individual components. Details on building blocks and patterns of this layer are left to the lower-level instantiation of this reference architecture.
Security Layer
Securitylayer captures cross-cutting concerns on securing IoTSE. This layer has four main capabilities. First, it protects an IoTSE instance from external intrusions by users and other IoTSE instances. Second, it assesses the trust and provenance of discovered IoT content.
Third, it authorizes access to an IoTSE instance and the contents that it holds. This capability can be realized via query interfaces and processors in the interface layer. Finally, it controls the degree of exposure of IoT content in search results. This capability can be realized via result processors in the interface layer. Details on building blocks and patterns of this layer require further research which is out-of-scope of this work.
3.4 A Reference Architecture for IoTSE 79
Content Collection CCp
CCs
Storage
Indexing
Search
Discovery
System-wide Sp
Ss Ip Is Sep Ses
CSI CS
C
Parallel Interlaced
Fig. 3.3 A taxonomy of IoTSE composition patterns.
by their capabilities, which are represented by inputs and outputs. Patterns discussed in this section provide the vocabulary for communicating the logical composition of IoTSE instances and offer a guide for combining ABBs to design a concrete IoTSE instance.
Composition patterns described in this section have been identified from workflows of IoTSE prototypes in the literature. Thesesystem-widepatterns are decomposed intosearch anddiscoverypatterns. The later set is further classified into three subsets: content collection, storage, and indexing(Fig. 3.3). Reaching this level of granularity allows our reference architecture to capture a wide variety of composition structure with the same set of “pattern vocabulary”. For instance, our reference architecture can describe both IoTSE instances carrying out every task, as well as the ones omitting storage and index generation. It can also describe variations in timing between components involved in a certain task.
Our description of patterns assumes that an ABB can be implemented as functionally equivalent software components that process different types of IoT content, and these com- ponents are utilized together in an IoTSE instance to resolve queries. For instance, Q.D.
ranker ABB can be realized as “Q.D. ranker for metadata” and “Q.D. ranker for streaming sensing data” components, which are utilized together in an IoTSE instance. In the following
Content Collection
Storage
Indexing
Discovery
Search
System-wide
CCp CCs
Sp Ss
Ip Is
CSI CS
Sep Ses
Parallel Interlaced
SD CD1 CD2
CC1 CC2
SD CD1
CD2 CC1 CC2
S1 S2
S1 S2
I1 I2
C
I1 I2
Q.D. 1 Q.D. 2 Q.I.
Agg
Q.D. 1 Q.D. 2 Q.I.
Agg
Content Collection Storage
Indexing
Content Collection Storage
Content Collection
Discovery Search
Discovery Search
Fig. 3.4 Detail of IoTSE composition patterns. Abbreviations used: SD - source detector, CD - content detector, CC - content collector, S - storage, I - indexer, Q.D. - query dependent
ranker, Q.I. - query independent ranker, Agg - aggregator.
description, we depict the parallel patterns in the context of only two types of IoT content for clarity. The IoTSE components with the index 1, such as Content Detector 1, process the first type of IoT content, while the components with the index 2 process the other type. The depicted patterns, however, can cover an arbitrary number of IoT content type.
It should also be noted that the patterns described in this section concern only with the parallelization of components on a logical level. They do not capture, for instance, duplication and parallelization of a component in runtime to achieve scalability.
Content Collection Patterns
The patterns in this group(CC)concern with detecting and retrieving IoT contents necessary for resolving queries. These patterns involve source detectors, content detectors, and content collectors. They receive instructions for detecting IoT content and return collected content
3.4 A Reference Architecture for IoTSE 81 as outputs. Two patterns in this group differ by the parallelization of content detection and collection.
Storage Patterns
This group(S)contains patterns for storing collected IoT content. These patterns involve storage building blocks. They receive IoT content as inputs and are not required to generate outputs. Two patterns in this group differ the parallelization of storage activities for different types of IoT contents.
Indexing Patterns
The patterns in this group(I)concern with generating and storing indexes for different types of IoT contents. These patterns involve indexer and index building blocks. They receive IoT content as inputs and return indexes as outputs. Two patterns in this group differ in the timing between index generation for different types of IoT content.
Discovery Patterns
The patterns in this group are generated by combining patterns from the three groups mentioned above. They aim at generating collections of IoT contents to support query assessment. This group has three patterns:CSI pattern involves content collection, storage, and indexing;CSpattern omits index generation; andCpattern further omits the storage of collected IoT contents. CS and C patterns are generally utilized by IoTSE instances which avoid storing massive data generated by IoT infrastructure.
Search Patterns
This group(Se)contains patterns for resolving queries. They involve Q.D. ranker, Q.I. ranker, and aggregator building blocks. The patterns in this group receive queries, IoT contents and,
optionally, indexes as inputs, and generate search results as outputs. The patterns in this groups differ by the timing of ranking components.
System-wide Patterns
Two patterns in this group capture the macro composition of an IoTSE instance, specifically the timing between discovery and search processes. In theparallelpattern, content discovery is carried out continuously and independently from query assessment. This pattern is common among search systems not concerning with computing and storage resources. Theinterlaced pattern, on the other hand, are utilized by IoTSE instances facing constraints on resources. In this pattern, content discovery is only carried out when a query is received.