在..../simpapp目录下共有4个文件，分别是README simpserv.c(客户端源程序) simpcl.c(服务器端源程序) ubbsimple(配置文件)

1. 设置环境变量

1.1 tuxedo系统在编译服务器或客户端shirt都需要一些环境变量。可建议一个setenv文件内容为：
. /home/tuxedo/bea/tuxedo9.1/tux.env
APPDIR=/home/tuxedo/bea/tuxedo9.1/samples/atmi/simpapp;export APPDIR
TUXCONFIG=$APPDIR/tuxconfig;export TUXCONFIG
WSNADDR=//192.1.1.121:9999;export WSNADDR
根据实际情况自己设定。
第一行是tux.env所在目录
第二行是simapp所在目录
第三行是simapp的二进制配置文件

1.2 执行环境变量
cd到setenv所在目录，假设为=/home/tuxedo/bea/tuxedo9.1/samples/atmi/simpapp
$. ./setenv

2. 配置文件

除了客户端和服务起程序以外，tuxedo还需要一个配置文件来描述一个tuxedo应用系统所包含的系统资源。修改simpapp下的ubbsimple的内容，改好后为：（注意红色部分）

#       (c) 2003 BEA Systems, Inc. All Rights Reserved.
#ident "@(#) samples/atmi/simpapp/ubbsimple    $Revision: 1.5 $"

#Skeleton UBBCONFIG file for the TUXEDO Simple Application.
#Replace the <bracketed> items with the appropriate values.

*RESOURCES
IPCKEY         123456

#Example:
#IPCKEY         123456

DOMAINID        simpapp
MASTER          simple
MAXACCESSERS    10
MAXSERVERS      5
MAXSERVICES     10
MODEL           SHM
LDBAL           N

*MACHINES
DEFAULT:
               APPDIR="/home/tuxedo/bea/tuxedo9.1/samples/atmi/simpapp"
                TUXCONFIG="/home/tuxedo/bea/tuxedo9.1/samples/atmi/simpapp/tuxconfig"
                TUXDIR="/home/tuxedo/bea/tuxedo9.1"
#Example:
#               APPDIR="/home/me/simpapp"
#               TUXCONFIG="/home/me/simpapp/tuxconfig"
#               TUXDIR="/usr/tuxedo"

happy   LMID=simple

#Example:
#beatux         LMID=simple

*GROUPS
GROUP1
        LMID=simple     GRPNO=1 PENINFO=NONE

*SERVERS
DEFAULT:
                CLOPT="-A"

simpserv        SRVGRP=GROUP1 SRVID=1

*SERVICES
TOUPPER

如果没改直接进行第3步，常有以下错误提示：
2.1 IPCKEY          <
                syntax error
CMDTUX_CAT:866: ERROR: tmloadcf: Severe error found. Stop syntax checking.
解决方法：对<>按照example进行修改

2.2 CMDTUX_CAT:868: ERROR: tmloadcf cannot run on a non-master node
解决方法：ubbsimple 文件中将<Machine-name>改为你的机器名，在windows下使用
echo %computername% 显示机器名，在unix下使用 uname -n 。注意在windows 下,通过hostname 或者 %COMPUTERNAME% 查出来的机器名不论是大小写,在ubb中设置成大写.其实我用小写也执行成功了。

3. 编译与执行

3.1 生成二进制配置文件,长出现问题看2.1 2.2
      $tmloadcf -y ubbsimple
3.2 编译客户端程序
      $buildclient -o simpcl -f simpcl.c
3.3 编译服务器程序
      $buildserver -o simpserv -f simpserv.c -s TOUPPER
      此处生成的可执行文件名要与ubbsimple中的相匹配
      否则，出项错误 Can't send request to service TOUPPER
3.4 启动tuxedo应用系统
     $tmboot -y
3.5 运行客户端
     $./simpcl hello
      显示Returned string is: HELLO表示测试成功
3.6 关闭tuxedo应用
     $tmshutdown -y

$ tmshutdown -y
Shutting down all admin and server processes in /home/billklmy/cfg/tuxconfig

tmshutdown: internal error: CMDTUX_CAT:764: ERROR: can't attach to BB
 
解决办法：执行ipcs -qms |  grep billklmy | grep -v 'grep' |  awk '{ print "ipcrm -"$1" "$2}' |sh
然后再tmboot -y即可了。
 
厂方解释原因是执行了大的报表查询程序导致的，很少出现。

JBoss ESB（JBoss）

在GA版本中有着成熟的组件，没有厂商绑定之类的特征。

Apache ServiceMix（Apache）

Apache ServiceMix 4基于OSGi，提供了一个与XML标准集成的选项。

OpenESB（Sun/Oracle）

OpenESB与Glassfish应用服务器以及NetBeans有着紧密的集成，因此学习曲线很简单。

MuleESB（MuleSoft）

Mule是当下使用最多的开源集成平台。MuleESB价格低廉，配置、扩展简单，而且灵活性强，使得它非常流行。

WSO2 ESB（WSO2）

相比其他使用了JBI规范的重量级ESB，WSO2这个新来者带来了一个轻量级的ESB。这是因为，WSO2 ESB以Web服务标准作为集成的焦点。

• ESB综述1：定义ESB  、ESB综述2：ESB使用案例   (InfoQ)
• 探索企业服务总线 part1(IBM DW)  ，part2  
• Defining the ESB   (DDJ)
• 《Enterprise Service Bus》  ,O'Reilly 2004

    ESB就是一个服务的中介，形成服务使用者->ESB服务Proxy->服务提供者的生物链，中介的作用在不同应用中各有不同：

• 解耦中介 ：客户对实际服务提供者的身份、物理位置、传输协议和接口定义都是不知道也不关心的，交互集成代码提取到了业务逻辑之外，由ESB平台进行中央的宣告式定义。
                ESB平台实现协议转换 (WebService，Http，JMS...)，消息转换 (转换、充实、过滤)，消息路由 (同步/异步、发布/订阅、基于内容路由、分支与聚合...)。 
• 服务中介 ：ESB平台作为中介提供服务交互中的基础服务。
                ESB平台实现SLA (可靠性保证，负载均衡，流量控制，缓存，事务控制，加密传输)，服务管理监控 (异常处理，服务调用及消息数据记录，系统及服务的状态监控，ESB配置管理)，统一安全管理 (这个有点理想主义)。
• 服务编排 ：多个服务进行编排形成新的服务。
                ESB支持一个直观的形式定义新组合服务的流程(工作流、BPEL 或 代码级编排)。

       缺点就是天然的额外中转性能消耗，中央ESB的性能瓶颈和高可用性问题。

ESB实现

开源ESB实现

• Mule   ，很多时候更像一个Service Container，OpenSource界暂时第一。
• WSO2  ，Axis2 背后公司的作品。
• ServiceMix  ，关注于JBI的实现。
• JBoss ESB  ，  Sun OpenESB   没有关注。

开源轻量级ESB

• Apache Camel  ，一个嵌入式的Router类库。
• Spring Intergration   ，相当清爽轻量的Spring Style的Router。

商业ESB

• BEA AquaLogic  ，作为ESB概 念比Mule纯粹，同时使用JMS作为message flow的底层，在Weblogic上实现HA，群集和监控管理界面。但路由编排再次走了图形编程+XML Context(XQuery)的老路，相当鸡肋。
• IBM(Message Broker, Websphere ESB，DataPower),
  

• 企业服务总线 ESB 的介绍
• IBM 的 ESB 产品
• 三款产品的比较
• 总结
• 参考资料

本文首先介绍了企业级应用程序的发展以及 ESB 的定义；随后，分析了 ESB 在 SOA 解决方案中所起的作用，并比较介绍了三款 ESB 产品在支持实现一个 ESB 解决方案中所起的作用。

企业服务总线 ESB 的介绍

企业应用的发展概述

在介绍企业服务总线之前，有必要花一些笔墨来介绍企业应用架构的发展和变迁。企业级应用架构的发展经历了以下几个阶段：

1. 独立应用系统
2. EAI 阶段
3. SOA 阶段

独立应用阶段

20 世纪 60 到 70 年代，企业应用处于独立应用系统阶段，当时的企业应用是一种用来替代重复性劳动的简单设计，其目的是用计算机代替孤立的，体力性质的工作环节，将相关联的企业信息或数据管理起来。这些系统大部分是独立的系统——有独立的数据库、应用服务器、用户界面。因此有时候这类应用也叫“竖井型”的应用。

但是，随着业务和信息的不断扩展，独立应用系统渐渐不能满足企业对 IT 的需求，表现在大量的信息冗余，因为在建立一个新的应用的时候需要重新建立一套数据库；功能的重新设计，相似的功能存在于多个系统中；例如，客户信息在一个公司中可能有多个拷贝分别存在于多个数据库中，不同时期建立的应用系统所使用的技术也会不同。对于获取客户资料这样的功能，必然存在于多个系统中，而且在不同的系统中其实现方式可能是 Java/J2EE、Delphi、C/C++。

EAI 阶段

20 世纪 80 到 90 年代，一些公司或集成商意识到应用集成的价值和必要性。EAI 是一种将多个不同平台、用不同方案建立的异构的应用集成的一种技术和方法。它的目标包括以下几个方面：各个分离的系统间的相互通讯，消除信息孤岛，实现信息的共享。从功能的角度来看，EAI 包括信息接收、转换、翻译、路由、传播和业务流程管理。从架构上看有两种方式：Hub/Spoke 方式和 Bus 方式。

图 1 所示的 Hub/Spoke 结构使用一个中心代理（Hub）和多个适配器（Spoke）将 Hub 和应用连接起来。适配器负责将应用的数据格式转换成 Hub 可以理解的格式，Hub 将数据再转换成目标系统可以理解的格式，并执行消息的路由。Hub/Spoke 方式的弊端在于只有一个代理中心，当连接的应用种类增加或者消息量增大时，代理中心的性能将成为整个系统的瓶颈，在可扩展性方面也存在着一定的问题。

图 2 所示的 Bus 结构使用一个中心总线，应用程序通过 Adapter 将消息发送给总线，总线负责消息的路由，接受方的应用程序也有自己的 Adapter 来转换接受到的消息。Bus 结构和 Hub/Spoke 结构的最大区别在于在 Bus 结构中，Adapter 位于应用程序中，而 Hub/Spoke 结构中，Adapter 由 Hub 来统一管理。这样在 Bus 结构中，加入一个新的应用变得很简单，可扩展性得到了很大的提高，但是应用程序方的负担加重了。

SOA 阶段

SOA 将应用资源看成一个个独立的，自包含并良好定义的服务，通过这些服务的组装，编排可以产生新的应用。每一个服务可以完成一个独立业务功能，并且不依赖于业务上下文或者其他服务的状态。服务的定义是标准的且被广泛支持的，比如 Web Service。在 SOA 的架构中，人们都用标准的方式来封装自己的服务，使得任何一个客户端程序都可以容易的和后台系统实施连接。而 ESB 是 SOA 架构中的一个核心基石，在几乎所有的 SOA 架构中，都将 ESB 放在核心的位置。图 3 是 IBM SOA Reference architecture，从中我们可以看出 ESB 在一个 SOA 架构中的地位，对该图的详细解释不在本文介绍范围之内，有兴趣的读者可以参考一下 IBM SOA 专区的相关文章。

下面我们来介绍一下 ESB。

什么是 ESB?

什么是 ESB？ESB 严格来说不是某一个产品，而是一种框架，设计模式。不同的提供商对 ESB 的理解也各有不同。

“ESBs are essentially integration systems, not SOA systems. SOA is about tearing down application silos, but integration systems reinforce those silos. [...] an ESB is especially good for bridging to legacy applications, and therefore it is a useful component in a services infrastructure”

----Anne Thomas Manes, Research Director with Burton Group

“An Enterprise Service Bus (ESB) is a distributed middleware system for integrating enterprise IT assets using a service-oriented approach.”

----Ron Ten-Hove , Sun Microsystems and JBI Spec Lead

“A Web-services-capable infrastructure that supports intelligently directed communication and mediated relationships among loosely coupled and decoupled business components.”

--Gartner

IBM 对 ESB 是这样描述的：

“An enterprise service bus (ESB) is a pattern of middleware that unifies and connects services, applications and resources within a business. Put another way, it is the framework within which the capabilities of a business' applications are made available for reuse by other applications throughout the organization and beyond. The ESB is not a new software product — it's a new way of looking at how to integrate applications, coordinate resources and manipulate information ”

从 IBM 的立场来说，ESB 不仅仅是一个概念，而是一种中间件模式；它不是某个产品，而是一种全新的集成应用，协调资源和操纵信息的框架。

下面来介绍 ESB 或可以称为 ESB 的中间件产品保护一些特征，有些是必须的，有些是可选的：

1. 连接性

   ESB 必须提供一种支持服务交互的桥梁，它必须支持多协议 (protocol) 之间的连接。不仅要提供对消息和面向事件的中间件的支持，还要提供和现有 EAI 技术的连接。连接性是 ESB 不可缺少的特征之一。

2. 服务交互

   服务交互可以理解为 ESB 的一个目的之一，ESB 作为 SOA 架构的核心，必然要支持服务的交互，要在服务的请求者和提供者架起一个坚实的桥梁，让服务的请求者和提供者只需要关心各自的业务逻辑，而不需要在发布和消费服务的环节花很大力气。服务交互也是 ESB 的必备特征。

3. 集成

   集成的概念是对于系统而言的，ESB 不仅要能集成那些很容易封装服务的系统，也要集成不能方便地封装服务的系统，例如 SAP, ERP, CRM, Siebel 等 EAI 系统、遗留系统。集成也是 ESB 的核心特征之一。

4. 消息处理

   在集成的过程中，必须要面对的是消息处理，在不同的应用系统中，消息的描述格式是不一样的。在集成环境中，必须要提供一种统一的格式来处理系统间的交互，从 ASBO(Application Specific Business Object ) 到 GBO(Generic Business Object) 之间的互转是 ESB 的核心特征之一。

5. 管理

   对于一个具有 ESB 特征的产品，管理也是一个重要的方面。例如，当一个服务从一个地址切换到另一个地址，在结构等不发生任何改变的时候，ESB 产品应该提供一个方便的途径适应这种改变。

6. QoS

   对于服务交互来说，QoS 也是一个重要的特征，比如针对不同的服务请求者提供不同质量的服务响应。有些服务的请求需要在事务中完成，有些服务的交互需要保证其可靠性。一个 ESB 产品应该提供给开发者定义 QoS 的接口。

7. 安全

   安全的必要性不言而喻，系统和系统之间的交互必然需要认证，授权，加密，签名等安全性。一个优秀的 ESB 产品应该提供可靠的，可灵活配置的安全支持。

IBM 的 ESB 产品

IBM 有三款 ESB 产品：WebSphere ESB (WESB)，WebSphere Message Broker(WMB)，DataPower。这三款 ESB 产品都提供了 ESB 所必备的特征，但是它们各有侧重，WESB 主要构建与 WebSphere Application Server 之上，侧重于对标准协议和消息的支持，更适合于 J2EE，Web-Service 为主要特征的集成环境；WMB 提供了一个高级的 ESB，它构建于 WebSphere Message Queue 之上，提供了百种以上协议的连接和数据格式的转换机制。Datapower 是一款比较新的 ESB 产品，除了提供必备的 ESB 的特性之外，Datapower 更侧重于安全。众所周知，在 XML 的环境中，安全对于性能的影响是巨大的，Datapower 给企业 ESB 提供了强大的安全保障。下面分别介绍这三款 ESB 产品。

WebSphere ESB

从图 4 中可以看出 ESB 构建与 WAS ND 之上，它使用了 WAS ND 及 WAS 对于安全，用户注册表，事务，消息引擎的支持，在其之上增加了对服务集成、消息流处理、建模以及 ESB 编程模型的支持等等。从图中还可以看出 WebSphere Process Server 是构建与 WESB 之上，并扩展了服务编排和流程管理方面的支持。

下面介绍在 WESB 上实现一个 SOA ESB 解决方案上的以下九个方面的特点，这九个方面的特点来源于上文中介绍的 ESB 的特性，或者特性的细化：

1. 消息转换

   WESB 所处理的消息为 XML 格式的数据，对于非 XML 结构的数据 WESB 不能处理。对于 XML 结构的数据，在 WESB 的消息流中数据以 SMO(IBM 对 SDO 的扩展，参见参考资料部分了解 SDO 的规范 ) 形式存在，WESB 可以对 XML 消息树的内容进行修改，包括改变某个节点的内容，增加新的节点以及删除某个节点等等。

2. 支持的协议

   WESB 支持符合 SOA 标准的协议，比如 SOAP/HTTP、SOAP/JMS、WSDL V1.1、UDDI V3.0，WebSphere MQ 等。也就是说 WESB 目前只支持 SOAP 方式来描述服务，传输协议可以是 HTTP、JMS 记忆原生的 WebSphere MQ 的连接。对于多传输协议的基础，建议使用 MB 来做 ESB 的解决方案，参考 MB 的介绍部分。

3. 消息路由

   消息的路由在 WESB 中有良好的支持，开发环境 WID 中提供了一个节点专门来负责消息路由，WID 也提供了良好的对路由规则定义的开发支持，开发人员可以很容易的定制负责的路由规则。若要实现动态路由的功能，则需要和一个服务的存储单元中来动态的查找服务，目前 WSRR 是一款优秀的提供该功能的工具（参见参考资料部分了解 WSRR）。WESB 从 V6.1 开始提供了 Endpoint lookup 节点来支持 WSRR 的集成，简化了开发过程。如果要实现简单的动态服务路由的功能，则可把服务的定义存放在数据库中，在 WESB 中通过 DB lookup 来查找服务的 Endpoint, 然后注入到消息流中，WESB V6.1 之前的版本就已经支持与数据库的集成。

4. 对 Web Service 的支持

   WESB 天生运行在 J2EE 的环境里面，对 Web Service 有着天然的支持。

5. 事件处理

   在消息流中，我们需要跟踪消息各节点的状态，以满足统计和出错处理的要求，在 WESB 中，通过 CEI 机制来处理消息。（CEI 的介绍请参见参考资料部分）

6. 与遗留系统的集成

   WESB 通过 Adapter 与遗留系统进行集成，支持 IBM Websphere Adapter 和 JCA Adapter，通过 JCA 我们就可以将遗留系统里面的服务和数据通过标准（SCA/SDO）的形式整合到集成环境中。

7. 安全方面的支持

   WESB 没有对安全做特殊的处理，使用 WAS 的安全支持来实现 ESB 的安全。

8. 性能

   WESB 是一个纯 Java 的应用，运行效率上有些限制，同时可以处理的消息流的数量级为几十到几百之间。

9. 开发和部署

   开发工具是 WID，一个 ESB 的消息流在 WID 中被称为 Mediation Module，它是一个 J2EE 应用，开发和部署工作无异于普通的企业级应用。

Message Broker

WMB 是 IBM 的应用整合中间件，是 IBM ESB 架构重要的产品组成部分之一，用于企业应用整合领域。WMB 目前的版本是 6.1.2，它的前身是 MQSeries Integrator。本质上看，WMB 是 MQ 的衍生产品，它使用 MQ 作为内部通信的机制。然后，WMB 提供的接入方式远不止 MQ 一种，包括 JMS、HTTP(S)、SCADA 等常见的新一代接口规范。在消息转化过程中，WMB 能够识别 XML、C 结构、SOAP 等各种自定义的消息格式。

如图 5 所示，WMB 可以分为开发环境和运行环境两大部分。其中开发环境由开发工具（Toolkit）和调试环境（Rational Agent Controller）组成，运行环境是 WMB 核心，也叫 Broker Domain，由三部分组成，配置管理器（Configuration Manager）、用户名服务器（User Name Server）和代理（Broker）。

• 代理（Broker）：消息代理是 WMB 的消息处理引擎，它提供 WMB 的所有运行服务，在 Windows 系统上它是一个系统服务，在 Unix 平台上表现为一个后台进程。应用系统利用与 MQ 的连接和队列将消息发送到消息代理。代理与代理之间，代理与配置管理器之间通过普通的 MQ 发生和接受类型的消息通道进行通信。在一个主机上我们可以创建一个或者多个 Broker，每个 Broker 会关联一个数据库，利用数据库存储 Broker 需要和相关的信息，每个 Broker 还需要一个队列管理器，多个 Broker 之间不能共享同一个队列管理器，每个 Broker 必须有自己特定的、唯一的队列管理器。每个 Broker 只能被一个配置管理器控制。
• 配置管理器（Configuration Manager）：配置管理器是整个 WMB 运行环境中的控制中心，它维护整个 Broker Domain 的配置信息，配置和管理所有代理，增、删、启动、停止消息流，所有的开发工具也是通过配置管理器来部署编译结果的。配置管理器也负责与用户名服务器联系，配置和管理各种用户权限。配置管理器和其他各个部件之间的接口是 MQ，所以配置管理器也必须是基于 MQ 队列管理器而运行的。
• 用户名服务器（User Name Server）：用户名服务器是 WMB 运行环境中的可选部分，它可以提供应用程序的接入认证以及订阅主题的访问控制服务。用户名服务器本身是不需要数据库，但必须依赖于队列管理器与其他组件通信。用户名服务器中的用户信息来自认证数据文件。
• 开发工具（Toolkit）：开发工具是基于 Eclipse 3.0 的集成开发环境，我们可以在其中开发消息流、消息集、ESQL 代码、Java 代码、映射规则等。通过内置的 MQ Client 与配置管理器连接，并将开发好的执行组件部署到相关的代理中。Eclipse 环境由不同的视图（Perspective）组成，我们在 WMB 中常用的有代理开发视图、代理管理视图等。
• 调试工具（Rational Agent Controller）：这是 IBM Rational 开发工具标准的调试工具。一般安装在代理所在的服务器一边，开发工具可以连接 RAC，通过它来控制和调试消息流的运行。需要注意的是，Toolkit 可以并行开发，但是对于同一个执行组不能并行调试，因 RAC 的调试过程是排他的。在 WMB6.0 之后 RAC 不需要再单独安装。

下面从九个方面来介绍 WMB 在实现一个 SOA ESB 解决方案上的支持的特点：

1. 消息转换

   WMB 在消息处理方面功能非常强大，对 XML 格式的消息或非 XML 格式的消息，如 C Header，COBOL 等都有很好的支持。实际上，通过开发消息对应的消息集（Message Set），可以在消息流中对任意格式的消息进行修改。WMB 提供了内置的 mapping 和 database 节点，用户可以通过图形化的方式方便的实现消息的转换或与数据库的交互。

2. 支持的协议

   WMB 支持所有 WESB 支持的传输协议，除了常用的 HTTP、JMS 等，还对 FTP、Socket、Mobile、Telemetry、Biztalk 和 Tuxedo 等有良好的支持。WMB 与 MQ 有着紧密的联系，对 MQ 的支持不在话下。WMB 内置的功能节点对这些协议提供了很好的支持，仅需配置即可，如图 6 所示。
   图 6. Message Broker 的内置开发节点
   
   　

3. 消息路由

   WMB 提供了很多功能强大的内置节点支持消息的路由，如 Filter 节点、Label 节点等，在新版本的 WMB 中又引入了 Router 节点，该节点几乎和 WESB 中的 Router 节点一样。若需要实现动态路由，可以使用 WSRR 作为服务的存储，WMB 和 WSRR 有很好的集成，通过 RegistryLookup 和 EndpointLookup 我们可以在消息流中实现动态路由。另外需要指出的是，WMB 可以提供一个消息输入，多个消息输出的功能，可以实现一个消息同时路由到多个输出端。

4. 对 Web Service 的支持

   在 WMB 中，消息流可以作为 Web Service 暴露出去供外部调用，也可以作为客户端调用外部提供的 Web Service。WMB 不仅提供了内置的 SOAPRequest、SOAPInput 等节点实现对 Web Service 的支持，而且对 WS 扩展，如 WS-Security 和 WS-Addressing 也有良好的支持。
   
   
   　

5. 事件处理

   在 WMB 中我们可以通过 Trace Service 来记录所发生的事件。Trace 分两种，一种是 User Trace 记录消息流级别的事件，另一种是 Service Trace，可以记录整个 WMB 的事件，如 Broker 的部署执行。WMB 提供了 Trace 内置节点，可以实时的记录流程中消息内容的变化。

6. 与遗留系统的集成

   WMB 对遗留系统有良好的支持。对 SAP，PeopleSoft 等大型的 EIS 系统，直接提供了内置的节点，通过 JCA Adapter 配置的方式和 EIS 系统交互。对于比较特别的遗留系统，如 CICS、VSAM 等，WMB 提供了丰富的 SupportPacs，客户可以下载并安装。

7. 安全方面的支持

   WMB 本身提供了两个层次上的安装，一个是部署时安全性，管理部署 bar 文件到 Broker 以及运行 WMB 管理命令的权限控制；另一个是运行时安全，涉及的权限控制包括发送消息到相应的消息流，以及消息流可以访问哪些 MQ 资源和非 MQ 资源，如数据库系统。

8. 性能

   WMB 底层是使用 C++ 开发的，在性能上相对于 WESB 有很大的提高。同时可以处理的消息数量级为几千到几万之间。

9. 开发和部署

   开发工具是 WMB Toolkit，我们开发的消息流和消息集被打成 bar 文件通过配置管理器部署到 Broker 中。

总的来说，WMB 是 IBM 久经考验的一款消息中间件产品，为异构的 IT 环境提供了统一的连接和转化，其优势如下：

• 利用 WebSphere MQ 作为企业消息传递主干，提供了很好的并发性和可靠性
• 不仅支持各种标准协议，而且支持和 WebSphere 企业应用程序适配器进行集成
• 支持多种数据格式之间的转换，包括 XML、遗留系统、行业标准和自定义消息格式
• 针对大量数据处理进行了优化，极大提高了处理速度。

Datapower

DataPower 是一个硬件产品，看起来像一个盒子。目前 IBM 有三款 Datapower 产品供用户选择。按照进入市场的先后次序，它们分别是：Datapower Accelerator XA35，Datapower Security Gateway XS40， Datapower Integration Appliance XI50，见图 7。

图 7. IBM 的 Datapower 产品线

• XA35 的主要侧重点是 XML 加速，众所周知，在 SOA 的环境中，XML 是应用最广泛的，而对 XML 的解析，加密，解密这些操作让应用服务器来做的话，这是一个很大性能开销，而 XA35 就是要替应用服务器的分担这些 XML 相关的工作，让应用服务器专注于处理业务逻辑；
• XS40 的主要侧重点是安全，即负责提供安全的企业网关，及对 XML 攻击的防范。
• XI50，从名字上看，主要侧重点是集成功能，是一款高级 ESB 产品，提供了多种协议和数据格式的路由和解析的功能。

虽然三款产品各有侧重，但是三款产品的功能也具有包含关系，XS40 包含 XA35 的功能，XI50 包含 XS40 的功能。

我们依然从以下九个方面来介绍 Datapower 在实现 ESB 解决方案中的特点。

1. 消息转换

   Datapower 对 XML 消息有强大的支持，但是 Datapower 绝不仅仅支持 XML，我们可以在 Policy 中使用 Transformation 节点来对消息进行任意我们需要的转换，其原理是使用 XSLT 来实现的，开发人员定义自己 XSLT Stylesheet 并在 Transformation 节点中指定，Datapower 负责转换。

2. 支持的协议

   Datapower 支持和以下传输协议，HTTP，HTTS，WebSphere MQ
   WebSphere JMS，TIBICO EMS，FTP Poller, FTP Server, NFS 等等。 Datapower 的 MPGW 就是一个处理不同协议的应用系统的互联的服务对象。

3. 消息路由

   Datapower 支持对服务和消息的路由，根据消息流中的上下文连接将消息动态的分发到不同的消息提供者。但是 Datapower 的动态路由和 WESB 以及 MB 的动态路由还是有区别的，Datapower 的动态路由需要由开发者定义路由的 Map，而 WESB 和 MB 支持在消息头的属性里动态的设置 Endpoint 的地址。目前 Datapower 可以和 WSRR 集成来定义 WS-Proxy（Datapower 中的一种服务对象），但不支持直接和 WSRR 联合实现动态访问 Endpoint 的功能。

4. 对 Web Service 的支持

   Datapower 的 XMlFirewall 和 WS-Proxy 提供了强大的对 Web Service 的支持，而且 datapower 提供了细粒度的对 Web Service 的控制，可以从服务级 (Service)，端口级 (port)，绑定级 (binding)，操作级 (operation) 来对消息体进行控制。此外，对 WS-Security 也提供了强大的支持。

5. 事件处理

   Datapower 中可以通过 Probe 的方式来跟踪消息流的中间状态，在 Probe 中，可以看到消息流的每个节点的消息内容。Probe 一般用于开发调试过程，在生产模式下一般不使用，因为使能 Probe 会牺牲一定的效率。Datapower 不支持与 CEI 类似将消息发送到其他应用系统的机制。

6. 与遗留系统的集成

   Datapower 不支持和 Adapter 的连接，若要与遗留系统的集成，则需要通过其他中间件转换在遗留系统和 Datapower 之间做而桥梁来连接。

7. 安全方面的支持

   Datapower 的强大之处在于其对安全方面的强有力的支持，它提供对 XML-attack 的原生支持（关于 XML-attack 的知识参见参考资料）；此外，Datapower 可以对 Web Service 提供细粒度的安全支持，包括加密 (Encryption)，解密 (Decryption)，签名 (Sign) 和确认 (Verify)，以及 HTTS 方面的支持。这些支持在 Datapower 上开发起来都异常简单。

8. 性能

   Datapower 无疑是三款 ESB 产品中性能最高的，对 XML 的处理速度达到线速，下图是一组测试结果。如果去处网络传输在其中的比例，对 XML 的处理性能所提高的倍数可达到上百倍。

   Software Solution		DP Solution
   Avg. response time ( TimeP / N )	XML processing time ( TimeX )	Avg. response time ( TimeP / N )	XML processing time ( TimeX )
   106 ms	96 ms	19 ms	11ms

9. 开发和部署

   Datapower 的没有相应的开发工具，但是提供了 Web GUI 的管理控制台和 CLI 方式的管理支持。我们在 Web GUI 下开发消息流，开发即部署。

   高速的 XML 处理能力和强大的安全支持，是 Datapower 作为 SOA 应用中的 ESB 的重要特色，这个特点使得 Datapower 成为一款举足轻重的 ESB 产品。

三款产品的比较

从上面的介绍我们可以看出，三款产品都提供了 ESB 的必须的功能，但各有侧重：

• WESB 是一个轻量级的 ESB，侧重于标准协议，SOAP,JMS 等应用的基础，构建于 WASND 基础之上，提供了和 J2EE 应用很好的集成功能；同时由于 WESB 是一个纯 Java 的应用服务器，在性能上也是相对较差一点的 ESB，可并发执行的 Mediation Flow 的数量级在几十个左右。WESB 适合使用于对性能要求不是很高，且遵循标准协议的 SOA 整合环境中。WESB 的优势是提供了和流程服务器 WPS 以及 J2EE 服务器 WAS 良好的整合。WESB 的应用场景见图 8：

• WMB 是一款高级的 ESB，提供了比 WESB 多很多的传输协议，数据格式的支持，它所支持几乎大部分常用的数据格式和协议。并且 WMB 提供了良好的扩展功能，开发人员可以在 WMB 基础上开发自己的数据格式解析的节点。WMB 使用 C/C++ 编写，在处理性能上比 ESB 也要高出很多倍，可并发执行的流可以达到上百个或上千个。从图 9 可以看出 WESB 和 WMB 在支持的协议上的区别。

WMB 应用于对性能要求相对较高，多种复杂协议存在的集成环境中。另外，WMB 构建于 WebSphere Message Queue（WMQ）之上。 WMQ 提供了对异步消息提供了可靠的传送机制，比较适合于信息传输量较大，信息交互频繁的场景中。如图 10 所示：

图 10. WMB 的使用场景

• Datapower 是 SOA 中的又一重要的 ESB，在 WESB 和 WMB 中都是用软件来实现 XML 解析和安全支持的，而 Datapower 使用硬件的 XML 解析和加速器，在性能上有了很大的提高。在很多 SOA 的环境里，安全和性能是天平的两端，增加安全势必要牺牲性能；而提高性能则需要牺牲安全。所以在安全和性能要求都比较高的环境中，Datapower 是一首选 ESB，因为 Datapower 可以在实现高性能的同时也保证安全。图 11 是一种 Datapower 的应用场景：

总结

基于上文对三款产品做了详细的比较，我们可以做如下总结，WESB 适用于 J2EE 环境下，对性能要求不是很高的，标遵循标准协议的 SOA 集成；WMB 应用更复杂的集成环境，表现为数据格式多种，传输协议多样，性能要求很高；而在安全和性能要求都很高的应用场景下，选择 Datapower 无疑是最好的选择。下面的图表再次对文中的描述进行总结。

在本文的第 2 部分中，我们将用一个简化的实际案例来描述三款 ESB 产品在实现上的差异。

参考资料

• CEI 的介绍：从这里您可以了解 Common Event Infrastructure 相关的内容。
• EAI vs. SOA vs. ESB： 本文向您讲解了这三个概念之间的关系和相关的内容。
• WebSphere Enterprise Service Bus 的产品文档中心： 在这里您可以找到所有和 WESB 产品相关的资源。
• WebSphere Message Broker 的产品文档： 在这里您可以找到所有和 WebSphere Message Broker 产品相关的资源。
• WebSphere Enterprise Service Bus 资源中心： 这里拥有 developerWork 中所有和 WESB 相关的内容，让您可以更全面地了解和学习这个产品。
• IBM developerWorks SOA and Web services 专区 提供了大量的文章，以及关于如何开发 Web 服务应用程序的初级、中级和高级教程。
• 使用 IBM SOA Sandbox 进行试验！通过 IBM SOA 进行实际的亲手实践来提高您的 SOA 技能。
• IBM SOA 网站 提供 SOA 的概述，并介绍 IBM 是如何帮助您实现 SOA 的。
• 了解关于 developerWorks 技术事件和网络广播 的最新消息。请特别关注以下 SOA 和 Web 服务技术讲座：
  • SCA/SDO:To drive the next generation of SOA
• 访问 Safari 书店 ，浏览有关这些技术主题以及其他方面的书籍。
• 查看快速的 Web 服务按需演示 。
• 获取 SOA and Webservices 专区的 RSS。（了解关于 RSS 的更多信息。）

• 使用 IBM 试用软件 开发您的下一个项目，可下载或索取 DVD 光盘。

• 参与 developerWorks Blog，从而加入到 developerWorks 社区中来，其中包括以下与 SOA 和 Web 服务相关的 Blogs：
  • Sandy Carter 的 Service Oriented Architecture -- Off the Record
  • Ali Arsanjani 的 Best Practices in Service-Oriented Architecture
  • Bobby Woolf 的 WebSphere SOA and J2EE in Practice
  • Eoin Lane 博士的 Building SOA applications with patterns
  • Kerrie Holley 的 Client Insights, Concerns and Perspectives on SOA
  • Simon Johnston 的 Service-Oriented Architecture and Business-Level Tooling

进入linux系统，在linux系统dos输入页面中输入tmadmin

进入tmadmin的监管环境，输入下面的命令即可

启动tmadmin
tmboot  -y

1查看服务信息psr
(1) 命令: printserver 简写 psr
(2)  psr [-m machine] [-g groupname] [-i srvid] [-q qaddress]
-m machine LMID为 machine的所有服务进程
-g groupname 组名为groupname的所有服务进程
-I srvid SRVID为srvid的服务进程
-q qaddress 消息队列为qaddress的所有SERVERS查看server的信息
(3) 结果示例:
Prog Name     Queue Name   Grp Name      ID   RqDone  Load Done  Current Service
---------    ----------    --------      --    ------  ---------  ---------------
rz_Ecsb        00004.04000   APGP2       4000    0        0       (  IDLE )
BBL            70020         simple         0     1       50       (  IDLE )
IFMTMS         APGP2_TMS    APGP2      30001     1       50       (  IDLE )
ftpserv32      00002.00001  FTPGP          1    60      3000     (  IDLE )
结果说明:
列号  描述
1. 服务的可执行文件名
2. 服务连接的队列名
3. 组名
4. 服务的数字id
5. 服务已经处理的请求数(该SERVER的所有service的负载因子总和)
6. 服务处理的全部请求的参数和，如果当前没有service被调用，则为IDLE
2查看交易信息psc
(1)  命令: printservice  简写: psc
psc [-m machine] [-g groupname] [-I srvid] [-q qaddress]
[-s service] [-a {0|1|2}]
-s service 显示名为sevice的service信息
-a {0|1|2} 显示系统的隐含的service
其他参数与psr命令相同
(2)  结果示例:
Service Name   Routine Name   Prog Name  Grp Name   ID   Machine   # Done   Status
------------   ------------     -------    --------   --   -------   ------   ------
416701         rz_Ecsb         rz_Ecsb     APGP2     4000    simple    0      AVAIL
416601         rz_Ecsb         rz_Ecsb     APGP2     4000    simple    0      AVAIL
416501         rz_Ecsb         rz_Ecsb     APGP2     4000    simple    0      AVAIL
(3)  结果说明:
列号    描述
1. Service Name :服务名
2. Routine Name :函数名(采用TUXEDO服务的别名机制,一个函数可以对应多个服务名)
3. Prog Name :service 所在的SERVER名
4. Grp Name :组名
5. ID ：server的ID号
6. Machine :server所在的LMID
7. # Done ：service被调用的次数
8. Status :service的状态。AVAIL表示可用
3查看队列信息pq
(1) 命令: printqueue 简写:pq [PADRESS]
(2) 结果示例:
pq 00004.05062
Prog Name      Queue Name  # Serve  Wk Queued  # Queued  Ave. Len    Machine
---------    ------------  ------   ---------  --------  --------    -------
CCS_GEDAIPC_50 00004.05062     1         0        0       0.0       simple
(3) 结果说明:
列号    描述
1. Prog Name :队列连接的服务的可执行文件名
2. Queue Name :字符队列名，是RQADDR参数或一个随机值
3. #Serve :连接的服务数
4. Wk Queued :当前队列的所有请求的参数和
5. #Queued :实际请求数
6. Ave.Len :平均队列长度
7. Machine :队列所在机器的LMID
4查看客户端信息pclt
(1) 命令: printclient 简写:pclt
-m machine 显示LMID号为machine上的客户端连接
-u username 显示用户名为username 的客户端连接
-c ctlname 显示用户进程为ctlname的客户端连接
(2) 结果示例:
  LMID        User Name       Client Name    Time    Status  Bgn/Cmmt/Abrt
---------- --------------- --------------- -------- ------- -------------
simple          ccsmis          WSH        17:42:47   IDLE      0/0/0
simple          ccsmis          tmadmin    0:44:28    IDLE      0/0/0
(3) 结果说明:
列号  描述
1. 已经登录的客户端机器的LMID
2. 用户名，由tpinit()提供的
3. 客户端名，由tpinit()提供的
4. 客户端连接后经过的时间
5. 客户端状态
6. IDLE——表示客户端目前没有任何交易在工作
7. IDLET——表示客户端启动了一个交易
8. BUSY——表示客户端在工作中
9. BUSYT——表示客户端正在交易控制下工作
10. 启动/提交/中断的交易数

5查看部分统计信息bbs
(4) 命令: bbstats  简写：bbs
> bbs
Current Bulletin Board Status:
Current number of servers: 335
Current number of services: 2324
Current number of request queues: 27
Current number of server groups: 11
Current number of interfaces: 0

6观察某个节点的进程信息default
(5) 命令：default –m
> default -m SITE13

SITE13> psr
Prog Name      Queue Name  Grp Name      ID RqDone Load Done Current Service
---------      ----------  --------      -- ------ --------- ---------------
BBL            30004.00000 SITE13         0  22827   1141350 ..ADJUNCTBB
BRIDGE         836437      SITE13         1      0         0 (  IDLE )
GWADM          00021.00019 BGWGRP1+      19      0         0 (  IDLE )
GWTDOMAIN      00021.00020 BGWGRP1+      20 123826         0
GWADM          00022.00021 BGWGRP2+      21      0         0 (  IDLE )
GWTDOMAIN      00022.00022 BGWGRP2+      22      0         0 (  IDLE )
GWADM          00025.00027 GWGRP1_+      27      4       200 (  IDLE )

7查看消息发送状态pnw
(6) 命令：printnetwork 简写 pnw
> pnw SITE12

SITE12                         Connected To:  msgs sent    msgs received
                                      SITE14      61904            62319
                                      SITE13      61890            62288
                                      SITE11      15972            13564
8退出管理模式q
(7) 命令: quit  简写：q

在BCB中怎样使用tuxedo呢？

本文给出了一个例子。

然而，这个例子在后来被证明还是有点问题的，

就是在tpcall调用后，无法释放dll，而且会出错。

这一问题咨询过tuxedo，多少年过去了，我还没有

得到问题的解。

tuxedo 的函数很多，所有应用都使用其中子集。这些函数子集包含在开发

包中一定的动态库中。下面以

tpinit,tpcall,tpterm,tpfree,tpalloc,Fget32,Fchg32,FLDOCC32 几个函数为

例介绍一下在该子集下的编程方式。（不是很准哟）

1、首先 找到这些函数所在的动态库。经过解析发现以上函数包含        

    在wtuxws32.dll，libfml32.dll 两个动态库中。多好，有了这两个动

   态库，应用程序发行时，带上他们就可以了。再也不会出现 操作系统弹出

   的动态库定位错误了。 且慢，后经研究发现，光有这两个dll不行，他们

   的运行还需如下6个dll：libbuft.dll，libengine.dll，libfml.dll，
 
   libgpnet.dll，libtux.dll，libwsc.dll。 哈哈。总算解析完了。

   好，把这些文件copy出来到自己的工程目录下。多棒。赶紧进入下一步。

2、配置编译环境。这很重要。为使大家编程方便，我们做些小动作。在

   BCB 的安装目录下（即$(BCB)标识的目录）建立tuxedo\目录，将

   tuxedo开发包中的 \bin\,\include\,\lib\几个目录拷贝到该目录下。
  
   然后，在Option|Directories/Conditionals中设置
  
    Include Path :   $(BCB)\Tuxedo\include
    Library Path :   $(BCB)\Tuxedo\lib
   
    好了，环境设置好了。在你的工程中include :
    #include <atmi.h>
    #include <fml32.h>
    #include <tmenv.h>
   
    哦，他们三个文件实在太重要了，不包含进来你会后悔的:)
   
3、建立一个tuxedo子集函数结构。为什么这样做呢，直接使用tuxedo函数

   不好吗？ 这没什么的，依个人编程环境而定。我习惯于在结构名下
  
   使用这些 外来开发包中的函数，因为你对他们不是很熟，有时会遗忘
  
   其名称，将其放在结构中，利用BCB自动提示功能，你就可以很容易
  
   找到（想起）需要的函数了。我定义的结构如下：
  
 typedef
 struct _FunTuxedo
 {
 
  int
  (_TMDLLENTRY *
  tpcall)(char _TM_FAR *,
   char _TM_FAR *,
   long ,
   char _TM_FAR * _TM_FAR *,
   long _TM_FAR *,
   long );
   
  int
  (_TMDLLENTRY *
  tpinit)(TPINIT _TM_FAR *);
  
  int
  (_TMDLLENTRY *
  tpterm)(void);
  void
  (_TMDLLENTRY *
  tpfree)(char _TM_FAR *);
  
  char *
  (_TMDLLENTRY *
  tpalloc)(char _TM_FAR *,
      char _TM_FAR *,
      long);
  
  int
  (_TMDLLENTRY *
  Fget32)(FBFR32 _TM_FAR *,
     FLDID32,
     FLDOCC32,
     char _TM_FAR *,
     FLDLEN32 _TM_FAR *);
  
  
  int
  (_TMDLLENTRY *
  Fchg32)(FBFR32 _TM_FAR *,
     FLDID32,
     FLDOCC32,
     char _TM_FAR *,
     FLDLEN32);
  FLDOCC32
  (_TMDLLENTRY *
  Foccur32)( FBFR32 _TM_FAR *,
    FLDID32);
  
  HMODULE hLibfml32; // libfml32.dll 动态库句柄
  HMODULE hWtuxws32; // wtuxws32.dll 动态库句柄
 
 }FUNTUXEDO,*PFUNTUXEDO;
 
    这里，我将两个动态库句柄加入到了结构中，是因为我打算动态使用
   
   tuxedo中间件。方便我释放他们。，下一节介绍装载/释放他们
  
4 装载、释放中间件(基于FUNTUXEDO结构)

   哈，这很容易，主要用到LoadLibrary,FreeLibrary,GetProcAddress
  
   三个函数。装载代码如下：
  
    PFUNTUXEDO pFun;      
 
    //Loading Fchg32, Fget32 by LIBFML32.DLL
    pFun->hLibfml32 = LoadLibrary(libfml32.dll);
    if (pFun->hLibfml32 == NULL)
    {
     return -1;
    }
   
    (FARPROC &)pFun->Fchg32
     =(FARPROC)GetProcAddress(pFun->hLibfml32,Fchg32);
    (FARPROC &)pFun->Fget32
     =(FARPROC)GetProcAddress(pFun->hLibfml32,Fget32);
 (FARPROC &)pFun->Foccur32
     =(FARPROC)GetProcAddress(pFun->hLibfml32,Foccur32);       
           
    if (pFun->Fchg32 == NULL || pFun->Fget32 == NULL || pFun->Foccur32 == NULL)
    {
     FreeLibrary(pFun->hLibfml32);
        pFun->hLibfml32 = NULL;
     return -2;
    }
 //Loading tpacall, tpalloc, tpfree, tpinit, tpterm by WTUXWS32.DLL
 pFun->hWtuxws32 = LoadLibrary(wtuxws32.dll);
    if (pFun->hWtuxws32 == NULL)
    {
     FreeLibrary(pFun->hLibfml32);
        pFun->hLibfml32 = NULL;       
     return -3;
    }   
       
    (FARPROC &)pFun->tpcall
     =(FARPROC)GetProcAddress(pFun->hWtuxws32,tpacall);                                 
    (FARPROC &)pFun->tpalloc
     =(FARPROC)GetProcAddress(pFun->hWtuxws32,tpalloc);
    (FARPROC &)pFun->tpfree
     =(FARPROC)GetProcAddress(pFun->hWtuxws32,tpfree);
    (FARPROC &)pFun->tpinit
     =(FARPROC)GetProcAddress(pFun->hWtuxws32,tpinit);
    (FARPROC &)pFun->tpterm
     =(FARPROC)GetProcAddress(pFun->hWtuxws32,tpterm);        
                       
    if (pFun->tpcall == NULL || pFun->tpalloc == NULL ||
     pFun->tpfree == NULL || pFun->tpinit  == NULL ||
        pFun->tpterm == NULL)
    {
     FreeLibrary(pFun->hLibfml32);
        pFun->hLibfml32 = NULL;       
        FreeLibrary(pFun->hWtuxws32);
 pFun->hWtuxws32 = NULL;
        return -4;
    }    
  
   释放时很简单，只需
        FreeLibrary(pFun->hLibfml32);         
        FreeLibrary(pFun->hWtuxws32);
   即可。

(注：传统情况下，FreeLibrary(DllHandle) 是不会出问题的。但在

BEA 公司 的 这些dll面前，ms 的 FreeLibrary 就不行了，当应用程序

退出时，会有非法地址访问的问题。我检查过数次，只要一经调用tpcall

，退出时就会有问题。)

  折衷的办法是 使用 try-catch，释放时不使用FreeLibrary,

而在应用程序退出时，最后使用 FreeLibraryAndExitThread,否则即使

你使用FreeLibrary 也没法通过 catch 捕捉到异常。呵呵。

   
 5、使用。例：...的内容查帮助吧。
 
    PFUNTUXEDO pFun;   
    char *pSendBuff;
    char *pRecvBuff;
    long lRet;
    short sRet;
    int iRet;    
   
   
    //中间件服务
   
    pSendBuff = pFun->tpalloc(...);
    if (pSendBuff == NULL)
    {
     return ERR_TUXEDO;
    }
   
    pRecvBuff = pFun->tpalloc(...);
    if (pRecvBuff == NULL)
    {
     pFun->tpfree(pSendBuff);
        return ERR_TUXEDO;
    }
   
    try
    {   
    iRet = pFun->Fchg32(...);
    if (iRet == -1)
    {
     throw(1);
    }                   
   
    //建立连接
    iRet = pFun->tpinit(NULL);
    if (iRet == -1)
    {
     throw(2);
    }                       
     
    iRet = pFun->tpcall(...);
    if (iRet == -1)
    {
     throw(3);
    }     
   
    iRet = pFun->tpterm();
    if (iRet == -1)
    {
     throw(4);       
    }
    iRet =pFun->Fget32(...);
    if (iRet == -1)
    {
     throw(4);       
    }                         
   
    pFun->tpfree(pSendBuff);
    pFun->tpfree(pRecvBuff);
   
    }
    catch(int Err)
    {                   
     pFun->tpfree(pSendBuff);
  pFun->tpfree(pRecvBuff);
        return Err;
    }
    catch(...)
    {
     return ERR_UNKNOWN;
    }   

    //这里可以处理接收到的数据结果
    //...  
     
6、编译。

注意，这里有一个问题。当tpcall后，释放dll时，有一点麻烦。

后来发现的。

2003-7

buildclient -o clnt -f cl.c

编译服务程序

buildserver -o simpserv -f srv.c -s TOUPPER

启动服务程序

tmboot –y

 

buildclient -o clnt -f cl.c

-o:指定生成的目标文件名

-f:指定要编译的源程序

编译服务程序

buildserver -o simpserv -f srv.c -s TOUPPER

-o:指定生成的目标文件名

-f:源程序

-s:提供系统启动时的tuxedo服务名称

说明:buildclient和buildserver没有编译能力,要编译tuxedo应用程序,需要安装第三方的编译器,如cc

1.tpinit连接TUXEDO服务器.

2.开辟数据缓冲区

3.将要传给service的数据放入缓冲区

4.tpcall调用服务。指定服务名,发送数据,并接收返回数据。（这里仅以同步调用为例）

5.tpfree释放缓冲区

6.tpterm退出应用，断开连接。