集成 

    需要进行某种形式的企业应用集成（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的参考架构由四个层组成：读卡器层、边缘服务器层、集成层和应用层。

    底层的读卡器以每秒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中均已实现。