Introduction to JBI

What is JBI?

TODO: Describe what the JBI specification is all about

Message Exchange Patterns

TODO: Describe the four standard JBI MEPs

JBI API

TODO: Describe the standard JBI API (MessageExchange, NormalizedMessage, ...)

JBI Components

servicemix-bean

Overview

The ServiceMix Bean component provides integration with beans (POJOs) with the JBI bus to make it easy to use POJOs to process JBI message exchanges. Like in an Message Driven Bean in J2EE a POJO will receive a message from the NMR and process it in any way it likes. Unlike in a JMS component where the coding is already done the Bean component gives the developer the freedom to create any type of message handling but it must be hand coded all the way.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/bean/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:bean="http://servicemix.apache.org/bean/1.0">
  <bean:endpoint service="test:service" endpoint="endpoint" bean="#listenerBean"/>
  <bean id="listenerBean" class="org.apache.servicemix.bean.beans.ListenerBean"/>
</beans></beans>

Endpoint types

The servicemix-bean component only defines one endpoint, called bean:endpoint. It can be used to receive and send message exchanges from/to the NMR.

Endpoint bean:endpoint

There are two ways to configure the bean endpoint. The first is using the fully qualified name of the class and the second is by passing to the endpoint a reference to an existing bean.

Using a Java class

When definining a bean:endpoint specifying a Java class name, a new instance of this class will be created for handling a single message exchange.

<beans xmlns:bean="http://servicemix.apache.org/bean/1.0"
       xmlns:my="urn:org:servicmix:docs:examples">

  <bean:endpoint service="my:service" endpoint="endpoint"
                 class="org.apache.servicemix.docs.bean.MyHandlerBean"/>

</beans>

Using a spring bean

Alternative, a reference to an existing bean can be passed to the bean endpoint.

<beans xmlns:bean="http://servicemix.apache.org/bean/1.0">
    <bean:endpoint service="test:service" endpoint="endpoint" bean="#listenerBean"/>
    <bean id="listenerBean" class="org.apache.servicemix.bean.beans.ListenerBean"/>
</beans>

Attention: The Bean Endpoint schema allows to set a Bean or a Bean Name. The Bean will create a single instance of the POJO per endpoint whereas the Bean Name will create an instance per request (message exchange).

Endpoint properties

MessageExchangeListener

The first kind of POJOs you can deploy implement the MessageExchagneListener interface. In such a case, servicemix-bean acts as a replacement of the lightweight container component. This level offers the most control on the exchange received and sent. This is usually used with the injected DeliveryChannel to send back the exchanges, or if the POJOs needs to act as a consumer (i.e. creating and sending exchanges to other services).

These POJOs are low-level POJOs: you need to understand the JBI Api and Message Exchange Patterns to correctly handle incoming exchanges.

Note that at this point (v 3.1), there is no base class that you can inherit to speed you in this process of implementing a POJO to handle JBI exchanges, but hopefully it will come in the future.

Examples

This example on the right shows the most simple bean. When it receives an exchange, it will print it to the console and set the status to DONE before sending the exchange back. This bean can not handle InOut exchanges, as it does not set any response (an exception would be thrown in such a case).

import org.apache.servicemix.jbi.listener.MessageExchangeListener;

import javax.annotation.Resource;
import javax.jbi.messaging.DeliveryChannel;
import javax.jbi.messaging.ExchangeStatus;
import javax.jbi.messaging.MessageExchange;
import javax.jbi.messaging.MessagingException;

public class ListenerBean implements MessageExchangeListener {

    @Resource
    private DeliveryChannel channel;

    public void onMessageExchange(MessageExchange exchange) throws MessagingException {
        System.out.println("Received exchange: " + exchange);
        exchange.setStatus(ExchangeStatus.DONE);
        channel.send(exchange);
    }

}

This example will handle an InOut exchange and will send back the input as the response.
Note that this example would fail if receiving an InOnly exchange, as setting a response on an InOnly exchange is not a legal operation.

import org.apache.servicemix.jbi.listener.MessageExchangeListener;
import org.apache.servicemix.jbi.util.MessageUtil;

import javax.annotation.Resource;
import javax.jbi.messaging.DeliveryChannel;
import javax.jbi.messaging.ExchangeStatus;
import javax.jbi.messaging.MessageExchange;
import javax.jbi.messaging.MessagingException;

public class ListenerBean implements MessageExchangeListener {

    @Resource
    private DeliveryChannel channel;

    public void onMessageExchange(MessageExchange exchange) throws MessagingException {
        if (exchange.getStatus() == ExchangeStatus.ACTIVE) {
            MessageUtil.transferInToOut(exchange, exchange);
            channel.send(exchange);
        }
    }

}

This is similar example as the one from above (also works only for InOut exchange) but it shows how you can extract message from an exchange in order to process it and send back.

import org.apache.servicemix.jbi.listener.MessageExchangeListener;
import org.apache.servicemix.jbi.util.MessageUtil;
import org.apache.servicemix.jbi.jaxp.SourceTransformer;

import javax.annotation.Resource;
import javax.jbi.messaging.DeliveryChannel;
import javax.jbi.messaging.ExchangeStatus;
import javax.jbi.messaging.MessageExchange;
import javax.jbi.messaging.MessagingException;
import javax.jbi.messaging.NormalizedMessage;
import javax.xml.transform.Source;

public class ListenerBean implements MessageExchangeListener {

    @Resource
    private DeliveryChannel channel;

    public void onMessageExchange(MessageExchange exchange) throws MessagingException {
        if (exchange.getStatus() == ExchangeStatus.ACTIVE) {
                        NormalizedMessage message = exchange.getMessage("in");
		        Source content = message.getContent();
			//process content according to your logic
			//e.g. to access the message body as a String use
			String body = (new SourceTransformer()).toString(content);

			message.setContent(content);
			exchange.setMessage(message, "out");
			channel.send(exchange);
        }
    }

}

Disclaimer

In versions 3.1 to 3.1.2 the ServiceMix Bean component will not handle asynchronous messages correctly because the final send of the message marked as DONE back to the NMR will be handled as a consumer message and that fails because there is no corresponding provider message. The only workaround is to send the messages synchronously.

Note: This was resolved in 3.1.3, 3.2.x and later via SM-1110.

MessageExchange dispatching

If the POJO deployed implements the org.apache.servicemix.MessageExchangeListener, every message received for this POJO will be dispatched to the onMessageExchange method.

In other cases, exchanges in a provider role will be dispatched according to the MethodInvocationStrategy configured on the endpoint. The default one try to find the method according to the operation name defined on the exchange. If there is only a single method acting as an operation, it will always be used.

Annotations

The servicemix-bean component can accept different kind of POJOs. These POJOs may be annotated to customize their behavior. All the following annotations belong to the org.apache.servicemix.bean package.

In addition, standard annotations can be used:

The following interfaces are part of this API:

More Examples

• AnnotatedBean

• AutoDeployedBean

• ConsumerBean

• ListenerBean

• PlainBean

servicemix-camel

Overview

The servicemix-camel component provides support for using Apache Camel to provide a full set of Enterprise Integration Patterns and flexible routing and transformation in both Java code or Spring XML to route services on the Normalized Message Router.

Namespace and camel-context.xml

When creating a servicemix-camel service unit, we reuse the default Camel namespace http://camel.apache.org/schema/spring.

This is an example camel-context.xml which uses the Spring DSL to define the Camel routes

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
         http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://camel.apache.org/schema/spring
           http://camel.apache.org/schema/spring/camel-spring.xsd">

  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <route>
      <!-- route defined in the Spring DSL -->
    </route>
  </camelContext>

</beans>

It is also possible to use the Java DSL inside a servicemix-camel service unit by referring to the package that contains the RouteBuilder classes. An example: this camel-context.xml file will activate all routes defined by RouteBuilders in the org.apache.servicemix.example.camel package.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
         http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://camel.apache.org/schema/spring
           http://camel.apache.org/schema/spring/camel-spring.xsd">

  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <packages>org.apache.servicemix.examples.camel</packages>
  </camelContext>

</beans>

URI

Camel routes use URIs to interact with the ESB. You can use these URIs to expose new endpoints on the ESB as well as to send message exchanges to existing endpoints.

The snippet below automatically exposes a new endpoint to the bus, where the service QName is MyService and the endpoint name is MyEndpoint.

from("jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint")

When a JBI endpoint appears at the end of a route, as in the example below, that will send

to("jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint")

The messages sent by this producer endpoint are sent to the already deployed JBI endpoint.

URI format

jbi:service:serviceNamespace[sep]serviceName[?options]
jbi:endpoint:serviceNamespace[sep]serviceName[sep]endpointName[?options]
jbi:name:endpointName[?options]

The separator that should be used in the endpoint URL is:

• / (forward slash), if serviceNamespace starts with http://

• : (colon), if serviceNamespace starts with urn:.

You can append query options to the URI in the following format, ?option=value&ption=value&..

Examples

Using jbi:service

jbi:service:http://foo.bar.org/MyService
jbi:service:urn:foo:bar:MyService

Using jbi:endpoint

jbi:endpoint:urn:foo:bar:MyService:MyEndpoint
jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint

Using jbi:name

When using jbi:name, the component uses http://activemq.apache.org/camel/schema/jbi}endpoint as the default Service QName.

jbi:name:MyEndpoint

URI options

Examples

jbi:service:http://foo.bar.org/MyService?mep=in-out       (override the MEP, use InOut JBI MessageExchanges)
jbi:endpoint:urn:foo:bar:MyService:MyEndpoint?mep=in      (override the MEP, use InOnly JBI MessageExchanges)
jbi:endpoint:urn:foo:bar:MyService:MyEndpoint?operation={http://www.mycompany.org}AddNumbers
(overide the operation for the JBI Exchange to {http://www.mycompany.org}AddNumbers)

Example routes

Simple Spring route

This simple Spring route registers a new endpoint on the ESB (service Router, endpoint name orders). The message exchange contents will be logged and then forwarded to another JBI service endpoint (service OrderService)

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
         http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://camel.apache.org/schema/spring
           http://camel.apache.org/schema/spring/camel-spring.xsd">

          <camelContext xmlns="http://camel.apache.org/schema/spring">
            <route>
              <from uri="jbi:endpoint:urn:org:example:Router:orders"/>
              <to uri="log:OrderLogging"/>
              <to uri="jbi:service:http://services.example.org/OrderService" />
            </route>
          </camelContext>

</beans>

The same route using the Java DSL

When we implement the same route in the Java DSL, we first code our RouteBuilder implementation

package org.apache.servicemix.example;

import org.apache.camel.builder.RouteBuilder;

public class JbiRouteBuilder extends RouteBuilder {

  @Override
  public void configure() throws Exception {
    from("jbi:endpoint:urn:org:example:Router:orders")
      .to("log:OrderLogging")
      .to("jbi:service:http://services.example.org/OrderService");
  }
}

In our camel-context.xml file, we just refer to the org.apache.servicemix.example package that contains our JbiRouteBuilder.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="
         http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
         http://camel.apache.org/schema/spring
           http://camel.apache.org/schema/spring/camel-spring.xsd">

  <camelContext xmlns="http://camel.apache.org/schema/spring">
    <route>
      <packageScan>
        <package>org.apache.servicemix.example</package>
      </packageScan>
    </route>
  </camelContext>

</beans>

Special considerations

Stream handling

If you are using a stream type as the message body, you should be aware that a stream is only capable of being read once. So if you enable DEBUG logging, the body is usually logged and thus read. To deal with this, Camel has a streamCaching option that can cache the stream, enabling you to read it multiple times.

from("jbi:endpoint:http://foo.bar.org/MyService/MyEndpoint")
  .streamCaching()
  .to("xslt:transform.xsl", "bean:doSomething");

Camel will cache large input streams (by default, over 64K) in a temp file using CachedOutputStream. When you close the input stream, the temp file will be deleted.

servicemix-cxf-bc

Overview

A JBI compliant HTTP/SOAP or JMS/SOAP binding component named servicemix-cxf-bc which use apache cxf internally.

The main features are:

• JBI compliant Binding Component

• Usable in a lightweight mode in servicemix.xml configuration files

• SOAP 1.1 and 1.2 support

• MIME attachments

• Support for all MEPs as consumers or providers

• SSL support

• WS-Security support

• WS-Policy support

• WS-RM support

• WS-Addressing support

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/cxfbc/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0">

  <!-- add cxfbc:consumer or cxfbc:provider definitions here -->

</beans>

Endpoint types

The servicemix-cxf-bc component defines two endpoints:

• cxfbc:consumer :: a server-side cxf endpoint that will consume plain HTTP+SOAP requests and send them into the NMR to a given JBI endpoint

• cxfbc:provider :: a client-side jbi endpoint which can receive requests from the NMR and send them to a given url where the service is provided

cxfbc:consumer

Endpoint properties

cxfbc:provider

Endpoint properties

Examples

Configuring the CXF JMS Transport

The ServiceMix CXF binding component also allows using the CXF JMS Transport to send and receive messages. You can use the <cxf:features/> element to add and configure the org.apache.cxf.transport.jms.JMSConfigFeature on the endpoint, as in the example below.

<cxfbc:provider wsdl="org/apache/servicemix/cxfbc/ws/security/hello_world.wsdl"
              service="greeter:HelloWorldService"
              endpoint="HelloWorldPortProxy"
              interfaceName="greeter:Greeter"
              busCfg="jms_conduit_config.xml">

  <!-- add interceptors here -->

  <cxfbc:features>
     <bean class="org.apache.cxf.transport.jms.JMSConfigFeature">
        <property name="jmsConfig">
            <bean class="org.apache.cxf.transport.jms.JMSConfiguration">
                <property name="concurrentConsumers">
                    <value>5</value>
                </property>
                <property name="connectionFactory">
                    <ref bean="myConnectionFactory" /> 
                </property>
                <property name="targetDestination">
                    <value>test.jmstransport.text.provider</value>
                </property>
                <property name="useJms11">
                    <value>false</value>
                </property>
            </bean>
         </property>
     </bean>
  </cxfbc:features>

</cxfbc:provider>

<amq:connectionFactory id="myConnectionFactory" brokerURL="vm://localhost"/>

The jms_conduit_config.xml file specified in the busCfg parameter, is optional and can be used to specify additional JMS transport parameters:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:jms="http://cxf.apache.org/transports/jms"
       xsi:schemaLocation="
       http://cxf.apache.org/transports/jms http://cxf.apache.org/schemas/configuration/jms.xsd
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

    <jms:conduit name="{http://apache.org/hello_world_soap_http}HelloWorldPort.jms-conduit" abstract="true"> 
        <jms:clientConfig clientReceiveTimeout="200000"/>
    </jms:conduit>

</beans>

Configuring the CXF HTTP Transport

In order to configure the underlying HTTP transport used by a CXF BC endpoint, you can specify an additional busCfg file as in the example below.

<cxfbc:provider wsdl="org/apache/servicemix/cxfbc/ws/security/hello_world.wsdl"
              service="greeter:HelloWorldService"
              endpoint="HelloWorldPortProxy"
              interfaceName="greeter:Greeter"
              busCfg="http_conduit_config.xml">

  <!-- add interceptors and additional CXF features here -->

</cxfbc:provider>

The http_conduit_config.xml file can then specify the additional CXF configuration. Have a look at this page for an overview of all the options supported by CXF.

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:http-conf="http://cxf.apache.org/transports/http/configuration"
       xsi:schemaLocation="http://cxf.apache.org/transports/http/configuration
                           http://cxf.apache.org/schemas/configuration/http-conf.xsd
                           http://www.springframework.org/schema/beans
                           http://www.springframework.org/schema/beans/spring-beans.xsd">

  <http-conf:conduit name="{http://apache.org/hello_world_soap_http}HelloWorldPort.http-conduit">
    <http-conf:client Connection="Keep-Alive"
                      MaxRetransmits="1"
                      AllowChunking="false" />
  </http-conf:conduit>
</beans>

servicemix-cxf-se

Overview

ServiceMix CXF SE component is a JBI Service Engine exposing (annotated) POJO as services on the JBI Bus.
It uses Apache CXF internally to perform service invocations and xml marshaling.

Features:

• jsr181 annotations

• jaxb2/aegis/xmlbeans databinding

• wsdl auto generation

• java proxy support

• MTOM / attachments support

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/cxfse/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:cxfse="http://servicemix.apache.org/cxfse/1.0">

  <!-- add cxfse:endpoint definitions here -->

</beans>

Endpoint types

The servicemix-cxf-bc component defines one endpoint type:

• cxfse:endpoint :: no description yet

cxfse:endpoint

Endpoint properties

cxfbc:proxy

Endpoint properties

servicemix-drools

Overview

The ServiceMix Drools component provides JBI integration to the Drools Rules Engine.

This Service Engine can be used to deploy a rules set that will implement a router or an actual service.

A router will mostly act as a transparent proxy between the consumer and the target service provider mad will mostly be implemented by the jbi.route(uri) method below. This method creates a new exchange identical to the one received by the component and will send it to the specified destination. You can also send back a Fault if needed. A router can also be implemented by using directly the JBI Apis (available with the jbi helper) by using the provided client.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/drools/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:drools="http://servicemix.apache.org/drools/1.0">

  <!-- add drools:endpoint definitions here -->

</beans>

Endpoint types

The servicemix-drools component defines one endpoint type:

• drools:endpoint :: no description yet

drools:endpoint

Endpoint properties

servicemix-eip

Overview

The servicemix-eip component is a routing container where different routing patterns can be deployed as service unit.
This component is based on the great Enterprise Integration Patterns book.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/eip/1.0. This is an example of an xbean.xml file with a namespace definition with prefix eip.

<beans xmlns="http://www.springframework.org/schema/beans"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:eip="http://servicemix.apache.org/eip/1.0"
      xsi:schemalocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">
  <!-- Pipeline example -->
  <eip:pipeline service="test:pipeline" endpoint="endpoint">
  <eip:transformer>
    <eip:exchange-target service="test:transformer" />
  </eip:transformer>
  <eip:target>
    <eip:exchange-target service="test:trace" />
  </eip:target>
</eip:pipeline>
</beans>

Endpoint types

The servicemix-eip component defines several endpoint types:

• eip:content-based-router :: Implements the Content-Based Router EIP

• eip:message-filter :: Implements the Message Filter EIP

• eip:pipeline :: Implements the Pipeline EIP

• eip:static-recipient-list :: Implements the Static Recipient List EIP

• eip:static-routing-slip :: Implements the Static Routing Slip EIP

• eip:wire-tap :: Implements the Wire Tap EIP

• eip:xpath-splitter :: Uses XPath to split a message

• eip:split-aggregator :: Aggregates messages that have been split by the xpath-splitter

• eip:content-enricher :: Implements the Content Enricher EIP

• eip:resequencer :: Implements the Resequencer EIP

• eip:async-bridge :: Handles an InOut exchange by correlating to separate InOnly exchanges

In addition, this component can use all ServiceMix flows (including clustered and transactional flows), can be configured to be resilient to crashes and supports full fail-over to another node when clustered.

Content Based Router

ContentBasedRouter can be used for all kind of content-based routing.
This pattern implements the Content-Based Router pattern.

Endpoint properties

Message Filter

MessageFilter allows filtering incoming JBI exchanges. As it drops unwanted messages and in an InOut exchange a response is required, MessageFilter and InOut MEPs cannot be used together.
This pattern implements the Message Filter pattern.

Endpoint properties

Pipeline

The Pipeline component is a bridge between an In-Only (or Robust-In-Only) MEP and an In-Out MEP. When the Pipeline receives an In-Only MEP, it will send the input in an In-Out MEP to the tranformer destination and forward the response in an In-Only MEP to the target destination.

The old org.apache.servicemix.components.util.PipelineComponent will be deprecated. This one offers the same feature but can be safely clustered and use in a transactional enviromnent.




In the default configuration, faults sent by the transformer component are sent back to the consumer as faults if the exchange MEP supports them, or as errors (for InOnly exchanges). This behavior can be changed by setting the sendFaultsToTarget attribute to true, in which case faults will be sent to the target component, or by adding a faultsTarget element where faults should be sent.

Endpoint properties

Static Recipeint List

The StaticRecipientList component will forward an input In-Only or Robust-In-Only exchange to a list of known recipients.
This component implements the Recipient List pattern, with the limitation that the recipient list is static.

Endpoint properties

Static Routing Slip

A RoutingSlip component can be used to route an incoming In-Out exchange through a series of target services.
This component implements the Routing Slip pattern, with the limitation that the routing table is static.
This component only uses In-Out MEPs and errors or faults sent by targets are reported back to the consumer, thus interrupting the routing process.

Endpoint properties

Wire Tap

A WireTap component can be used to forward a copy of the input message to a listener in a proxy fashion.
This component implements the WireTap pattern.
It can handle all four standard MEPs, but will only send an In-Only MEP to the listener.
The originating service must be configured to send messages to the WireTap directly.
In the case of an In-Out MEP, this means that the WireTap needs to be configured to send the exchange along to the destination service.

Similar to the example above, the WireTap can also be used:

• to forward the output message of an exchange using <eip:outListener/>

• to forward the fault message of an exchange using <eip:faultListener/>

Endpoint properties

XPath Splitter

The XPathSplitter component implements the Splitter pattern using an xpath expression to split the incoming xml.

Endpoint properties

Split Aggregator

The SplitAggregator is an aggregator mainly usefull to collect messages that have been created using a splitter.
It relies on several properties that should be set on the exchanges (count, index, correlationId).

Endpoint properties

Content Enricher

With a Content Enricher you can extract additional information from a source and add this information to your message. This is useful if the calling service for example extracts a 'userID' and your target system is only aware of a 'userName'. By using the Content-Enricher you could extract this information from a source system and add this additional information ('userName') to your message.

<eip:content-enricher service="test:contentEnricher" endpoint="endpoint">
  <eip:enricherTarget>
    <eip:exchange-target service="test:additionalInformationExtracter" />
  </eip:enricherTarget>
  <eip:target>
    <eip:exchange-target service="test:myTarget" />
  </eip:target>
</eip:content-enricher>

Endpoint properties

Eip Resequencer

A resequencer re-orders incoming In-Only or Robust-In-Only exchanges and sends them synchronously to a targets service. Synchronous sending ensures that messages arrive in correct order at the target service. This component implements the Resequencer pattern.





It works on (continuous) streams of message exchanges using a timeout policy. Since the resequencer doesn't make batch reads there's no need to know the number of messages to be re-ordered in advance (although a capacity parameter prevents the resequencer from running out of memory). If the maximum out-of-sequence time difference between messages in a message stream is known, the resequencer's timeout parameter should be set to this value (milliseconds). In this case it is guaranteed that all elements of a stream are delivered in correct order to the target service. The lower the timeout value is compared to the out-of-sequence time difference the higher is the probability for out-of-sequence messages sent by this resequencer. Large timeout values should be supported by sufficiently high capacity values.


For comparing elements of a sequence the resequencer component can be configured with a sequence element comparator. A default comparator is provided that compares message exchanges based on Long sequence numbers. This comparator expects the sequence number to be the value of the org.apache.servicemix.eip.sequence.number property of the exchanges's in\-NormalizedMessage. The name of the property can be customized in the comparator configuration (see below). You may also provide a custom comparator by implementing the SequenceElementComparator interface.

 <eip:resequencer
   service="sample:Resequencer"
   endpoint="ResequencerEndpoint"
   comparator="#comparator"
   capacity="100"
   timeout="2000">
   <eip:target>
     <eip:exchange-target service="sample:SampleTarget" />
   </eip:target>
 </eip:resequencer>
 <!-- Configure default comparator with custom sequence number property -->
 <eip:default-comparator id="comparator" sequenceNumberKey="seqnum"/>

A running example can be downloaded from here. In this example, a custom-coded message sender sends messages in "wrong" order to the resequencer. The resequencer re-orders these messages and (synchronously) sends them to a file sender-endpoint. The file sender-enpoint writes the messages (in proper order) to the work/output directory.

Endpoint properties

Async Bridge

The AsyncBridge expects an InOut mep as input. It then uses the exchange id of the InOut mep as the correlation id and creates an InOnly message by copying the input message and sends it to the target (with the correlation id set as a property). Next it expects an InOnly to come back with the same correlation id property. When this happens, the message is copied to the out message of the original exchange and sent back. If no response is received during the configured amount of time (timeout property in milliseconds), an error will be sent back to the original consumer.

 <eip:async-bridge
  service="sample:AsyncBridge"
  endpoint="AsyncBridgeEndpoint"
  <eip:target>
    <eip:exchange-target service="sample:SampleTarget" />
  </eip:target>
</eip:async-bridge>

Correlation Id

There is a convention between the AsyncBridge and the target on how the correlation id is transmitted. The correlation id can only be transmitted from the AnsycBridge to the target using a message property . The property name can be customized. On the other hand, the correlation id coming back from the target could be set in a message property or the message payload. The AsyncBridge could use an Expression to extract the correlation id from the message returning from the target.

 <eip:async-bridge
         service="sample:AsyncBridge"
         endpoint="AsyncBridgeEndpoint"
         responseCorrIdProperty="correlationIdProperty"
         responseCorrId="#responseCorrIdExpression">
         <eip:target>
             <eip:exchange-target service="sample:SampleTarget" />
         </eip:target>
 </eip:async-bridge>

 <bean id="responseCorrIdExpression" class="org.apache.servicemix.expression.JAXPStringXPathExpression" >
       <contructor-arg value="/my-response/message/@corrId"/>
 </bean>   

As you can see from the sample above the responseCorrIdProperty is used to set the name of the property that the target will query to get the correlation id sent by the AsyncBridge. In other words, the target will do something like this to extract the correlation id

 String correlationId = exchange.getProperty("correlationIdProperty");

The responseCorrId is set with an instance of type org.apache.servicemix.expression.Expression, in this case the class org.apache.servicemix.expression.JAXPStringXPathExpression.
This expression resolves the location of the correlation id coming back from the target. In the above example the expression shows that the correlation id comes as part of the message payload in an attribute called "corrId" of the /my-response/message element. In a similar manner the class org.apache.servicemix.expression.PropertyExpression could have been used to locate the correlation id in a message property.

Endpoint properties

Tips

ExchangeTarget

All patterns use the <exchange-target /> tag to specify the target of a JBI exchange.
This element has the following attributes:

NamespaceContext

Some patterns use XPath expression. To use such expressions on an xml with namespaces, you need to define a NamespaceContext.


This NamespaceContext can be referenced by a namespaceContext attribute as shown in the XPathSplitter or MessageFilter examples.

Predicates

Some patterns uses predicates to test a given JBI exchange. The only predicate currently implemented is the XPathPredicate, but you can implement your own and deploy it with the service unit.

Configuring temporary message storage

Many of the pattern implementation need to store MessageExchanges temporarily. An example: the aggregator will need to keep track of the MessageExchange it is aggregating. By default, the EIPs use a plain MemoryStoreFactory to create in-memory stores, but there are other options. If you set the timeout property on the MemoryStoreFactory, it will evict old object from the in-memory store to avoid a memory leak. You can also use a JDBCStoreFactory to store data in a database instead of in memory.

Example: to use an in-memory store with timeout for a storing active and closed aggregations in a <split-aggregator/>, you can do

<eip:split-aggregator service="test:aggregator" endpoint="endpoint"
                      storeFactory="#StoreFactory" closedAggregateStoreFactory="#StoreFactory">
  <eip:target>
    <eip:exchange-target service="test:trace5" />
  </eip:target>
</eip:split-aggregator>

<bean id="StoreFactory" class="org.apache.servicemix.store.MemoryStoreFactory">
  <property name="timeout" value="120000"/> <!-- 2 minute timeout -->
</bean>

Creating your own patterns

Some classes have been designed to be extensible, this includes:

• org.apache.servicemix.eip.support.AbstractAggregator

• org.apache.servicemix.eip.support.AbstractSplitter

servicemix-exec

Overview

The ServiceMix Exec component is used to invoke commands (executables, binaries, shell commands, shell scripts, etc). The command can be static (defined in the endpoint attributes) or dynamic (provided in the incoming message, including arguments).

Namespace and xbean.xml

The namespace URI for the servicemix-exec component is http://servicemix.apache.org/exec/1.0. The is an example of <filename>xbean.xml</filename> with a namespace definition with prefix exec.

<beans xmlns:exec="http://servicemix.apache.org/exec/1.0">

   <!-- add exec:endpoint definitions here -->

</beans>

Endpoints types

The ServiceMix Exec component only defines one endpoint, called exec:endpoint.

Endpoint exec:endpoint

Endpoint properties

Abstract WSDL

TODO

How it works

TODO

servicemix-file

Overview

The ServiceMix File component provides JBI integration to the file system. It can be used to read & write files via URI or to periodically poll directories for new files.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/file/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:file="http://servicemix.apache.org/file/1.0">

  <!-- add file:poller and file:sender definitions here -->

</beans>

Endpoint types

The servicemix-file component defines two endpoint type:

• file:poller :: Periodically polls a directory for files and sends an exchange for every file

• file:sender :: Writes the contents of an exchange to a file

file:poller

Endpoint properties

file:sender

Endpoint properties

servicemix-ftp

Overview

The ServiceMix FTP component provides JBI integration to the FTP servers. It can be used to read & write files over FTPor to periodically poll directories for new files.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/ftp/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:ftp="http://servicemix.apache.org/ftp/1.0">

  <!-- add ftp:poller and ftp:sender definitions here -->

</beans>

Endpoint types

The servicemix-ftp component defines two endpoint type:

• ftp:poller :: Periodically polls a directory on an FTP server for files and sends an exchange for every file

• ftp:sender :: Writes the contents of an exchange to a file on an FTP server

ftp:poller

Endpoint properties

ftp:sender

Endpoint properties

Examples

Using ftp:pool to configure the FTP connections

In order to gain more control over the FTP connection parameters (active/passive, timeout, ...) that are being used, you can define your own FTP connection pool. Afterward, you can refer to the pool object from both a sender and poller endpoint.

<?xml version="1.0"?>
<beans xmlns:ftp="http://servicemix.apache.org/ftp/1.0"
       xmlns:sample="urn:servicemix:example">

  <ftp:sender service="sample:sender" endpoint="endpoint"
              uri="ftp://localhost/myfolder"
              clientPool="#clientPool"/>

  <ftp:pool id="clientPool" username="myname" password="$ecret"
            dataTimeout="90000" />

</beans>

The table below shows the full list of options offered by ftp:pool:

If you need even more fine-grained control over the FTP connections or the way the payloads are being handled, have a look at the Camel FTP component, which offers a lot of options out of the box, but also allows setting any property on its underlying Commons NET FTPClient and FTPClientConfig instances.

servicemix-http

Overview

ServiceMix ships with a JBI compliant HTTP/SOAP binding component named servicemix-http.

Here are the main features:

• JBI compliant Binding Component

• Usable in a lightweight mode in servicemix.xml configuration files

• Integrated HTTP server based on Jetty 6

• HTTP Client using Jakarta Commons HTTP Client

• Highly performant and scalable using Jetty 6 continuations

• SOAP 1.1 and 1.2 support

• MIME attachments

• WS-Addressing support

• WSDL based and XBean based deployments

• Support for all MEPs as consumers or providers

• SSL support

• WS-Security support

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/http/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:http="http://servicemix.apache.org/http/1.0">

  <!-- add http:consumer, http:soap-consumer
           http:provider and http soap:provider definitions here -->

</beans>

Endpoint types

The servicemix-http component defines four endpoint type:

• http:consumer :: This endpoint allows you to expose a service in the ESB to the outside world over HTTP. Whenever it receives an HTTP request, it will interact with the configured services on the ESB to provide the HTTP response.

• http:soap-consumer :: Similar to http:consumer, but specifically geared towards handing SOAP requests and responses

• http:provider :: This endpoint allows you to access remote services from within the ESB. It will perform an external HTTP request whenever it receives a JBI MessageExchange

• http:soap-provider :: Similar to http:provider, but specifically geared towards performing SOAP requests

It also provides one additional legacy endpoints, which are still available to ease migration from ServiceMix 3:

• http:endpoint :: (Deprecated) Legacy endpoint, capable to acting as a consumer or provider based on the configuration

http:endpoint

Endpoint properties

http:consumer

Endpoint properties

http:provider

Endpoint properties

http:soap-consumer

Endpoint properties

http:soap-provider

Endpoint properties

servicemix-jms

Overview

ServiceMix ships with a JBI compliant JMS binding component named servicemix-jms.

Here are the main features:

• JBI compliant Binding Component

• Usable in a lightweight mode in servicemix.xml configuration files

• SOAP 1.1 and 1.2 support

• MIME attachments

• WS-Addressing support

• WSDL based and XBean based deployments

• Support for all MEPs as consumers or providers

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/jms/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:jms="http://servicemix.apache.org/jms/1.0">

  <!-- add jms:consumer, jms:soap-consumer, jms:jca-consumer,
           jms:provider, jms:soap-provider and jms:jca-provider definitions here -->

</beans>

Endpoint types

The servicemix-jms component defines six endpoint type:

• jms:consumer :: This endpoint allows you to expose a service in the ESB to the outside world over JMS. Whenever it receives a JMS message, it will interact with the configured services on the ESB.

• jms:soap-consumer :: Similar to jms:consumer, but specifically geared towards handing SOAP requests and responses

• jms:jca-consumer :: Similar to jms:consumer, but adds the possibility of using a JCA resource adapter

• jms:provider :: This endpoint allows you to access remote services from within the ESB. It will send a JMS message whenever it receives a JBI MessageExchange

• jms:soap-provider :: Similar to jms:provider, but specifically geared towards performing SOAP requests

• jms:jca-provider :: Similar to jms:provider, but adds the possibility of using a JCA resource adapter

It also provides one additional legacy endpoints, which are still available to ease migration from ServiceMix 3:

• jms:endpoint :: (Deprecated) Legacy endpoint, capable to acting as a consumer or provider based on the configuration

jms:endpoint

Endpoint properties

jms:consumer

Endpoint properties

jms:provider

Endpoint properties

jms:soap-consumer

Endpoint properties

jms:soap-provider

Endpoint properties

jms:jca-consumer

Endpoint properties

servicemix-mail

Overview

he ServiceMix Mail component provides support for receiving and sending mails via the enterprise service bus.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/mail/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:mail="http://servicemix.apache.org/mail/1.0">

  <!-- add mail:poller and mail:sender definitions here -->

</beans>

Endpoint types

The servicemix-mail component defines two endpoint type:

• mail:poller :: Connect to a POP3 or IMAP server and send a MessageExchange for every mail

• mail:sender :: Connect to an SMTP server and send a mail for every JBI MessageExchange it receives

mail:poller

Endpoint properties

mail:sender

Endpoint properties

servicemix-osworkflow

Overview

The ServiceMix OSWorkflow component provides workflow functionality to the ESB. You can specify one or more workflows and it's processing will start when a valid message is received.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/osworkflow/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:osworkflow="http://servicemix.apache.org/osworkflow/1.0">

  <!-- add osworkflow:endpoint here -->

</beans>

Endpoint types

The servicemix-osworkflow component defines a single endpoint type:

• osworkflow:endpoint :: The endpoint will receive messages from the NMR and will then start the processing of the workflow.

osworkflow:endpoint

Endpoint properties

servicemix-quartz

Overview

The servicemix-quartz component is a standard JBI Service Engine able to schedule and trigger jobs using the great Quartz scheduler.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/quartz/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:osworkflow="http://servicemix.apache.org/quartz/1.0">

  <!-- add quartz:endpoint here -->

</beans>

Endpoint types

The servicemix-quartz component defines a single endpoint type:

• quartz:endpoint :: The quartz endpoint can be used to fire message exchanges at a given (recurrent) time.

quartz:endpoint

Endpoint properties

servicemix-saxon

Overview

The servicemix-saxon component is a standard JBI Service Engine for XSLT / XQuery. This component is based on Saxon and supports XSLT 2.0 and XPath 2.0, and XQuery 1.0.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/saxon/1.0. This is an example of xbean.xml file with a namespace definition with prefix saxon.

    <beans xmlns:saxon="http://servicemix.apache.org/saxon  /1.0">

      <!-- add saxon:xslt, saxon:xquery or saxon:proxy definitions here -->

    </beans>

Endpoint types

The servicemix-saxon component defines these endpoints:

• saxon:xslt: Translates the in message content using XSLT to send back the translated content in the out message

• saxon:proxy: Acts as a proxy for an endpoint, translating the message passed to/from the endpoint using XSLT

• saxon:xquery: Use xquery to extract parts of the XML

Endpoint saxon:xslt

The XSLT endpoint can be used to apply an XSLT stylesheet to the incoming exchange and will return the transformed result as the output message.

<saxon:xslt service="test:xslt" endpoint="endpoint"
            resource="classpath:transform.xsl" />

Endpoint properties

Mandatory properties

The endpoint requires one of these two properties to be specified:

Optional properties

Using properties and parameters

All properties defined on the JBI exchange and input JBI message will be available for use inside the XSLT stylesheet as parameters.

In addition to those properties and the one specified in the parameters property on the endpoint, the following objects are also available:

• exchange : the JBI exchange

• in : the input JBI NormalizedMessage

• component : the XsltEndpoint instance being called

Below is an example that demonstrates how the properties of the exchange and normalized message can be accessed from inside the xslt.

<?xml version="1.0" encoding="windows-1253"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0"
                xmlns:class="http://saxon.sf.net/java-type"
                xmlns:me="java:javax.jbi.messaging.MessageExchange"
                xmlns:nm="java:javax.jbi.messaging.NormalizedMessage">
    <xsl:output method="xml" indent="yes" encoding="ISO-8859-1"/>
    <xsl:param name="exchange" as="class:javax.jbi.messaging.MessageExchange"/>
    <xsl:param name="in" as="class:javax.jbi.messaging.NormalizedMessage"/>

    <xsl:template match="/">
    <message>
        <!-- The value of messageId will be read from thr property MSG_ID of the "in" NormalizedMessage -->
        <messageId>
            <xsl:value-of select="nm:getProperty($in, 'MSG_ID')"/>
        </messageId>
    </message>
</xsl:stylesheet>    

All those parameters can be accessed using XSLT standard ways using <xsl:param/>.

Endpoint saxon:proxy

One common use case is the need to transform a request coming from a service and send it to another service and do the same with the response. A simple example is the need to translate the request and responses between two SOAP endpoints. Such a use case could be implemented using two XSLT endpoints and an EIP StaticRoutingSlip. However, there are some drawbacks, as the operation is lost in the process, and a static routing slip can not be used to process InOnly exchanges.

<saxon:proxy service="test:proxy" endpoint="endpoint"
             resource="classpath:transform-in.xsl"
             outResource="classpath:transform-out.xsl"
             faultResource="classpath:transform-fault.xsl">
  <saxon:target>
    <saxon:exchange-target service="test:echo" />
  </saxon:target>
</saxon:proxy>

Endpoint properties

Mandatory properties

Depending on the MEP, you have to set one or more XSL stylesheets to be used for converting the message payloads:

You also have to specify the target service that should be invoked from this endpoint:

• target : ExchangeTarget that specifies the target service for the proxy endpoint

Optional properties

Endpoint saxon:xquery

The XQuery endpoint can be used to apply a selected XQuery to the input document.

<saxon:xquery service="test:xquery" endpoint="endpoint"
              resource="classpath:query.xq" />

Endpoint properties

Mandatory properties

You need to specify one of query, resource or expression

Optional properties

Sample configurations

Dynamic stylesheet selection (saxon:xslt)

This endpoint configuration will dynamically load the XSL-T resource that is specified in the xslt.source property on the NormalizedMessage

<saxon:xslt service="test:xslt-dynamic" endpoint="endpoint">
  <saxon:expression>
    <bean class="org.apache.servicemix.expression.PropertyExpression">
      <property name="property" value="xslt.source" />
    </bean>
  </saxon:expression>
</saxon:xslt>

Using parameters in the XSL-T stylesheet (saxon:xslt)

You can define a Map of parameters on the saxon:xslt endpoint.

<saxon:xslt service="test:xslt-params" endpoint="endpoint"
            resource="classpath:parameter-test.xsl">
  <property name="parameters">
    <map>
      <entry key="stringParam" value="cheeseyCheese"/>
      <entry key="integerParam">
        <bean class="java.lang.Integer">
          <constructor-arg index="0" value="4002"/>
        </bean>
      </entry>
    </map>
  </property>
</saxon:xslt>

In the XSL file, you can access the parameter values with <xsl:param/>. You can also access headers on the NormalizedMessage (like e.g. org.apache.servicemix.file) with the same syntax.

<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' version='1.0'>
  <xsl:param name="stringParam"/>
  <xsl:param name="integerParam"/>
  <xsl:param name="org.apache.servicemix.file" />
  ...
</xsl:stylesheet>

Inlined XQuery and specific output configuration (saxon:xquery)

<saxon:xquery service="test:xquery-inline" endpoint="endpoint">
  <saxon:query>
    for $x in /bookstore/book
    where $x/price > 30
    return $x/title
  </saxon:query>
  <saxon:outputProperties>
    <saxon:property key="{http://saxon.sf.net/}wrap-result-sequence">yes</saxon:property>
  </saxon:outputProperties>
</saxon:xquery>

Dynamic XQuery selection (saxon:xquery)

This endpoint configuration will dynamically load the XQuery resource that is specified in the xquery.source property on the NormalizedMessage

<saxon:xquery service="test:xquery-dynamic" endpoint="endpoint">
  <saxon:expression>
    <bean class="org.apache.servicemix.expression.PropertyExpression">
      <property name="property" value="xquery.source" />
    </bean>
  </saxon:expression>
</saxon:xquery>

servicemix-scripting

Overview

The ServiceMix Scripting component provides support for processing scripts using JSR-223 compliant scripting languages.

The component is currently shipping with:

• Groovy (1.5.6)

• JRuby (1.1.2)

• Rhino JavaScript (1.7R1)

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/scripting/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:scripting="http://servicemix.apache.org/scripting/1.0">

  <!-- add scripting:endpoint here -->

</beans>

Endpoint types

The servicemix-scripting component defines a single endpoint type:

• scripting:endpoint :: The scripting endpoint can be used to use scripts to handle exchanges or send new exchanges

scripting:endpoint

Endpoint properties

servicemix-snmp

Overview

The ServiceMix SNMP component provides support for receiving SNMP events via the enterprise service bus by using the SNMP4J library.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/snmp/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:snmp="http://servicemix.apache.org/snmp/1.0">

  <!-- add snmp:poller or snmp:sender definitions here -->

</beans>

Endpoint types

The servicemix-snmp component defines two endpoint types:

• snmp:poller :: Periodically polls a device status using SNMP and sends the OIDs as a JBI MessageExchange

• snmp:trap-consumer :: Consumes an SNMP trap message and sends the OIDs as a JBI MessageExchange

snmp:poller

Endpoint properties

vfs:trap-consumer

Endpoint properties

servicemix-validation

Overview

The ServiceMix Validation component provides schema validation of documents using JAXP 1.3 and XMLSchema or RelaxNG.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/validation/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:scripting="http://servicemix.apache.org/validation/1.0">

  <!-- add validation:endpoint here -->

</beans>

Endpoint types

The servicemix-validation component defines a single endpoint type:

• validation:endpoint :: Validates the incoming XML message - can be configured to fail the exchange or to send validation errors back to the sender in the message body.

validation:endpoint

Endpoint properties

servicemix-vfs

Overview

The ServiceMix VFS component provides support for reading from and writing to virtual file systems via the enterprise service bus by using the Apache commons-vfs library.

Namespace and xbean.xml

The namespace URI for the servicemix-bean JBI component is http://servicemix.apache.org/vfs/1.0. This is an example of an xbean.xml file with a namespace definition with prefix bean.

<beans xmlns:vfs="http://servicemix.apache.org/vfs/1.0">

  <!-- add vfs:poller or vfs:sender here -->

</beans>

Endpoint types

The servicemix-vfs component defines two endpoint types:

• vfs:poller :: Periodically polls a directory on one of the VFS-supported file systems for files and sends an exchange for every file

• vfs:sender :: Writes the contents of an exchange to a file on one of the VFS-supported file systems

vfs:poller

Endpoint properties

vfs:sender

Endpoint properties

servicemix-wsn2005

Overview

The servicemix-wsn2005 is a standard JBI Service Engine which implements the WS-Notification specification from Oasis.

servicemix-xmpp

Overview

The ServiceMix XMPP component is used to communicate with XMPP (Jabber) servers through the JBI bus.

xmpp:receiver

Endpoint properties

xmpp:sender

Endpoint properties