RFID技术挑战和参考架构

无线射频识别（Radio Frequency Identification，RFID）技术正在零售、医药、运输和国防等领域得到日益广泛的应用。RFID可在跟踪和追踪、血统追踪、预测、药品召回以及整个供应链基础架构的效能等方面提供极高的价值。但是，我们通常所关心的安全性、可伸缩性、可用性、可靠性、分布式管理以及性能等问题也与RFID关系密切。

本文将讨论适用于与企业大型IT生态系统相接合的RFID基础架构的架构。重点介绍通常被RFID供应商所忽略的几个问题，阐述在选择RFID基础架构供应商时需要考虑的架构选项，并详细研究这些选项的架构优点。

简介

无线射频识别（Radio Frequency Identification，RFID）正在成为现实，因为现代供应链要求有更高的效能、更大的信息流和灵活性。RFID产品已在零售、医药、运输、国防和带包装消费品等行业中得到广泛应用。采用RFID技术可以改进血统追踪，提高预测水平和集装箱安全性，同时减少货物皱缩、召回和脱销等问题的发生，从而节约数十亿美元的供应链成本。

沃尔玛、Albertson's和Best Buy等零售商已要求他们的顶级供应商到2005年末全部启用RFID。这些要求会扩展到数以千计的供应商、商店和配送中心，它们都需要装配多功能分布式读卡器，这样就引发了几个技术挑战。现在，大部分采用RFID技术的企业都集中于小规模的试点和一站式概念验证。但是，要真正实现RFID的优点，必须在整个企业范围内采用该项技术。

基于长期与大流量分布式事务环境打交道的成功经验，BEA已确定了企业要完全采用RFID技术必须解决的七项关键技术挑战。在未来几年内，RFID技术的广泛采用将会在可伸缩性、可用性、安全性、互操作性、集成、管理和消息传递等IT领域产生重要的意义。而BEA提供了一个可作为当前和长期RFID解决方案基础的参考架构。

本文适合对RFID技术具有一定了解的读者阅读。

RFID技术挑战

随着RFID技术的应用日益广泛，它的分布式特性与处理的大流量相结合，会在可伸缩性、可用性、安全性、互操作性、集成、管理和消息传递等七个重要领域引发一些严重的技术挑战。本节将逐一介绍这些挑战。

可伸缩性

随着RFID技术的应用日益广泛，企业需要处理分布在全球各个供应链中数以千计的读卡器的输入信息。快速发展将会挑战可伸缩性。需要处理的数据量非常庞大（读卡器每秒可捕获120个到400个信号），这样就产生了更大的挑战。

要处理这种级别的数据流量，需要使用非阻塞（non-blocking）I/O机制。当众多用户同时使用RFID访问一个应用程序时，大多数中间件解决方案为每个客户端打开一个插口，并为每个用户建立独有的线程。这种阻塞I/O技术严重限制了性能和可伸缩性。与此相反，非阻塞I/O可以使BEA WebLogic Server之类的中间件能够在多个并发用户中复用少量的读卡器线程，确保较高的性能和可伸缩性。

在处理读卡器的大流量数据流和进行消息传递时，需要大量使用I/O和网络。边缘服务器的CPU利用主要用于边缘服务器的复本检测和模式匹配。在要处理的数据量确定的情况下，网络带宽也会成为一个问题。“批量数据传输”（Boxcarring）——即，将多个请求包装在一个数据包中——可以舒缓网络堵塞问题。它还可以减少多个请求通过安全层及其它代码层所需的时间。

最后，边缘层中央数据储存库的使用会产生系统瓶颈，影响可伸缩性。例如，如果将从一组RFID读卡器捕获的数据全部写入数据库，进入数据库的巨大数据流会对性能产生严重影响。因此，应该在集成层处理数据库交互，这样就可以大大减少需要处理的数据。这种架构（如图1所示），相对于事件储存库方法，可以定义为事件源方法。

图1：在边缘层使用数据库会严重限制可伸缩性。边缘应作为事件源而非事件储存库。

可用性

为确保数据穿越整个基础架构和应用协议栈可靠地传递至正确的目的地，需要消除边缘层、集成层以及二者之间所有端点的单点故障（single points of failure，SPOF）。

在捕获数据和过滤数据的边缘层，对中央数据库的依赖性会影响可伸缩性和可用性。另一种做法是，系统可以将事件暂时保留在内存中，在使用之后删除，或者需要的话，可以记录在文件系统中。该实践可以大大降低对数据库可用性的依赖性。

在读卡器层，搭接部分——例如，月台门处的多功能读卡器或天线——可以提高在物理层准确捕获事件的可能性。边缘层可以管理此层中的读卡器，打开一些读卡器而关闭另外的一些，消除副本等等。

由于边缘不记录它传递的事件，而业务逻辑包含在集成层中，因此集成层的可用性至关重要。必须将任何包含商业负载均衡系统的RFID解决方案的互操作性都考虑在内，因为需要负载均衡系统来分配负荷并保证故障转移。集成层也必须能够通过集群化的JMS（Java Message Service）提供高度可用的消息传递功能。

为确保各层不会出现单点故障，客户可能希望使用集群化的数据库来辅助数据层。当然了，在集成层使用数据库比在边缘层使用更有效。

安全性

对于RFID来说，大量相关的潜在敏感数据使得安全性成为RFID系统至关重要的一个方面。最低级别，安全管理可以防止读卡器被关闭以及记录项被窃取。因此，必须通过验证、授权或审计来保护管理接口，这也许会通过SSL（Secure Socket Layer，安全套接字层）来实现。

但是，大部分RFID中间件解决方案都无法使用SSL。SSL“握手”机制牵涉到CPU密集型的计算，而这会影响边缘层处理其它CPU密集型作业（如：过滤）的能力。不使用SSL，边缘层会不太安全。因此，整个堆栈——包括读卡器层、边缘层和集成层——通常应包装到一个防火墙中，所有对堆栈的远程访问都要经过许可端口和协议。然后就可以实施周边身份验证（perimeter authentication），通过一个Web应用程序或Web服务远程管理堆栈。

最后，所选择的中间件平台必须易于与第三方提供者的身份验证、授权、LDAP和审计技术相集成，如图2所示。

图2：边缘服务器需要支持可插入的安全提供者接口。

互操作性

互操作性对于确保RFID的成功实现具有多重重要意义。或许，最迫切的需求是基于标准的JCA适配器要有效连接到诸如仓库管理系统或运输管理系统之类的应用程序。仅仅能够以私有格式发布JMS消息或事件是远远不够的；应用程序供应商，比如SAP、Yantra和Manhattan，要求事件以确定的格式呈现。适配器可以填平鸿沟，将信息以可接受的格式传播至恰当的应用程序。中间件解决方案应能够提供和支持适用于关键应用程序的适配器。

在其它方面，开箱即用的互操作性同样至关重要。例如，中间件应能够与防火墙提供者、身份验证、授权和审计提供者、负载均衡系统和JMS供应商进行互操作。读卡器的互操作性也非常重要。尽管读卡器通信协议的标准化一直在进行，但在出现一个占据主导地位的标准之前，每个中间件供应商都必须提供一个读卡器抽象层和互操作性解决方案。

设计良好的架构可以将读卡器抽象层置于边缘层，使得集成层具有读卡器无关性。也就是说，集成层无需考虑特定的读卡器协议或格式。

在读卡器抽象层，重要的一点是要公开所有特定于读卡器的命令（可能通过动态读卡器接口发现），而不是仅仅公开最不常见的命令。抽象层也应能够支持多种读卡器版本或读卡器供应商，而提供统一的抽象层，如图3所示。

图3：边缘服务器需要在异构环境中进行互操作。

集成

需要进行某种形式的企业应用集成（Enterprise Application Integration，EAI）才能实现RFID事件的全部价值。仅仅将事件从边缘服务器分派至一系列的应用程序还不能成为完美的解决方案，因为它会产生与安全性、可靠消息传递、性能、可用性、适配器连接、业务流程界定等相关的问题。

比较而言，EAI解决方案可提供对一个问题的全面概览。例如，一个在达拉斯和旧金山具有不同边缘服务器的组织，可以将事件发送至共同的EAI解决方案。涉及连接至不同边缘服务器的读卡器或天线的事件需要组合并关联到一个统一的EAI层。而且，复杂的事件组合不适用于这种情况，因为边缘层需要占用CPU周期。随着业务流程涉及到组织内部和外部越来越多的系统和人员，EAI层变得更为关键。

其它一些方面也使得集成解决方案更为必要。要连接至后端应用程序，需要使用基于标准的适配器；在可视化环境下汇编、监控和管理流程的能力也非常重要。通过通用抽象层（比如控件），在业务流程、门户、Web服务、RFID读卡器和其它元素之间构成复杂交互的能力可以大大提高。（有关控件的更多信息，请访问dev2dev Beehive页面）。最后，在传递事件时，必须在边缘层和实际集成层之间实现无缝集成。

管理

随着RFID在各个供应链中启用，管理整个架构的能力成为必要。以高级别来看，RFID的监控和管理包括两个方面：设备管理和对读卡器的配置。管理员需要一个管理整个架构的接口，该接口应该包含在一个集中式的门户框架中。

RFID管理解决方案还应与现有的管理提供者（例如，HP OpenView或Tivoli）无缝集成，需要支持SNMP和JMX之类的标准协议。理想的情况是，一个中央配置主机应能够将配置推行至边缘和整个供应链中的读卡器。

当配置内部复杂的分布式环境时，还会出现一些其它挑战，例如保护单元素服务和消除网络分区症状（split-brain syndrome）。要想RFID配置能够执行良好，必须解决这些挑战。

消息传递

保证的exactly-once（只发送一次）消息处理语义非常难以实现。即使在干预式消息传输过程中，发送方和接收方也都存在着消息中断的可能性。大部分中间件解决方案没有考虑确保exactly-once消息语义的需求。但是，如果不考虑这个问题会产生一系列问题——例如，单次交付报告会被无意地交付多次。仓库管理员就会认为向合作伙伴发送了两份报告而非一份；在不同的时间和地点多次发生这种情况，其效果就会非常惊人。

另一个重要因素是确保对消息排队和出队的事务性保证。如果消息没有按事务顺序排队，队列就没有保证；类似地，出队的消息也无法保证经过完全处理。其它方面的考虑主要是围绕操作幂等性——重新执行已部分完成的操作是否安全。

有时，需要进行连接的计算，特别是在发送方和接收方地理位置较远时。在这种情况下，如果一方依赖于另一方的同步响应，则网络中断就会带来整个操作的终止。这种情况下应该设为异步通信。

通常使用JMS进行异步通信。但是，如果JMS提供者在接收方，发送方如果无法对消息进行排队就会阻塞（或者引发错误并负责重新尝试发送）。因此，在发生这些问题的情况下，将JMS放在接收方不会对发送方有任何帮助。但是，如果要使用存储-转发消息传递机制，其中的许多问题都可以解决。这样，异步通信就可以恢复，因为存储-转发系统会负责继续发送消息、重试，等等。由于这个原因，JMS Bridge或存储-转发技术就显得至为重要。

参考架构层

BEA的参考架构由四个层组成：读卡器层、边缘服务器层、集成层和应用层。如图4所示。

图4：未来的参考架构

底层的读卡器以每秒120和400次的速度轮询标记，通常基于一个类似于运动传感器的触发器。无论在任何时间，IP可寻址的读卡器应由一个且仅由一个边缘服务器进行控制。该要求是避免与网络分区相关的问题所必需的。

边缘服务器定期轮询读卡器（例如每秒两次），删除复本，并进行筛选和设备管理。边缘服务器还负责创建ALE事件并将其分派至集成层。这种分派通常需要exactly-once消息语义（参见上面的“消息传递”）。

集成层接收多个ALE事件并将其合并到涉及各种系统和人员的工作流中，这些系统和人员是更大的业务流程的一部分。集成层通过基于标准的JCA适配器与打包应用程序（如：仓库管理系统或产品信息管理系统）交互。通过一些提供抽象层的控件和开源框架，该层也可以与系统一起工作，抽象层将后端组件公开为可重用组件。

集成层也可以通过Web服务接口与对象名解析服务（Object Naming Service，ONS）进行通信。类似于DNS服务器，ONS可以用于查寻独有的RFID标记ID以及确认附加的产品信息。集成层还必须维护电子产品代码信息服务（Electronic Product Code Information Service，EPC-IS）储存库，并从中查询数据，该库提供了ALE事件（如：通过供应链跟踪和追踪产品）的业务上下文。围绕EPC-IS储存库的标准目前正在定义。

最后，集成层还可以利用B2B消息（如：查询EPC-IS储存库的EDI或Web服务请求）通过防火墙中的网关与外部系统进行通信。

边缘与集成层的分离可以提高可伸缩性并降低客户成本，因为边缘层既是轻量级的，成本又低。随着应用服务器和数据库连接池的使用日益流行，互联网数据库连接的快速增长，随着业界从互联网通信转向RFID通信，需要有一个单独的层进行筛选并将连接集中到集成层。

控制消息通过管理门户流入系统，进入集成层，然后进入边缘，最后进入读卡器。自动配置和配置沿着这个链向下进行，而读卡器数据逆链而上进行筛选和传播。

结束语

本文研究了RFID服务器的七个隐含挑战：可伸缩性、可用性、安全性、互操作性、管理、消息传递和集成。本文还提供了一种参考架构，它包括整个生态系统，其中RFID起着重要作用。还讨论了常见的架构差异（如：数据库位于边缘层）及其产生的结果。

总而言之，当考虑RFID边缘服务器时，重要的是要选择一种轻量级的、可远程管理和远程自动配置的安全可靠并具有可伸缩性的RFID边缘服务器。其它特定于RFID的关键考虑事项包括：边缘服务器架构如何解决高I/O和网络带宽问题，由密集的模式匹配所引发的极高的CPU占用量，以及这些如何与边缘层的低CPU和内存占用量要求相配合。事务性可靠的消息，消息的有序性，exactly-once消息传递保证，以及在断开模式下执行的能力，这些对选择RFID服务器来说也是重要的考虑事项，特别是对于断开模式操作。

本文的参考架构和上述各注意事项在WebLogic RFID Server中均已实现。