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

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

  • No labels