Testing Anypoint Studio 3.5.0 and Mule ESB 3.5.0

Today I've been playing with the new Anypoint Studio (formerly known as MuleStudio) that was released last week. Among many features I'd like to highlight a couple that I regard very useful, apart from this, Studio has gained a lot in usability and user experience.

WebService Consumer Element

This is a new feature for MuleESB 3.5.0 and it has a really nice integration with studio. Traditionally, in order to consume a SOAP web service from Mule, one would have needed to either generate a Java-based client or deal with raw SOAP XML payloads. Now, by simply specifying a WSDL, studio helps us presenting the available bindings and ports. Finally, thanks to Data sense and DataMapper (these features were present on previous versions of MuleStudio), you can easily populate the request and take advantage of the response.

This is how our flow would look like:

This approach is very lightweight and is by far easier than the previous approach with the CXF Module.

Request-Reply Element

Finally, request-reply has gained visual support, this element is particularly useful when we have to call asynchronous services but need to synchronously wait for the response. This element is not new but for long time has been something we'd need to go to the XML view to take advantage of. Now we have nice visual integration.

This is a sample flow demonstrating the use of the request-reply element:

This flow places a call into a VM queue (could be JMS as well) and waits for the response in the reply queue. This allows us to synchronize the call to the second flow within the first one but at the same time keep it's asynchronous nature for other consumers.

Scatter-Gather

This element allow us to run multiple routes but in parallel, and take advantage of the result, this is, an asynchronous counterpart for the existing 'All' router. Previously, this behavior could have only been achieved in an 'artificial' way, this is mixing request-reply, all and collection aggregator. Now it is available to use in a general form.

Here are sample flows showing the parallel processing of this component:

The invoked flow, sleeps for 2 seconds and produces a log statement before the sleep happens.

Database Access Reloaded

Previously, MuleESB had the JDBC transport, which was sort of un-natural for new MuleESB versions but at the time of it's release Mule didn't have features such as poll or watermark. Now, database access has been transformed into a shiny module that tackles access to databases in a very consistent and easy way. The following example shows how to run a query every 30 seconds and log the resulting records.

This module allows easy creation of parameterized queries (before these queries were also possible but somehow unnatural to produce), easy access to stored procedures and other interesting features.

Source Code

The following snippet is the XML source for the previous examples that demonstrates a more comprehensive view of the settings applied to the components:

Final Words

Studio and Mule 3.5.0 are very promising versions of this integration platform. It has a great deal of features that are not 'visual' but extremely important for our integration architecture, I.E. shared domains, which allows us to split our integration into multiple apps and be able to internally communicate between them.

jDTO Binder gains experimental support for compile-time config validation

One of the most frustrating things that emerge when working with a framework is misconfiguration, specially if we find out of this misconfiguration on runtime or worse, after moving the application into production.

Normally when frameworks suffer this kind of weakness, developers might decide to create IDE-specific plugins or extra tooling to prevent unwanted and unnoticed runtime misconfiguration. The object to object mapping framework I've developed (jDTO Binder) is a great tool but sadly suffers from this issue so, as part of release 1.5, I am currently developing a set of tools that aim to ease the development. The first of this tool is a compile-time annotation processor that can validate the configuration for a given DTO.

Annotation Config Validation

The great thing of compile-time annotation processors is that are able to integrate with any IDE and they're able to have the build failing if a misconfiguration is detected.

Here is how it looks jDTO Binder compile-time verifier out of the box in Netbeans IDE 7.2:

Currently this is experimental and I'm working on the idea, the specific validations that will be performed and the way this validations should manifest will emerge on the development of this idea and for the time being very experimental and limited support is implemented but hopefully it will plot on improved productivity.

In the current state the compile time verifier functionality checks and prints compile-time warnings when the source property of a given DTO field is mistyped and also encourages the user to place annotations on getters instead of on fields following a performance suggestion showed on the official documentation.

jDTO Binder 0.7 Released

I'm proud to announce the release of version 0.7 of jDTO Binder, the java framework to populate DTO objects easily.

This release includes the latest bugfixes and two new features:

Default configuration file.

The jDTO framework has the "convention over configuration" philosophy and therefore a new convention was introduced: If there is a package resource called jdto-mappings.xml on the default package, then it will use that configuration file instead of the annotations config, so now, if you're using CDI, you have the option to map your DTOs using an XML configuration file.

Read / Write Maps

The framework has gained the ability to read and write maps, so now implementations of the java.util.Map interface can be used to populate DTO's and can be populated out of objects.

The following code snippets demonstrates how to use this feature.

Map from object:

SimpleEntity entity = new SimpleEntity("myString", 23, 34.45, true);

HashMap<String, Object> map = binder.extractFromDto(HashMap.class, entity);


String strVal = (String) map.get("aString");
int intVal = (Integer) map.get("anInt");
double doubleVal = (Double) map.get("aDouble");
boolean boolVal = (Boolean) map.get("aBoolean");

Object from map:

HashMap<String, String> values = new HashMap<String, String>();

values.put("myString", "simpleString");
values.put("related.aString", "relatedString");

SimpleAssociationDTO dto = binder.bindFromBusinessObject(SimpleAssociationDTO.class, values);

These new features enables the users of the framework to explore new posibilites for example populating objects from properties files in a really elegant way.

jDTO Binder - Immutable DTOs

jDTO Binder 0.6 is out and with one new great feature. A really good practice in java is to minimize mutability of objects and with this you gain thread safety and also you can optimize memory by creating an instance pool; jDTO Binder can now instantiate objects by using a constructor other than the default and therefore making possible immutable DTO's

In order to take advantage of this feature, your DTO class should have one or more constructors with arguments and none default constructor. Also since some limitations of the Java Reflection API you need to configure each constructor argument to specify which will be the source value.

The following is an example of an immutable DTO:

public final class SimpleImmutableDTO {
    private final String firstString;
    private final String secondString;
    
    //make this the DTO constructor.
    @DTOConstructor
    public SimpleImmutableDTO(@Source("myString") String firstString, @Source("related.aString") String secondString) {
        this.firstString = firstString;
        this.secondString = secondString;
    }
    
    public SimpleImmutableDTO(String firstString, String secondString, String thirdString) {
        this.firstString = firstString;
        this.secondString = secondString;
    }
    
    public String getFirstString() {
        return firstString;
    }

    public String getSecondString() {
        return secondString;
    }
    
}

Immutable DTOs can take advantage of all of the features regular DTOs can except for "transient" constructor arguments which at the time doesn't make sense to me.

Also this feature is enabled for XML configuration:

<dto type="com.juancavallotti.jdto.dtos.SimpleImmutableDTO">
    <immutableConstructor>
        <arg type="java.lang.String">
            <source name="myString" />
        </arg>
        <arg type="java.lang.String">
            <source name="related.aString" />
        </arg>
    </immutableConstructor>
</dto>

jDTO Binder - New Logo and new Value Mergers.

As I'm currently with no computer at all, I could make just little progress on jDTO, but today I'm proud to announce that I have created for it the logo, the same is also open source svg:

If it should have a meaning, then the arrows could mean the data transportation and the letters are self-explained.

Another new feature that will be seen on release 0.5 is a new "age" value merger, if a source field is a Date or Calendar instance, then it will calculate the time between now and the given date in different time units: Years, weeks, days and any user-defined number that represents an interval of milliseconds.

I want to thank my friend Gustavo Genovese for reviewing my code and helping me with a nice solution for compensating leap years with a fixed interval.

Please any suggestions with the logo or any contribution of any kind will be greatfully received.

You can find an updated version of the jDTO book here. (It will be always updated since it points to my master branch).