`
hsrong
  • 浏览: 36509 次
  • 性别: Icon_minigender_1
  • 来自: 深圳
社区版块
存档分类
最新评论

JBossESB4.7 Programming Guide 翻译之八--Defining Service Configurations

    博客分类:
  • ESB
 
阅读更多
Defining Service Configurations
Overview
        JbossESB4.7的配置是基于jbossesb-1.2.0XSD。这个XSD是ESB的配置指南。这个model包含两个主要部分:
          1 <provider> model的这个部分定义了所有消息的<bus>privider,这些<bus>是供<services>部分定义的消息的<listener>使用。
          2 <service> model的这个部分定义了一个Jboss ESB实例拥有的所有服务。每个<service>实例中包含或者“Gateway”或者“Message Aware”监听定义.
    使用JBoss Developer Studio是基于这种模型进行配置的最简单的方式。你也可以使用一个XSD aware的XML编辑器,比如Eclipse IDE中的xml Editer。这为开发者提供了一个自动补全特性。

Providers
    配置中的<providers>部分为一个单独的ESB实例定义了所有消息的<provider>实例。目前支持两种类型的provider:
           Bus Providers:这些描述了事件驱动的provider的信息,例如“push”消息的listener。这种provider类型的一个例子就是<jms-provider>。
           Schedule Provider:指的是计划驱动listener的配置。如入。“pull”消息的listener。
    一个Bus Provider(例如<jms-provider>)可以包含多个<bus>定义。<provider>也可以包含多个相关的<property>实例,这些属性对于定义在<provider>中的所有<bus>实例是通用的(例如JMS,- “connection-factory”, “jndi-context-factory”)。相反,每个<bus>实例也可以定义自己特有的属性(例如,对于JMs -“destination-type”, “destination-name”)。
    例如,下面是一个关于JMS provider 的配置:

<providers>
    <provider name="JBossMQ">
<property name="connection-factory" value="ConnectionFactory" />
<property name="jndi-URL" value="jnp://localhost:1099" />
<property name="protocol" value="jms" />
<property name="jndi-pkg-prefix" value="com.xyz"/> 
<bus busid="local-jms">
   <property name="destination-type" value="topic" />
       <property name="destination-name" value="queue/B" />
       <property name="message-selector" value="service='Reconciliation'"
       <property name=”persistent” value=”true”/>
</bus>
    </provider>
</providers>


         上面这个例子用的是基本类型的<provider>和<bus>。这是相当合理的,但是我们建议在真实的配置过程中,使用这些类型的扩展类型。比如对于JMS来说,使用<jms-provider>和<jms-bus>。上述配置中最重要的部分就是配置定义在<bus>实例上的busid属性。这个是<bus>元素的必须的属性(对于他的扩展也一样)。这个属性会在<listener>配置中引用来表明这个listener接收的消息是哪个<bus>实例的。

Services
    配置中的<service>部分定义了这个ESB实例所拥有的全部服务。它是以定义一系列<service>配置实现的。一个<service>可以包含以下属性:

名称 描述 类型 是否必须
name 该服务在Service Registry注册的服务名 xsd:string 是
category 该服务在Service Registry注册的服务目录 xsd:string 是
description 可读的存储在Registry中的服务的描述 xsd:string 是

    一个<service>可能定义一系列<listeners>和<actions>。这个配置model定义了一个基本的<listener>类型,还为主要支持的传输定义了专门listener。比如<jms-listener><sql-listener>.
    基本的<listener>定义了下列属性。所有的<listener>扩展都继承了这些属性定义。因此,JBossESB支持的所有网关和listener都能设这些属性,比如InVM。

名称 描述 类型 是否必  须
name Listener的名字。这个属性是记录日志的目的 xsd:string 是
busrefid 对于<bus>的busid的引用,listener通过该bus接收消息 xsd:string 是
maxThreads 这个listener能够激活的处理消息的最大并发线程数 xsd:string 是
is-gateway 用于表明这个listener是网关还是Message Aware Listener xsd:string 是

          Listener可以定义0或者多个<property>元素。这些<property>元素用于定义的特殊属性。
注意:对于服务中定义的每个gateway listener,一个ESB aware Listener。在ESB内部,你不能发送一个消息到网关。并且,注意一你问网关不是一个端点,他在Registry中没有端点引用(EPR)。
    下面是一个<listener>引用<bus>的例子:

    如果一个服务不包含一系列<action>的话,这个服务不能发挥什么作用。Actions是服务真正发挥作用的元素。一般<action>中包含了处理从服务上获取的消息payload的逻辑。也有可能,action中也包含了转换信息或者将消息路由出去的逻辑,以便能被其他服务或实体处理。
下面是action的一些属性:
名称 描述 类型 是否必须
name action的名字。这个属性是记录日志的目的 xsd:string 是
class org.jboss.soa.esb.actions.ActionProcessor的实现类的名字 xsd:string 是
process
处理方法的名字。在消息处理过程中将会调用。默认是“process”方法。 xsd:string 否
         <actions>元素中包含了一系列的<action实例,这些action是按照他们在<actions>出现的顺序依次调用的。每个<action>返回的消息将会作为下个<action>的输入消息。

         <actions>元素中包含了一系列的<action实例,这些action是按照他们在<actions>出现的顺序依次调用的。每个<action>返回的消息将会作为下个<action>的输入消息。
就像model中的其他元素一样,<action>元素也包含0或者多个<property>元素。属性元素既可以是“name-value-pair”的形式定义,也可以是任何形式的内容。根据XSD的定义,不管这个<property>在哪配置,任何形式的内容都是<property>元素的有效子内容。然而,只有在<action>元素上定义的<property>实例时才使用任何形式子内容。
就像上面所说的那样,action是通过实现org.jboss.soa.esb.actions.ActionProcessor类来实现的。这个接口的所有实现必须包含一个构造函数:
        public ActionZ(org.jboss.soa.esb.helpers.ConfigTree configuration);

    可以通过构造函数的ConfigTree实例获得所有的Action属性,包括<property>实例中的任何形式的内容。这些内容是ConfigTree实例内容的一部分。
下面是一个<actions>配置的例子:

<actions>
    <action name="MyAction-1" class="com.acme.MyAction1"/>
    <action name="MyAction-2" class="com.acme.MyAction2">
        <property name=”propA” value=”propAVal” />
    </action>
    <action name="MyAction-3" class="com.acme.MyAction3">
        <property name=”propB” value=”propBVal” />
        <property name=”propC”>
            <!-- Free form child content... -->
            <some-free-form-element>zzz<some-free-form-element>
        </property>
    </action>
</actions>


Transport Specific Type Implementations
    JBossESB配置model定义了基本类型<provider>,<bus>和<listener>的特殊传输实现,比如JMS,SQL等。这使我们能对配置进行更好的验证,同时使用XSD aware的xml编辑器进行配置更简单。当创建配置时,建议使用这些特殊类型而不是基本类型。
在使用基本类型创建配置时的原则同样适用于使用这些特定传输的配置。
    1.定义provider配置。例如。<jms-provider>
    2.针对这个新的provider添加bus配置,指定一个唯一的busid属性值
    3.正常的定义你的<services>,添加传输指定的listener配置。(例如,<jms-provider>要通过busrefid引用bus配置,比如<jms-listener>引用<jms-bus>)
    唯一的规则就是当使用这些特定传输类型时,你不能使用一种类型的listener去引用另一种类型的bus,也就是说listener与所引用的bus要是相同类型的,比如你可以使用<jms-listener>引用<jms-bus>。否则,将会导致一个运行时的错误。
在这个版本中,可用的传输特定实现有:
1.JMS
<jms-provider>, <jms-bus>, <jms-listener> 和 <jms-message-filter>。<jms-message-filter>只能添加在<jms-bus>和<jms-provider>元素中。<jms-bus>和<jms-listener>指定了JMS的连接属性,<jms-message-filter>指定了现实消息的QUEUE/TOPIC 和 selector细节。
2.SQL
<sql-provider>, < sql -bus>, < sql -listener> 和 < sql -message-filter>。<sql -message-filter>只能添加在< sql -bus>和< sql -provider>元素中。< sql -bus>和< sql -listener>指定了JDBC的连接属性,< sql -message-filter>指定消息或者行的选择处理属性。
3.FTP
<ftp-provider>, <ftp -bus>, <ftp -listener> 和 < ftp -message-filter>。< ftp -message-filter>只能添加在<ftp-bus>和< ftp-listener>元素中。< ftp-bus>和< ftp-provider>指定了FTP的连接属性,< sql -message-filter>指定消息或者文件的选择处理属性。
4.HIBERNATE
<hibernate-provider>,<hibernate-bus>,<hibernate-listener> 和<hibernate -message-filter>。< hibernate-message-filter>只能添加在< hibernate-bus>和< hibernate -listener>元素中。< hibernate -provider>指定了FileSystem获取属性,比如hibernate配置文件的位置,< hibernate -message-filter>指定要拦截的类和事件。
5.File System:
<fs-provider>, <fs-bus>, <fs-listener> 和 < fs-message-filter>。< fs-message-filter>只能添加在<fs-bus>和< fs-listener>元素中。< fs-bus>和< fs-provider>指定了文件系统连接属性,< fs -message-filter>指定消息或者文件的选择和处理属性。
6.Schedule:
<schedule-provider>。这是一种reshuffle的provider,和前面几种基于bus的provider不同。更多细节参考Scheduling一章。
7.JMS/JCA integration:
<jms-jca-provider>。这个provider可以代替<jms-provider>,以便能使用JCA inflow来传送进入的消息。这为action管道引进了一种事务流,使action处于一个JTA事务中。
也许你已经注意到了,在目前实现的所有特定传输类型中包含一种基本类型中没有的,那就是<*-message-filter>。这种元素可以被添加到<*-listener>或者<*-bus>中。允许在两个地方设置就意味着你就可以指定全局性的消息过滤也可以专门为某个listener指定。
为了展示和描述每个传输特定类型的属性,你可以使用jbossesb-1.1.0XSD,jbossesb-1.1.0XSD全面的描述了每个属性。

|属性名|描述|是否必须|
|dest-type|目标的类型,QUEUE或者 TOPIC|强制|
|dest -name|QUEUE或者 TOPIC的名称|强制|
|selector|如果同一个queue或者topic上有多个listener,将会根据消息的selector进行过滤|可选|
|persistent|表明JMS的传输模型是不是需要持久化。True或者false|可选。默认为true|
|acknowledge-mode|JMS会话的确认模型|AUTO_ACKNOWLEDGE,CLIENT_ACKNOWLEDGE,DUPS_OK_ACKNOWLEDGE之一|可选。默认AUTO_ACKNOWLEDGE|
|jms-security-principal|JMS目标的用户名。创建连接时使用。|可选|
|ms-security-credential|JMS目标的密码。创建连接时使用|可选
<jms-bus busid="quickstartGwChannel">

<jms-message-filter dest-type="QUEUE" dest-name="queue/quickstart_jms_secured_Request_gw"
jms-security-principal="esbuser"
jms-security-credential="esbpassword"
/>
</jms-bus>

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics