In general RFID uses electromagnetic waves to transmit and receive information stored in a tag to or from a reader (Gabsi et al., 2022). The RFID operation system is given in Figure 1, which presents a passive or semi-passive RFID system that communicates using the backscattering principle. The RFID reader interrogates the tag and eventually supplies it with the energy it needs to operate via radio waves on a specified frequency. The tag converts a part of the received signal into energy and uses it to respond to the reader (in case of a passive or semi-passive tag). A dialogue is then established between the reader and the tag according to a well-defined communication protocol. The middleware then collects and processes the RFID data and is responsible for monitoring the RFID readers, filtering, formatting, aggregating, and storing the collected RFID events for further processing and exploitation by the applications concerned. The scanned data is transmitted to the user application for exploitation.

Sometimes in real cases of RFID technology adoption, we find different RFID products from different manufacturers, which poses the heterogeneity problem. From this arises the importance of the Reader Interface layer. It is the lowest in middleware architecture, oversees managing all the middleware interactions with the various components of the physical RFID infrastructure; it also provides drivers for various devices supported by the middleware (Amaral et al., 2009).

Therefore, the Reader Interface layer controls all hardware-related parameters such as Air Interface, Reader Protocol, and the host-side communication. It provides a uniform communication interface between RFID devices and the rest of the middleware layers, allowing applications to operate independently of RFID readers.

It is the layer responsible for many services that an RFID middleware is supposed to provide (Anouar Abdelhakim Boudhir et al., 2019); it processes the raw data flow sent by the RFID readers based on the reading events management (reading the data stored in the RFID tags). Given the data volume received from RFID tags, this requires a filtering & aggregation feature that is responsible for eliminating data that applications do not need in particular duplicates, in order to select only the useful data for applications, once the data has been filtered and aggregated, the data can be transmitted to the upper layer of the architecture (Amaral et al., 2009). In fact, rather than sending useless data over the network, applications receive only useable data.

With the aim of providing client applications with access to the various services offered by the middleware, this layer ensures the interfacing of the latter with the back-end applications while ensuring the abstraction of the system. Application Interface provides the necessary resources to allow the applications to request these services as well as the desired data and let us not forget the operations’ execution in one or more RFID readers.

Ensures the provision of information on all running processes. It provides the ability to:

- Remove, add, and modify RFID devices linked to the system.

Based on the above, it is concluded that typical middleware may need to support these different features: Hardware Abstraction, Duplicate removal & Filtering, Data Aggregation, Data Formatting, and Application Connector.

It is an RFID middleware developed by the.NET Framework; as shown in Figure 3, it contains 5 layers which makes it among the multi-layer middleware architectures (Prabhu et al., 2006). This architecture components are listed below:

• RFID Hardware: It administrates Tags, Readers, and other sensors (hardware part). It is in charge of abstracting this system part in order to make easier the management and the addition of new components (Perret, 2017) (the input/output components), as it offers a unified interface to the physical RFID infrastructure devices.

It is an RFID middleware that has the following objectives: Reliability, Load Balancing, High Throughput, Scalability, and Data Organization. As shown in Figure 4, this middleware principle is based on these two notions: virtual reader abstraction and Vpath (Virtual Path) (Ahmed et al., 2007).

• Virtual reader abstraction: it manages a set of physical readers that are located in the same neighbourhood.

Fosstrak for Free and Open-Source Software for Trace and track (previously called Accada platform), is an open-source platform that implements the specifications of EPCglobal Inc. This RFID middleware is designed to meet the needs of tracking and tracing applications (Floerkemeier et al., 2007). As shown in Figure 5, this platform consists of three layers.

• EPCIS (EPC Information Services): it receives data from the middleware and transforms it into a more suitable format for enterprise/business applications.

ASPIRERFID is an RFID middleware compatible with EPCglobal standards and others; it is developed within the framework of a project named ASPIRE by ON2 and implements the NFC Forum and OSGi Alliance specifications, as well as several Java Community Process (JCP) specifications (Kefalakis et al., 2008). As can be seen from Figure 6, layers constituting this middleware are:

• Hardware abstraction layer

It is a Middleware platform (Java-based) designed by Sun Microsystems Inc. that supports EPCglobal standards in its design. As shown in Figure 7, its main components are the Event Manager and Information Server (Gupta and Srivastava, 2004):

• Event Manager RFID: it is based on Jini and its main objectives are to interface with the hardware part (tags or sensors and readers) to collect, filter, and transmit events to the RFID information system.

Is an open-source agent-based middleware developed by Arkansas University that collects RFID data and stores it in a database of choice (Oracle or MySQL). TagCentic allows managing heterogeneous RFID readers and RFID tag printers. This Middleware supports several popular RFID readers (Alien, Symbol, and ThingMagic) and supports simulated readers such as Rifidi (Hoag and Thompson, 2006). Figure 8 depicts the architecture of Tagcentric.

LIT Middleware acronym for Logistics Information Technology Middleware is an RFID middleware based on both EPCIS and ALE layers in its implementation. The layer named ALE consists of the following four sub-layers (see Figure 9) (Kabir et al., 2008):

• Application Abstraction Layer: provides access to RFID data via ALE API.

EPCIS is composed of three sub-layers:

- Capturing Service Layer - Query Service Layer

This work represents lightweight middleware that supports data acquisition, processing, and download. The architecture structure is illustrated in Figure 10 (He et al., 2013).

This middleware architecture is based on the MySQL DBMS, which will provide the back-end applications with the required RFID data via SQL statements.

Lightweight RFID middleware architecture is composed of:

• Reader Connection Interface: this module consists of two sub-modules: Management of Reader RFID reader connection program.

It is a lightweight embedded RFID middleware architecture based on the ALE standard. It is characterized by an event-handling mechanism, and it provides a unified interface (Liu et al., 2009).

As shown in Figure 11 the middleware architecture consists of:

• Device Manager: Thanks to this module, the middleware supports heterogeneous RFID devices; to manage this equipment it provides a unified management interface.

This middleware, which is based on a simple architecture, uses almost less than 20% of the functions provided by the EPC system. It has a low-cost compact system compared to ALE structure for convenient use by small and medium-sized companies (Chen et al., 2017). This middleware architecture (Figure 12) has different aspects from the EPC system middleware, the differences are listed below:

• Supported formats: the proposed architecture supports different ID formats, plus the 2 formats ISO18000-6C (EPC C1G2) and ISO180006B, it also supports active tags; knowing that EPC Middlewares only support IDs of tags in GID-96 format.

Figure 13 depicts the overall DEPCAS architecture. The scheme proposed here is based on the architecture of modern SCADA (Supervisory Control and Data Acquisition) systems (Cardiel et al., 2012). The key issues of DEPCAS are as follows:

(1) Hiding heterogeneous RFID deployment systems with a homogeneous layer approach.

This Middleware system is organised into four sub-systems:

• Graphical User Viewer.

Is an RFID middleware is programmed in Java and is based on the LLRP protocol to manage RFID readers and retrieve the data (Kheddam et al., 2013). The strength of this architecture is fault tolerance through two mechanisms, namely the online diagnostic algorithm based on statistical analysis of RFID events that guarantees to detect defective elements on the physical RFID infrastructure. And the second mechanism which is a verification process based on an extended finite state machine of LLRP.

As shown in Figure 14, SafeRFID is composed of three layers:

• Data Processing Layer: It is the layer in charge of carrying out most of the functionality provided by this middleware, as data aggregation and filtering, etc., which makes it the most essential layer in this proposed architecture.

Represents an RFID middleware that includes, in addition to the standard features that an RFID middleware should offer, areas of innovation especially related to mobility and manufacturer’s autonomy.

The architecture of the MedRFID Middleware is shown in Figure 15. It is composed of 7 layers:

• Collect: This is the module that oversees the collected RFID data, writing on tags, managing readers, unifying the data format regardless of the reader type.

FlexRFID is middleware that is part of the Multilayer Middleware family. It consists of four layers: DAL, BEDPL, BRL, and AAL (Ajana et al., 2009b). This is illustrated in Figure 16.

• DAL/Device abstraction layer: allows interfacing with the Hardware; thanks to it, the Middleware can support a heterogeneous network of sensors and devices based on these three modules: Device Management and Monitoring Module, Data Source Abstraction Module, Device Abstraction Module.

IBM WebSphere RFID is a middleware solution that spans the three domains Edge, Premises, and Business Process Integration Domain. It allows the interconnection of RFID equipment with business information systems. This is illustrated in Figure 17. It consists of three components (IBM Corporation, 2009):

• Premises Server (PS): is the centrepiece of IBM’s solution. It is a J2EE application, considered as an intermediary between the physical world and the world of information technology, which uses the “Business Integration Domain".

BTMiddlawre refers to a lightweight RFID middleware architecture. The implementation of its architecture (Figure 18) follows the database approach, and the difference between this architecture and other database-based architectures is that it is DBMS NoSQL-based, which enables it to collect and process Big RFID Data (Haibi et al., 2018).

The major difference that characterizes this architecture is that the implementation layer is divided into four different functional modules as shown in Figure 19 (Qiyue and Ping, 2017).

This middleware architecture allows access only to authorised users by verifying their identities. Implementation layer consists of 4 modules:

• Anti-virus module: This algorithm-based digital signature module is adopted so that it will be applied when detecting the malicious access as well as the information carrying virus.

CUHK RFID System is an RFID middleware layer that complies with the EPCglobal standard specifications. It includes an interface that follows the Application-Level Events standard providing read/write functions on the RFID tags and offers IS applications access to the RFID network. The connection with the RFID readers can be done either by IP networks or RS-232 adapters. This middleware allows configuration, control, and monitoring of the RFID equipment network. Figure 20 presents CUHK RFID System architecture. The key Middleware system elements are (Mak et al., 2007):

• ALE interface module: It represents a standard API that gives back-end applications the ability to access RFID data. The desired RFID event and data formatting type can be chosen and specified by the applications, and they can also specify a notification channel for the middleware to report in each event cycle.

This middleware architecture is mainly based on these 3 layers (Zhang et al., 2020):

1) Service-scheduling layer.

2) Device driver layer.

3) Application business layer.

It provides an application abstraction based on a unified data interface. And for scheduling service, this middleware concentrates on the management of the entire middleware platform, the planning and management of application services, the planning and management of devices and the log system.

This RFID middleware is organized as a three-tier architecture, with a physical RFID infrastructure combined with WSN, RFID middleware (UIR-Middleware), and back-end applications. To ensure hardware abstraction, this architecture proposes the HAL layer which in turn consists of the following 3 sub-layers AAL, EDML, and HAL the abbreviations for Application Abstraction Layer, Event and Data Management Layer, and Hardware Abstraction Layer respectively (Rouchdi et al., 2018c).

This section classifies the different RFID middleware according to various functionalities. First, by following the study (Ahmed et al., 2011), the middleware solutions studied are grouped according to their design approaches, as follows:

• Generic RFID Middleware: This type of middleware is dedicated to processing large amounts of data and focuses on scalability, data organization, large-scale data management, and high throughput.

Table 1 groups the 20 architectures studied in this manuscript according to the classification presented in (He et al., 2013). By applying the taxonomy presented in (Ahmed et al., 2011) to all the examined studies, we observe that current Middleware architectures consider the constraint of regular data collection and processing with different mechanisms, but none of them takes into account users’ privacy issue, which requires the proposal and implementation of a new well-secured middleware architecture to be perfect in terms of RFID data security. We can conclude that all the presented architectures are oriented to the industrial domains concerns. This result indicates that researchers must focus on proposing robust security architectures to protect human data. Among the potential proposals is the coupling of encryption solutions with access rights management solutions at the same time to increase data security.

About twenty research works have been studied, 17 middleware architectures between them are implemented, and two studies present architectures without implementation. This gives 85% of middlewares are implemented (Figure 21A). This result shows that the majority of RFID middleware goes beyond the modelling phase through to the implementation phase. Since the RFID middleware market is dominated by three trends (Abad et al., 2012a; Abad et al., 2012b), giants’ software vendors, Specialized companies, Research Results (Takes origin in research centres and universities), the first two types are supposed to implement the architectures for commercial purposes. A set of middleware in the third category also goes into the implementation phase because most of these research studies are done as part of research projects requiring the implementation phase. This is why we find a majority of middleware architectures with implementation.

Figure 21B shows that the majority of middleware architectures examined are not applied to a well-defined application domain, and it also shows which areas are attracting the most attention from researchers and companies, namely (SCM & Logistics) and SMEs, with respectively 36% 18% of all evaluated studies, followed by the aeronautical sector. In recent years, we also note that new application areas have seen the integration of RFID technology, namely, IoT and sensing applications. The first RFID middleware appeared, used mainly in cases where data needs to be shared in more than one location at a time and a variety of business applications requiring access to data collected by RFID readers (Al-Jaroodi et al., 2009), such as logistics and SCM fields. This type of areas requires multiple readers to spread across factories, warehouses, and distribution centres. The integration of RFID technology into SCM & Logistics systems has reduced waste and enhanced visibility at multiple steps of the supply chain (Amin, 2013; Sheng et al., 2008) through its capacity to automatically track each article across the chain securely and in real-time. RFID also contributes to reducing data entry errors, efficiently manages inventory, and optimizes the flow of goods (Ropraz, 2008b). This mainly justifies why a large number of SCM & Logistics companies are investing in RFID.

Among examined works in our study, we notice that the majority of RFID Middleware implementations are not Open-Source with a percentage of 59% (Figure 21C). This reflects that a significant number of middleware implementations can only be modified by their original authors, limiting the possibility that this middleware will be improved and developed as more people are unable to work for its improvement.

Figure 21D illustrates the trend in publications over time. As we can see, it is clear that the serious effort to address this research field only began in 2007. We also note a decrease in the number of works published between 2013 and 2016, followed by an increase between 2016 and 2019, reflecting those earlier studies till 2016 have shortcomings and no longer keeps pace with technological development, which has forced researchers to present and propose new improvements in middleware architectures. Since there is a huge amount of research work has been paid to RFID hardware components, this result shows that there is a gap between the number of research work contributing to RFID tags’ hardware design & performance, and those dealing with RFID data acquisition, processing, and management solutions. Given that RFID is moving into critical areas characterized by massive amounts data, where the concept of real time is very important. It should be highlighted that the traditional data platforms and techniques are less effective in these kinds of fields (Haibi et al., 2022a; Oussous et al., 2017).

Based on the study of RFID technology and in particular the Middleware components, it is noted that this field is very active, and researchers continue to contribute to it. The main limitations and issues identified in the current architectures are listed in Table 2.

The volume of RFID data is constantly growing in modern applications. This (big data) reality means that data transformation is more important than ever for back-end applications, as they do not have the capacity to understand and process raw RFID data without it being transformed so that they can make the right decisions. From the existing literature on RFID middleware architectures, most middleware architectures use XML as an exchange format. Nevertheless, this can be understood given that, by far, XML has been the single option to share and transfer of data for a long time. Although this exchange format has its benefits, it is not adequate for big RFID data sets, is significantly more verbose, relatively more difficult to read and interpret, and has a much more complex syntax that does not directly correspond with data structures in today’s coding languages (Breje et al., 2018), it is becoming unsuitable for use in modern systems. Over the last decade, the debate between XML versus JSON has been one of the most prominent topics in developer circles. However, based on the literature comparing these two formats, we find that JSON has several advantages over XML (Vanura and Kriz, 2018). For instance, data processing with JSON is easier than with XML, and JSON is independent of the languages that use it and easy for machines to parse, allowing JSON to rapidly replace XML in last few years (Lanthaler and Gütl, 2012). This set of advantages allowed us to consider adding the functionality of formatting raw RFID data in JSON format as well.

The term Big Data is used when traditional data management tools are not able to store or process such massive data sets (Khemiri et al., 2022), and this is the case with RFID data in modern applications. Big Data is often defined based on three concepts called the 3 Vs. (Kouanou et al., 2018; Erevelles et al., 2016):

• Volume: the data volume is already large and is constantly increasing. This can generate storage and analysis difficulties -which is one of the characteristics of RFID data-. For example, the use of RFID technology as a traceability system by a medium-sized retail chain will produce 300 million RFID scans a day (Boontrai et al., 2009) and getting the relevant information out of this vast data stream will not be easy.

Thus, the development of autonomous objects equipped with RFID tags produces large amounts of data that challenge many traditional approaches in Information Systems. The latter have to deal with huge amounts of disparate RFID data, i.e., highly variable, structured or unstructured, sometimes imperfect (Moniruzzaman and Hossain, 2013). A set of data characterized by these notions must therefore be managed using dedicated Big Data tools. Today only the NoSQL systems can manage the huge volumes of big data which is generated very fast (Jose and Abraham, 2017a). The term NoSQL covers database systems that are not relational. These databases offer an alternative to traditional databases for processing large volumes of data. They do not present the properties of a relational database [ACID properties (atomicity, consistency, isolation and durability)] and are not, in general, interrogable with SQL language. They have been designed to manage large volumes of data (for this they have the “horizontal scalability” properties, because the data can be distributed over several databases) and unstructured data (their data model is more flexible than that of RDBMSs (Relational Database Management Systems).

NoSQL databases can be classified into four categories: key-value databases (Dynamo, Reddis, Voldemort, etc.), document-type databases (MongoDB, CouchDb, etc.), column-type databases (Hbase, Cassandra, BigTable … ) and graph type databases (Neo4J, InfoGrid … ) (Xiang et al., 2016).

For our architecture, we chose the MongoDB database (belongs to the document-oriented model databases) for its multiple advantages and functionalities. MongoDB is a system that stores data in BJSON (binary JSON) (Zhang et al., 2014), it is optimized for loading from JSON files (which makes it perfect for our Middleware that uses this type of data formatting), that’s why we have coupled for our Middleware the JSON format for data presentation and the MongoDB database for storing large amounts of data. Table 3 shows some important features of MongoDB (Jose and Abraham, 2017a).

In a general context, modern RFID applications require continuous processing of streaming data detected at different locations, at different times and at different rates, in order to achieve added value in their business and service areas. Real-time analysis is now a central concern for companies (Khaddar et al., 2011). It is an essential practice to significantly increase turnover but also to remain competitive. The science that examines raw data in real-time with the aim of drawing conclusions–without delay-is called real-time analysis. Analytical tools are adopted to empower organizations and businesses to make better decisions, and data analysis is considered among the most essential tasks behind success in several fields of services and business. Some examples of these areas include the RFID technology application areas where they rely on timely and rapid analysis based on available data to make quality decisions. Recently, CEP has proven to work as a basic tool for processing RFID data in real time to identify all circumstances on demand and act instantly (Aftab et al., 2018), as it was designed specifically to solve issues related to real-time event processing in distributed systems (Amaral et al., 2011). The CEP is characterized by scalability, efficiency, speed, robustness, and heterogeneity. It inputs an endless and infinite stream of events from different sources to facilitate real-time data management and detects a massive number of events with low latency. Furthermore, CEP can be used for a wide range of applications (Elkhoukhi et al., 2022), from simple surveillance to very complex applications such as fraud detection and algorithmic trading (Tawsif et al., 2018). Thus, CEP can handle massive unpredictable RFID data, which is generated by RFID networks from multiple sources (Aftab et al., 2018).

With the rapid developments in the RFID technology field, there has been a growing trend toward the adoption of this technology and even in critical sectors. This raised the important security issue of how to control and prevent unauthorized access to RFID data.

• RBAC

One approach to protect the privacy of stored data is to use access controls. Many access control models have been proposed over the years in the literature (Gouglidis et al., 2012). In this context, there are two well-known models, RBAC and ABAC, and according to (Aftab et al., 2018) the RBAC is most trustworthy instead of ABAC. Role-based access control (RBAC) is a well-known access control model that can help simplify security management, especially in large-scale systems. Since its first formalisation in the 1990s, RBAC has been widely used in many systems to provide users with flexible controls over access to their data. The RBAC model was extended and updated in 1996 (Zhou et al., 2015), and the RBAC standard was proposed in 2000 (Gouglidis et al., 2012). This model makes it possible to establish, within a company’s information system, an efficient access control to the services and applications and of this IS. It is mainly based on the definition of roles to be attributed resources and users. RBAC has become the most widely used management model because it can be easily applied to different structures. Each role is a simple collection of permissions and users are granted permissions only through the roles to which they are assigned.

When defining an RBAC model, the following conventions are useful.

• U: users

The role is the core of the RBAC model and is seen as an intermediate entity between users and permissions as it groups a set of privileges and then assigns them to users according to their role (Dana and Sèdes, 2009/3; Al Kukhun and Sèdes, 2012).

As shown in Figure 22A, role assignment in the RBAC model follows a mutual relationship where a User (person, computer process, machine, etc.) can play multiple roles in a single session and a role can be assigned to multiple users. UA ⊆ U   x   R

Assigning a role will grant multiple permissions to the user and a permission can be assigned to multiple roles. PA ⊆ R   x  PRMS

The nature of a permission describes the type of operations (OPS) (e.g., read, write, update, etc.) allowed on OBS objects (data resources: documents, computer processes, machines, etc.) (Al Kukhun and Sèdes, 2012). The relationship between these objects and the assigned operations is also mutual; an operation can be allowed on several objects and an object can be assigned different permissions (Breje et al., 2018). PRM ⊆ OPS  x  OBS

• Blowfish

As mentioned before, in the current era of RFID applications, with terabytes of data generated daily, securing information is a challenge. Cryptography is a process of making information unintelligible to an unauthorised person, thus providing confidentiality to genuine users which can make the RFID data environment more secure (Patil et al., 2016). In general, there are two main families of cryptographic encryption algorithms: Symmetric or private key algorithms and Asymmetric or public key algorithms (Latif, 2020).

This layer is responsible for providing the various services and functions to the end users of the IS. This layer can be composed of one or many backend applications, such as WMS, ERP, user applications (website, mobile application).

HAL is in charge of interfacing with the physical RFID infrastructure. It represents the abstraction of the physical parts of the system and supports different devices (read-only, read/write, passive, active tags.) working with multiple frequency bands (HF, LF or UHF). The device abstraction is done in a different way in RF²ID, it is based on the notion of virtual readers so that each virtual reader manages a set of physical readers in the same neighbourhood. The diversity of RFID devices constituting the Physical Layer in our case makes the RFID network heterogeneous, and this requires the integration of an abstraction layer of RFID devices into the middleware that interacts with the physical RFID network. Such an approach allows companies to adopt RFID solutions without managing the low-level programming. Furthermore, this approach improves the flexibility of the middleware in terms of hardware selection, as it provides a unified communication gateway to the physical RFID infrastructure, i.e., heterogeneous RFID devices, regardless of the employed frequency range (HF, UHF or LF), or the adopted communication protocol (e.g. LLRP or other), the manufacturer or the communication interface. So, in our case, the Hardware Abstraction Layer will ensure the interfacing with the hardware independently of its characteristics. The HAL is structured in three different sub-layers.

• Hardware Abstraction Module

As mentioned before, there are many readers of different brands and of course with different characteristics and protocols. Thanks to the functionalities offered by this module, our middleware architecture will be able to communicate with a heterogeneous RFID physical RFID infrastructure no matter which communication protocol is employed (USB, Ethernet or RS232), the brand, or the frequency range, because this module acts as a unified interface of communication with the physical RFID infrastructure. In addition, via HAM, all basic RFID reader parameters are under the control of the system administrator, this set of parameters includes Stop/Start, Activation/Deactivation, and Read/Write.

• Device Management and Monitoring Module

This module offers the user the possibility to select from a broad range of RFID devices depending on their requirements and allows him to replace equipment directly without influencing the insurance software solution. Thanks to DMMM the RFID reader driver libraries are called dynamically which makes the architecture more flexible.

• Data abstraction Module

Still with the aim of guaranteeing a unified interfacing with heterogeneous RFID devices, this module ensures that the RFID data will be communicated with the RTDP layer in a common format regardless of the characteristics of the hardware RFID components, in addition DAM handles middleware requests such as ACKs and inventory results.

Equivalent to the “data management layer” for WinRFID, it fills a set of inconsistencies (read errors, unread tag, tag read several times), defines management rules for checking the data read, aggregation and redundant data filtering.

Gathered at the layer named Middleware for the Fosstrak middleware, which is in charge of filtering, aggregating and distributing data, this layer also allows applications to define a subscription in which each application defines the readers to be used, the type of data it is interested in, their formats, etc.

For the AspireRFID middleware this layer is called the Hardware Abstraction Layer, it provides a hardware abstraction to unify the way the middleware interacts with readers from different manufacturers, and which use different communication protocols.

It is the “RFID Event Manager” layer in the Sun Java System middleware, its main purpose is to interface with readers, collect EPC events, filter redundant data and feed important EPC events to the RFID information server or other ERP application. This layer is based on Jini technology.

The Data Processing Layer (DPL) layer for our case, which lies between AAL and HAL, is the core of the Middleware. Because any kind of middleware service or functionality is provided through it. The lower HAL layer communicates with the RTPL by providing it with the raw collected RFID stream. Subsequently the different modules of the RTPL layer will be responsible of storing, formatting, filtering, and the exchange of formatted RFID data with the appropriate back-end applications. The CEP module is required to apply complex queries to several data streams simultaneously to detect specified conditions (events), thus triggering appropriate actions in real time. This enables the middleware to track, analyse and process large RFID data streams when an event is detected. This layer consists of.

• Data Dissemination

Normally, client applications have to exploit the RFID data. DD module is implemented in order to transmit this data to any interested application. When a back-end application requests RFID information and if it has the required authorisations, this module ensures the transfer of the data it is interested in.

• Data Aggregation

The DA component is tasked with grouping RFID data according to specific criteria so that each back-end application receives only the data relevant to it, and to reduce the increased granularity. For instance, “grouping data coming from the same RFID reader".

• Database Management

DM is responsible for all database organization e.g., deletion, storing and sharing data. As discussed in Section 5.1, among the things that characterize new areas of application of RFID technology is the flow of RFID data, which is really very important, and in order to ensure the storage of this huge volume of RFID data our approach relies on the SQL solution for big data storage, and more specifically the MongoDB database.

• Data Reading

For our approach the Data Reading component represents the same thing for most proposed middleware architectures, it is in charge of collecting data from the RFID tags.

• Data Transformation

The raw data has no meaning for the applications, that’s why “Data transformation” in our architecture transforms it into business events. For instance, in the scenario of deploying RFID technology in the baggage handling process, a bag’s location can be expressed as: the bag was in this location at this hour. According to the literature, it has been observed that middleware architectures are mainly based on the representation of data in the XML form, certainly, this format offers a number of significant benefits in terms of data presentation and exchange, but it has a set of limitations which has led us to think of other data presentation formats to ensure better interoperability. As mentioned in (Lanthaler and Gütl, 2012), today the lighter approach of JSON has proven to be popular and is rapidly replacing XML, which led us to consider including the option to format raw RFID data in JSON as well, according to the need of the IS applications.

• Data Filter

The RFID data stream generated is always huge in the case of a network of mobile RFID objects. The task of extracting useful data from this vast selection requires data filtering mechanisms. So, it is the role of the module DF to eliminate the undesired data, especially the duplicates.

• Data Writing

As mentioned in the “RFID System Components” section, we find read/write tags, which enable the insertion of information on the RFID tag chips. This proposed middleware architecture provides this functionality by calling the DW module.

• CEP Module

As mentioned in the introduction, RFID enhances the presence of data that evolves regularly over time and needs to be processed continuously, due to the massive presence of RFID tags. Such exponential data growth causes the 3V in Big Data nature with extreme data streaming speed. This poses significant challenges to overcome the problems of Big Data analysis and real-time decision-making issues. To this end, it is realistic to consider the representation of data as streams and to use processing models corresponding to this information. To tackle the problem, our architecture is based on the paradigm of real-time complex event processing via the CEP Module which solves the Big Data velocity problem. CEP Module will be responsible for tracking RFID data streams from multiple sources to analyse events in real time in order to respond as quickly as possible, providing organisations with greater situational awareness and business agility.

Equivalent to the data presentation layer in the WINRFD architecture, which provides data and functionality to users. In order to hide the complexity of the RFID system, this module aims to provide a common interface for the application layer to give them the option to access the different functionalities of the middleware if they are granted the necessary authorisations.

One of the aims of this work is to secure RFID data, as security is the major problem facing every user. This prompted us to include the Access Rights Management Layer (ARML) in our proposed middleware design. Figure 24 depicts the ARML architecture, which controls all connection requests emerging from the application layer, ensuring that no requests from applications without the necessary authorisations from ARML will be processed. This layer based on the RBAC module limits the system against unauthorized access, as there are a number of restrictions to access RFID data with each user. ARML will therefore help to regularize access to RFID data so that only authorized users to access, will have the right to use the decrypted RFID data. Its operating principle is firstly based on authentication to certify the identity of the user, and then, depending on the authorizations granted to this user, the Access Control Decision module (ACD) shares the decision. In the case that it has appropriate authorisation, ACD will identify the resources he can access and the operations he can perform; if the user is not authorized, their requests will be denied.

• Authentication Management

Each time the Middleware receives an authentication request, it delegates it to the Authentication Management Module, which is in charge of analysing the credentials provided by the user during the Login phase and then saves the authentication results to the Authentication History module.

• Authorization Management

After communication with the Decision Module, it determines the permissions granted to an authenticated user.

• AC Decision Module

This is the element that evaluates incoming requests (“who” wants to do “what” on “what”) against registered rules (“who” can do “what” on “what”), the Allow/Deny decision will depend on the roles and permissions assigned to users.

• Policy Definition

Policy Definition contains statements that collect roles and permissions to express what can and cannot be accessed. Policies in ARML can grant or deny actions on the middleware. In this layer, roles are used to associate users with permissions on resources. Users are assigned roles, and permissions are assigned to roles rather than to individual users; only users who have been granted role membership can access the permissions associated with the roles and can therefore access resources. The ARML consists of:

- Permissions Assignment: The administrator is the only actor who can assign permissions to roles. Permissions represent statements describing the behaviour, i.e., the set of operations that can be performed on the middleware.

This module records historical information about the use of the middleware by storing all successful and failed authentications.

This layer is responsible for data encryption, upon arrival of RFID events, BEL encrypts all RFID tag data collected by the reader based on the Blowfish encryption algorithm.

RFID has been used in many sectors for many years, but due to the evolution of RFID equipment, its application has broadened in recent years to include critical areas. As these kinds of domains face a variety of new challenges, especially in gathering, processing, analysing and securing big RFID data in real-time, that is why our middleware must support interoperability by ensuring the dissemination of RFID data according to the format requested by the IS, while supporting the heterogeneity of RFID devices, the security of RFID data, and the processing and storage of real-time RFID big data.

Aviation is one of these areas; today airlines face many challenges that have an impact on customer retention, and therefore on profitability. SITA (Société Internationale de Télécommunications Aéronautiques) reports that both the number of travellers and the volume of luggage are constantly rising. International Air Transport Association (IATA) and SITA estimates, lost baggage costs airlines worldwide $2.1 billion annually! And according to traveller surveys, baggage disputes and delays are the major causes of traveller dissatisfaction, and baggage reclaim is the main stressor for travellers. The aviation industry is one of the areas that has great opportunity to profit from RFID and IoT. To provide a better and secure system for the aviation industry and travellers, we have proposed a design for an RFID-based baggage tracking system. This project aims to build a baggage tracking system for Moroccan airports. To our knowledge, this is the first innovative academic research study on this topic in Morocco. The implementation of this system will provide an efficient tool for Moroccan airports to recover lost luggage. Figure 25A shows the scenario architecture.

One of the ways in which airlines can become more efficient is to adopt and leverage technological advances in their overall offering. RFID has demonstrated strong benefits in many areas, so it can contribute to the improvement of the baggage handling process, with the aim of solving the problem of lost baggage or at least minimising the number of lost bags, which can be reflected in customer satisfaction. The implementation of an RFID-based IoT system (in which labelled suitcases are considered the “objects” of RFID infrastructure) will offer real-time monitoring of baggage location, with accurate checking stages carried out at different phases of the travel process and without manual handling. Streamlining luggage handling using RFID technology by implementing a system that performs following our proposed middleware architecture specifications outlined previously, will benefit Moroccan airports and airlines in several ways, and by exploiting an approach such as the one described in this paper, airports will benefit from the widespread connectivity and availability of RFID data, which will be integrated into the IS. Figure 25B show some of the interfaces of our middleware, namely: Authentication interface, Dashboard, Reader configuration, Encrypted RFID data.

As shown in Figure 26A, first, the Blowfish middleware layer helps encrypt RFID data as it arrives. Using the ARML layer, the middleware limits the system against unauthorized access, as there are a number of restrictions to access RFID data.

To test the functioning of our middleware we have developed an application dedicated to the airport staff. Figures 26B, C show some graphical interfaces of the application. Figure 26C illustrates that the middleware prevents the user Achraf from viewing the location of the luggage.

On arrival at the airport, the traveller is first required to go through the check in phase, in which the details of each traveller are recorded in the database with the Electronic Product Code (EPC) assigned to him. Each step in the airport is equipped with an RFID reader as shown in the Figure 27A, so each step is represented by an RFID reader. The RFID middleware is the manager of this RFID network since it is connected with this set of readers, and it receives the events generated by these 5 readers each time a bag or suitcase passes through the interrogation zone of a reader. Each event contains baggage information: EPC code, suitcase location and the time. In this way, the deployed system tracks the position of the RFID-tagged suitcases throughout their journey. And in order to detect possible problems related to the baggage handling process in real time, we consider that the maximum time for a “trip” on the conveyor is N seconds, and after this time the baggage should be considered missing. The method therefore consists in verifying that the same baggage has passed through the five readers within the expected time interval and therefore that there are five events detected for the same baggage in the last n seconds.

We employed three readers for our implementation test, and the event processing rules are implemented using a query language, called EPL (Event Processing Language), which allows to query the content of events. The flowchart (Figure 27B) shows the pseudo code behind the operation of the CEP module which verifies that the same baggage has passed through all three readers within the expected time interval, if so, it registers the state of the baggage and continue listening to events. Otherwise, it triggers an event to notify airport staff that a suitcase is lost and continue to listen for upcoming events.

This scenario represents only an application to test and validate the concept of our proposed middleware architecture and does not reflect the full scope of possible applications that our proposed middleware could address, hence its scalability aspect.

The ISO/IEC 9126 standard, via the portability metric, offers two evaluation factors called scalability and heterogeneous system support. The first of these is used to assess the durability of stable status in increasing of application, i.e., the number of requests coming from applications and the number of applications that can be connected to the middleware. The second factor is used to assess the middleware abstraction level to ensure communication with different backend applications.

We tested our middleware with a prototype baggage tracking application and an access control application, and also identified middleware integration scenarios in the SCM and healthcare domains by integrating it with a Hospital Information System (HIS). According to the authors of (Baruffa et al., 2020), the most important alternative factor of portability metric is heterogeneous system support; this led us to develop a generic class via the AAL to be integrated into the applications that will use our middleware.

The ISO/IEC 9126 standard, again via the portability metric, allows middleware to be assessed in terms of scalability and capacity to support heterogeneous devices. Here, the term scalability means the sustainability of the steady state of the middleware as the number of RFID devices increases. Typically, manufacturers provide RFID equipment with a set of brand-specific APIs to ensure interaction with the middleware. In our proposed architecture, the HAL provides a communication interface with the heterogeneous RFID equipment network. The LLRP protocol is implemented to support readers that use this protocol, in addition to the APIs provided by manufacturers. To test our middleware, we used the readers available in our laboratory, which were D-Logic, RC522, and EM4100.

In this assessment, metrics were assigned to the environmental contexts in which the middleware was implemented. The context can take different forms, such as the mobility of the objects to be tracked, location, time, and the user’s activities. Context assessment can be done by applying scenarios and verifying that the application is context-sensitive. Real-time baggage tracking can play the role of a scenario that will assess the context sensitivity of the middleware. In the baggage traceability scenario using RFID technology, each suitcase is tagged with an RFID tag to guarantee real-time tracking. Using the CEP implementation, in the event of a problem (e.g., lost baggage), the middleware broadcasts context-dependent information, and informs only the specific users that are affected.

The functionality metric of the ISO/IEC 9126 standard was used to assess the interoperability of our middleware. Interoperability was identified as the most important alternative factor of functionality (Baruffa et al., 2020). Until formatting is applied, back-end applications cannot process the raw RFID events stream. In our proposed architecture the task of receiving and transforming the raw RFID data into business events exploitable by applications is guaranteed by the data transformation module. Currently, XML and JSON are the two most frequently used data exchange formats. However, JSON is generally preferred over XML, and has quickly come to replace it (Chung and Berhe, 2021), which motivated us to add the option to use the JSON format. The added value of our architecture is that it allows the user to choose between XML or JSON depending on the specifications of the company’s IS.

In addition to these essential functionalities, our proposed architecture also supports other services that are specific to the newer areas of application of RFID technology. For example, this kind of application is characterised by a high volume of data, and in some sectors, it is not only necessary to manage very large quantities of data but also data with a very large size, although the relational DBMS are limited for use with very high data flows (Baruffa et al., 2019). Our database management module enables the storage of big data due to the integration of the NoSQL MongoDB database. There is also the real-time analysis service, which extracts relevant real-time content from huge raw RFID data stream via the CEP module, which captures information from real-time data streams.

The security and privacy assessment are intended to evaluate the security and privacy of the RFID middleware, and how it protects sensitive application data where necessary through the use of policies. This is achieved by generating a scenario in which access to decrypted data is restricted to specific parts and by testing how the middleware handles this access control policy. The example of data security that we used in our scenario is illustrated in Figure 26A. This policy maps an airport business rule that says that only the admin can access decrypted traveller information after the authentication phase. This policy restricts access to this information.