Appendix B. Differences between Mule 1.4.x and Mule 2.0.x
This appendix presents a high-level overview of the differences between Mule 1.4.x and Mule 2.0.x. If you want more information on this subject, the Mule site also provides information about what’s new in Mule 2.0:
We start with the biggest change, which is the way you configure Mule. If you’re experienced with Mule 1.4, you probably know that Mule 1.4 used a DTD to validate the configuration and provide rudimentary code completion. In Mule 2.0, this is changed to an XSD-based configuration.
XSD-based configuration
With the XSD-based configuration, it’s easy to create Mule configurations. You define in your XML header the schemas you wish to use, and you get automatic code completion in modern IDEs such as Eclipse, Netbeans, and IntelliJ’s IDEA. Let’s look more closely at this change in configuration. Listing B.1 shows an empty Mule 1.4.x configuration.
Listing B.1. Mule 1.4.x-based empty configuration file
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mule-configuration PUBLIC
"-//MuleSource //DTD mule-configuration XML V1.0//EN"
"http://mule.mulesource.org/dtds/mule/mule-configuration.dtd">
<mule-configuration id="Mule_1.4.x_configuration" version="1.0">
</mule-configuration>
This configuration in Mule 1.4.x defines the DTD to use for this configuration file. The DTD contains all the descriptions of the elements you can use in the configuration. Although this provides some basic autocompletion, Mule 2.0.x has switched to using XSDs, which provide much more autocompletion functionality in the IDEs than the DTD does.
Let’s look at the same empty configuration in Mule 2.0.x; see listing B.2.
Listing B.2. Mule 2.0.x-based empty configuration file
<?xml version="1.0" encoding="UTF-8"?>
<mule:mule xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mule="http://www.mulesource.org/schema/mule/core/2.0"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
http://www.mulesource.org/schema/mule/core/2.0
http://www.mulesource.org/schema/mule/core/2.0/mule.xsd">
</mule:mule>
This XML file uses namespaces and references some external XSDs. These external XSDs contain all the information the IDE needs for autocompletion and which Mule 2.0.x uses internally to validate your configuration. Note that not all the elements are defined in a single file, as is the case with Mule 1.4.x; the Mule configuration is now split out over multiple XML schemas. For instance, file-specific elements are located in the http://www.mulesource.org/schema/mule/file/2.0/mule-file.xsd schema. For more information on these elements, see appendix D, where we list the most important schemas you can use to configure Mule 2.0.x.
Before we examine the configuration of the endpoints, let’s quickly look deeper into the differences between a basic Mule 1.4.x configuration and a Mule 2.0 .x configuration. In Mule 1.4, you configure services by using a mule-descriptor. Listing B.3 shows how to configure a service in Mule 1.4.
Listing B.3. Mule 1.4.x mule-descriptor configuration
<mule-descriptor name="simpleUMO"
implementation="appendixB.SimpleComponent">
<inbound-router>
..
</inbound-router>
<outbound-router>
..
</outbound-router>
</mule-descriptor>
This listing contains the basic XML elements you use when you configure a mule-descriptor in Mule 1.4.x: You define the implementation class, an inbound router that contains inbound-router elements, and an outbound router that contains outbound-router elements. This is also changed in Mule 2.0.x; listing B.4 shows the same configuration, but using the Mule 2.0 .x elements.
Listing B.4. Mule 2.0.x service configuration
<mule:service name="sample-service">
<mule:inbound>
..
</mule:inbound>
<mule:component class="appendixB.SimpleComponent"/>
<mule:outbound>
..
</mule:outbound>
</mule:service>
The configuration for Mule 2.0.x is much the same as for Mule 1.4.x. All the elements from listing B.3 are still present—they’ve just been renamed. Another interesting thing to notice in listing B.4 is the sequence in which the elements are declared. In Mule 2.0.x, the elements are declared in the sequence in which a message is processed by this service. First the message is processed by the inbound element, then the message is processed by the component, and finally the message is processed by the outbound element.
Now that we’ve looked at the basic difference between the Mule 1.4.x configuration using a DTD and the Mule 2.0.x configuration using a number of XML schemas, let’s examine the next big change: the way you can configure endpoints.
Transport-specific endpoints
In chapter 2, we explained how you can configure endpoints in Mule 2.0.x. We showed that you can use a specific endpoint URI to configure an endpoint or use the transport-specific endpoints. The transport-specific manner of endpoint configuration wasn’t available in Mule 1.4.x, but it provides an easy way in Mule 2.0.x to configure endpoints, because it works with XSD-based code completion.
Changing from URI-based endpoints to the transport-specific endpoints isn’t difficult, as we show in the next example. Let’s start by looking at an SMTP endpoint that can be used to send mail using an SMTP server:
smtp://mule:[email protected]?subject=HelloWorld&[email protected]
If you’ve worked with Mule 1.4.x, this will look familiar. Let’s now look at this endpoint in Mule 2.0.x. It’s configured in Mule’s SMTP schema, which you can find here:
The previous endpoint now looks like this:
<stmp:outbound-endpoint
user="mule"
password="pass"
host="smtp.gmail.com"
subject="HelloWorld"
to="[email protected]"/>
You specify the same endpoint but now use the SMTP-specific endpoint, which you can create using code completion. In Mule 2.0.x, transport-specific endpoints are provided for almost all the transports.
In addition to the XML configuration and endpoint changes, there are a couple of internal API changes that may affect you.
API changes
If you’ve written your own Mule 1.4.x components or extended the components provided by Mule 1.4.x, you’ll have to rewrite them to work with Mule 2.0.x. The main reason is that the package names and some internal classes have been renamed or moved to different locations. The primary API changes are as follow:
- Removed UMO prefix— Many interfaces in Mule 1.4.x are prefixed with the UMO name. In Mule 2.0.x, this UMO prefix has been removed.
- API moved to a different package— In Mule 1.4.x, the API was mostly contained in the org.mule.umo package. In Mule 2.0.x, the API has been moved to the org.mule.api package.
- Transport providers moved— The name of the package where the providers are located has also been changed, from org.mule.providers to org.mule.transport.
- General changes in API— Internal API changes have been made to a number of classes.
These changes shouldn’t be a reason not to switch to Mule 2.0.x. The issues that arise from them are usually easy to solve by changing to the new classes and interfaces.