Skip to content

Latest commit

 

History

History
70 lines (40 loc) · 5.11 KB

mule-0.8-release-notes.adoc

File metadata and controls

70 lines (40 loc) · 5.11 KB

Mule 0.8 Release Notes

Mule has undergone a major overhaul since version 0.7.1. The purpose of the rearchitecture was to simplfy use and development, improve extensibility, and create a more flexible and robust Enterprise Service Bus server. The following changes have been made-

Zero code intrusion

UMO components dont need to extend MuleUMO or any other abstract class or interface. Any object, bean or other framework component can be managed by mule.

IoC or Dependency Injector support

Mule now has external container support. This means that your UMO component and/or any supporting objects can exist in an external Ioc container such as Spring or PicoContainer. Mule also provides a simple interfaces for adding you’re own container support.

Lifecycle Management

UMO Components can have configurable lifecycle support. So existing components managed by Mule will still have their lifecycle methods fired i.e. init(), start(), stop() etc.

Interceptors

Interceptors are based on the same principle as Servlet Filters using the Command pattern. Interceptors can be chained together to perform timing, profiling, security/permission checking, decorating or anything else for each umo that is invoked. You can also define standard interceptor stacks in the config, and apply the stack to your UMO components.
Interceptors replace Chains in the previous version of Mule.

Sample Applications

Two Sample applications have been added to get started with Mule. See Examples for more information. Also, a reference application is planned to test all the functionality of Mule.

Test Compatability Kit

There is a Test Compatibility kit (TCK) for Mule, which provides a range of Abstract TestCases for common components in mule, such as Providers, transformers and Component Resolvers. See TCK (http:/www.muleumo.org/tck.html) for more information.

Transformers

Message transformers can now be chained together to allow for finer grained transformer implementations i.e.

JMS TextMessage -> String (XML) -> BeanBean -> String (XML) -> XSL Transform -> Email Message

Finer grained transformer implementations are more reusable.

Providers

Provider are now packaged and documented separately from the Mule project. This removes all provider dependancies from the Mule project and allows for pick-and-use of providers. It also makes it easier for 3rd party providers to be distributed with Mule. There is a project template for new providers in src/providers/template directory.

Documentation

All the site documentation has been updated and new documents have been added such as the Architecture Guide.

What’s Next?

Obviously, there have been many fundamental changes to Mule which means there hasn’t been any time to add any new components and there is still some outstanding functionality that I think really needs to be in Mule:

  • Transaction support needs to be built into the Providers transparently and controlled through configuration. This is next on the list.

  • Mule needs better security, both in terms of encrypting data between endpoints (needs a transformer implementation similar to the compression transformer) and credential checking for applications accessing the bus through a provider.

  • Hey, what happened to the Web Services Provider? I’m afraid it fell by the wayside and needs to be pick up again. Made this release without it because not all ESB implementations use WS anyway. The WS provider will be released shortly.

  • Providers clean up. Providers got left out of the refactoring because I don’t think their interface will need to change in order to clean them up. Currently some implement threading and some don’t. I think Mule should provide the threading framework for all providers. Also need to add support for permission checking (to send and receive over the provider) and transaction management. Again, these features should be transparent and should not affect the current API.

  • Comprehensive Configuration model. Mule’s current configuration implementation isn’t very flexible or extensible, though it does work so there is no hurry on this one.

  • A new Mule icon would be nice. I think the current one is a bit lame!

What’s on the Roadmap?

These are things I would like Mule to have. some of them, if not all are subprojects. If anyone is interested in picking up any of these I would be very happy to talk to you.

  • A configuration GUI would be great. One of the hardest things about mule is it’s configuration, a user interface would really help.

  • A web based, management/monitoring GUI would also be very desirable. I guess I need add JMX support to Mule and also explore JMX more to see you can do things like send commands to components such as stop processing.

  • More providers! With all the refactorings I haven’t had time to write any more providers. The most important ones right now would be a Web Services Provider and JDBC provider/OR mapping provider.

  • A persistence/serialisation/deserialisation template strategy. Basically provide a skeletal persistence layer that you can plug in you persistence and object serialisation strategies.