某厂家RFID中间件功能摘录

      看到某个厂家的中间件产品功能介绍，可作为今后设计中间件/平台功能参考：
 
rfid软件领域:
     1、系统集成
           与数据交换系统的集成
           与BI集成
            供应链
2、中间件
3、信息服务
        编码解析
         信息检索
背景
虽然可能会面向不同行业的应用，但是RFID应用系统具备一些共同的特性和需求
1.标签数据处理和数据管理的需求
         通过对物品进行编码，识别，组织，追踪，RFID提供了一个物理世界与数字世界的桥梁，但是还存在一个深沟，如何将这些传感器数据解释为业务逻辑友好的数据。例如，一个货架上的物理读写器会周期性的将它读到的标签数据进行上送，大概至少会达到几十甚至上百标签每秒种的数据量。如果不进行任何预处理，上层或外部系统直接面对这些数据，首先增加了开发人员的工作难度，其次大大增加处理系统和通讯系统的负荷。所以如果在其他应用系统使用RFID数据前，进行一些数据处理工作，无疑可以降低RFID系统集成工作的门槛，让业务开发人员专心的编写业务逻辑，使这些应用系统可以快速支持RFID。RFID应用系统需要有效的使用RFID系统产生的大规模的实时数据。该应用系统需要为电子标签数据提供一个清晰的实时数据处理模型来满足追溯和管理查询。
2.方便与其他系统集成和以此套件为基础的应用开发工作

3.底层硬件设备管理的需求：
典型的RFID应用系统需要管理多个阅读器，这些阅读器被部署到几十个甚至上百个位置，工作于联网环境下，在没有人工干预的情况下向上层系统发送数据。为了保证接收到的业务数据准确可靠，必须可以实时检测读写器（及其天线）的状态信息，以判断其是否正常工作，并在出现异常情况时及时做出反应。
解决之道
RFID最基础的应用是对标签轨迹的追溯和对标签位置的定位。从逻辑层面看，用户关心的是区域（位置或着门），而非哪个读写器读到了标签。而超高频读写器每个主机可以拖4拖8甚至拖16个天线，并且可以区分是哪个天线读到了标签。所以可以通过合理的组合天线来划分位置，提高灵活度同时降低成本。更进一步的我们可以以位置为基础，定义出门，即根据标签在两个位置出现的先后顺序来判断标签是进门还是出门。
与其他系统集成的详细说明
目前系统提供两种类型的报告接收地址：HTTP，JDBC.
用户只需要像服务指定端口发送格式如下的请求：


http://localhost:8084/receiver,3,3
location:L1
subscribe

Destination： 代表报告接收的地址描述http://localhost:8084/receiver 部分代表一个HTTP类型的
报告接收地址。,3,3前面3代表如果如果连续三次没有发送成功，则放弃像该地址发送报告。后面3代表
如果相邻两次失败间隔超过300MS,则放弃像该地址发送报告。如果地址类型为Database://xxx xxx为
服务器定义的数据库的别名引用。该数据库可以为SQLSERVER ORACLE MYSQL 也可以使用系统内置的数
据库。
reqSource：location:L1代表接收服务端定义的位置名称为L1的报告。如果为Portal：P1，则代表接收
服务端定义的通道为P1的报告。
与其他系统集成的详细说明
当选择数据库作为报告的接收端时，以此为基础的系统开发就和MIS系
统非常类似，我们的开发人员只需要跟数据库打交道即可得到
如此丰富的信息。例如。
Ø 位置相关的追溯
Ø 追踪一个标签轨迹
Ø 追踪一个位置现有的标签
Ø 定位一个标签什么时间什么位置丢失的
Ø 查看一下运输过程中是否有标签丢失。例如已经确信在上一个位置L1 和时间T 所有的标签是完整
的，那么想看一下这些标签有没有都到达当前的位置L2
Ø 某个标签是否出现在某个位置
Ø 查看一个标签从一个位置到另一个位置的用时
 
----------------------------------------------------------------------------------------