Transports and Message Formats

This section discusses the transports and message format framework architecture and how you can implement custom transports and message formats.

Implementing custom Transports
Supporting custom Message formats

Implementing custom Transports

Transports define how messages can flow into and out of the UltraESB. A transport listener defines a Spring bean which will start accepting messages and inject them into the ESB, and a transport sender defines a Spring bean which registers a URL prefix of a destination message to be handled by it (e.g. mailto:, file:, etc), so that the ESB will call into it to deliver messages with that prefix. Although the UltraESB ships many transports by default, an end user can additionally extend the framework to support:

New custom TCP level transports (e.g. proprietary low level transports)

To support a new TCP or TCPS based transport, one needs to basically extend the base TCP transport, and implement the TCPServiceHandler. The MLLP/S transport for HL7 messages is a concrete implementation which could be used as a sample - see the HL7ServiceHandler.
Library level custom transports (i.e. transports for which already a third party library exists - e.g. QuickFix for the Financial Information Exchange protocol etc).

To write a new library level transport, one could start by extending the AbstractTransportListener and the AbstractTransportSender classes. A polling transport (i.e. one which periodically polls for messages according to a specified schedule or CRON expression) could be written by extending the AbstractPollingTransportListener.
Polling Custom Transports

It is possible to use the generic polling support to configure a proxy service to be invoked on a specified schedule - e.g. based on a CRON expression. When the inSequence of the proxy service is invoked, one can write any custom code to perform a message fetching etc. For example, this maybe useful to perform a custom polling of a Database query and depending on the results, create a message and submit for further processing.

Supporting custom Message formats

The UltraESB does not force a canonical message format (e.g. SOAP, JMS etc) for all messages flowing in through different transports. Hence a message maybe held in its native or most optimal format.

When to use custom Message formats
Even if you have to implement a custom transport, you do not have to implement a custom message format. Analyze your requirements to first decide if holding the message payload in a currently supported message format with a custom transport will not be adequate. It is rarely that you may want to write a custom message format.

Technical Questions ?
You can log your technical questions at Stack Overflow
1. Login to Stack Overflow
2. Navigate to How to Ask page.
3. Search to see if a question relevant to your own has been asked.
4. If your search turned up nothing helpful or if it didn’t quite answer your question, we then suggest you ask a question yourself. Click on Proceed to navigate to Ask Question page.
5. Provide a descriptive title and describe the nature of your question. Please make sure to use the tag ultraesb when asking your question.

For example, a HTTP/S request is held on a RAM disk based file or a memory mapped file depending on the selected File Cache implementation, and a SOAP/XML message possibly parsed into a DOM for XPath evaluation. However, keeping the raw message on a file allows an immense level of flexibility. As an example, by simply adding the VTD XML library into the classpath of the UltraESB along with the VTDFastXML library, XPath expressions can be evaluated without DOM parsing, and is faster than SAX based techniques while still keeping the original message on a file. In addition, when binary messages such as Hessian are being proxied, the binary files are natural and the best option with regards to performance. The same hold true for example when using XSLT transformations - as its much easier and better in performance for the XSLT processors to read the input from a File, than a String, DOM or Axiom model for example.

The default message formats supported by the UltraESB are the following.

File
String
Map
Object
Byte Array
DOM
Data Handler
User defined custom formats based on GenericMessage - e.g. HAPIMessage

Refer to the HAPIMessage and the implementation classes of the other MessageFormat’s for more information on how custom message formats could be supported natively.

Terms of Use