An Overview of Marshalers in ServiceMix
Marshalers in ServiceMix are used to convert messages to/from the JBI normalised messages. For example, the JBI spec requires that the payload of a normalized message be XML. So when non-XML messages are sent through a binding component (BC) those messages must be normalized into XML and when a message leave a BC it may need to be denormalized to be compatible with the external service to which it is being sent. For information on this see message normalization. The overall idea with the marshaler is that it captures the raw message as it enters the BC and allows for any kind of transformation of that message before sending it into the JBI component.
Because ServiceMix doesn't provide the ability to handle message normalization for every conceivable message format out there, ServiceMix provides classes for implementing your own custom marshalers.
Existing Marshalers in ServiceMix
As shown in the image below, the MarshalerSupport
class is the base class for many marshalers inside of ServiceMix:
However, there are many other marshalers besides those in the image above. These include the following list but there are many more as well:
servicemix-http
DefaultHttpConsumerMarshaler
DefaultHttpProviderMarshaler
HttpSoapConsumerMarshaler
HttpSoapProviderMarshaler
RestProviderMarshaler
SerializedMarshaler
servicemix-jms
servicemix-mail
servicemix-quartz
Creating a Custom Marshaler
Creating a custom marshaler is actually a pretty easy task. Depending on what kind of marshaler you need to create, you may take a different approach. For example, when creating a custom marshaler for the servicemix-http, you might just need to extend the DefaultHttpConsumerMarshaler
or the DefaultHttpProviderMarshaler
to override the createExchange()
and sendOut()
methods. Because the servicemix-http component provides its own base classes in HttpConsumerMarshaler
and HttpProviderMarshaler
which are specifically designed for use with the HTTP protocol. Oftentimes it's easier to extend one of these existing marshalers, but this is certainly not the only approach.
You can also create a custom marshaler from scratch by extending the MarshalerSupport
class.
Older stuff
Questions:
- My initial questions about this area were based on the apparent ad-hoc implementations of the marshalers (from the class diagram).
- I thought that the interface Marshaler was intended as a base for all marshalers.
- I was also confused why some marshalers are standalone, while others derive from a common base (MarshalerSupport).
- Yet more have interfaces (eg FileMarshaler), but there is no consistency
– PS
Notes [19/12]:
- Marshaler (the interface) is really intended for POJO/NM support
- Other transports have own hardwired marshalers with args/helpers appropriate to each transport
- If user wants to write own marshaler for specific binding (eg JMS components) then in general must derive the ServiceMix hardwired marshaler for that binding. eg MyJmsMarshaler extends JmsMarshaler
- Some standalone marshalers don't derive MarshalerSupport base class. No particular reason ; they just preceded it, that's all
- Code base for diagram is SM2.0.2
- See IRC log 19/Dec for more comments
Update [20/12]:
- SM devs refactored interface Marshaler to PojoMarshaler to reduce confusion about purpose of Marshaler
Class diagram showing ServiceMix 2.0.2 marshalers