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.
-
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
UsernameToken Support
To enable WS-Security within your application, a few steps are required:
-
Define a Policy within your WSDL, and reference with with a PolicyReference inside your binding.
-
Configure your <soap.binding> with an <endpointConfig> so JBossWS-CXF is configured properly.
-
Configure your <soap.binding> with an <inInterceptors> section, including the appropriate JBossWS-CXF <interceptor> to handle incoming SOAP requests.
-
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:
-
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.
-
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:
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:
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.
-
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:
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/.
-
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>
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:
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
-
connection
-
outboundInteraction
-
connectionSpec : Configuration for javax.resource.cci.ConnectionSpec. Note that JMSProcessor doesn't use this option.
-
interactionSpec : Configuration for _javax.resource.cci.InteractionSpec. _Note that JMSProcessor doesn't use this option.
-
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. 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. JMSProcessor needs destination property to specify target destination. CCIProcessor needs recordClassName property to specify record type to be used to interact with EIS. If you use CCIProcessor with the record type other than MappedRecord and IndexedRecord, you need to implement corresponding RecordHandler. Please refer to org.switchyard.component.jca.processor.cci.IndexedRecordHandler and org.switchyard.component.jca.processor.cci.MappedRecordHandler.
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="destination" value="ReferenceQueue"/>
</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 reffer camel documentation for detailed description of them.
Known Limitation
https://issues.jboss.org/browse/SWITCHYARD-1285 - Declarative transaction management by the Transaction Policy doesn't work with camel-jms properly. We are investigating how can we solve it, but you may want to use JCA gateway instead for now.
Generic options
Following options can be apile to <binding.jms> definition:
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:
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:
FTP specific options
-
passiveMode
-
timeout
-
soTimeout
-
siteCommand
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
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:
<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
For detailed description of these parameters please visit camel-sql site.
Binding Services with database
Two additional attributes may be specified for binding.sql element when used with service reference:
<sca:composite name="camel-binding" targetNamespace="urn:switchyard-quickstart:camel-binding:0.1.0">
<sca:service name="GreetingService" promote="GreetingService">
<camel:binding.sql period="10s">
<camel:query>SELECT * FROM greetings</camel:query>
<camel:dataSourceRef>java:jboss/datasources/GreetDS</camel:dataSourceRef>
</camel:binding.sql>
</sca:service>
</sca:composite>
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:
Binding Services with Mail
Supported options are:
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 apile to <binding.quartz> definition:
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:
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 asmall 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.
Before SwitchYard 0.7 binding.camel element was used instead of binding.uri
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&initialDelay=50&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>
Message Composers
A MessageComposer can compose or decompose a native binding message to/from SwitchYard's canonical message. A MessageComposer does this in three steps:
-
Construct a new target message instance.
-
Copy the content ("body") of the message.
-
Delegate the header/property mapping to a ContextMapper.
We currently provide a SOAPMessageComposer, a CamelMessageComposer, and a HornetQMessageComposer. These default implementations are used by their associated bindings, but can be overridden by the user.
Custom Message Composers
To implement a custom MessageComposer, you need to implement the org.switchyard.component.common.composer.MessageComposer interface:
public interface MessageComposer<T> {
ContextMapper<T> getContextMapper();
MessageComposer<T> setContextMapper(ContextMapper<T> contextMapper);
Message compose(T source, Exchange exchange, boolean create) throws Exception;
public T decompose(Exchange exchange, T target) throws Exception;
}
-
The getContextMapper() and setContextMapper() methods are just bean properties. If you extend BaseMessageComposer, both of these are implemented for you.
-
Your compose() method needs to take the data from the passed in source native message and compose a SwitchYard Message based on the specified Exchange. The create parameter is whether or not we ask the Exchange to create a new Message, or just get the existing one.
-
Your decompose() method needs to take the data from the SwitchYard Message in the specified Exchange and decompose it into the target native message.
Then, specify your implementation in your switchyard.xml:
<binding.xyz ...>
<messageComposer class="com.example.MyMessageComposer"/>
</binding.xyz>
Context Mappers
A
ContextMapper
moves native binding message headers and/or properties to/from SwitchYard's canonical context. We provide many ContextMapper implementations OOTB (see section below). These default implementations are used by their associated bindings, but can be overridden by the user.
Custom Context Mappers
To implement a custom ContextMapper, you need to implement the org.switchyard.component.common.composer.ContextMapper interface:
public interface ContextMapper<T> {
void mapFrom(T source, Context context) throws Exception;
void mapTo(Context context, T target) throws Exception;
}
-
Your mapFrom() method needs to map a source native message's properties to the SwitchYard Message's Context.
-
Your mapTo() method needs to map a SwitchYard Message's Context properties into the target native message.
-
If you extend BaseContextMapper, these methods are stubbed-out with no-op implementations so you only have to implement what you want to.
Then, specify your implementation in your switchyard.xml:
<binding.xyz ...>
<contextMapper class="com.example.MyContextMapper"/>
</binding.xyz>
Alternatively, you can implement the org.switchyard.component.common.composer.RegexContextMapper. The purpose of this interface is to add regular expression support, where you can filter exactly which Context properties get mapped:
public interface RegexContextMapper<T> extends ContextMapper<T> {
ContextMapper<T> setIncludes(String includes);
ContextMapper<T> setExcludes(String excludes);
ContextMapper<T> setIncludeNamespaces(String includeNamespaces);
ContextMapper<T> setExcludeNamespaces(String excludeNamespaces);
boolean matches(String name);
boolean matches(QName qname);
}
-
The setIncludes(), setExcludes(), setIncludeNamespaces() and setExcludeNamespaces() methods are just bean properties. The matches() methods use those bean properties to determine if the specified name or qualified name passes the collective regular expressions.
-
If you extend BaseRegexContextMapper, all of these are implemented for you. Then, in your implementation's mapFrom / mapTo methods, you only need to first check if the property matches before you map it.
If your implementation extends RegexContextMapper, the following additional (regular expression valued) attributes of the <contextMapper/> element become meaningful/respected:
-
includes = Which context property names to include.
-
excludes = Which context property names to exclude.
-
includeNamespaces = Which context property namespaces to include (if the property name is a qualified name).
-
excludeNamespaces = Which context property namespaces to exclude (if the property name is a qualified name).
OOTB Implementation Notes
Note: All of the out-of-the-box implementations below extend BaseRegexContextMapper, thus all can be configured with the regular expression attributes described above.
-
The SOAPContextMapper, when processing an incoming SOAPMessage, takes the mime (in most cases, HTTP) headers from a soap envelope and maps them into the SwitchYard Context as Scope.IN properties with the SOAPComposition.SOAP_MESSAGE_MIME_HEADER label, and takes the soap header elements from the soap envelope and maps them into the SwitchYard Context as Scope.EXCHANGE properties with the SOAPComposition.SOAP_MESSAGE_HEADER label. When processing an outgoing SOAPMessage, it takes the SwitchYard Scope.OUT Context properties and maps them into mime (in most cases, HTTP) headers, and takes the SwitchYard Scope.EXCHANGE Context properties and maps them into the soap envelope as soap header elements.
The SOAPContextMapper has an additional attribute that the other OOTB ContextMappers do not have: soapHeadersType:
<binding.soap>
<contextMapper includes=".*" soapHeadersType="VALUE"/>
</binding.soap>
The value of soapHeadersType can be CONFIG, DOM, VALUE or XML (and correspond to the enum SOAPHeadersType.CONFIG, DOM, VALUE or XML). With CONFIG, each soap header element is mapped into an org.switchyard.config.Configuration object, with DOM, each soap header element is left as is (a DOM element), with VALUE, just the String value of each soap header element is stored, and with XML, each soap header element is transformed into an XML String.
-
The CamelContextMapper, when processing an incoming CamelMessage, takes the CamelMessage headers and maps them into the SwitchYard Context as Scope.IN properties with the CamelComposition.CAMEL_MESSAGE_HEADER label, and takes the Camel Exchange properties and maps them into the SwitchYardContext as Scope.EXCHANGE properties with the CamelComposition.CAMEL_EXCHANGE_PROPERTY label. When processing an outgoing CamelMessage, it takes the SwitchYard Scope.OUT Context properties and maps them into the CamelMessage as headers, and takes the SwitchYard Scope.EXCHANGE Context properties and maps them into the Camel Exchange as properties.
-
The HornetQContextMapper, when processing an incoming ClientMessage, takes the ClientMessage properties and maps them into the SwitchYardContext as Scope.EXCHANGE properties with the HornetQCompsition.HORNETQ_MESSAGE_PROPERTY label. When procesing an outgoing ClientMessage, it takes the SwitchYard Scope.EXCHANGE Context properties and maps them into the ClientMessage as properties. There is no concept of "headers" in a HornetQ ClientMessage.
-
The HTTPContextMapper, when processing an incoming HTTP request, takes the incoming request headers and maps them into the SwitchYard Context as Scope.IN with the HttpComposition.HTTTP_HEADER label. When processing an outgoing HTTP response, it takes the SwitchYard Scope.OUT Context properties and maps them into the response headers.
-
The RESTEasyContextMapper, when processing an incoming HTTP request, takes the incoming request headers and maps them into the SwitchYard Context as Scope.IN with the RESTEasyComposition.HTTP_HEADER label. When processing an outgoing HTTP response, it takes the SwitchYard Scope.OUT Context properties and maps them into the response headers.
The reasoning of scoping headers as IN and OUT scopes was modeled after the notion of http headers, where you will see some headers specifically useful for http requests, and other headers specifically useful for http responses. In both cases, they are most likely tied to the binding's notion of an incoming message or an outgoing message.
The reasoning of scoping properties as EXCHANGE scope came from the idea that this is most likely application or domain data, and possibly useful in the entire processing of the Exchange. An example of this would be a processInstanceId when using the BPM Component.
Operation Selectors
OperationSelector provides a capability to determine which service operation should be invoked for the message exchange. The following options are available. If the target service only has a single operation, this setting is optional.
Static Operation Selector
specify a operation name in the configuration.
<hornetq:binding.hornetq>
<swyd:operationSelector operationName="greet" xmlns:swyd="urn:switchyard-config:switchyard:1.0"/>
(... snip ...)
</hornetq:binding.hornetq>
XPath Operation Selector
specify a XPath location which contains a operation name to be invoked in the message contents.
If the configuration looks like this:
<jca:binding.jca>
<swyd:operationSelector.xpath expression="//person/language" xmlns:swyd="urn:switchyard-config:switchyard:1.0"/>
(... snip ...)
</jca:binding.jca>
And the message content is like this:
<person>
<name>Fernando</name>
<language>spanish</language>
</person>
Then operation spanish() would be invoked.
Regex Operation Selector
specify a Regular Expression to find a operation name to be invoked in the message contents.
If the configuration looks like this:
<http:binding.http>
<swyd:operationSelector.regex expression="[a-zA-Z]*Operation" xmlns:swyd="urn:switchyard-config:switchyard:1.0"/>
(... snip ...)
</http:binding.http>
And the message content is like this:
xxx yyy zzz regexOperation aaa bbb ccc
Then operation regexOperation() would be invoked.
Java Operation Selector
specify a Java class which is able to determine the operation to be invoked.
configuration should look like this:
<jca:binding.jca>
<swyd:operationSelector.java class="org.switchyard.example.MyOperationSelectorImpl" xmlns:swyd="urn:switchyard-config:switchyard:1.0"/>
(... snip ...)
</jca:binding.jca>
Note that the org.switchyard.example.MyOperationSelectorImpl needs to be a subclass of org.switchyard.component.common.selector.OperationSelector or other concrete OperationSelector classes for each service bindings. You can override the selectOperation() method as you like.
Default OperationSelector implementation for each service bindings are following:
-
Camel : org.switchyard.component.camel.selector.CamelOperationSelector
-
JCA/JMS : org.switchyard.component.jca.selector.JMSOperationSelector
-
JCA/CCI : org.switchyard.component.jca.selector.CCIOperationSelector
-
HTTP : org.switchyard.component.http.selector.HttpOperationSelector
Scope of Support
Support for operation selector is limited to Camel, JCA and HTTP service bindings. Support for other service bindings will be added in the future.