如图我们可以看到SALT相当于 TUXEDO 服务的一个代理，调用过程可以分解为如下几步：

    接收所有的Web Service客户端的调用请求

    把对应的SOAP请求转换成TUXEDO内部调用请求

    分发给相应的TUXEDO SERVICE并接受处理结果

    把结果转换成SOAP协议格式返回给客户端

    因为SALT是一个本地的TUXEDO 服务，相比以前利用Web service访问TUXEDO Service的方法（比如利用WTC），它减少了转换的过程，提供了开发的效率，也提高了运行时处理的速度。

    从上图我们还可以判断，SALT中的GATEWAY进程和以前/WS中的WSL和DOMAIN中的GWTDOMAIN进程功能类似，有着独立的监听端口。

    但是在实际的使用过程中，发现SALT1.1的监听进程和实际业务处理过程并没有象/WS和DOMAIN那样设计，把监听进程和实际处理业务进 程分开，在/WS中是有WSL和WSH，在DOMAIN中是GWTDOMAI，GWADM，感觉以往TUXEDO的设计风格有些差别。SALT这种设计模 式在负载大的情况下可能存在弊端。不过SALT提供了启动多个GWWS提高性能的方法，算是另外一种弥补方式吧。

    SALT的特性

    配置驱动的部署模式（Configuration-Driven Deployment，这是BEA公司的官方说法）：

    SALT对于TUXEDO来说可以看程一个对Web Service的支持是外挂系统，即以前开发的服务程序不需要任何的改动。这个外挂系统只需要简单的配置就可以完成，不需要任何附加的编程工作，配置文件 是一个XML文件。SOAP XML文档与Tuxedo Typed Buffer之间实现的是自动转换。

  上一节已经讲了GWWS的一些特性，这里在补充一些，GWWS在启动时加载自己的配置文件。这个过程包括读取XML配置文件，效验 （validating）配置文件，从Tuxedo Service 元数据注册文件（Metadata Repository）中加载对应的TUXEDO服务信息以及可靠WS传输（WS-ReliableMessaging）的规则定义文件。因此我们可以知 道GWWS可以在系统运行时期动态加载。

    你还可以通过GWWS server下载WSDL文件。

    异步调用和可靠消息传输

    SALT提供了与WS-Adressing（WS-Addressing1.0）兼容的异步通信方式。还支持客户端和服务器端的可靠消息传输（WS-ReliableMessaging）.

    安全性

    SALT使用TUXEDO的安全框架。在传输层可以使用HTTPS协议提高安全性。

    最后要注意：SALT是单独的一个产品，需要单独购买，license也不包含在标准的license里面，需要单独下载。现在支持TUXEDO8.1以上的版本。

    SALT支持的各种标准

    数据传输：SOAP1.1; SOAP1.2， 带附件的SOAP协议。

    Web Service注册： UDDI2.0

    Web Service描述协议：WSDL1.1; WS-Policy

    Web Service的架构：WS-Addressing，WS-ReliableMessaging

    互操作性

    通过SALT产生的WSDL文件，客户可用通过各种不同平台下的Web Service开发工具开发。下面是BEA官方在线文档提供的一个互操作性的一个表格，大家可以通过它简单了解一下SALT产品的互操作性。

  说了太多的理论，下面详细介绍了SALT的具体安装配置调试的过程

    安装过程

    首先安装TUXEDO9.1， SALT也支持TUXEDO8.1。这里以TUXEDO 9.1为例介绍SALT的安装配置过程。

    安装平台 Microsoft

  在BEA网站下载BEA SALT1.1 for Tuxedo9.1，注意下载产品后，还要下载SALT的license，和JOLT类似，SALT是单独的产品，需要单独的license。

    安装SALT需要注意的问题：

    第一，要打上Tuxedo9.1 RP3以后的补丁，否则系统会提示无法安装SALT。补丁可以找BEA客户支持部免费提供（当然是有服务的客户）。注意：TUXEDO8.1安装时也是需 要补丁包的，补丁在WINDOWS系统要rolling patch 268以上，UNIX系统要rolling patch 265以上。

    可以参考：http://edocs.bea.com/salt/docs11/relnotes/relnote.html#wp35631

    第二，安装TUXEDO补丁时，在WINDOWS系统要手工停止BEA ProcMGR V9.1这个服务，否则补丁无法正常安装。安装补丁后，注意必须要重新启动这个服务。这个服务是BEA提供在WINDOWS平台下模拟UNIX IPC调用的关键进程。

    方法：我的电脑 -> 管理 -> 服务 -> BEA ProcMGR V9.1。

    运行salt11_tux91_32_win2k3_x86.exe，完成安装。

    在安装完成后，会在TUXEDO安装目录下看到SALT的卸载文件。

    配置实例：

    利用TUXEDO自带的simpapp来配置。

    步骤：

    把%TUXDIR%samplessaltsimpapp路径下的GWWS_conf.xml文件和mdrsimple.in文件拷贝到%TUXDIR%samplesatmisimpapp 路径下。

    在ubbsimple的SERVERS段中加入

  共4页。

    说明：SALT是TUXEDO的本地服务，所以在UBB中需要加入TMMETADATA和GWWS这两个服务进程。

    在ubbsimple的MACHINES段中加入

  编译TUXCONFIG

  通过如下命令来生成元数据注册文件（metadata repository）

  服务配置文件mdrsimple.in中定义了TUXEDO中的全部或者部分服务。这些服务通过mdrsimple.in这个注册文件声明为Web Service。

    这个文件是运行环境中重要的一个配置文件。

    这个例子中该文件内容如下：

  我们可以看到这个文件定义了Web Service和TUXEDO服务的对应关系，参数类型和属性。

    有关TUXEDO服务元数据注册文件的说明文档参看：http://edocs.bea.com/salt/docs11/metarepo.html

    用你自己系统的网络环境把GWWS_conf.xml这个配置文件中#HOSTNAME# 和#GWWS-PORT# 替换掉。

    GWWS_confi.xml是GWWS启动时读取的配置文件，GWWS的各个属性都在这个文件中定义，是一个很重要的配置文件。详细的说明可 以参考：http://edocs.bea.com/salt/docs11/admin/config.html#wp1051710

    编译simpapp服务进程

  启动simpapp

  试验环境执行结果如下：

    共4页。

  我们可以看到TMMETADATA 和 GWWS这两个进程正常启动。

    生成WSDL文件，

  在simpapp路径下回生成simpapp.wsdl文件，有了这个文件，就可以给各种Web Service客户端提供访问TUXEDO Web Service的接口定义文件了。

    利用axis web service客户端来访问SALT

    步骤

    设置ant环境和axis环境

    比较简单的办法是在安装weblogic的机器上随便找个域，运行senDomainenv.cmd，ant的环境就会自动设置ant所需的环境变量。

    也可以利用ant的安装环境中的setEnv设置。

    利用％TUXDIR%samplessaltsimpappaxisclient提供的文件。修改axis.properties文件。我的axis安装在“D:apacheaxis-1_3”。

    我的axis.properties如下所示，注意要使用“\”双斜线。

  编译程序

  试验环境执行结果如下：

    D:beatuxedo9.1samplessaltsimpappaxisclient>ant compile Buildfile: build.xml init: compile:[wsdl2java] WSDL2Java D:beatuxedo9.1samplessaltsimpappsimpapp.wsdl [copy] Copying 1 file to D:beatuxedo9.1samplessaltsimpappaxisclientb uildworkcombeasaltexamplessimpappaxisclient [javac] Compiling 5 source files to D:beatuxedo9.1samplessaltsimpappax isclientbuildclasses [javac] 注意： D:beatuxedo9.1samplessaltsimpappaxisclientbuildworkc ombeasaltexamplessimpappaxisclientTuxedoWebServiceLocator.java 使用了未经检查或不安全的操作。 [javac] 注意： 要了解详细信息，请使用 -Xlint:unchecked 重新编译。 [jar] Building jar: D:beatuxedo9.1samplessaltsimpappaxisclientbuildsimpapp.jar BUILD SUCCESSFUL Total time: 12 seconds

    执行客户端程序

  试验环境执行结果如下：

  通过tmadmin的psr命令可以看到服务器端的调用情况

  SALT的监控

    在监控命令wsadmin模式下，查看当前配置命令：configstats(cstat)? -i InstanceID

    该命令显示各项的含义如下

    Config context id，GWWS进程使用的配置实例个数

    Config Elapsed time，配置文件装载的时间

    Current client number，当前使用这个配置文件的客户端（SOAP客户端）个数

    max attaching time，配置实例绑定GWWS的最长时间

    查看运行状态命令：gwstats(gws) -i InstanceID

    该命令显示各项的含义如下

    Request Response Done， 成功处理的客户端请求个数，即由GWWS服务进程成功处理后返回给web service客户端的完整处理过程。

    Request Response Fail，处理失败的请求个数，失败的原因可能是非法的SOAP请求，TUXEDO内部错误，SOAP请求被拒绝。

    Oneway Done，成功的把请求分发给TUXEDO服务的次数，

    Oneway Fail，分发给TUXEDO服务失败的次数。

    运行实际情况：

    共4页。

  SALT的调优

    GWWS的参数设置

    线程池的大小：参数“thread_pool_size”，默认线程池大小是16，但是在某些业务负载比较大的应用中这个数目的线程显然无法满 足需要。 因此建议通过流量分析来设置适用的线程池大小。比如，一个并发客户数在500左右的应用中，建议你部署4个GWWS进程，每个进程的线程池设为64。

    网络超时控制：“timeout”，这是一个网络超时调优参数，默认的超时为300秒。调整这个参数可以减少超时引发的错误。

    最大的Content length控制：“max_content_length”，BEA SALT管理员可以限制客户端发送请求缓冲区的大小，对于基于HTTP的SOAP协议来说，也就是限制HTTP的content length的大小。默认情况下没有大小限制。

    Backlog控制：“max_backlog”，默认值为20。这个参数的含义我们可以通过实例来解释一下，在windows系统中，对于某个端口的连接请求如果达到20，可能系统就认为超过了流量的限制（UNIX有系统参数控制，windows通过

    这种情况下如果系统的峰值连接请求是80，那么为了保证没有请求会被系统拒绝，你就需要把backlog设置为60。

    一般情况下，默认的20就能满足大多数系统的需要。只有在系统流量非常大的系统才需要调整该参数。同时调大该参数也增加了同步攻击（Syn-flood attack）的风险。

    TUXEDO的BLOCKTIME

    GWWS网络超时参数标识了一个请求在网络层消耗的最大时间，而BLOCKTIME则限定了一个请求在TUXEDO内部等待的最大时间。如果客 户端请求进入TUXEDO系统后，在BLOCKTIME的时间内请求没有处理完成，GWWS服务进程会给客户端返回一个SOAP的失败信息，同时关闭与客 户端的网络连接。BLOCKTIME在UBB配置的RESOURCE段。

    使用多个GWWS进程提高性能

    TUXEDO中最常用的一种提高吞吐量，服务器端处理能力的一种方法。如果GWWS成为了你系统的瓶颈，在物理资源允许（CPU，内存）的条件 下，增加GWWS进程的个数。使用多个GWWS需要注意的是，由于每个GWWS使用的是不同的访问端口，因此对于客户端来说每个GWWS都是不同的访问 点。客户端的配置就稍显繁琐。

    小结

    BEA公司提供的SALT是一种比JOLT， WTC更Service Orient的软件组件。SALT的出现使得TUXEDO产品可以更方便，更快捷的方式接入各种SOA平台，提高TUXEDO应用的整合能力。熟悉和了解 这个产品对广大TUXEDO开发人员管理员以及系统架构设计人员有着积极的意义。