RFID开发介绍—Edge Server (2)

上篇文章中我们简单介绍了BEA Edge Server的安装、使用和简单的标签读、写过程。接下来我们介绍Edge Server中的一些其他读写方式和工作流模块，大家可以根据实际情况，在此基础上开发自己的应用。

一、关于Immediate读取方式的更多说明

１、事件周期和可靠性

有很多原因会造成读卡器不能在一个读周期内检测到标签，可能是因为RFID标签本身的不可靠特性，也有可能是在像托盘这样的大容器负载很多标签缓慢 通过读卡器时，有标签并没有产生ALE事件。通过ALE，我们配置一个事件周期包括多个读周期，这样就能提高所有的标签都被包含在结果报告中的概率。

我们可以通过下面的实验来模拟读不到某些标签的现象，并且通过配置ECSpec中的durationReadCycles来使一个事件周期包括多个读周期，以提高读卡成功率。

1. 打开两个读卡模拟器，在上一篇文章有操作说明。在其中一个读卡模拟器中设置“可靠性”参数为50%：



2. 重复运行ImmediateSample程序，观察运行结果，会发现并不是每次都可以读到所有标签。
3. 使 用ECSpec编辑器导入ECSpec.xml文件，并且定位到durationReadCycles参数，将当前值1修改为10。导出 ECSpec 到samplesImmediateSample 目录下，覆盖原有的文件。



4. 重新运行ImmediateSample，观察运行结果，会发现每次都可以读到所有标签。

２、复合读卡器

可以通过管理控制台定义“复合读卡器”，复合读卡器可以包含一个活着多个逻辑读卡器。使用复合读卡器而不是在ECSpec中定义多个逻辑读卡器带来 的好处是复合读卡器可以是业务上下文相关的，而不用考虑具体的读卡器，例如可以将复合读卡器命名为“DockDoor21”并且其中包含 “ConnecTerra1”, “ConnecTerra2”等一组逻辑读卡器，这样在应用程序的ECSpec中就只要按照“DockDoor21”使用就可以，而不用考虑是不是 “ConnecTerra1”, “ConnecTerra2”等等。

1. 打开管理控制台，在设备浏览器中选择“Composite Readers”，然后在右边窗口选择“New”：



2. 配置一个如下的，包含ConnecTerra2 和ConnecTerra4的复合读卡器CompositeReader1：



3. 在第二个读卡模拟器的第二个天线的配置中，将每个EPC值增加1，例如

gid-64-i.38000.171.1 应该改为gid-64-i.38000.172.1 ：



4. 使用管理控制台的测试功能进行测试：



5. 选 择读卡器为 CompositeReader1，默认在选择后测试就开始，可以选择左下角的开始、停止按钮控制测试。观察测试结果，可以看到14个标签，其中7个来自 于ConnecTerra2，7个是ConnecTerra4的，如果此时读卡模拟其中的“可靠性”参数还是设置为50%的话，可以看到某些EPC旁边有 红色的“X”，当可靠性提高的100%这些警告标志就会消失。

３、不同的边界条件

ALE规范允许设置不同的边界条件来控制事件周期的开始和结束。最基本的边界条件就是指定持续时间，如我们在前面做过的实验，指定持续5000ms或者包含10个读周期。此外，事件周期也可以是被外界事件所触发的。

其中一个很有意思并且很有用的边界条件是称为“稳定集合间隔时间”，稳定集合间隔时间是用来指定一段时间，在这段时间的读周期里面再没有新的标签出现，这是事件周期就算是结束。

下 面的图可以用来说明稳定集合间隔时间的概念。该图表示一些RFID标签会通过一个假想的读卡通道，例如一个叉车的托盘中有8个贴了RFID标签的物件要通 过仓库大门。当叉车通过大门的时候，在任何读周期都可能会检测到不同的RFID标签。例如，在第一个读周期检测到了EPC #1 and EPC #2，在第三个读周期检测到了EPC #1 and EPC #5，……

在经过一段持续的读周期后，所有的8个标签就都至少被检测到一次了。这样读卡器不会再检测到新的标签出现，在这样的状态持续“稳定集合间隔时间”后，就会生成ECReport。如下图中，每个读周期的时间设为1000ms，“稳定集合间隔时间”设为4000ms。

在第一个读周期，检测到EPC #1 和 EPC #2两个标签。因为这个连个新检测到的标签，所以此时Edge Server会开始一个持续时间为4000 ms的定时器，即“稳定集合间隔时间”。如果在接下来的4000 ms的定时中没有检测到新的标签，Edge Server就会产生ECReport并且返回给应用程序。

然而在第二个读周期，又有一个新的标签EPC #5被检测到。因为在“稳定集合间隔时间”内有新的标签被检测到，定时器复位，即重新开始计时4000 ms。类似的，在第四个和第六个读周期又出现了新的标签，所以定时器都被复位。

在第八个读周期中，最后一个新的标签EPC #6被检测到。在接下来的4个读周期中，不再有新的标签出现。所以事件周期结束，并且返回生成的ECReport。

下面我们来看看在BEA Edge Server中如何配置和使用这样的边界条件：

1. 使用管理控制台重新导入samplesImmediateSample 目录下面的ECSpec。选择CompositeReader1作为逻辑读卡器，设置“Stable Set Interval”为15000 ms。



2. 接下来将ConnecTerra2和ConnecTerra4的所有标签都去除选中，其中ConnecTerra2是第一个模拟器的第二个天线，ConnecTerra4是第二个模拟器的第二个天线。



3. 开始运行ImmediateSample，每3到4秒选中一个去掉的EPC，直到将所有的14个EPC都选中。在选中所有EPC后大约15秒，事件周期会结束。
4. 分析命令行窗口中产生的报告，注意其中的terminationCondition和totalMilliseconds值。可以参考如下ECReports：

Immediate Sample, XML-based
 sending request to Edge Server...
 ...received response.
Received the following ECReports:
t="http://schemas.connecterra.com/EPCglobal-extensions/ale">

 
  
   
    
     urn:epc:tag:gid-64-i:38000.172.1
    
    
      …………
    
     urn:epc:tag:gid-64-i:38000.4971.7
    
   
   
    14
   
  
  
 

Application specific data can go hereonData>


 SimReadr2
 SimReadr

150

5. 也可以使用ECSpec的测试功能来运行上述的测试。

二、用subscribe方式读取标签信息

１、运行Subscribe示例

Subscribe示例是使用ALE的“subscribe”方式实现异步报告发布，同时也展现了一起ALE API中的其它可管理方式。

它和“Immediate”示例不同的地方是：

• 可以定义多个ECSpecs，每个都有各自的名字
• 使用subscribe命令，给“事件周期”添加一个或者多个“订购者”，来获取报告
• 在定义“事件周期”和“订购者”之后，Edge Server执行“事件周期”，并且异步的给“订购者”返回报告

具体操作步骤如下：

1. 打开读卡模拟器、Edge Sever和管理控制台
2. 打开资源管理器，浏览目录 samples SubscribeSample.
3. 修改run.bat

set EDGEHOST=localhost

set EDGEPORT=6060

4. 点击run.bat，注意到命令行窗口显示的命令行参数使用方法
5. 使用ECSpec editor导入SubscribeSample 目录内的ECSpec.xml
6. 导入成功后，选择File->Deploy As，部署一个新的叫做“MengSpec”的ECSpec
7. 再部署一个叫做“Meng2Spec”的ECSpec
8. 在命令行输入如下命令：

>run subscribe Meng2Spec console:test

9. 看到输出：

Target ALE Service: http://localhost:6060/axis/services/EPCglobalALEService

ubscribing notification handler for spec Meng2Spec in Edge Server.

10. 观察管理控制台的变化：



11. 运行以下命令可以停止发布报告：

>run.bat unsubscribe Meng2Spec console:test

由于SubscribeSample的代码相对比较冗长，限于篇幅，本文不在这里进行详细的分析。读者可以自己参看代码和相应的注释，尤其注意其中的非immediate方式的处理过程和所调用的ALE API。

２、报告和报告发送方式

BEA Edge Server 支持很多种报告发送方式，包括命令行方式、文件系统、HTTP和TCP等。前面我们已经看到使用命令行方式，下面以文件系统为例展示其它的报告发送方式。

1. 首先创建两个临时目录：

>mkdir c: emple1

>mkdir c: emple2

2. 执行如下命令:

>run.bat subscribe MengSpec file:///c:/temp/ale1

3. 执行如下命令:

>run.bat subscribe Meng2Spec file:///c:/temp/ale2/file.txt

4. 在运行几秒钟以后, unsubscribe 上述的ECSpecs (MengSpec and Meng2Spec).

>run.bat unsubscribe MengSpec file:///c:/temp/ale1

>run.bat unsubscribe Meng2Spec file:///c:/temp/ale2/file.txt

5. 察看这两个临时目录下面的内容。在ale1目录下，由于在命令行指定的是目录，所以不同的ECReports被保存在不同的文件中，而在ale2目录下，ECReports被保存在同一个在命令行指定了名称的文件中。

三、Edge Server和工作流

BEA Edge Server 提供可配置的工作流模块，使用户可以快速配置中间件来处理RFID部署环境中的通用物料运输工作流。下面我们讨论一个比较特殊的工作流—有方向工作流。

有方向工作流的思想非常简单：用户或者说是应用程序可能会需要了解一个标签移动的方向，例如一个贴有标签的商品正在从仓库移动向商场货架。有方向工作流模块记录附加了时戳的流动方向，并且可以通过配置将该数据作为一个ECReport发送给企业中央服务器。

一个有方向的工作流最少需要两个读卡器，然后由标签先通过其中一个读卡器后通过另外一个读卡器而推断出其流动方向。在实际部署中，会有很多异常情况导致方向推断过程出错，例如两个读卡器同时读到同一个标签或者在一个读卡器读到该卡后，另一个读卡器一直没有检测到该卡。

限于文章篇幅，大家可以参考下面链接的示例来建立自己的工作流：http://edocs.bea.com/rfid/edge_server/docs21/workflow_reference/config_use.html#wp424256

在这篇文章中，我们介绍了Edge Server中Immediate方式的一些更复杂得配置、一些其他读写方式和工作流模块。限于作者的水平和文章的篇幅，没有能够更多深入探讨和分析，希 望能起到让大家入门和上手的效果吧。大家在实际项目中，可以根据具体的需求情况，在本文介绍的基础上开发自己的应用程序。如果需要对BEA Edge Server体系结构有更完整地认识或者需要能具体深入地了解该产品的话，可以参考BEA的文档：http://edocs.bea.com/rfid/edge_server/docs21/

RFID开发介绍—Edge Server(1)

接下来的文章会介绍如何安装、配置和部署BEA的RFID产品，包括BEA Edge Server, BEA Enterprise Server和 BEA Compliance Express。默认的，每个步骤都是接下来步骤的基础。并且该配置是基于WebLogic Server 9.1的，本篇首先介绍BEA Edge Server。

一. 安装及使用

1. 产品安装（以windows为例）

• 从以下网址下载或者拷贝rfid_edge210_win32.exe

　　http://commerce.bea.com/showproduct.jsp?family=RFIDEDGE&major=2.1&minor=0

• 双击该文件，运行安装程序
• 看到介绍面板后，点击“下一步”
• 看到许可面板后，接受许可，点击“下一步”
• 看到安装目录选择面板，选择路径或者默认，点击“下一步”
• 看到安装类型面板，选择“快速”，点击“下一步”
• 接下来的配置都按照默认值，点击“下一步”
• 浏览安装信息摘要，点击“安装”
• 选择“完成”结束安装

2. 打开阅读器模拟器、Edge Server和管理控制台

1. 打开资源管理器，浏览到in 目录
2. 打开阅读器模拟器:双击RunReaderSim.bat.



3. 修改/etc/edge.props文件，修改后如下：

　　com.connecterra.ale.servicePort = 6060

　　com.connecterra.ale.savantID = SAVANT_ID

　　com.connecterra.ale.siteID = SITE_ID

　　com.connecterra.ale.telemetryPeriod = 5000

　　或者可以使用Edge Server Configuration Wizard来进行配置，配置过程如下：

4. 从windows菜单选择运行Configuration Wizard 或者直接运行/common/bin/config.cmd命令：



5. Configuration Wizard打开后，首先进入欢迎页面，选择其中的下一步。
6. 在出现的页面中配置各参数如下 ：



7. 选择下一步，在确认页面中选择“创建”，最后确认。
8. 打开Edge Server:浏览到in 目录，双击 RunEdgeServer.bat.



9. 修改/etc/admin-console.props，修改后如下：

　　com.connecterra.ualegui.edgeServerURLs=http://localhost:6060

10. 打开管理控制台: 浏览到in 目录，双击 RunAdminConsole.bat.

3. 使用管理控制台和ECSpecs来验证操作

　　安装BEA Edge Server是相对比较容易的，但是需要验证它的工作是否正确就需要我们进一步学习了。使用管理控制台和阅读器模拟器，我们可以快速的配置一个“事件周 期”（“Event Cycle Specification”, or “ECSpec”）来模拟读取标签。下面就是创建一个简单的ECSpec并且使用管理控制台的测试特性。

　　在开始配置前，首先需要理解的 一点是RFID应用程序其实就是BEA Edge Server的一个客户端。BEA Edge Server实现了ALE（Application Level Events）规范，ALE客户端需要定义一个ECSpec，然后提交给ALE接口（即Edge Server）。Edge Server使用ECSpec的内容来控制阅读器的限制条件、使用哪个逻辑阅读器、报告返回等等。其中限制条件可能是例如何时开始读卡、何时停止读卡；一 个逻辑阅读器是一个任意的RFID阅读点，通常是具有统一命名的一组天线；报告指Edge Server返回给应用程序的信息。

　　具体操作如下：

1. 在管理控制台里面左边的设备浏览器中，选中ECSpecs



2. 在右边选择“NEW”，这样会打开ECSpec Editor



3. 使用“>>”按钮将ConnecTerra1 和ConnecTerra2两个逻辑阅读器到选择窗口。
4. 在“Stop”区，选中“Duration”，输入5000，这个域以毫秒为单位。配置好地ECSpec如下：



5. 在左边选择“Reports”
6. 在右边选择“New Report”，就按默认设置创建名为“Report_0”的报告，配置后的窗口如下：



7. 在菜单中选择ToolsàTest，看到如下窗口：



8. 在管理控制台可以通过选择设备浏览器中的RFID Devices下面的SimReadr来查看设备统计信息。有两组图，每个逻辑阅读器或者天线，每个逻辑阅读器都可以看到如下信息：
9. 读 周期时间—一个完整的读周期所用的时间，一个读周期是Edge Server和阅读器之间的最小交易单位，它被三个因素影响：(1) Edge Server和阅读器之间协议交互所用的时间，这和驱动设计和实现有关；(2)网络延迟；(3)阅读器内部读卡机制、设计等等。
10. 读周期数-- Edge Server执行的总读周期数
11. 标签数：Edge Server所能读到的标签数

4. 配置多个阅读器模拟器

　　在本节配置完成后，我们从逻辑上将实现如下的部署图：

　　首先，创建第二个阅读器，并且配置Edge Server来使用它

1. Make a copy of, and put the copy in the bin directory.
1. 复制RunReaderSim.bat，放在bin目录下，重命名为RunReaderSim2.bat
2. 打开RunReaderSim2.bat，将READER_PORT修改为5051，保存，关闭文件
3. 运行新的模拟器(RunReaderSim2.bat).
4. 在管理控制台配置Edge Server使用新的阅读器：选择设备管理器里面的RFID设备，在右边窗口选择SimReadr，并且Clone



5. 将新阅读器的名字改为“SimReadr2”，Reader Port 改为5051.两个逻辑天线的名字修改为“ConnecTerra3” 和“ConnecTerra4”.



• 确定后，新的配置如下：



6. 为了测试，需要在ECSpec中添加新的逻辑阅读器，首先导出已经存在的ECSpec，然后再导入并且添加新的逻辑阅读器。

二. 读取标签信息

1. 运行Immediate示例

　　Immediate示例使用ALE“Immediate”方式来演示同步报告发布。

1. 打开阅读器模拟器、Edge Sever和管理控制台
2. 打开资源管理器，浏览目录 samplesImmediateSample.
3. 修改run.bat

　　set EDGEHOST=localhost

　　set EDGEPORT=6060

4. 点击run.bat，观察输出，注意报告有7个标签



5. 使用管理控制台ECSpec editor导入示例的ECSpec，ECSpec文件也在该目录中



　　测试导入的ECSpec：

2. 程序分析

/**
* ImmediateSample 是使用ALE api  从指定的逻辑读卡器读取一个EPC 列表的小
* 程序
* ECSpec 将从一个XML文件中读取，周期报告也将以XML格式打印出来
*/
public class ImmediateSample
{
//程序的使用说明，其中的命令行参数ecSpecFilename 应该是ECSpec.xml，//aleServiceURL 形如：http://localhost:6060/axis/services/EPCglobalALEService。 
   private static void usage()
   {
       System.out.println(
           "usage: ImmediateSample  ");
       System.exit(1);
   }
 
   public static void main(String[] args) 
   {
       System.out.println( "Immediate Sample, XML-based" );
     
       //分析命名行参数   
       if ( args.length != 2 )
           usage();

       String aleServiceURL = args[0];
       String ecSpecFilename = args[1];
  
       try
       {
           // 创建一个ALE客户端实例
           ALE aleClient = new SOAPALEClient(new URL(aleServiceURL));
   
           // 从XML文件读取ECSpec (Event Cycle Specification)
           // ECSpec 包括定义事件周期的所有参数，也可以在程序中指定
           ECSpec myECSpec = readECSpec(ecSpecFilename);
      
           // 使用 ALE.immediate()方法，发出事件请求
           // immediate() 在一个事件周期完成后会阻塞，并且返回报告
           System.out.println( "  sending request to Edge Server...");
           ECReports myECReports = aleClient.immediate(myECSpec);
           System.out.println( "  ...received response.
");

           printECReports(myECReports);
       }
       catch (Exception e)
       {
           e.printStackTrace();
       }
   }
 
   /**
    * 从XML文件读取ECSpec的辅助方法
    */
   private static ECSpec readECSpec(String ecSpecFilename)
       throws IOException,
              XMLDeserializerException
   {
       // ECSpec 和ECReports等对象可以转换为XML 表现形式
       // XMLSerializationFactory是一个单态的工厂，从中可以通过转换完成XML
       // 的序列化和反序列化     
       // 下面，使用XML反序列化将XML 中的内容转换为一个ECSpec 对象实例
       XMLSerializationFactory factory =
           XMLSerializationFactory.getInstance(
               XMLSerializationSyntax.EPCGLOBAL_ALE_1_0);
       XMLDeserializer deserializer = factory.createDeserializer();

       FileReader fileReader = new FileReader(ecSpecFilename);

       ECSpec ecSpec = deserializer.deserializeECSpec(fileReader);
       return ecSpec;
   }

   /**
    * 将XML形式的ECReports输出到控制台
    */
   private static void printECReports(ECReports ecReports)
       throws XMLSerializerException,
              IOException
   {
       System.out.println("Received the following ECReports:
");
 // XMLSerializationFactory是一个单态的工厂，获取实例 
       XMLSerializationFactory factory =
           XMLSerializationFactory.getInstance(
               XMLSerializationSyntax.EPCGLOBAL_ALE_1_0);
       XMLSerializer serializer = factory.createSerializer();

         //使用XML序列化将ecReports对象实例转化为XML形式，并输出.
       Writer w = new OutputStreamWriter(System.out);
       serializer.serialize(ecReports, w, true);
       w.flush();
   }
}

三. 写入标签信息

1. 运行 ImmediateProgram 示例

1. 确保只打开一个阅读器模拟器，并且只选中其中一个天线的一个标签：



2. 打开命令行窗口，浏览到samplesImmediateProgramSample
3. 执行如下命令：

　　>run.bat urn:epc:tag:gid-64-i:1.4.10

4. 运行结果应该是XML格式的PCWriteReport，表示写入TAG程序运行的结果，如下：

   Received the following PCWriteReport:

"=0" totalMilliseconds="531" totalTrials="1" xmlns="http://schemas.con
necterra.com/alepc">
application specific data can go here
true
SUCCESSFUL

 SimReadr


0
urn:epc:tag:gid-64-i:1.4.10
ConnecTerra1
Press any key to continue . . .

• 元素表示写入程序成功，元素相应的也设置为SUCCESSFUL ；如果写入出现问题， 将会提供诊断用的信息，例如CACHE_EMPTY, READER_ERROR等等
• 元素表示那个物理阅读器参与了标签写操作，我们的操作中可以看到是SimReadr
• 为空，表示写操作周期中没有失败的阅读器
• 被设置为零，可以在程序中设置该值，该值也与ECSpec中的设置相关。
• 显示写入标签的值: urn:epc:tag:gid-64-i:1.4.10
• Finally, indicates that the logical reader ConnecTerra1 was the logical reader that wrote this tag.

程序分析

/**
* ImmediateProgramSample 是使用ALEPC api来通过逻辑读卡器将EPC值写入标
* 签的一个简单程序
*/
public class ImmediateProgramSample
{
//程序使用说明  
   private static void usage()
   {       
       System.out.println("usage: ImmediateProgramSample ");
       System.exit(1);
   }
 
   public static void main(String[] args) 
   {
       System.out.println( "Immediate Program Sample, XML-based" );

       //分析命名行参数   
       if ( args.length != 3 )
           usage();
//程序的使用说明，其中的命令行参数pcSpecFilename 应该是PCSpec.xml，//aleServiceURL 形如：http://localhost:6060/axis/services/EPCglobalALEService。
// epcVal是EPC值
       String aleServiceURL = args[0];
       String pcSpecFilename = args[1];
       String epcVal = args[2];
  
       try
       {
           // 创建一个ALEPC客户端实例.
           ALEPC aleClient = new AxisALEPCClient(new URL(aleServiceURL));
 
 // 从XML文件读取PCSpec (Programming Cycle Specification)
           // PCSpec包括定义写入周期的所有参数，也可以在程序中指定          
           PCSpec pcSpec = readPCSpec(pcSpecFilename);     
          
           // 使用ALEPC.immediate()方法，发出事件请求
           // immediate() 在一个事件周期完成后会阻塞，并且返回报告
System.out.println( "  sending request to Edge Server...");
           PCWriteReport writeReport = aleClient.immediate(pcSpec, new URI(epcVal));
           System.out.println( "  ...received response.
");

           printWriteReport(writeReport);
       }
       catch (Exception e)
       {
           e.printStackTrace();
       }
   }
 
   /**
    *从XML文件读取PCSpec的辅助方法
    */
   private static PCSpec readPCSpec(String pcSpecFilename)
       throws IOException,
              PCXMLDeserializerException
   {       
       // PCSpec和PCWriteReport等对象可以转换为XML 表现形式
       // PCXMLSerializationFactory是单态工厂类，从中可以通过转换完成XML
       // 的序列化和反序列化     
       // 下面，使用XML反序列化将XML 中的内容转换为一个PCSpec对象实例       
       PCXMLSerializationFactory factory = PCXMLSerializationFactory.getInstance();
       PCXMLDeserializer deserializer = factory.createDeserializer();

       FileReader fileReader = new FileReader(pcSpecFilename);

       PCSpec pcSpec = deserializer.deserializePCSpec(fileReader);
       return pcSpec;
   }

   /**
    * 将XML形式的PCWriteReport输出到控制台
    */
   private static void printWriteReport(PCWriteReport writeReport)
       throws PCXMLSerializerException,
              IOException
   {
       System.out.println("Received the following PCWriteReport:
");  
      
       //获取PCXMLSerializationFactory的实例，序列化PCWriteReport
       PCXMLSerializationFactory factory = PCXMLSerializationFactory.getInstance();
       PCXMLSerializer serializer = factory.createSerializer();
     
        //使用XML序列化将writeReport对象实例转化为XML形式，并输出
       Writer w = new OutputStreamWriter(System.out);
       serializer.serialize(writeReport, w, true);
       w.flush();
   }
}

　　本篇我们简单介绍了BEA Edge Server的安装、使用和简单的标签读、写过程，大家可以根据实际情况，在此基础上开发自己的应用。后面我们还会介绍Edge Server中的一些其他读写方式和工作流模块。

RFID开发介绍—概述

RFID (射频识别技术)是一种使能技术，其本身并没有提供多少价值，但它却能使公司开发出相应应用来创造价值。

概述

　　RFID系统在实际应用中，电子标签附着在待识别物体的表面，电子标签中保存有约定格式的电子数据。读卡器可无接触地读取并识别电子标签中所保 存的电子数据，从而达到自动识别物体的目的。读卡器通过天线发送出一定频率的射频信号，当标签进入磁场时产生感应电流从而获得能量，发送出自身编码等信 息，被读取器读取并解码后送至电脑主机进行相关处理。

　　通常在读卡器读标签的时候给主机系统传递三个信息：标签ID，读卡器自己的ID，读标签的时间。 通过获取这个读卡器的位置，就知道了该产品的位置，以及它是什么产品，然后根据时间数据跟踪标签，就随时随地知道产品的位置了。

系统结构

　　一个完整、典型的RFID系统通常由下面四个模块组成：

• 标签(Tag)
• 读卡器（Reader）
• RFID中间件
• 应用程序

标签(Tag)

　　标签由天线和芯片组成，天线在标签和读卡器间传递射频信号，芯片里面保存每个标签具有的唯一电子编码和用户数据。每个标签都有一个全球唯一的 ID号码—UID，UID是在制作芯片时放在ROM中的，无法修改；用户数据区是供用户存放数据的，可以进行读写、覆盖、增加的操作。

读卡器（Reader）

　　读取（或写入）标签信息的设备，可设计为手持式或固定式。读卡器对标签的操作有三类：

• 识别(Identify):读取UID；
• 读取(Read):读取用户数据；
• 写入(Write):写入用户数据

RFID中间件

　　RFID中间件是将底层RFID硬件和上层企业应用结合在一起的粘合剂。 虽然原则上的中间件是横向的软件技术，但在RFID系统中，为使其更适用于特定行业，RFID中间件往往会针对行业做一定的适配工作。

　　在RFID系统这种具体情况下，中间件层除通常的功能外，还有以下特定功能：

• 使阅读/写入更加可靠
• 把数据通过读卡器网络推或者拉到正确位置(类似路由器)
• 监测和控制读卡器
• 提供安全读/写操作
• 降低射频干扰
• 处理标签型和读卡器型事件
• 应用通知
• 接受并且转发来自应用的中断指令
• 给用户提供异常告警

　　从体系结构上讲，RFID中间件还可以分为子层，包括边缘层和集成层。边缘与集成层的分离可以提高可伸缩性并降低客户成本，因为边缘层既是轻量级的，成本又低。

　　边缘层定期轮询读卡器，删除复本，并进行筛选和设备管理。边缘服务器还负责创建ALE事件并将其分派至集成层。

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

1）边缘层

　　边缘层通常提供的功能有标准的设备支持和管理、高效的捕获数据和过滤数据、创建ALE事件并将其分派至集成层等。

　　边缘层应该 支持丰富的设备，包括流行的 RFID 读卡器和打印机，以及各类条形码识别器、指示灯、LED 显示、电眼和可编程逻辑控制器 (PLC)。它可以运行在单独的计算机上，也可以嵌入新出现的其他设备，如路由器中。应该符合 EPCglobal应用级别事件 (ALE) 标准，提供易于使用的标签写入和其他类型设备的扩展功能，并支持 ISO 和EPCglobal 标签标准（包括 Gen2）。

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

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

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

2）集成层

　　集成层接收多个ALE事件并将其合并到涉及各种系统和人员的工作流中，这些系统和人员是更大的业务流程的一部分。它通常提供的功能有安全性、互操作性、管理、消息传递和集成等等。

• 安全

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

• 互操作

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

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

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

• 管理

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

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

• 消息传递

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

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

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

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

• 集成

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

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

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

应用程序

　　RFID应用通常根据来自标签的数据执行特定的动作，例如资产跟踪和排序，在客户买走某个商品后在系统中将其删除。相反的，应用也会根据企业内 部的信息对标签进行写入，例如对已经售出的商品写入“已销售”信息或者对出发的运货的运输车写入“零售路线”的信息。RFID应用通常会根据不同的行业领 域进行分类：

1. 仓储库存、资产管理领域

　　因为电子标签具有读写与方向无关、不易损坏、远距离读取、多物品同时一起读取等特点，所以可以大大提高对出入库产品信息的记录采集速度和准确性；减少库存盘点时的人为失误库，提高存盘点的速度和准确性。

2. 产品跟踪领域

　　因为电子标签能够无接触的快速识别，在网络的支持下，可以实现对附有RFID 标签物品的跟踪，并可清楚了解到物品的移动位置，如已经成功应用的symbol公司为香港国际机场和美国McCarran 国际机场的行李跟踪系统和中国铁路列车监控系统。

3. 供应链自动管理领域

　　可以设想，如果商场的货架部署的电子标签读写器，当货物减少时，系统会将缺货信息自动传递给仓库管理 系统，并且系统会将缺货信息自动汇总并传递给生产厂家。电子标签自动读写和在网络中信息的方便传递功能将大大提高供应链的管理水平，通过这个过程降低库 存，提高生产的有效性和效率，从而大大提供企业的核心竞争力。

　　电子标签在零售商店中的应用包括从电子标签货架、出入库管理、自动结算等各个方面。

　　沃尔玛公司是全球 RFID电子标签最大的倡导者，现在 WAL-MART 的两个大的供货商 HP 和 P&G 已经在他们的产品大包装上开始使用电子标签。

4. 防伪领域

　　RFID 电子标签的应用并不是为防伪单独设计的，但是电子标签中的唯一编码、电子标签仿造的难度以及电子标签的自动探测的特点，都使电子标签具备了产品防伪和防盗 的作用，在产品上使用电子标签，还可以起到品牌保护的功能，防止生产和流通中盗窃的功能。可广泛应用于药品、品牌商品防伪、门禁、门票等身份识别领域。

5. 医疗卫生领域

　　RFID技术在医疗卫生领域的应用包括对药品监控预防，对患者的持续护理、不间断监测、医疗记录的安全共享、医学设备的追踪、进行正确有效的医 学配药、 以及不断的改善数据显示和通信，还包括对患者的识别与定位功能，用来防止医生做手术选错了病人和防止护士抱错了出生的婴儿的事情发生。

RFID相关标准

　　目前，RFID还未形成统一的全球化标准，市场为多种标准并存的局面，但随着全球物流行业RFID大规模应用的开始，RFID标准的统一已经得 到业 界的广泛认同。RFID系统主要由数据采集和后台数据库网络应用系统两大部分组成。目前已经发布或者是正在制定中的标准主要是与数据采集相关的，其中包括 电子标签与读写器之间的空气接口、读写器与计算机之间的数据交换协议、RFID标签与读写器的性能和一致性测试规范、以及RFID标签的数据内容编码标准 等。后台数据库网络应用系统目前并没有形成正式的国际标准，只有少数产业联盟制定了一些规范，现阶段还在不断演变中。

　　RFID标准争夺 的核心主要在RFID标签的数据内容编码标准这一领域。目前，形成了五大标准组织，分别代表了国际上不同团体或者国家的利益。 EPC Global是由北美UCC产品统一编码组织和欧洲EAN产品标准组织联合成立，在全球拥有上百家成员，得到了零售巨头沃尔玛，制造业巨头强生、宝洁等跨 国公司的支持。而AIM、ISO、UID则代表了欧美国家和日本；IP-X的成员则以非洲、大洋洲、亚洲等国家为主。比较而言，EPC Global由于综合了美国和欧洲厂商，实力相对占上风。

• EPC Global

　　EPC Global是由UCC和EAN联合发起的非盈利性机构，全球最大的零售商沃尔玛连锁集团、英国Tesco等100多家美国和欧洲的流通企业都是EPC的 成员，同时由美国BEA公司、IBM公司、微软、Auto-ID Lab等进行技术研究支持。此组织除发布工业标准外，还负责EPCgobal号码注册管理。EPC Global系统是一种基于EAN·UCC编码的系统。作为产品与服务流通过程信息的代码化表示，EAN·UCC编码具有一整套涵盖了贸易流通过程各种有 形或无形的产品所需的全球唯一的标识代码，包括贸易项目、物流单元、位置、资产、服务关系等标识代码。EAN·UCC标识代码随着产品或服务的产生在流通 源头建立，并伴随着该产品或服务的流动贯穿全过程。EAN·UCC标识代码是固定结构、无含义、全球唯一的全数字型代码。在EPC标签信息规范1.1中采 用64-96位的电子产品编码；在EPC标签2.0规范中采用96-256位的电子产品编码。

• ISO标准

　　国际标准化组织(ISO)制定也制定了RFID自动识别和物品管理的一系列标准。例如，ISO创造了使用RFID跟踪牛群的标准。 ISO11784定义了如何组织标签的数据结构，ISO11785定义空中接口协议。国际标准化组织也起草、建立了RFID标签在支付系统、非接触智能卡 和接触式卡领域的空中接口标准(ISO14443和ISO15693)。它也建立了测试RFID标签和读卡器兼容性的标准(ISO18047)和测试 RFID标签和读卡器性能的标准 (ISO18046)。下面是其中的一些标准：

• ISO 15693—Smart Labels
• ISO 14443—Contactless payments
• ISO 11784—Livestock
• ISO 18000 - 包括可能被用来追踪货物供应链的空中接口协议。 它们基本覆盖了用于RFID系统的频率范围。 它的七个组成部分是：
• 18000—1: Generic parameters for air interfaces for globally accepted frequencies
• 18000—2: Air interface for 135 KHz
• 18000—3: Air interface for 13.56 MHz
• 18000—4: Air interface for 2.45 GHz
• 18000—5: Air interface for 5.8 GHz
• 18000—6: Air interface for 860 MHz to 930 MHz
• 18000—7: Air interface at 433.92 MHz

BEA参考实现

　　BEA在EPCglobal-即RFID的国际标准组织内一直保持领先地位。BEA WebLogic RFID 产品系列是第一个端到端、基于标准的RFID 基础架构平台，能自动运行具有全新 RFID 功能的业务流程。领先的无线射频识别 (RFID) 基础架构技术与 BEA 面向服务架构 (SOA) 驱动的平台的强强结合，使企业可利用网络边缘和数据中心资产，并在所有层次获得无与伦比的扩展性和性能。BEA的参考架构由四个层组成：读卡器层、边缘服 务器层、集成层和应用层。如下图所示。

　　底层的读卡器以特定的速度轮询标记，通常基于一个类似于运动传感器的触发器。无论在任何时间，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系统的工作原理、系统结构、标准化工作和BEA公司的RFID参考实现。在后续的文章中我们会教大家一步一步的学 习使用BEA公司提供的中间件产品来构建RFID企业应用。其中涉及的产品有包括BEA Edge Server, BEA Enterprise Server和 BEA Compliance Express。

WLS 9.1与MQ v5.3 通过JMS Bridge通信配置

最近参与一个系统的原型开发,原型要求演示WebLogic Server9.1与其他第三方产品的通信支持,包括与IBM MQSeries的双向交互、与Tuxedo的双向交互、支持与.NET的通过Web Service交互等。我负责完成与IBM MQSeries的双向交互这部分，在网上找了不少文章，发现其中基本都是基于WebLogic Server 8.1实现的。因为WebLogic Server 9.1在JMS上有很大的增强，所以我参考以前的文章，自己实现了WebLogic Server 9.1与IBM MQSeries 5.3的双向交互并且进行了测试。想必很多同行会遇到跟我一样的问题，特此撰文一片跟大家分享。本文配置在window xp上测试成功。

概述

　　目标是实现WebLogic Server 9.1和IBM MQSeries5.3之间的的双向交互，包括：

• WebLogic Server 9.1消息转发给IBM MQSeries5.3
• IBM MQSeries 5.3消息转发给WebLogic Server 9.1

　　具体地，将WebLogic Server9.1队列WLSSendQueue的消息转发到IBM MQSeries 5.3队列MQReceiveQueue，同时将IBM MQSeries 5.3队列MQSendQueue的消息转发到WebLogic Server 9.1队列WLSSendQueue。

　　WebLogic Server包含一个完整的、有丰富特性的消息服务器。第三方的消息服务器(如IBM MQSeries)，只要其提供了JMS API的实现，也可以在其中运行。Messaging Bridge是一种由WebLogic Server提供的J2EE设备，用于转发两个消息提供者的消息。你可以使用Messaging Bridge将消息从一个消息提供者的目的地（队列或者主题）移至另外一个消息提供者的目的地。因此，当WebLogic应用程序需要与第三方消息提供者 （比如IBM MQSeries）进行交互时，Messaging Bridge就可以承担这个中间角色。我们需要做如下配置：

• 通过WebLogic控制台建立两个WebLogic队列：发送队列WLSSendQueue和接收队列WLSReceiveQueue。
• 类似地，通过MQ资源管理器建立两个MQ本地队列：发送队列MQSendQueue和接收队列MQReceiveQueue。
• 为 了实现消息转发需要建立两个Messaging Bridge：WLS2MQBridge 和MQ2WLSBridge 。WLS2MQBridge：将WebLogic发送队列WLSSendQueue的消息转发到MQ接收队列MQReceiveQueue； MQ2WLSBridge：将MQ发送队列MQSendQueue的消息转发到WebLogic接收队列WLSReceiveQueue。
• 为 了实现事务性消息转发， WebLogic需要使用XAQueueConnectionFactory，而MQ需要使用MQXAQueueConnectionFactory。这 就确定了WebLogic需要使用支持XA的连接工厂，MQ必须采用绑定的模式，并且WebLogic和MQ必须安装在同一台机器上。

WLS配置

　　WebLogic Server 9.1在WebLogic JMS的配置、部署和动态管理方面引入了重要的改进。它对JMS 1.1规范提供官方支持。此外，在系统中添加了人们期待已久的消息排序高级特性。XML API的XML消息处理功能得到了增强。在WebLogic 9.1平台上使用JMS非常轻松有趣、可靠且迅速。下面是现有新特性中的一些亮点。

• 自动化的 JMS 故障恢复

　　自动化的JMS故障恢复是业内期待已久的特性。JMS利用“Automatic WebLogic Server Migration”特性来提供自动化的JMS故障恢复。在整个WebLogic Server实例进行故障恢复时，JMS也将自动从故障中恢复过来。尽管其他的一些JMS服务器提供商已经利用一些复杂装置提供了这样的功能，但 WebLogic 9.1的实现是最直观而清晰的。

• 排序单元

　　消息排序是大多数消息处理应用程序的一项基本要求。WebLogic Server JMS即使在集群环境中也能确保消息的顺序处理。它甚至可以定义多个组来将消息分组，这样每个组都拥有自己的处理顺序（如图1所示）。



• 存储转发 (SAF)

　　WebLogic存储转发(store and forward, SAF)服务使WebLogic Server能在通过WebLogic Server实例部署的应用程序间可靠地交付信息。SAF的强大功能使得我们可以很容易地将多个消息服务链接在一起（如图2所示）。



• Messaging Bridge具有如下优点：
• 不需要编码，纯配置，加速你的开发；
• 灵活的体系结构，容易配置多个Messaging Bridges，并且而且可以动态的启动和停止单个Messaging Bridge；
• 采用即取即用的MQ 适配器，实现全面的MQ JMS 支持，能够设定MQ 主题查询；
• 充分利用WebLogic容器进行服务管理，并且集中所有的Bridges资源在一个线程池；
• 全面的事务处理能力，两阶段事务处理；
• 全面的JCA 支持；
• 确保服务质量和连接管理，实实在在的一次性服务；
• 控制台监视能力；
• 集成BEA WebLogic应用与外部消息提供商，以便将新的应用与现有的投资连接起来。

创建Server域

　　创建Server Domain, domain名称jms_domain

修改启动文件

　　修改WebLogic的启动文件startWebLogic.cmd。将IBM MQSeries和IBM MQSeries Java的安装目录加到WebLogic path下，同时将MQ JMS Java类包加入到WebLogic classpath下：

@rem added the following to configure messaging bridge with local MQSeries installation
set MQ_INSTALL_PATH=D:\installed\MQ
set MQ_JAVA_INSTALL_PATH=D:\installed\MQ\Java
set MQ_JAVA_LIB=%MQ_JAVA_INSTALL_PATH%\lib
set MQ_CLASSPATH=%MQ_JAVA_LIB%\com.ibm.mq.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\com.ibm.mqbind.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\com.ibm.mqjms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\fscontext.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\jms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\jndi.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\jta.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\ldap.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%\providerutil.jar

set MQ_PATH=%MQ_INSTALL_PATH%\in;%MQ_JAVA_INSTALL_PATH%\in;
      %MQ_JAVA_INSTALL_PATH%\lib
set PATH=%MQ_PATH%;%PATH%
set CLASSPATH=%MQ_CLASSPATH%;%WEBLOGIC_CLASSPATH%;
      %POINTBASE_CLASSPATH%;%JAVA_HOME%\jre\lib\rt.jar;
     %WL_HOME%\server\lib\webservices.jar;%CLASSPATH%

配置JMS

　　注意WLS91的连接工厂和队列要到JMS Modules下面设置：

• 创建文件后备存储BridgeFileStore
• 创建JMS服务器BridgeJMSServer，和Paging Store设为" BridgeFileStore" ，Target为adminServer
• 创建支持XA的连接工厂WLSCFXA，JNDI Name为bridge.wlsCFXA
• 创建JMS发送队列WLSSendQueue，JNDI名称为bridge.wlsSendQueue，Target为BridgeJMSServer
• 创建JMS接收队列WLSReceiveQueue，JNDI名称为bridge.wlsReceiveQueue，Target为BridgeJMSServer

配置Messaging Bridge Destination

• JMS Bridge Destination名称为MQReceiveBridgeDestination
• Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
• Connection URL为file:/D:/installed/MQ/Queues，
• Initial Context Factory为com.sun.jndi.fscontext.RefFSContextFactory，
• Connection Factory JNDI Name为bridge.mqQCFXA,
• Destination JNDI Name为bridge.mqReceiveQueue
• Destination Type: Queue
• JMS Bridge Destination名称为MQSendBridgeDestination
• Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
• Connection URL为file:/D:/installed/MQ/Queues，
• Initial Context Factory为com.sun.jndi.fscontext.RefFSContextFactory，
• Connection Factory JNDI Name为bridge.mqQCFXA,
• Destination JNDI Name为bridge.mqSendQueue
• Destination Type: Queue
• JMS Bridge Destination名称为WLSReceiveBridgeDestination
• Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
• Connection URL为t3://localhost:7001，
• Initial Context Factory为weblogic.jndi.WLInitialContextFactory，
• Connection Factory JNDI Name为bridge.wlsCFXA,
• Destination JNDI Name为bridge.wlsReceiveQueue
• Destination Type: Queue
• User Name: weblogic（域配置时指定的）
• User Password: weblogic（域配置时指定的）
• JMS Bridge Destination名称为WLSSendBridgeDestination
• Adapter JNDI Name: eis.jms.WLSConnectionFactoryJNDIXA
• Connection URL为t3://localhost:7001，
• Initial Context Factory为weblogic.jndi.WLInitialContextFactory，
• Connection Factory JNDI Name为bridge.wlsCFXA,
• Destination JNDI Name为bridge.wlsSendQueue，
• Destination Type: Queue
• User Name: weblogic（域配置时指定的）
• User Password: weblogic（域配置时指定的）

配置Messaging Bridge

• JMS Bridge名称为MQ2WLSBridge
• Source Bridge Destination:　　MQSendBridgeDestination
• Target Bridge Destination:　　WLSReceiveBridgeDestination
• Quality Of Service:　　　　　　Exactly-Once
• Started:　　　　　　　　　　　　Yes
• JMS Bridge名称为WLS2MQBridge
• Source Bridge Destination:　　WLSSendBridgeDestination
• Target Bridge Destination:　　MQReceiveBridgeDestination
• Quality Of Service:　　　　　　Exactly-Once
• Started:　　　　　　　　　　　　Yes

MQ 配置

　　IBM MQSeries是IBM的商业通讯中间件(Commercial Messaging Middleware)。IBM MQSeries提供一个具有工业标准，安全，可靠的信息传输系统。它的功能是控制和管理一个集成的商业应用，使得组成这个商业应用的多个分支程序(模 块)之间通过传递信息完成整个工作流程。IBM MQSeries具有特殊的技术防止信息重复传送，确保信息一次且仅一次(once-and-only-once)传递，保证传输的可靠性。本文使用的 MQ版本为IBM MQSeries 5.3。

　　IBM MQSeries基本由一个消息传输系统和一个应用程序接口组成，其资源是消息和队列(Messaging and Queuing)。

　　队列管理器（Queue Manager）：管理队列的系统，实现网络通信，保证消息安全可靠地传输到目的地。用于确保队列之间的信息提供，包括网络中不同系统上的的远程队列之间的信息提供。并保证网络故障或关闭后的恢复。

　　队列：一个安全的信息存储区。因为信息存放在队列中，所以应用程序可以相互独立的运行，以不同的速度，在不同的时间，在不同的地点。

　　本地队列：对程序而言，本地队列属于该程序所连接的队列管理器。

　　远程队列：该队列不属于该程序所连接的队列管理器，而只是远端队列管理器的队列在本地的定义。

　　传输队列：它是一个本地队列，保存了指定要发送到远端的消息。

　　死信队列：它是一个本地队列，用于存放无法传递的消息。

　　通道：在两个队列管理器之间建立起来的数据传输链路。

　　应用程序接口：应用程序和信息系统之间通过MQSeries API实现的接口。

Install MQ

• 安装过程中选择自定义安装模式，并确保安装JMS所需的Java　jar包支持如下图:

　　(缺省安装未包含)

确认MQ服务已启动。

　　可通过MicroSoft windows控制面板中管理工具下的服务控制台确认。如下图：

从程序菜单启动MQ 资源管理器

　　如果程序提示试用版过期,可以通过修改系统时间搞定.我就是修改到了2004年。

通过MQ资源管理器创建一个通道

　　建立名为BRIDGE.CHANNEL的通道，其他参数缺省设置。

通过MQ资源管理器创建两个本地队列

　　建立两个本地队名为MQReceiveQueue, MQSendQueue，其他参数缺省设置。

更新MQ安装目录下与ＪＭＳ配置相关的文件

　　JMSAdmin.config文件位于%MQ_INSTALLL_HOME_PATH%\Java\bin，主要定义JNDI服务的提供商， 即JMS Server Factory和URL。%MQ_INSTALLL_HOME_PATH%\Java\bin目录下新建目录bridgeconfig，将 JMSAdmin.config文件拷贝到bridgeconfig。

　　使用Sun的文件JNDI服务Factory,故定义

　　

INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:/D:/installed/MQ/Queues
SECURITY_AUTHENTICATION=none
（例子中，MQ安装目录%MQ_INSTALLL_HOME_PATH%为：D:/installed/MQ/）
JMSAdmin.bat文件也位于%MQ_INSTALLL_HOME_PATH%\Java\bin，此文件用于启动ＭＱ的JMS命令行管理界面，要设置启动JMS命令行管理界面所需环境变量。在JMSAdmin.bat中添加如下环境变量：
set MQ_JAVA_INSTALL_PATH=D:\installed\MQ\Java
set MQ_JAVA_LIB=%MQ_JAVA_INSTALL_PATH%lib
set MQ_CLASSPATH=%MQ_JAVA_LIB%com.ibm.mq.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%com.ibm.mqbind.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%com.ibm.mqjms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%fscontext.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%jms.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%jta.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%ldap.jar
set MQ_CLASSPATH=%MQ_CLASSPATH%;%MQ_JAVA_LIB%providerutil.jar

进入MQ的JMS命令行管理界面绑定MQ的JMS Factory以及JMS本地队列

• 开启MicroSoft Windows的Dos窗口(cmd.exe)
• 进入MQ安装目录下的java目录下的bin目录
• 运行JMSAdmin.bat并通过-cfg参数指定JMSAdmin.config文件位置

　　本次例子中输入：D:\ installed\MQ\Java\bin>jmsadmin -cfg .\bridgeconfig\jmsadmin.config

• 如上图所示界面，生成一个MQXAQueueConnectionFactory对象，Messaging Bridge将使用这个工厂对象建立MQ的XA连接，使用命令DEFINE XAQCF，起名：bridge.mqQCFXA。
• 生成JMSQueue对象来绑定MQ队列MQReceiveQueue。
• 生成JMSQueue对象来绑定MQ队列MQSendQueue。
• 使用dis ctx命令，查看目前已有的对象和绑定，可以看到XA连接工厂和队列都已绑定。

测试

MQ发送，WLS接收

1. MQ发送队列放入测试消息



2. 在WLS控制台监测消息到达

WLS发送，MQ接收

1. WLS发送队列放入测试消息

　　执行下面的代码，给WLS发送队列放入测试消息

　　

package com.bea;
import javax.naming.InitialContext;
import javax.naming.Context;
import javax.naming.NamingException;
import javax.jms.*;
import java.util.Hashtable;
/**
* Created by IntelliJ IDEA.
* User: pmeng
* Date: 2006-6-3
* Time: 14:54:08
*/
public class SendMessageTest {
   public static void main(String[] args) {      
       try {
           Hashtable env = new Hashtable();
           env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
           env.put(Context.PROVIDER_URL, "t3://localhost:7001");
           InitialContext ctx = new InitialContext(env);             
           QueueConnectionFactory factory = (QueueConnectionFactory) ctx.lookup("bridge.wlsCFXA");
           QueueConnection connection = factory.createQueueConnection();
           QueueSession session = connection.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
           Queue queue = (Queue) ctx.lookup("bridge.wlsSendQueue");
           connection.start();
           QueueSender queueSender = session.createSender(queue);
           TextMessage msg = session.createTextMessage();
           msg.setText("Menghe.");
           queueSender.send(msg);
       }
       catch (NamingException e) {
           System.out.println("NamingException:" + e.getMessage());
           e.printStackTrace();
       }
       catch (JMSException e) {
           System.out.println("JMSException:" + e.getMessage());
           e.printStackTrace();
       }
   }
}

2. MQ资源管理器查看接收到的消息

参考资料

1. BEA WebLogic Server 8.1 JMS与 IBM MQSeries 集成方案，周海根，
   http://dev2dev.bea.com.cn/techdoc/20040411784.html
2. BEA WebLogic 8.1 JMS 与IBM MQ v5.3 通过JMS Message Bridge通信配置，陈仁祥

My First Blog on Blogger

I follow the link from http://slashdot.org/ and find the blogger site. Just have a taste, I hope it will be google-style like, because google always satisfies us. No more words at working time, the link to a very nice article:
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=191901844