Saddle Integration

Current status:

Since Saddle went public last December, many improvements have been added. A lot of bugs have been squashed and many subtle improvements have been added that make Saddle smother and allow are more fluent and intuitive work with this tool. Here we have to send a big "Thank You" to all the users, who provided numereous bug reports and improvement ideas. We really appreciate that!

Besides the bug fixing and smaller improvements, also new features have been added like the support for Mule 3.1 and the different Mule Enterprise Editions (we had our focus only on the Community Edition before..) or the support for fixed length message parsing and generation to name a view.

Finally, the first tutorial has been created that introduces you to the work with Saddle and also to some of its advanced features. Further tutorials will follow.

We are currently preparing a new release version of Saddle and updating the documentation to reflect all changes.

After this release, we plan some larger changes in the Saddle architecture and its message handling layer that will lead to an even more flexible and convenient system.
I will elaborate on that in a follow-up post within the next days.

Besides this thread, you can always follow the current state of the development in "realtime" on our Trac system at SourceForge and by checking up the nightly builds, you will find in the download section.

Say Goodbye to DOM!

So far, Saddle was using DOM (Document Object Model) for parsing data into the Saddle Message Templates and accessing the parsed data. This approach worked fine but came with some major drawbacks:

Performance
DOM is great for the purpose it has been designed but for representing a message structure particular requirement have to be met. DOM does not provide the possibility to store direct references to other Nodes within a Node object. Next, the DOM sturcture maintains a lot of elements that are not required for representing a message structure. Finally, for each instance of a message structure, the XML template has to be parsed to a DOM tree, which is very expensive as there is no fast clone function.

Flexibility
Different data types cannot be stored in their native format but have to be converted to strings. This is especially problematic for the treatment of binary data as it has to be encoded (e.g. Base64). Also, all nodes at a certain level of a branch are siblings. There is no differentiation between instances of the same Node and real siblings (=other nodes at the same level). Attributes cannot be shared between instances of the same Node, even if they are identical.

Usability
As the actual Node objects cannot be altered without changing the DOM library, all operations on them have to addressed by using an external API. Furthermore, this API was not consistent.

Footprint
for each instance of a message field, several objects are created, which results in a significant memory occupation.

The new Saddle Message Layer is a custom implementation with a sgnificantly higher performance, lower footprint and higher flexibility and usability:

A message template is now only parsed once into a Message Factory instance. Each time a transformer or a Mapping needs an empty instance, simply the produce() method of the MessageFactory is called, which clones the Structure that had been created from the message template.

Field attributes are identical for each instance of the same field and also for fields of different message instances. Thus, they are only created once and simply referenced by each field or instance, they decribe. That lowers the footprint and increases processing speed at the same time.

Each field comes now with a set of functions for accessing and modifying its content that can be called directly. In the past, this calls had to be made from the external API.

E.g. a call for getting the path of the parent of a certain field looked with the old Message Layer like: 

getMessageInstance().getPath(getMessageInstance().getParent(currentField));

With the new Message Layer this call would be simply:

currentField.getParent().getPath();

This approach is more comfortable to use and helped us to obtain much cleaner and easier understanding code for our integration projects.
All concerned components like custom transformers, connectors, and the Message Mapper Module have been adapted to the new Message Layer.

What will you have to change?
If you are using the Saddle Message Layer, you have to adapt the calls to the API in your mappings to the new format. But this should be straight forward and easy to accomplish as the function names remained mainly the same.

The new Message Layer will be one of the features of the v0.8 release of Saddle. You can already test it by downloading the latest nightly build.

Feel free to post any comments, questions, or remarks.

The Saddle Development Team

Release of Saddle v0.8 is immediate

We are currently debugging Saddle v0.8. You can follow the debugging by viewing the status of the bug reports in the Saddle bug tracker.
You can help us with that by downloading the latest nightly build in the download section and reporting any bugs you encounter.
Documentation and the tutorial have already been updated to the new version. Right after the release further tutorials will be created explaining the new project structure as well as advanced features like database-handling or HL7 support.

You can find information about the new features of the upcoming version in the blog and also in the previous posts.

The next features that will be implemented is the support for flows and an overhaul of the Saddle monitoring functionality.
We will provide you more details about that in subsequent posts.

Mule 3.2

We just added support for Mule 3.2 in the nightly builds. It should normally do the same than for 3.1 and there is still no support for new Mule 3 features like flows (but these will come as a next step after the release of Saddle 0.8)

So if you wanted to give Saddle a try but definitely wanted to use the latest Mule version it would be great if you could try it out now and give us some feedback in this forum.

There are also some new features like the possibility to define custom properties on endpoints or object factories and access to embedded scripts in scripting components and transformers.

Best regards,
The Saddle Team

Flow development

After releasing Saddle 0.8 we instantly started to work on flow support. While doing this we recognized, that our current approach of building the configuration files would lead to very complicated and hard to maintain class structures.
This is why we are currently overhauling the way our configurations are built.

To determine what has to be done if one element is linked to another one Saddle uses a set of strategy classes that are associated to each category of elements (for example inbound endpoints or components) as normally all elements of one type behave in the same way. For a short overview on the design pattern see its page on Wikipedia.

However the old way of fixed allocation of one strategy to a certain type of object became more and more complicated to handle as we extended Saddle's functionality for example with the Reply Service in the component section. This lead us to thinking about a more flexible and easier to configure approach.

As we realized that our strategies would get even more complicated if we added flow support to them we started thinking about a better approach and came to the idea of a more flexible way of defining the palette and what has to be done for which element.

Our solution for these problems was to allow the configuration of the palette using an XML file for each Mule version.  This would allow us to assign elements to categories that all use a default strategy, but also allow the definition of elements that needed a special strategy instead of the default one.

The XML approach gives everyone the possibility to tailor the palette to their needs. Categories can be reordered, renamed and new ones can easily be added.



As you can see in the image above the different strategies that are needed are now hierarchically organized. There are two abstract base classes, one for flow handling strategies and one for service handling strategies.
All strategy implementations are derived from these two classes, depending on whether they will handle services or flows. The abstract classes provide default functionality that is used through all Strategies and additional helper mtehods for specific types of elements have been placed into helper classes to prevent a code duplication there (see EndpointHelper and FilterHelper).

Some mule versions differ in the handling of configurations, for example mule 3.1 and onwards allow multiple outbound endpoints in an exception strategy. Such extra handling can now easily be implemented by deriving a new strategy class for mule 3.1 and add handling code for multiple outbound endpoints there whithout having to touch the existing classes. The new class will then be set in the XML file of the palette and will now be used automatically.

Saddle will determine whether to use a defined service or flow strategy based on the currently open workflow and the elements that should be linked.
This allows us to keep the old service support as the flow support starts to grow, without the one influencing the other.

We already started writing some strategies to support flows in Saddle and will continue to work on them for the next weeks. If you want to keep track of our progress feel free to try the latest nightly builds that will continuously be enhanced with more flow support. If you do this please keep in mind that the nightly builds are potentially unstable and might mess up your configuration files, so be sure to always keep a backup of your files.

Best regards,
The Saddle Team