JBoss Community Archive (Read Only)

SwitchYard

Bindings

SOAP

The SOAP component in SwitchYard provides SOAP-based web service binding support for services and references in SwitchYard. 

Binding Services with SOAP

Composite-level services can be exposed as a SOAP-based web service using the <binding.soap> binding definition.  The following configuration options are available for binding.soap when binding services:

  • wsdl : location of the WSDL used to describe the web service endpoint.  A relative path can be used if the WSDL is included in the deployed application.  If the WSDL is located outside the application, then a file: or http: URL can be used.

  • socketAddr : the IP Socket Address to be used. The value can be in the form hostName/ipAddress:portNumber or hostName/ipAddress or :portNumber.

  • wsdlPort : port name in the WSDL to use.  If unspecified, the first port definition in the WSDL is used for the service endpoint

  • contextPath : additional context path for the SOAP endpoint. Default is none.

In AS7 by default the JBossWS-CXF stack is enabled now and hence the socketAddr parameter will be ignored. However, this parameter can be used for standalone usage.

Here's an example of what a SOAP service binding looks like: 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:service name="OrderService" promote="OrderService">
        <soap:binding.soap>
            <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
            <soap:socketAddr>:9000</soap:socketAddr>        
         </soap:binding.soap>
    </sca:service>
</sca:composite>

Binding References with SOAP

Binding a reference with SOAP can be used to make SOAP-based web services available to SwitchYard services. The following configuration options are available for binding.soap when binding references:

  • wsdl : location of the WSDL used to describe the web service endpoint.  A relative path can be used if the WSDL is included in the deployed application.  If the WSDL is located outside the application, then a file: or http: URL can be used.

  • wsdlPort : port name in the WSDL to use.  If unspecified, the first port definition in the WSDL is used for the service endpoint.

  • endpointAddress : the SOAP endpoint address to override from that specified in the WSDL. Optional property, if not specified will use the one specified in the WSDL.

  • timeout : The request's time-out value in milliseconds.

  • proxy : HTTP Proxy settings for the endpoint.

  • basic/ntlm : authentication configuration for the endpoint. 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
         <soap:binding.soap>
            <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
            <soap:endpointAddress>http://www.change.com/toanewendpointurl</soap:endpointAddress>
         </soap:binding.soap>
    </sca:reference>
</sca:composite>

Proxy Configuration

If the SOAP reference needs to pass through a proxy server then the proxy server configuration can be provided using the proxy element. The following configuration options are available:

  • type : The proxy type. Can be HTTP or SOCKS, default is HTTP

  • host : The proxy host.

  • port : The proxy port (optional).

  • user : The proxy user (optional).

  • password : The proxy password (optional). 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
        <soap:binding.soap>
            <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
            <soap:endpointAddress>[http://www.change.com/toanewendpointurl]</soap:endpointAddress>
            <soap:proxy>
                <soap:type>HTTP</soap:type>
                <soap:host>192.168.1.2</soap:host>
                <soap:port>9090</soap:port>
                <soap:user>user</soap:user>
                <soap:password>password</soap:password>
            </soap:proxy>
        </soap:binding.soap>
    </sca:reference>
</sca:composite>

Authentication Configuration

If the SOAP reference endpoint is secured using BASIC/NTLM, then the authentication configuration can be provided using the basic or ntlm elements. The following configuration options are available:

  • user : the user name.

  • password : password.

  • host : the authentication host (optional).

  • port : the authentication port (optional).

  • realm : the authentication realm (optional, applicable only for BASIC).

  • domain: the Windows domain for authentication (optional, applicable only for NTLM).

A sample NTLM authentication configuration: 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
        <soap:binding.soap>
            <soap:wsdl>wsdl/OrderService.wsdl</soap:wsdl>
            <soap:endpointAddress>[http://www.change.com/toanewendpointurl]</soap:endpointAddress>
            <soap:ntlm>
                <soap:user>user</soap:user>
                <soap:password>password</soap:password>
                <soap:domain>domain</soap:domain>
            </soap:ntlm>
        </soap:binding.soap>
    </sca:reference>
</sca:composite>

Security

Important

It is strongly suggested that you first read up on JBoss Web Services WS-Security.

UsernameToken Support

To enable WS-Security within your application, a few steps are required:

  1. Define a Policy within your WSDL, and reference with with a PolicyReference inside your binding.

  2. Configure your <soap.binding> with an <endpointConfig> so JBossWS-CXF is configured properly.

  3. Configure your <soap.binding> with an <inInterceptors> section, including the appropriate JBossWS-CXF <interceptor> to handle incoming SOAP requests.

  4. Include a WEB-INF/jboss-web.xml in your application with a <security-domain> specified, so JBossWS-CXF knows which modules to use for authentication and roles mapping.

SwitchYard provides a policy-security-wss-username Quickstart as an example. Here are the pertinent sections:

META-INF/WorkService.wsdl 

  <binding name="WorkServiceBinding" type="tns:WorkService">
    <wsp:PolicyReference URI="#WorkServicePolicy"/>
    ...
  </binding>
  <wsp:Policy wsu:Id="WorkServicePolicy">
    <wsp:ExactlyOne>
      <wsp:All>
        <sp:SupportingTokens xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
          <wsp:Policy>
            <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">
              <wsp:Policy>
                <sp:WssUsernameToken10/>
              </wsp:Policy>
            </sp:UsernameToken>
          </wsp:Policy>
        </sp:SupportingTokens>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>

META-INF/switchyard.xml 

  <binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
    <wsdl>META-INF/WorkService.wsdl</wsdl>
    <contextPath>policy-security-wss-username</contextPath>
    <endpointConfig configFile="META-INF/jaxws-endpoint-config.xml" configName="SwitchYard-Endpoint-Config"/>
    <inInterceptors>
        <interceptor class="org.jboss.wsf.stack.cxf.security.authentication.SubjectCreatingPolicyInterceptor"/>
    </inInterceptors>
  </binding.soap>

WEB-INF/jaxws-endpoint-config.xml 

<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
    <endpoint-config>
        <config-name>SwitchYard-Endpoint-Config</config-name>
        <property>
            <property-name>ws-security.validate.token</property-name>
            <property-value>false</property-value>
        </property>
    </endpoint-config>
</jaxws-config>

WEB-INF/jboss-web.xml 

<jboss-web>
    <security-domain>java:/jaas/other</security-domain>
</jboss-web>

With the above pieces in place, JBossWS-CXF will intercept incoming SOAP requests, extract the UsernameToken, attempt to authenticate it against the LoginModule(s) configured in the application server's "other" security domain, and provide any authorized roles. If successful, the request will be handed over to SwitchYard, who can do further processing, including enforcing our own policies. In the case of WS-Security, SwitchYard will not attempt a second clientAuthentication, but instead will respect the outcome from JBossWS-CXF. Note that if the original clientAuthentication fails, it is a "fail-fast" scenario, and the request will not be channeled into SwitchYard.

Signature and Encryption Support

Required steps:

  1. The Policy in your WSDL needs to reflect the added requirements. An example of this can be found in the JBossWS documentation here: Signature and Encryption.

  2. Configure your <soap.binding> with an <endpointConfig> so JBossWS-CXF is configured properly.

For example:

META-INF/switchyard.xml 

  <binding.soap xmlns="urn:switchyard-component-soap:config:1.0">
    <wsdl>META-INF/WorkService.wsdl</wsdl>
    <contextPath>policy-security-wss-username</contextPath>
    <endpointConfig configFile="META-INF/jaxws-endpoint-config.xml" configName="SwitchYard-Endpoint-Config">
  </binding.soap>

WEB-INF/jaxws-endpoint-config.xml 

<jaxws-config xmlns="urn:jboss:jbossws-jaxws-config:4.0" xmlns:javaee="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:jboss:jbossws-jaxws-config:4.0 schema/jbossws-jaxws-config_4_0.xsd">
    <endpoint-config>
        <config-name>SwitchYard-Endpoint-Config</config-name>
        <property>
            <property-name>ws-security.callback-handler</property-name>
            <property-value>org.switchyard.quickstarts.demo.policy.security.wss.signencrypt.WorkServiceCallbackHandler</property-value>
        </property>
        <property>
            <property-name>ws-security.encryption.properties</property-name>
            <property-value>META-INF/bob.properties</property-value>
        </property>
        <property>
            <property-name>ws-security.encryption.username</property-name>
            <property-value>alice</property-value>
        </property>
        <property>
            <property-name>ws-security.signature.properties</property-name>
            <property-value>META-INF/bob.properties</property-value>
        </property>
        <property>
            <property-name>ws-security.signature.username</property-name>
            <property-value>bob</property-value>
        </property>
    </endpoint-config>
</jaxws-config>

META-INF/bob.properties 

org.apache.ws.security.crypto.provider=org.apache.ws.security.components.crypto.Merlin
org.apache.ws.security.crypto.merlin.keystore.type=jks
org.apache.ws.security.crypto.merlin.keystore.password=password
org.apache.ws.security.crypto.merlin.keystore.alias=bob
org.apache.ws.security.crypto.merlin.file=META-INF/bob.jks

Attachments

SOAP with Attachments (SwA)

By default any attachment sent with a SOAP Envelope is passed around in a SwitchYard Message as an attachment. The default SOAPMessageComposer handles this.

SOAP with MTOM/XOP

To support optimization mechanism, the underlying stack transports/receives the attachments as Mime-Multipart messages. One additional configuration in SwitchYard that allows to expand an xop:inline's SOAP Message is this:

  • mtom : attribute xopExpand when set to true will replace the xop:include element with the contents from the Mime attachment.

sample: 

<soap:binding.soap xmlns:soap="urn:switchyard-component-soap:config:1.0">
    <soap:wsdl>Foo.wsdl</soap:wsdl>
    <soap:endpointAddress>http://modified.com/phantom</soap:endpointAddress>
    <soap:mtom enabled="true" xopExpand="true"/>
</soap:binding.soap>

MTOM can be enabled using WSDL policy as shown below or can be overridden as shown above using the SwitchYard config. 

<definitions targetNamespace="urn:switchyard-component-soap:test-ws:1.0" name="ImageService"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="urn:switchyard-component-soap:test-ws:1.0"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
    xmlns:wsp="http://www.w3.org/ns/ws-policy"
    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
    xmlns:xmime="http://www.w3.org/2005/05/xmlmime"
    xmlns:wsoma="http://www.w3.org/2007/08/soap12-mtom-policy"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
...
    <wsp:Policy wsu:Id="ImageServicePortBinding_policy">
        <wsp:ExactlyOne>
            <wsp:All>
                <wsoma:MTOM/>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>
...
  <binding name="ImageServicePortBinding" type="tns:ImageService">
    <wsp:PolicyReference URI="#ImageServicePortBinding_policy"/>
    <soap:binding transport="http://www.w3.org/2003/05/soap/bindings/HTTP/" style="document"/>
    <operation name="resize">
      <soap:operation soapAction=""/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>

Addressing

SwitchYard runtime provides support for WS-A via the underlying SOAP stack. To enable WS-A you can either set a policy or use the UseAdrressing element in the WSDL as shown below: 

<definitions targetNamespace="urn:switchyard-component-soap:test-ws:1.0" name="HelloAddressingService"
    xmlns="http://schemas.xmlsoap.org/wsdl/"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:tns="urn:switchyard-component-soap:test-ws:1.0"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
    xmlns:wsp="http://www.w3.org/ns/ws-policy"
    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
...
    <wsp:Policy wsu:Id="HelloSOAPAddressingServicePortBinding_policy">
        <wsp:ExactlyOne>
            <wsp:All>
                <wsam:Addressing wsdl:required="false">
                    <wsp:Policy/>
                </wsam:Addressing>
            </wsp:All>
        </wsp:ExactlyOne>
    </wsp:Policy>
...
  <binding name="HelloSOAPAddressingServicePortBinding" type="tns:HelloAddressingService">
    <wsp:PolicyReference URI="#HelloSOAPAddressingServicePortBinding_policy"/>
    <soap:binding transport="http://www.w3.org/2003/05/soap/bindings/HTTP/" style="document"/>
    <operation name="sayHello">
      <soap:operation soapAction=""/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>
...
  <binding name="HelloSOAPAddressingServicePortBinding2" type="tns:HelloAddressingService2">
    <wsaw:UsingAddressing required="true" />
    <soap:binding transport="http://www.w3.org/2003/05/soap/bindings/HTTP/" style="document"/>
    <operation name="sayHello">
      <soap:operation soapAction=""/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>

HTTP

The HTTP component in SwitchYard provides HTTP-based binding support for services and references in SwitchYard. 

Binding Services with HTTP

Composite-level services can be exposed as a HTTP-based service using the <binding.http> binding definition.  The following configuration options are available for binding.rest when binding services:

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details.

  • contextPath : A context path for the HTTP endpoint.

Here's an example of what a HTTP service binding looks like: 

<sca:service name="QuoteService" promote="StockService/QuoteService">
    <http:binding.http>
        <selector:operationSelector operationName="getPrice"/>
        <http:contextPath>http-binding/quote</http:contextPath>
    </http:binding.http>
</sca:service>

Binding References with HTTP

Binding a reference with HTTP can be used to make HTTP-based services available to SwitchYard services. The following configuration options are available for binding.http when binding references:

  • address : A URL that points to the HTTP endpoint. It is optional and if not specified will default to http://127.0.0.1:8080/.

  • method : The HTTP method used for invoking the endpoint. Default is GET.

  • timeout : The request's time-out value in milliseconds.

  • contentType : The HTTP Content-Type header that needs to be set on the request.

  • proxy : HTTP Proxy settings for the endpoint.

  • basic/ntlm : authentication configuration for the endpoint.

Here's an example of what a HTTP reference binding looks like: 

<sca:reference name="Symbol" promote="StockService/SymbolService" multiplicity="1..1">
    <http:binding.http>
        <http:address>http://localhost:8080/http-binding/symbol</http:address>
        <http:method>POST</http:method>
        <http:contentType>text/plain</http:contentType>
    </http:binding.http>
</sca:reference>

Proxy Configuration

If the HTTP reference needs to pass through a proxy server then the proxy server configuration can be provided using the proxy element. The following configuration options are available:

  • host : The proxy host.

  • port : The proxy port (optional).

  • user : The proxy user (optional).

  • password : The proxy password (optional). 

<sca:reference name="Symbol" promote="StockService/SymbolService" multiplicity="1..1">
    <http:binding.http>
        <http:address>http://localhost:8080/http-binding/symbol</http:address>
        <http:proxy>
            <http:host>host</http:host>
            <http:port>8090</http:port>
            <http:user>Beal</http:user>
            <http:password>conjecture</http:password>
        </http:proxy>
    </http:binding.http>
</sca:reference>

Authentication Configuration

If the HTTP reference endpoint is secured using BASIC/NTLM, then the authentication configuration can be provided using the basic or ntlm elements. The following configuration options are available:

  • user : The authentication user.

  • password : The authentication password.

  • realm/domain : The authentication realm or the Windows domain.

A sample BASIC authentication configuration: 

<sca:reference name="Symbol" promote="StockService/SymbolService" multiplicity="1..1">
    <http:binding.http>
        <http:address>http://localhost:8080/http-binding/symbol</http:address>
        <http:basic>
            <http:user>Beal</http:user>
            <http:password>conjecture</http:password>
            <http:realm>Any</http:realm>
        </http:basic>
    </http:binding.http>
</sca:reference>

RESTEasy

The RESTEasy component in SwitchYard provides REST-based binding support for services and references in SwitchYard. 

Binding Services with RESTEasy

Composite-level services can be exposed as a REST-based service using the <binding.rest> binding definition.  The following configuration options are available for binding.rest when binding services:

  • interfaces : A comma seperated list of interfaces or abstract/empty classes with JAX-RS annotations.

  • contextPath : Additional context path for the REST endpoint. Default is none.

Here's an example of what a REST service binding looks like: 

<sca:service name="OrderService" promote="OrderService/OrderService">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.OrderResource,org.switchyard.quickstarts.rest.binding.TestResource</rest:interfaces>
        <rest:contextPath>rest-binding</rest:contextPath>
    </rest:binding.rest>
</sca:service>

Binding References with RESTEasy

Binding a reference with REST can be used to make REST-based services available to SwitchYard services. The following configuration options are available for binding.rest when binding references:

  • interfaces : A comma seperated list of interfaces or abstract/empty classes with JAX-RS annotations.

  • address : A URL that points to the root path of resources. This is only applicable for Reference bindings. It is optional and if not specified will default to http://127.0.0.1:8080/.

  • timeout : The request's time-out value in milliseconds.

  • contextPath : Additional context path for the REST endpoint. Default is none.

  • proxy : HTTP Proxy settings for the endpoint.

  • basic/ntlm : authentication configuration for the endpoint.

Here's an example of what a REST reference binding looks like: 

<sca:reference name="Warehouse" promote="OrderService/Warehouse" multiplicity="1..1">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.WarehouseResource</rest:interfaces> 
        <rest:address>http://localhost:8080</rest:address>
        <rest:contextPath>rest-binding</rest:contextPath>
    </rest:binding.rest>
</sca:reference>

In this example above the resource URLs will start from http://localhost:8080/rest-binding.

Proxy Configuration

If the REST reference needs to pass through a proxy server then the proxy server configuration can be provided using the proxy element. The following configuration options are available:

  • host : The proxy host.

  • port : The proxy port (optional).

  • user : The proxy user (optional).

  • password : The proxy password (optional). 

<sca:reference name="Warehouse" promote="OrderService/Warehouse" multiplicity="1..1">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.WarehouseResource</rest:interfaces> 
        <rest:address>http://localhost:8080/rest-binding</rest:address>
        <rest:proxy>
            <rest:host>host</rest:host>
            <rest:port>8090</rest:port>
            <rest:user>Beal</rest:user>
            <rest:password>conjecture</rest:password>
        </rest:proxy>
    </rest:binding.rest>
</sca:reference>

Authentication Configuration

If the REST reference endpoint is secured using BASIC/NTLM, then the authentication configuration can be provided using the basic or ntlm elements. The following configuration options are available:

  • user : The authentication user.

  • password : The authentication password.

  • realm/domain : The authentication realm or the Windows domain.

A sample NTLM authentication configuration: 

<sca:reference name="Warehouse" promote="OrderService/Warehouse" multiplicity="1..1">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.WarehouseResource</rest:interfaces> 
        <rest:address>http://localhost:8080/rest-binding</rest:address>
        <rest:ntlm>
            <rest:user>user</rest:user>
            <rest:password>password</rest:password>
            <rest:domain>domain</rest:domain>
        </rest:ntlm>
    </rest:binding.rest>
</sca:reference>

SSL Configuration

If the REST reference endpoint is secured using SSL, the following optional configuration options are available:

  • verifier : Allowed options are ANY,STRICT or BROWSER. Please read Apache HTP component documentation for more info.

  • keystore : The SSL keystore.

  • keystorePass : The password for SSL keystore.

  • truststore : The SSL truststore.

  • truststorePass : The password for SSL truststore.

A sample configuration: 

<sca:reference name="Warehouse" promote="OrderService/Warehouse" multiplicity="1..1">
    <rest:binding.rest>
        <rest:interfaces>org.switchyard.quickstarts.rest.binding.WarehouseResource</rest:interfaces> 
        <rest:address>https://localhost:8443/rest-binding</rest:address>
        <rest:ssl>
            <rest:verifier>ANY</rest:verifier>
            <rest:keystore>https.jks</rest:keystore>
            <rest:keystorePass>changeit</rest:keystorePass>
            <rest:truststore>client.jks</rest:truststore>
            <rest:truststorePass>changeit</rest:truststorePass>
        </rest:ssl>
    </rest:binding.rest>
</sca:reference>

JCA

The JCA gateway allows you to send and receive messages to/from EIS via JCA ResourceAdapter.

Binding Services with JCA message inflow

Composite-level services can be bound to a EIS with JCA message inflow using the <binding.jca> binding definition.  The following configuration options are required for binding.jca:

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details.

  • inboundConnection

    • resourceAdapter

      • @name : Name of the ResourceAdapter archive. Please make sure the resource adapter has been deployed on JBoss application server before you deploy the SwitchYard application which has JCA binding.

    • activationSpec

      • property : Properties to be injected into ActivationSpec instance. Required properties are specific to the ResourceAdapter implementation.

  • inboundInteraction

    • listener : FQN of the listener interface. When you use JMSEndpoint, javax.jms.MessageListener should be specified. When you use CCIEndpoint, javax.resource.cci.MessageListener should be specified. Otherwise, you may need to specify EIS specific listener interface according to its ResourceAdapter. Note that the endpoint class should implement this listener interface.

    • endpoint

      • @type : FQN of the Endpoint implementation class. There are 2 built-in Endpoint, org.switchyard.component.jca.endpoint.JMSEndpoint and org.switchyard.component.jca.endpoint.CCIEndpoint. Note that these 2 have corresponding listener. If neither JMSEndpoint nor CCIEndpoint is applicable for the EIS you're supposed to bind to, then you need to implement its own Endpoint class according to the ResourceAdapter implementation. The Endpoint class should be a subclass of org.switchyard.component.jca.endpoint.AbstractInflowEndpoint.

      • property : Properties to be injected into Endpoint class. See "Endpoint Properties" for more detail.

    • transacted : The boolean value to indicate whether transaction is needed by endpoint or not. True by default.

    • batchCommit : Multiple incoming messages are processed in one transaction if you define this element. The transaction is committed when the number of processed messages reach to batchSize, or batchTimeout milliseconds pass since the transaction is started. Transaction reaper thread is watching inflight transaction, and once batch timeout occurs the transaction reaper thread commits it.

      • @batchSize : The number of messages to be processed in one transaction

      • @batchTimeout : The batch timeout in milliseconds

Endpoint Properties

The build-in endpoints JMSEndpoint and CCIEndpoint has following configurable properties.

  • JMSEndpoint : Note that all the properties for this endpoint is to perform IN_OUT MEP. JCA JMS message inflow is generally IN_ONLY, but if you set these properties, JMSEndpoint sends reply or fault message back in return for inflow message.

    • connectionFactoryJNDIName : JNDI name of JMS ConnectionFactory

    • jndiPropertiesFileName : Name of the JNDI properties file

    • destinationType : Destination type of replyTo/faultTo. Possible values are Queue, Topic and JNDI deprecated. We recommend to use Queue or Topic and specify physical name

    • replyTo : Name of the replyTo destination

    • faultTo : Name of the faultTo destination

    • messageType : Type of the message. Possible values are Text, Object, Bytes, Map, Stream and Plain. Object message is used by default.

    • userName : User name

    • password : password

    • destinationJndiPropertiesFileName

  • CCIEndpoint

    • images/author/images/icons/emoticons/star_yellow.gif connectionFactoryJNDIName : JNDI name of CCI ConnectionFactory

images/author/images/icons/emoticons/star_yellow.gif required property

Dynamic property configuration

Some of JMSEndpoint properties are configurable via context property. You can override those properties with specifying corresponding context property.

JMSEndpoint property name

Context property name

destinationType

org.switchyard.component.jca.endpoint.destinationType

replyTo

org.switchyard.component.jca.endpoint.replyTo

faultTo

org.switchyard.component.jca.endpoint.faultTo

messageType

org.switchyard.component.jca.endpoint.messageType

Here's an example of what a JCA service binding looks like. This example binds a service to the HornetQ JMS: 

<sca:composite name="JCAInflowExample" targetNamespace="urn:userguide:jca-example-service:0.1.0">
    <sca:service name="JCAService" promote="SomeService">
        <jca:binding.jca>
            <selector:operationSelector operationName="onMessage"/>
            <jca:inboundConnection>
                <jca:resourceAdapter name="hornetq-ra.rar"/>
                <jca:activationSpec>
                    <jca:property name="destinationType" value="javax.jms.Queue"/>
                    <jca:property name="destination" value="ServiceQueue"/>
                </jca:activationSpec>
            </jca:inboundConnection>
            <jca:inboundInteraction>
                <jca:listener>javax.jms.MessageListener</jca:listener>
                <jca:endpoint type="org.switchyard.component.jca.endpoint.JMSEndpoint"/>
                <jca:transacted>true</jca:transacted>
                <jca:batchCommit batchSize="10" batchTimeout="5000"/>
            </jca:inboundInteraction>
        </jca:binding.jca>
    </service>
    <!-- sca:component definition omitted -->
</sca:composite>

Binding References with JCA outbound

Composite-level references can be bound to a EIS with JCA outbound using the <binding.jca> binding definition.  The following configuration options are required for binding.jca:

  • outboundConnection

    • resourceAdapter

      • @name : Name of the ResourceAdapter archive. Please make sure the resource adapter has been deployed on JBoss application server before you deploy the SwitchYard application which has JCA binding.

    • connection

      • @jndiName : JNDI name which the ConnectionFactory is bound into.

  • outboundInteraction

    • connectionSpec : Configuration for javax.resource.cci.ConnectionSpec. Note that JMSProcessor doesn't use this option.

      • @type : FQN of the ConnectionSpec implementation class.

      • property : Properties to be injected into ConnectionSpec instance. 

    • interactionSpec : Configuration for _javax.resource.cci.InteractionSpec. _Note that JMSProcessor doesn't use this option.

      • @type : FQN of the InteractionSpec implementation class.

      • property : Properties to be injected into InteractionSpec instance.

    • processor

      • @type : FQN of the class which processes outbound delivery. There are 2 build-in processor, org.switchyard.component.jca.processor.JMSProcessor and org.switchyard.component.jca.processor.CCIProcessor. JMSProcessor just sends a message to the JMS provider, so it only supports IN_ONLY MEP. CCIProcessor sends a input record and return a output record which is returned by the EIS. If neither JMSProcessor nor CCIProcessor is applicable for the EIS you're supposed to bind to, then you need to implement its own processor class according to the ResourceAdapter implementation. Note that this class should be a subclass of org.switchyard.component.jca.processor.AbstractOutboundProcessor.

      • property : Properties to be injected into processor instance. See "Processor Properties" for more detail.
        If the ConnectionFactory and JMS destination need to be looked up from remote JNDI provider, you can add JNDI properties file into your SwitchYard application and specify its file name with jndiPropertiesFileName property. If the ConnectionFactory and JMS Destination should be looked up from different JNDI provider, you can specify both of jndiPropertiesFileName and destinationJndiPropertiesFileName to point distinct JNDI properties file. JNDI destination lookup is deprecated. We recommend to specify Queue or Topic for destinationType and specify physical name for destination name
        You can specify the message type to be sent with messageType property. Available values are Stream for StreamMessage, Map for MapMessage, Text for TextMessage, Object for ObjectMessage, Bytes for BytesMessage and Plain for Message with no payload (headers and properties only). ObjectMessage is used by default.

Processor Properties

The build-in processors JMSProcessor and CCIProcessor has following configurable properties.

  • JMSProcessor

    • images/author/images/icons/emoticons/star_yellow.gif connectionFactoryJNDIName : JNDI name of JMS ConnectionFactory

    • jndiPropertiesFileName : Name of the JNDI properties file

    • images/author/images/icons/emoticons/star_yellow.gif destinationType : Destination type. Possible values are Queue, Topic and JNDI deprecated. We recommend to use Queue or Topic and specify physical name

    • images/author/images/icons/emoticons/star_yellow.gif destination : Name of the destination

    • messageType : Type of the message. Possible values are Text, Object, Bytes, Map, Stream and Plain. Object message is used by default.

    • username : User name

    • password : password

    • destinationJndiPropertiesFileName deprecated

    • acknowledgeMode deprecated

    • transacted deprecated

  • CCIProcessor

    • images/author/images/icons/emoticons/star_yellow.gif connectionFactoryJNDIName : JNDI name of CCI ConnectionFactory

    • images/author/images/icons/emoticons/star_yellow.gif recordClassName : Name of the record record type to be used to interact with EIS. If you use CCIProcessor with the record type other than MappedRecord IndexedRecord or StreamableRecord, you need to implement corresponding RecordHandler. Please refer to org.switchyard.component.jca.processor.cci.IndexedRecordHandler, org.switchyard.component.jca.processor.cci.MappedRecordHandler and org.switchyard.component.jca.processor.cci.StreamableRecordHandler.

images/author/images/icons/emoticons/star_yellow.gif required property

Dynamic property configuration

Some of JMSProcessor properties are configurable via context property. You can override those properties with specifying corresponding context property.

JMSProcessor property name

Context property name

destinationType

org.switchyard.component.jca.processor.destinationType

destination

org.switchyard.component.jca.processor.destination

messageType

org.switchyard.component.jca.processor.messageType

Here's an example of what a JCA reference binding looks like. This example binds a reference to the HornetQ JMS: 

<sca:composite name="JCAReferenceExample" targetNamespace="urn:userguide:jca-example-reference:0.1.0">
    <sca:reference name="JCAReference" promote="SomeComponent/SomeReference" multiplicity="1..1">
        <jca:binding.jca>
            <jca:outboundConnection>
                <jca:resourceAdapter name="hornetq-ra.rar"/>
                <jca:connection jndiName="java:/JmsXA"/>
            </jca:outboundConnection>
            <jca:outboundInteraction>
                <jca:processor type="org.switchyard.component.jca.processor.JMSProcessor">
                    <jca:property name="destinationType" value="Queue"/>
                    <jca:property name="destination" value="ReferenceQueue"/>
                    <jca:property name="messageType" value="Text"/>
                </jca:processor>
            </jca:outboundInteraction>
        </jca:binding.jca>
    </sca:reference>
</sca:composite>

JMS

The JMS binding in SwitchYard provides support for asynchronous communication with messaging providers. It supports both sides - service and reference.  The JMS binding is built on top of camel-jms and supports most of options for this endpoint. Please refer camel documentation for a detailed description of them.

Generic options

Following options can be apile to <binding.jms> definition:

  • queue or topic : destination name to consume from/produce to

  • connectionFactory : an instance of connection factory to use

  • username

  • password

  • clientId

  • durableSubscriptionName

  • concurrentConsumers

  • maxConcurrentConsumers

  • disableReplyTo

  • preserveMessageQos

  • deliveryPersistent

  • priority

  • explicitQosEnabled

  • replyTo

  • replyToType

  • requestTimeout

  • selector

  • timeToLive

  • transacted

  • transactionManager

  • acknowledgementModeName

  • acknowledgementMode

Binding Services with JMS

Here's an example of what a jms service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.jms>
            <camel:queue>INCOMING_GREETS</camel:queue>
            <camel:connectionFactory>#connectionFactory</camel:connectionFactory>
            <camel:username>esb</camel:username>
            <camel:password>rox</camel:password>
            <camel:selector>RECEIVER='ESB' AND SENDER='ERP'<camel:selector>
        </camel:binding.jms>
    </sca:service>
</sca:composite>

Binding References with JMS

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:reference name="GreetingService" promote="camel-binding/GreetingService" multiplicity="1..1">
        <camel:binding.jms>
            <camel:topic>GREETINGS_NOTIFICATION</camel:topic>
            <camel:connectionFactory>#connectionFactory</camel:connectionFactory>
            <camel:priority>8</camel:priority>
        <camel:binding.jms>
    </sca:reference>
</sca:composite>

File

The file binding in SwitchYard provides filesystem level support for services and references in SwitchYard.

The file binding is built on top of camel-file and supports most of options for this endpoint. Please refer camel documentation for detailed description of them.

Generic options

Following options can be apiled to <binding.file> definition:

  • directory : directory to consume/produce files to

  • autoCreate : automatically create directory if doesn't exist

  • bufferSize : write buffer size

  • fileName : file name filter for consumer or file name pattern for producer

  • flatten : skip path and just use file name

  • charset : charset used for reading/wrinting file

Binding Services with Files

Supported options are:

  • delete

  • recursive

  • noop

  • preMove

  • move

  • moveFailed

  • include

  • exclude

  • idempotent

  • idempotentRepository

  • inProgressRepository

  • filter

  • sorter

  • sortBy

  • readLock

  • readLockTimeout

  • readLockCheckInterval

  • exclusiveReadLockStrategy

  • processStrategy

  • startingDirectoryMustExist

  • directoryMustExist

  • doneFileName

Here's an example of what a file service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.file>
            <camel:directory>target/input</camel:directory>
            <camel:fileName>test.txt</camel:fileName>
            <camel:consume>
               <camel:initialDelay>50</camel:initialDelay>
               <camel:delete>true</camel:delete>
            </camel:consume>
        </camel:binding.file>
    </sca:service>
</sca:composite>

Binding References with File

Binding a reference with file can be used to store outcome of service on disk. The following configuration options are available for binding.file when binding references:

  • fileExist

  • tempPrefix

  • tempFileName

  • keepLastModified

  • eagerDeleteTargetFile

  • doneFileName

For detailed description of these parameters please refer camel-file documentation 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:reference name="GreetingService" promote="camel-binding/GreetingService" multiplicity="1..1">
        <camel:binding.file>
            <camel:directory>target/output</camel:directory>
            <camel:autoCreate>false</camel:autoCreate>
            <camel:produce>
                <camel:fileExist>Override</camel:fileExist>
            </camel:produce>
        <camel:binding.file>
    </sca:reference>
</sca:composite>

FTP FTPS SFTP

SwitchYard provides support for remote file systems on both sides service and reference.

The ftp binding is built on top of camel-ftp and supports most of options for this endpoint. Please refer camel documentation for detailed description of them.

Generic options

Following options can be apiled to <binding.ftp> <binding.ftps> and <binding.sftp> definition:

  • host

  • port

  • username

  • password

  • binary

  • connectTimeout

  • disconnect

  • maximumReconnectAttempts

  • reconnectDelay

  • separator

  • stepwise

  • throwExceptionOnConnectFailed

FTP specific options

  • passiveMode

  • timeout

  • soTimeout

  • siteCommand

FTPS specific options

  • securityProtocol

  • isImplicit

  • execPbsz

  • execProt

  • disableSecureDataChannelDefaults

SFTP specific options

  • knownHostsFile

  • privateKeyFile

  • privateKeyFilePassphrase

Binding Services with Files

Supported options are same as for File.

Here's an example of what a file service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.ftp>
            <camel:directory>target/input</camel:directory>
            <camel:host>localhost</camel:host>
            <camel:port>22</camel:port>
            <camel:username>camel</camel:username>
            <camel:password>secret</camel:password>
            <camel:consume>
               <camel:initialDelay>50</camel:initialDelay>
               <camel:delete>true</camel:delete>
            </camel:consume>
        </camel:binding.file>
    </sca:service>
</sca:composite>

Binding References with File

Binding a reference with file can be used to store outcome of service on remote server. All File referene properties are supported. 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:reference name="GreetingService" promote="camel-binding/GreetingService" multiplicity="1..1">
        <camel:binding.ftp>
            <camel:directory>target/output</camel:directory>
            <camel:autoCreate>false</camel:autoCreate>
            <camel:host>localhost</camel:host>
            <camel:port>22</camel:port>
            <camel:username>camel</camel:username>
            <camel:password>secret</camel:password>
            <camel:produce>
                <camel:fileExist>Override</camel:fileExist>
            </camel:produce>
        <camel:binding.ftp>
    </sca:reference>
</sca:composite>

TCP UDP

SwitchYard provides support for network level integration with TCP and UPD protocols.

The TCP and UDP binding is built on top of camel-netty and supports most of options for this endpoint. Please refer camel documentation for detailed description of them.

Generic options

Following options can be apiled to <binding.tcp> and <binding.udp definition:

  • host

  • port

  • receiveBufferSize

  • sendBufferSize

  • reuseAddress

  • encoders

  • decoders

  • allowDefaultCodec

  • workerCount

  • sync

  • disconnect

TCP specific options

  • textline

  • tcpNoDelay

  • keepAlive

UDP specific options

  • broadcast

SSL Options

This endpoint supports SSL. Following parameters may be used to configure it:

  • ssl - turn on SSL

  • sslHandler - custom SSL Handler to use

  • passphrase - bean reference to String instance used to open KeyStore

  • securityProvider - name of Java security provider

  • keyStoreFormat

  • keyStoreFile - reference to File instance which is used loaded into java KeyStore

  • trustStoreFile - reference to File instance

  • sslContextParametersRef - if this parameter is specified it must be an bean reference to an instance of org.apache.camel.util.jsse.SSLContextParameters where you may specify all necessary parameters at once.

Binding Services with tcp/udp

Here's an example of what a file service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.tcp>
            <camel:host>localhost</camel:host>
            <camel:port>3939</camel:port>
            <camel:allowDefaultCodec>false</camel:allowDefaultCodec>
            <camel:sync>false</camel:sync>
        </camel:binding.tcp>
        <camel:binding.udp>
            <camel:host>localhost</camel:host>
            <camel:port>3940</camel:port>
            <camel:allowDefaultCodec>false</camel:allowDefaultCodec>
            <camel:sync>false</camel:sync>
        </camel:binding.udp>
    </sca:service>
</sca:composite>

JPA

The jpa binding in SwitchYard provides support for consuming and storing JPA entities. It supports both sides - service binding for entity consumption and reference for entity storing.

The JPA binding is built on top of camel-jpa and supports most of options for this endpoint. Please reffer camel documentation for detailed description of them.

Generic options

Following options can be apiled to <binding.jpa> definition:

  • entityClassName

  • persistenceUnit

  • transactionManager

Binding Services with JPA

Supported options are:

  • consumeDelete

  • consumeLockEntity

  • maximumResults

  • consumer.query

  • consumer.namedQuery

  • consumer.nativeQuery

  • consumer.resultClass

  • consumer.transacted

The consumeLockEntity option causes problems with transaction management.

Here's an example of what a mail service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.jpa>
            <camel:entityClassName>org.switchyard.quickstarts.camel.jpa.binding.domain.Greet</camel:entityClassName>
            <camel:persistenceUnit>JpaEvents</camel:persistenceUnit>
            <camel:transactionManager>#jtaTransactionManager</camel:transactionManager>
            <camel:consume>
                <camel:consumeLockEntity>false</camel:consumeLockEntity>
                <camel:consumer.transacted>true</camel:consumer.transacted>
            </camel:consume>
        </camel:binding.jpa>
    </sca:service>
</sca:composite>

Binding References with JPA

Binding a reference with jpa can be used to store entity. The following configuration options are available for binding.jpa when binding references:

  • flushOnSend

  • usePersist 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:reference name="GreetingService" promote="camel-binding/GreetingService" multiplicity="1..1">
        <camel:binding.jpa>
            <camel:entityClassName>org.switchyard.quickstarts.camel.jpa.binding.domain.Greet</camel:entityClassName>
            <camel:persistenceUnit>JpaEvents</camel:persistenceUnit>
            <camel:produce>
                <camel:flushOnSend>false</camel:flushOnSend>
            </camel:produce>
        </camel:binding.jpa>
    </sca:reference>
</sca:composite>

SQL

The sql binding in SwitchYard provides database read/write support for references in SwitchYard.

The file binding is built on top of camel-sql.

SQL Binding options

Following options can be apiled to <binding.sql> definition:

  • query : SQL query to execute

  • dataSourceRef : data source name

  • batch : turn on JDBC batching

  • placeholder : a placeholder sign used to replace parameters in query

  • consume:  define the consumer attributes. This is optional.

    • delay: number of milliseconds between query executions.

    • initialDelay: a delay before query is run first time.

For detailed description of these parameters please visit camel-sql site.

Binding Services with database

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.sql>
            <camel:query>SELECT * FROM greetings</camel:query>
            <camel:dataSourceRef>java:jboss/datasources/GreetDS</camel:dataSourceRef>
            <!--This is optional. If not defined the default camel values will be used.-->
            <camel:consume>
               <camel:initialDelay>1000</camel:initialDelay>
               <camel:delay>500</camel:delay>
            </camel:consume>
        </camel:binding.sql>
    </sca:service>
</sca:composite>

For being compatible with previous versions (although not recommended), it is allowed to include in the camel:binding.sql tag the attributes.

  • period: number of milliseconds between query executions.

  • initialDelay: a delay before query is run first time.

Binding References with database

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:reference name="GreetingDatabaseStore" promote="camel-binding/GreetingDatabaseStore" multiplicity="1..1">
        <camel:binding.sql>
            <camel:query>INSERT INTO greetings (name) VALUES (#)</camel:query>
            <camel:dataSourceRef>java:jboss/datasources/GreetDS</camel:dataSourceRef>
        <camel:binding.sql>
    </sca:reference>
</sca:composite>

Mail

The mail binding in SwitchYard provides support for consuming and sending mail messages. It supports both sides - service binding for mail consumption and reference for message sending.

The Mail binding is built on top of camel-mail and supports most of options for this endpoint. Please reffer camel documentation for detailed description of them.

Generic options

Following options can be apiled to <binding.mail> definition:

  • host

  • port

  • username

  • password

  • connectionTimeout
    Additional attribute secure may be used to identify usage of secured connection (pop3s/imaps/smtps) instead.

Binding Services with Mail

Supported options are:

  • folderName

  • fetchSize

  • unseen

  • delete

  • copyTo

  • disconnect
    Additional attribute accountType may be specified to choose mail protocol. Possible values are pop3 or imap. Default is imap.

Here's an example of what a mail service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.mail>
            <camel:host>localhost</camel:host>
            <camel:username>camel</camel:username>
            <camel:consume accountType="pop3">
                <camel:copyTo>after-processing</camel:copyTo>
            </camel:consume>
        </camel:binding.mail>
    </sca:service>
</sca:composite>

Binding References with Mail

Binding a reference with mail can be used to send outgoing message. The following configuration options are available for binding.mail when binding references:

  • subject

  • from

  • to

  • CC

  • BCC

  • replyTo 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:reference name="GreetingService" promote="camel-binding/GreetingService" multiplicity="1..1">
        <camel:binding.mail>
            <camel:host>localhost</camel:host>
            <camel:username>camel</camel:username>
            <camel:produce>
                <camel:subject>Forwarded message</camel:subject>
                <camel:from>camel@localhost</camel:from>
                <camel:to>rider@camel</camel:to>
            </camel:produce>
        </camel:binding.mail>
    </sca:reference>
</sca:composite>

Quartz

The quartz binding in SwitchYard provides support for triggering services with given cron expression.

The quartz binding is built on top of camel-quartz.

Generic options

Following options can be applied to <binding.quartz> definition:

  • name : name of job

  • cron : execution expression

  • stateful : use a StatefulJob; defaults to false

  • trigger.startTime : sets the trigger start time; format is yyyy-MM-dd'T'HH:mm:ss

  • trigger.endTime : sets the trigger end time; format is yyyy-MM-dd'T'HH:mm:as

  • trigger.timeZone : set the trigger timezone; format is any string accepted by java.util.TimeZone

Binding Services with Quartz

Here's an example of what a quartz service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.quartz>
            <camel:name>GreetingJob</camel:name>
            <camel:cron>0 0/5 * * * ?</camel:cron>
        </camel:binding.quartz>
    </sca:service>
</sca:composite>

Timer

The timer binding in SwitchYard provides support for triggering services with fixed timer. It's lightweight alternative for Quartz.

The file binding is built on top of camel-timer. Please refer camel documentation for detailed description of options.

Generic options

Following options can be apiled to <binding.timer> definition:

  • name : name of timer

  • time

  • pattern

  • period

  • delay

  • fixedRate

  • daemon

Binding Services with Timer

Here's an example of what a timer service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.timer>
            <camel:name>GreetingTimer</camel:name>
            <camel:time>2012-01-01T12:00:00</camel:time>
            <camel:pattern>yyyy-MM-dd'T'HH:mm:ss</camel:pattern>
            <camel:delay>1000</camel:delay>
            <camel:fixedRate>true</camel:fixedRate>
        </camel:binding.timer>
    </sca:service>
</sca:composite>

SEDA

The SEDA binding in SwitchYard provides asynchronous service binding between camel route and SwitchYard service.

SEDA queue is not persistent.

This binding is built on top of camel-seda. Please refer camel documentation for detailed description of options.

Generic options

Following options can be apiled to <binding.seda> definition:

  • name : queue name

  • size : the maximum capacity of the SEDA queue (the number of messages it can hold)

  • concurrentConsumers

  • timeout

  • multipleConsumers

  • limitConcurrentConsumers

Binding References with SEDA

The following configuration options are available for binding.seda when binding references:

  • waitForTaskToComplete

Binding Services with SEDA

Here's an example of what a SEDA service binding looks like: 

<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
    <sca:service name="GreetingService" promote="GreetingService">
        <camel:binding.seda>
            <camel:name>GreetingQueue</camel:name>
            <camel:size>6</camel:size>
            <camel:concurrentConsumers>2</camel:concurrentConsumers>
        </camel:binding.seda>
    </sca:service>
</sca:composite>

Camel URI

Camel binding support in SwitchYard allows Camel components to be used as gateway bindings for services and references within an application.

Binding Services with Camel

Every camel component binding supported by SwitchYard has it's own configuration namespace. However, there is a small exception. Bindings for direct, seda, timer and mock share same namespace urn:switchyard-component-camel-core:config:1.0.

Composite-level services can be bound to a Camel component using the <binding.uri> binding definition.  The following configuration options are available for binding.uri:

  • configURI : contains the Camel endpoint URI used to configure a Camel component instance

  • operationSelector : specification of the operation to use for the message exchange. See Operation Selector for more details. This setting is not used for cxfrs configurations.

    binding.uri is not linked with any specific component. It allows usage of 3rd party camel components which are not part of distribution.

Here's an example of what a service binding looks like using a Camel component. 

<sca:composite name="SimpleCamelService" targetNamespace="urn:userguide:simple-camel-service:0.1.0">
    <sca:service name="SimpleCamelService" promote="SimpleComponent/SimpleCamelService">
        <camel:binding.uri configURI="file://target/input?fileName=test.txt&amp;initialDelay=50&amp;delete=true">
            <selector:operationSelector operationName="print"/>
        </camel:binding.uri>
    </sca:service>
    <!-- sca:component definition omitted -->
</sca:composite>

Binding References with Camel

Binding a reference with Camel is very similar to binding a service.  The only significant difference is that specification of the operationSelector is not required on reference bindings. Logically reference elements points to outgoing communication eg. service called by Switchyard. 

<sca:composite name="orders" targetNamespace="urn:switchyard-quickstart-demo:orders:0.1.0">
    <sca:reference name="WarehouseService" promote="OrderComponent/WarehouseService" multiplicity="1..1">
        <camel:binding.uri configURI="file://target/output"/>
    </sca:reference>
</sca:composite>
JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-13 09:45:38 UTC, last content change 2013-03-26 01:05:36 UTC.