Mule : Mule 0.8 Release Notes
This page last changed on Sep 14, 2005 by rossmason.
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 intrusionUMO 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 supportMule 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|http://www.springframework.org"] or PicoContainer. Mule also provides a simple interfaces for adding you're own container support. Lifecycle ManagementUMO 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. InterceptorsInterceptors 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. Sample ApplicationsTwo 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 KitThere 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 TransformersMessage transformers can now be chained together to allow for finer grained transformer implementations i.e. JMS TextMessage -> String (XML) -> Bean Bean -> String (XML) -> XSL Transform -> Email Message Finer grained transformer implementations are more reusable. ProvidersProvider 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. DocumentationAll 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-
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.
|
![]() |
Document generated by Confluence on Oct 03, 2006 09:23 |