 | Did you know . . .
MuleSoft has released Studio GA, a powerful new interface for Mule ESB that can cut your development time by half or more. You can model, debug, and deploy your applications all within the rich, yet flexible Studio environment.
Studio provides two-way (i.e., graphical and code-based) editing, which means that developers no longer have to trade ease-of-use against fine-grained control over their development projects. Any changes you make in one mode appear instantly in the other.
Mule Enterprise and Mule iON developers can fine-tune their applications in the advanced Studio XML editor, then re-deploy them on whichever version of Mule those applications were originally developed.
Studio installation is almost instantaneous, and a pair of tutorials can get you up and running in less than 40 minutes.
Let’s get Kicking!
|
New in this Release
[Mule 3.2] This page lists release notes for current and previous Mule releases. It also describes the major new features and changes in Mule ESB version 3.2
Release Notes
Fixes and features in the releases listed below are included in Mule 3.2 Community. That's a lot of goodness!
For a summary of what's new and different in Mule 3.1, see New in Mule ESB Version 3.1
[Mule 3.2] New in Mule ESB Version 3.2
High Availability Clustering 
Ensuring zero message loss is a primary concern when you're building mission-critical applications. Mule 3.2 provides key capabilities to support these applications. These capabilities include:
- High availability clustering to ensure system-level availability
- Reliability patterns for non-transactional connectors
Clustering: Mule ensures system availability by clustering together Mule ESB servers into one virtual server composed of multiple nodes. The cluster acts as a unit, communicating and sharing information through a distributed shared memory data grid. If a node becomes unavailable due to failure or planned downtime, another node in the cluster can assume the workload and continue to process existing events and messages. Because all nodes in a cluster process messages simultaneously, clusters can also improve performance and scalability. Compared to a single node instance, clusters can support more users or improve application performance by sharing the workload across multiple nodes or by adding nodes to the cluster.
For more details about clusters, see Mule High Availability (HA) Clusters.
Reliability Patterns: A zero-message loss application not only requires the underlying ESB to be reliable, but that reliability needs to extend to individual connections. New reliability patterns introduced in Mule 3.2 give you the tools to build fully reliable applications in your clusters. The Mule 3.2 documentation provides code examples that show how you can implement a reliable message pattern for a number of different non-transactional transports, including HTTP, FTP, File, and IMAP. (Mule's built-in support for transactional transports such as JMS enables reliable messaging for applications that use these types of transports.)
Learn more at Reliability Patterns.
Business Event Analyzer
Many businesses require accurate analysis of business events. Some use case examples include:
- Root cause analysis
- Regulatory compliance
- Business activity monitoring
- Business intelligence
Mule gives you in-depth visibility into business transactions and events on your Mule servers. This visibility is available out of the box in the Business Events tab in the management console. However, it can also be integrated with other applications through storage in a persistent database. You can track events for the flows and message processors handling your business transactions and drill down into event-related data to do things like analyze the root cause of failures, isolate performance bottlenecks, and test for compliance to company procedures.
See Analyzing Business Events for more details.
Request-Reply Messaging Style for Flows
Mule's support for the request-reply messaging style has been extended to flows. Previously it was available only to services. The request-reply messaging style (also known as asynchronous request-response and asynchronous request-reply), is well suited for scenarios where you want to send a request that will result in an asynchronous reply message and process that reply as though it came from a simple synchronous request.
For more information about the request-reply messaging style, see Async Request Response.
The request-reply message style is implemented in flows with the new request-reply message processor. You can learn more about the processor at Using Message Processors to Control Message Flow.
Tighter Control Over Flows
Mule 3.2 provides processing strategies that give you more flexibility in the way flows are processed. For example, you can instruct Mule to use a synchronous processing strategy for simple flows where you want everything to be handled in band. Or you can specify a queued-asynchronous strategy. In this case, Mule stores the current event in a SEDA queue that uses a thread pool to run its entries asynchronously, resulting in the same high performance characteristics for a flow as for a service.
For more information, see Flow Processing Strategies.
Improvements in Transactional Behavior
Mule 3.2 significantly extends transactional support in flows in two ways:
First, inbound VM endpoints now support fully transactional flows, including XA transactional flows. This is a direct result of the decoupling of message exchange patterns and synchronous/asynchronous behavior described in Tighter Control Over Flows. This allows VM to be used in many situations which previously required JMS, with much less overhead and no need to integrate third-party software. Find out more in the Transactional Inbound VM Queues section of the VM Transport Reference.
Second, by default, a non-transactional outbound endpoint will now ignore an active transaction rather than rejecting it. This can provide the equivalent of a multi-resource transaction. For details, see Non-transactional outbound endpoints.
Better Performance Through SEDA Queues
As you've read in Tighter Control Over Thread Processing in Flows, a flow can now store events in a SEDA queue, providing the flow with the same performance characteristics as a service. But this is only one of the important changes in Mule 3.2 regarding SEDA queues. In fact, the way Mule's internal SEDA queues store messages has changed. Mule's internal SEDA queues now use an ObjectStore for persisting messages. Significantly, this change in approach allows you to configure the object store to use when persisting messages on individual services. For example, you can specify an in-memory store or a file-based store. You can even configure a custom object store to use for SEDA queues.
To learn more, see Mule Object Stores.
More REST APIs for Management
Mule provides REST APIs that you can use to programmatically access much of Mule's management functionality. In previous versions you could use the REST APIs to perform server-related operations such as registering new servers and managing existing servers. Mule 3.2 expands the set of REST APIs to include:
- Find, upload, and delete applications inside the repository.
- Deploy, undeploy, create, update, and delete deployments inside a server.
- Create, remove, and get information about a cluster, as well as start, stop, and restart applications on a cluster.
- Manage flows, including finding, starting, and stopping flows, as well as finding, starting, and stopping a flow's endpoints.
To get more details, see Using the Management Console APIs.
Drools Support Added
Mule 3.2 adds support for Drools, a best-of-breed open source rules engine. This allows you to build Mule applications driven by business rules, including those that require complex event processing.
For more details, see the Drools Module Reference and the Mule's Mouth blog posts on integrating a rules engine into Mule.
Fine-Grained Class Loading Control and Plugin Packaging
Applications sometimes run into library version conflicts, where the application requires a version of a class that is different than one provided by Mule. Now Mule gives you that control, enabling you to override default classloading.
This flexibility also extends to class loading within a plugin. You can have the same fine-grained control over class loading within a plugin as is available to an application. For example, a cloud connector can bundle a third-party library that it's been tested with (that is, a library different from one that Mule provides) and declare a preference to load the third-party version.
Find out more at Classloader Control in Mule.
New "Retry Until Successful" Message Processor
Mule 3.2 adds a new new message processor called until-successful to its list of more than 20 message processors. You can use the until-successful message processor to retry an operation until it succeeds. For example, you can configured it to send a message to an outbound endpoint until the send succeeds.
The new message processor is described further in Using Message Processors to Control Message Flow.
Simplified Data Source Configuration for JDBC Transport
Mule 3.2 simplifies the way you specify a data source for the JDBC transport. Instead of defining the data source using Spring beans, you define it with a simpler data-source element.
See the Data Configuration section in the JDBC Transport Reference for details.
Enhanced Localization
Mule 3.2 enables the localization of text in the management console user interface. Now you can localize the text that users see in the management console UI in addition to the text of error messages generated by the Mule server.
For further information about localization in Mule, contact your MuleSoft sales representative.
Bug Fixes
Mule 3.2 also includes fixes for over 80 bugs. Details can be found in the Release Notes. As usual, several of these were patches submitted by the Mule user community and we thank you for your contributions to making Mule a great product!
| Your Rating: |
Thanks for voting! |
|
|
Please Wait |
Results: |
|
26 |
rates |
This page
Other pages
Account
Administration