|This topic relates to Mule ESB Version 2.x.|
To see the corresponding topic in Mule ESB Version 3.x, click [Configuring Components].
Service components contain the business logic for working with the messages passed through Mule ESB. A service component can be any type of object, including a Spring bean, POJO, script, web service, or REST call.
Because they are highly specific to your implementation, you will typically create your own custom components, or simply use an existing POJO. Mule also ships with some standard components you can use or extend as needed. This page describes how to configure the different types of components.
For detailed information on the elements you configure for components, see Component Configuration Reference.
There are several simple components included with Mule that are useful for testing or bypassing component execution.
|<log-component/>||Logs component invocations, outputting the received message as a string. This component does not return a response.|
|<echo-component/>||Extends the log component to log and echo the incoming message. The message is transformed before being returned, so transformations on inbound endpoints will be applied.|
|<null-component/>||Throws an exception when invoked. This is useful for testing use cases that use a forwarding consumer inbound router.|
|<passthrough-component>||Similar to the echo component but does not log. This component is useful when defining services that consist of inbound and outbound endpoints/routers but don't have a component implementation. Note that explicitly configuring this component has exactly the same result as configuring a service with no component.|
|<bridge-component/>||Identical to the pass-through component but preserves the Mule 1.4 terminology.|
|<test:component/>||Configures the Mule FunctionalTestComponent, which allows more complex testing scenarios to be created. For more information, see Functional Testing.|
Java components specify a Java class to be used as the service component or configure a reference to an implementation in a container such as Spring. They also configure the way in which Mule should manage the Java service component's life-cycle, invoke it, and (if pooled) manage the pool of instances.
Java components can be configured quickly and easily by simply specifying the service component implementation class name on the <component> or <pooled-component> element. The <pooled-component> element allows you to establish a pooling profile for the service (see Tuning Performance). In both cases, the PrototypeObjectFactory will be used by default and a new object instance will be created for each request or (for pooled components) for each new object in the pool.
Alternatively, you can explicitly specify object factories, such as the SingletonObjectFactory that creates a single instance of the object:
The explicit syntax is required instead of the shortcut <component class> syntax if you add interceptors to the component. For further configuration options and information on the default settings that are applied, see Configuring Java Components.
These are several other components available that allow you to use different technologies such as web services for your service components. These components are often included as part of transports or modules.
|<http:rest-service-component/>||Proxies a remote call to a REST-style web service.|
|<cxf:wrapper-component/>||Proxies a remote call to a web service using CXF.|
|<axis:wrapper-component/>||Proxies a remote call to a web service using Axis.|
|<script:component/>||Configures a JSR-223 script for the service component.|
Mule interceptors are useful for attaching behaviors to multiple service components. The interceptor pattern is often referred to as practical AOP (Aspect Oriented Programming), as it allows the developer to intercept processing on an object and potentially alter the processing and outcome. For complete information, see Using Interceptors.