Radio Frequency Identification (RFID) technology is a fast, real-time, and accurate information collection and processing technology. It uniquely and effectively identifies physical objects through radio frequency signals and can be widely used in various industries such as manufacturing, retail, logistics, transportation, healthcare, defense, animal husbandry, and mining. A basic RFID system generally consists of three parts: tags, readers, and application support software. Middleware is an important component of the application support software, serving as a bridge between hardware devices such as tags and readers and enterprise application software such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). The main task of middleware is to filter, summarize, calculate, and group tag-related data transmitted from the reader, reducing the large amount of raw data transmitted from the reader to the enterprise application and generating event data with semantic interpretation. In short, middleware is the "nerve center" of the RFID system. The design of RFID middleware involves many considerations, such as: how to implement various quality attributes of the software, how to isolate the middleware from hardware devices, how to handle the relationship with device management functions, and how to achieve high-performance data processing, etc. 1 RFID Network Framework Structure The framework structure of a radio frequency identification network is shown in Figure 1. Tag data is processed by middleware through grouping and filtering before being reported to the application system. The application system is responsible for persistent storage of event data and management of business information bound to tags. The RFID system's shared public service platform provides public services such as Root Node Object Name Service (ONS), enterprise application authentication management, tag information discovery, and enterprise authorization code management. The root node ONS, together with the internal ONS of all enterprise-level RFID systems, forms an ONS tree. Any tag can find the address of its corresponding tag information database on the ONS tree, allowing further access to its detailed information. 2. Middleware Functions and Implementation Principles In short, the middleware's function is to accept requests from the application system, initiate operation commands to one or more specified readers such as tag counting, tag identification data writing, tag user data area reading and writing, tag data locking, and tag killing, and receive, process, and report the results to the backend application system. Tag counting is the most basic and widely used function. 2.1 Tag Inventory Function Overview The tag inventory workflow can be simply described as follows: The application system defines its tag data requirements in the form of rules. These rules are submitted by the application system to the middleware and maintained by the middleware. The rules define: which readers need to inventory data, the start and end conditions of the tag data reporting cycle (event cycle), how to filter tag data, how to group tag data, whether the reported data is original inventory data, newly added tag data, or newly removed tag data, and what original data the tag data includes, etc. The application system specifies a rule and submits a tag data reservation to the middleware. Based on the application system's tag data reservation, the middleware starts the event cycle in a timely manner and issues tag inventory commands to the readers. The readers send the data they have inventoried within a certain time period (reading cycle) to the middleware. The reading cycle can be determined privately by the middleware and the readers. The middleware receives the data reported by the readers. According to the rule definition, the middleware performs filtering, grouping, and accumulation operations on the received data, and at the end of the event cycle, generates a data result report according to the rule requirements and sends it to the rule's subscriber. The filtering process can remove duplicate data and data that the application system is not interested in, greatly reducing the amount of data transmitted between components. This process can be seen in Figure 2. Here, it is necessary to explain the concept of logical reader. The middleware abstracts the event source into a logical concept - logical reader. A logical reader can contain multiple physical readers, or even more finely into multiple antennas containing multiple physical readers. The division of logical readers can be determined according to the actual system deployment. For example, if a warehouse has two exits with four readers deployed, these four readers can be configured into a logical reader as needed, and can be named "warehouse exit". When the application system needs the tag data of the warehouse exit, it can issue an inventory command based on this logical reader, and the name of the logical reader is used as a parameter for some application programming interface (API) calls. 2.2 Tag Inventory Implementation Principle As mentioned above, the rule is the key element of the entire middleware function. The rule is equivalent to the order form sent by the application system to the middleware, which defines the requirements for the time (event cycle) and specifications (how to filter, how to group, report style, etc.) of the goods (tag data). The principle description part refers to the relevant content of EPCglobal [1]. Rules and reports have their own information models to represent the information they carry. At the same time, rules have their own state machine models. When accepting long-term or one-time reservations from the application system, these reservation operations will trigger state transitions of the rules, such as transitioning from the "not requested" state to the "requested" state. Rules are defined by the application system through API. (1) Rule Information Model The description of the rule information model uses the Unified Modeling Language (UML), as shown in Figure 3. In the context of object-oriented programming, a rule can be represented as a class (ECSpec). From the information model description, it can be seen that a rule class has relationships with multiple other classes, or has the following attributes: a list of one or more logical readers (readers), event cycle boundary definitions (boundaries), one or more report definitions (reportSpecs), and a flag indicating whether the rule itself is included in the report (includeSpecInReports). (2) Report Information Model Similar to the rule information model, the report information model is shown in Figure 4. Among them, the event report group class (ECReports) has the following attributes: rule name (specName), time reporting time (date), event period duration (totalMilliseconds), event period termination condition (terminationCondition), rule definition class instance (spec), and a list of one or more report class instances (reports). The report class (ECReport) contains specific tag data information. (3) Tag inventory API The application system issues requests such as defining rules and subscribing data by calling the API provided by the middleware. The API call process can be implemented using specific technologies such as Java RMI and SOAP. The most important API is shown in Table 1. Among them, the poll operation is equivalent to the subscribe operation. After receiving data for an event period, the unsubscribe operation is called. The immediate operation is equivalent to the define operation. After defining the rule, the poll operation is called, and then the undefine operation is called. (4) Rule state machine model From its definition, a rule may exist in three states: unrequested, requested, and active. Once a rule is created, it is in the Unrequested state before being subscribed to by any client (i.e., application system). The first subscription action to the rule will cause it to transition to the Requested state. When the event cycle start condition is met, the rule enters the Active state. When the event cycle end condition is met, if the rule has a subscriber, it transitions to the Requested state; otherwise, it transitions to the Unrequested state. 3. Middleware System Architecture As a software system (or component), a middleware system, in addition to fulfilling certain functional and performance requirements, must also meet quality attributes such as understandability, scalability, modifiability (or refactorability), pluggability, and reusability as software design requirements. In the past decade or so, object-oriented thinking has almost completely dominated the field of software design, becoming the most mainstream analysis and design method. In recent years, research on design patterns has also become increasingly sophisticated, and patterns have almost become a "higher-level programming language" (compared to high-level programming languages ​​such as Java and C++) and are widely used. Object-oriented thinking and design patterns are all aimed at achieving the goals of software being understandable, extensible, modifiable, pluggable, and reusable. This paper will also apply object-oriented thinking and reference pattern languages ​​to conduct a preliminary exploration of the software architecture of middleware. In the examples below, if high-level programming languages ​​are involved, Java language will be used [2]. 3.1 Encapsulation and isolation of each node in the processing flow Dividing each node in the middleware's business process into different modules can achieve advantages such as encapsulation, high cohesion, and low coupling, as shown in Figure 5. Among them, the report upload module is responsible for implementing different types of report upload methods, such as HTTP and JMS; the API interface module is responsible for isolating the application system and the middleware core business logic processing module, and providing the middleware API interface to the application system; the middleware core business logic processing module is responsible for the middleware core business, including data receiving and filtering, data grouping, report generation, and rule object state transition; the reader communication module is responsible for communication between the middleware system and the reader.