星期二, 八月 22, 2006

RFID开发介绍—概述

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

概述

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

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

RFID系统

系统结构

  一个完整、典型的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.   因为电子标签具有读写与方向无关、不易损坏、远距离读取、多物品同时一起读取等特点,所以可以大大提高对出入库产品信息的记录采集速度和准确性;减少库存盘点时的人为失误库,提高存盘点的速度和准确性。

  3. 产品跟踪领域

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

  5. 供应链自动管理领域

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

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

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

  7. 防伪领域

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

  9. 医疗卫生领域

  10.   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的参考架构由四个层组成:读卡器层、边缘服 务器层、集成层和应用层。如下图所示。

RFID

  底层的读卡器以特定的速度轮询标记,通常基于一个类似于运动传感器的触发器。无论在任何时间,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所示)。

    图1

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

    图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包支持如下图:

  (缺省安装未包含)

Install MQ

确认MQ服务已启动。

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

确认MQ服务已启动

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

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

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

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

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

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

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

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

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

  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,此文件用于启动MQ的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

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

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

测试

MQ发送,WLS接收

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

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

WLS发送,MQ接收

  1. WLS发送队列放入测试消息
  2.   执行下面的代码,给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();
    }
    }
    }
  3. MQ资源管理器查看接收到的消息
  4. 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通信配置,陈仁祥

星期二, 八月 15, 2006

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