Radio frequency identification (RFID) technology has developed rapidly in recent years and has entered the stage of commercial application.

The ultimate purpose of implementing RFID scheme is to use the massive information generated by RFID for business. This needs to solve the problem of how the enterprise’s existing business system interfaces with RFID system, including connecting RFID equipment, processing RFID data, converting it into business information and so on. In order to avoid the need to rewrite business information due to the change of tag type and system business logic, the connection control and intermediate data processing of RFID hardware module need to be separated from the upper application software. Therefore, the concept of RFID middleware is introduced.

In addition, the use of SOA system has the characteristics of high scalability and good maintainability, so as to provide users with flexible maintenance services. Service Oriented Architecture SOA (Service Oriented Architecture) is also introduced.

Based on the above analysis, this paper proposes an RFID middleware scheme based on SOA. The scheme can abstract the functions of RFID technology into services, apply the construction method based on J2EE, and comprehensively apply JMX, JMS, struts and other technologies. Enterprise application system obtains the services provided by RFID middleware by requesting services. Use XML for data transmission and provide web service interface.

1 technical basis

1.1 RFID Middleware

RFID middleware is an intermediate program to realize data transmission, filtering and data format conversion between RFID hardware equipment and application system. Various data information read by RFID reader is extracted, decrypted, filtered, format converted and imported into the enterprise’s management information system through middleware, and reflected on the program interface through the application system for operators to browse, select, modify Query. Middleware technology also reduces the difficulty of application development, so that developers do not need to face the underlying architecture directly, but call through middleware.

RFID middleware is a message oriented software middleware. Information is transmitted from one program module to another or more program modules in the form of messages. Messages can be sent asynchronously, so the sender does not have to wait for a response. RFID middleware further expands and deepens the application of middleware based on the development of the original middleware of enterprise application and combined with its own application characteristics, making the development of RFID application system easier, improving the portability of software and enhancing the maintainability and reliability of the system, Therefore, its architecture design solution is a very important core technology of RFID application [1].

At present, the manufacturers providing RFID middleware platform mainly include IBM, Oracle, Microsoft, sap and sun. For these manufacturers, RFID middleware is only an extension of their existing software, and their RFID products can be quickly and easily integrated with their existing software product lines. However, the disadvantage is that its products are highly dependent on other software products of the manufacturer.

1.2 Service Oriented Architecture SOA

Service oriented architecture is a technical architecture style. It represents an open, agile, extensible and composable Architecture [2], and defines the loose coupling relationship between service providers and consumers. Its business agility helps enterprises become more flexible and respond to changes timely and quickly. The core concept of SOA is service [3], and its basic structure is shown in Figure 1. It contains three basic roles of service: service provider, service requester and service registration. Three operations are used between these roles: service publishing, service discovery, and service binding. As an implementation technology of SOA, Web Services provides a standard interface based on XML, which has the characteristics of good encapsulation, loose coupling, standardization of protocol specification and high integration, and can well meet the needs of SOA application mode.

An overview of RFID middleware design process based on SOA

1.3 JMX and JMS

Java Management Extensions (JMX) is a framework for implanting management functions for applications, devices, systems, etc. In the JMX specification, the management component is a Java object that can represent the management resources. It follows a certain design pattern and implements the specific interface defined in the specification. This definition ensures that all management components represent managed resources in a standard way. The management interface is the information exposed by the managed resources. The managed resources can be controlled by modifying these information. The management interface includes: attribute values that can be contacted, operations that can be performed, notification events that can be sent, etc. [4].

JMS (Java Message Service) is a standard API for accessing enterprise message system. It defines the interface for accessing message middleware in Java, but JMS is only an interface and has not been implemented. The message middleware that implements JMS interface is called JMS provider. The method of running in JMS framework is as follows:

(1) Get a JNDI initialization context.

(2) Find 1 connection factory based on context.

(3) Get 1 connection from the connection factory.

(4) Connect to establish a session.

(5) Find the destination (topic / queue).

(6) According to the session and destination, the message maker (topicpublisher / queuesender) and consumer (topicsubscrib Er / queuereceiver) are established.

2 RFID middleware architecture based on SOA

Using the loose coupling and business-oriented characteristics of SOA, the application system integration scheme realized in combination with RFID middleware can provide rich interfaces, help realize the management of RFID equipment and data processing, simplify the support for the application of underlying equipment and avoid the processing of low-level interfaces of underlying equipment. The integration of RFID middleware and enterprise system is realized by using web service technology to complete the loose coupling integration of the two.

The infrastructure layer of RFID middleware architecture based on SOA is divided into device management layer, event processing layer and service interface layer. The corresponding functions of each layer are packaged and implemented through web service technology. This paper focuses on the three functional layers of the infrastructure in the RFID Middleware Architecture [5]. These three levels have clear function division and inter layer interaction interface. The RFID middleware architecture is shown in Figure 2.

An overview of RFID middleware design process based on SOA

The middleware design includes RFID device management component and event process management component. RFID device management component is a distributed agent, which is responsible for level 1 event filtering; Device management includes device interrogator. For each reader and sensor device, the agent must interact. The process management component places the events into the trading environment through the next level filtering of RFID events, and then publishes the application layer event ale (application layer event) [5].

2.1 equipment management

The device management layer is located at the bottom of the architecture and directly interacts with readers. The main functions include:

(1) Collect data on the RF card.

(2) The data from different types of readers are adapted to obtain unified and formatted data, and the data is verified.

(3) Packet the verified data according to the user-defined protocol, and send the message packet to the message system of the event processing layer.

According to its functions, this paper studies and develops RF card reader module, reader interface, data verification and data packaging. The reader module is coded according to the specifications provided by the hardware supplier; The reader interface is mainly used to convert the data from the protocol format into the EPC code required by the system; CRC verification is adopted for data verification; Data packaging first determines the type of label data according to the “data classification” content in the obtained card code, and then encapsulates the label data into corresponding message packets according to this data type.

Since each ale reader event flow may come from multiple physical device configuration tables, the device manager creates one interrogator for each device table and informs the interrogator which sensor is bound to the specified reader. The interrogator sends a sensor event stream to the device manager, which constructs one or more sensor event streams into reader events. The device manager sends the preliminarily processed reader events to the ale server.

Interrogator agent: the configuration of a device manager consists of the devices it manages and the interrogators it wants to consult, and then interacts with its corresponding device manager. Each device profile table consists of physical device properties and interrogator configuration. Physical device properties are named sensors (e.g. antenna and 1 metal sensor).

Event information space: the event information space is similar to a common fault-tolerant event information broker. It supports asynchronous receiving of events from device manager, ale events and other configuration requirements from event process management. The event information space also provides a store and forward mechanism to ensure that important events are not lost in case of interrupted network or other component failure [5].

In the system, the remote method call of each reader module is encapsulated into a management component (MBean) and registered in the JMX server as an instance of the JMX server. The reader is monitored and managed through JMX framework, so that the RFID middleware system can provide the function of managing and monitoring readers. This section describes adding a time service to the reader management component to control the reader regularly.

2.2 event handling layer

In RFID system, on the one hand, various applications frequently obtain data from RFID system in different ways; On the other hand, due to the limited network bandwidth and its contradiction, it is necessary to design a set of message passing system, so that the events generated by the equipment management layer can be transmitted to the message system, processed by the event management process, and then transmitted to the relevant application system. In this mode, the reader does not have to care which application system needs what data. At the same time, the application does not need to maintain the network channel with each reader, but only needs to send the requirements to the message system. Therefore, the designed message system should have the following functions: (1) data cache function; (2) Content based routing function; (3) Data classification storage function [6].

Creating an MBean to implement a data processing node will be described below. Message components can be deployed according to MBeans. Execution function of message processing component: obtain messages from the source queue, process the messages, and then place the result messages into the target queue. The UML diagram of message processing is shown in Figure 3.

An overview of RFID middleware design process based on SOA

Jbossmq is configured through the XML file jbossmq-destinations-service.xml. The following is the code to obtain the JBoss JNDI initialization context:

Hashtable props=newHashtable();

props.put(Context.INITIAL CONTEXT FACTORY,“org.jnp.interfaces.NamingContextFactory”);

props.put (Context. PROVIDER URL, ip +“:1099”);

props.put(“java.naming.rmi.security.manager”,“yes”);

props.put(Context.URL PKG PREFIXES,“org. jboss.naming”);

Context context=new InitialContext(props);

Messages from the message system are saved in the form of temporary XML files and disk files for use by the data interface. The message system completes message caching, classification integration, routing and forwarding, temporary storage and other operations [4].

Event process management (EPM) consists of ale service, configuration management, complex event process and transaction rule execution. Access to EVP can be realized through HTTP, JMS and network service interfaces.

EPM registers / subscribes to events of interest. When events occur in the information space, EPM will be notified. Once these events are received, complex event processing (filter) will be applied to process these events in combination with transaction rules. In another case, an external client (such as epc-is) has registered to receive ale, and these filtered events will be sent to the location specified by the ale client.

2.3 service interface layer

The data from the event processing layer is ultimately classified XML files. The same type of data is saved in the form of XML file and provided to one or more corresponding applications. The service interface layer mainly filters and stores these data, and provides a service interface to access the corresponding database. The specific operations are as follows:

(1) Store the XML files stored on the disk in batches. When the amount of XML data reaches a certain amount, start the data warehousing function module to transplant the XML data to various databases.

(2) Filter out duplicate data before data migration.

(3) Provide web services for accessing databases inside and outside the enterprise

Interface.

Among them, the data filtering process is completed in the process of processing temporarily stored XML files. The method is: compare multiple records of the same card number according to the read timestamp. If the timestamp difference of adjacent records is less than the user-defined threshold, it is considered that repeated reading occurs, and the last record is selected. And so on, eliminate all redundant data. Web services technology is used to publish the access to the database in the form of services for internal applications and enterprise partners to call [2]. Taking data filtering as an example, its core code is as follows:

for(int i=1;i《rowcount;i++)

{span=EndTime.Subtract(StartTime);

spantiIDe=sPan.Seconds; // Difference between timestamps of adjacent records

if(spantime《=0.002)

{subtime[i]=i;}

//If the difference between adjacent timestamps is less than 2 ms,

//Mark the 2nd record as redundant data

else subtime[i]=0;}

For (int j = 1; J rowcount; j + +) / / delete redundant records

{if(subtime[j].ToString()!=“0”)

{ds.Tables[0].Rows[j].Delete();j=j-1;

rowcount=rowcount11;}

}

The following is part of the code [7] that the service interface layer sends a soap response to the application system and returns the processing result.

《report xmlns=“”》

《process procInsID=“503” givenID=“231” givenName=“

ShipOut”》

《event eventType=“report_tag_event”》

《header》Product Quantity Match Success

《/header》

《status》success《/status》

《tagList》

《tag ID=“00110011”detectTime=“2008-11-01 T13:13:

00.110+08:00”/》

《/tagList》

3 implementation and test of RFID Middleware

The RIFD middleware system development tool adopts eclipse 3.2, the application server software adopts JBoss 4.0, and the web container is Tomcat 5.5. In addition, the server adopts MVC multi-level structure framework based on struts, and the data service layer adopts MySQL 5.0 database.

In the experiment, the terminal is networked through 485 network, and the application system uses warehouse management system. As a service requester, the warehouse management system checks the service WSDL according to the warehousing information published by the service interface layer to obtain the interface definition and listening address of the service. The warehousing management module sends a soap request message to the web service through the service agent interface to request the warehousing information check service. After receiving the service request, the web service platform sends a message to the RFID middleware, Create an instance of the outbound information check service, and the equipment management layer starts the corresponding RFID reader to read the tag information according to the service request parameters. Then, the read tag information is packaged and transmitted to the event processing layer after processing, and the tag information is checked according to the parameters of the service request and the captured tag information. After processing, the information that the check data is correct or wrong is returned to the service interface layer, as shown in Figure 4. Finally, the service interface layer sends a soap response to the warehouse management system and returns the processing result [5].

An overview of RFID middleware design process based on SOA

Experiments show that the original application system only supports one fixed card reader. After using RFID middleware, various card readers can be used in one system, and the upper program does not need to be modified, which increases the scalability and maintainability of the system and saves time and cost. The system stability is also greatly improved, which effectively solves the problems concerned in enterprise application.

This paper proposes an RFID middleware architecture based on SOA and comprehensively applying JMX, JMS and other technologies, and explains the meaning and function of each part of RFID middleware and the implementation of infrastructure. This middleware structure can well shield the information of various low-end physical devices. Due to the modular structure, it can be reduced according to needs, and corresponding modules can be added when necessary. For example, whether authentication and security modules can be added according to needs. Through web service, higher-level packaging of RFID middleware can be realized, which ensures the mutual independence and collaborative work of the three functional layers in RFID infrastructure.

Tagged:

Leave a Reply

Your email address will not be published. Required fields are marked *