End to End Example - A Mule 3.5.0 App with Domains

Recently, I've added to my gradle plugin for building mule apps the ability to build domain-based (A.K.A. mule shared resources) projects. While the plugin gains maturity and is getting ready for prime time, I've started eating my own dog food with it and as a result I've produced a sample application that uses some features of Mule 3.5.0 Community Edition. Please checkout the instructions on how to run the sample project.

The Use Case

Let's imagine that we have in our premises a database of cooking recipes, but we have the requirement of exposing a REST API so users can check available recipes and post new ones.

This is a simple use case but we have some additional requirements as well as some constraints:

1. The Backend APP needs to have the less down time possible.
2. We need to be able to change the API since it will evolve and gain new features.
3. We need to be able to scale the backend so when thousands of users access it at the same time it does not become extremely unresponsive.
4. Upon an upgrade in the backend it would be desirable that users can still post recipes. 

Implementation

For the implementation of these requirements, I've decided to divide and conquer, this is create two modules:

1. API Module: This is responsible for receiving requests through HTTP, and adapt them in a way the backend can understand and process them. Also is responsible for representing appropriately the information provided by the back-end.
2. Backend Module: This module is responsible for accepting requests, processing them and returning the results.

The following is a diagram of the implemented architecture:

The communication between the modules is leveraged through JMS, initially as the app has only a couple of users, we don't want to have a separate JMS Broker, so we'll leverage an embedded broker, but this is easily upgradable to an external broker without making any changes to the Modules.

Backend Implementation

For implementing the backend (source code) I've leveraged the brand new Database Module. This module allows to easily run parameterized queries. The backend module's main interface are JMS queues, and for the operations that require a response, we'll take advantage of mule's automatic reply when ReplyTo-type headers are present.

API Implementation

For implementing the front end (source code), I've used APIKit, this module allows us to easily expose a REST-like API out of a RAML file, so before starting the implementation I went to the Anypoint Platform website and created a RAML File with the API Editor.

In order to implement the requirement of accepting recipes even if the backend is missing I used a Asynchronous approach, this is the create operation returns a Task ID, and it's up to the client to check if the task has been completed, normally it is desirable that the APP itself notifies the clients when their tasks have been completed, nevertheless due to the nature of the HTTP transport, this is not possible.

There are some tasks that require a synchronous response, these are: check the list of recipes and check the status of a given task. These calls have been implemented with JMS queues as well, but leveraged mule's request-reply router for synchronizing these calls, so if a redeployment of the backend happens in a reasonable time-frame, requests from the client will last a little longer but not fail.

Conclusions

The use of Mule ESB 3.5.0 allowed me to implement this use case in a matter of a couple of hours. In particular this version with the ability of sharing the JMS connector I can easily do Inter-APP communication (which is easier in Mule Enterprise by sharing a VM connector) and still have the ability to scale, add more servers, cluster etc.

Migration of a Maven-based project to Gradle

Recently I've started noticing that some of the big names in java open source have migrated their builds from Maven to Gradle.

To my own development needs, Maven was good enough, so for some time I remained sceptic with Gradle and carried on working with the former. Today I gave Gradle an opportunity and so far I find it has been amazing.

As with any new technology, to gain adoption you can't just simply be "better" because for most of the people, changing stuff require a lot of effort, so marginal improvements are simply not strong enough, you need to be radically better. I believe the creators of Gradle had this in mind when they created this tool.

The learning Curve

Any tool has it's own learning curve so, before I even tried to do something with it, I started reading the documentation. At the very beginning, it seemed to me that Gradle was just a pretty redo of Apache Ant but written in groovy and I started wondering why I was wasting my time on that. 

My advice for those who get the same initial feeling is: carry on reading, it's going to get good really soon.

After reading the quick-start chapter of the Gradle documentation I was able to see the power of this tool but still I had the taste that it was something equals to Ant but prettier and empowered by the fact that the builds are scripted in Groovy. The breakthrough came to me when I started reading about the so called "plugins", these plugins allow a full set of build conventions (like maven plugins) but are extremely simple to configure (unlike maven plugins).

After a little more than two hours of reading, I already had a couple ideas on how to use Gradle for building my apps, so I started migrating a simple tool I have for my day-to-day work. I'd need to say that the learning curve is very smooth.

The project I migrated

To start playing, I took one desktop-app I created to help my day-to-day work, this is just a simple Java based app, with Swing UI but it has an embedded instance of Mule ESB. This app was distributed as a zip file that anyone could execute with two clicks. The following is the pom.xml file I had to build and distribute the app.

I used an archetype that allowed me to easily get the executable file with its dependencies for running, also I had configured the project so it creates a zip file that I can distribute without much effort.

In order to start migrating the app, first I needed to create the Gradle build file, this is a groovy script called "build.gradle", this file is our new "pom.xml".

This is how the final file looks:

The first line of the script applies the java plugin to the project, this imports a predefined build configuration that applies to common java projects.

My project directory structure already had the "/src/main/java", "/src/main/resources", etc that typical maven projects have, I am happy with that structure and I simply didn't wish to change it, fortunately the creators of the java plugin liked these conventions as well and made them to be their standard.

The second line of the script applies the "application" plugin, this is a fantastic plugin that helps you distribute standalone java apps.

Next, I define the naming properties of my project, this is the same concept of the coordinates we need to define for each maven project, the main difference is that these are optional. The name or the artifact will be taken from the name of the folder where the project is contained.

Then, I defined as extended properties the versions of each of my dependencies, my first attempt was to not use the 'ext.' object but Gradle printed a warning when building saying that this is deprecated, It was not obvious to me how to get this done properly, so I took a sneak peak on the spring framework build script to get some inspiration.

After that, I've defined the libraries my project depends on. Gradle provides a more concise syntax for defining this as well but I sticked with the little verbosity that I'm used to because of my maven background.

I configured the main class as a project property as well, this is just required for the application plugin to know what is the entry point of the app.

Finally, I've configured my repos. Since Gradle can use maven repos (but it is not maven) I need to specify that I want the maven central repo to be included, as well as my local repo (.m2/repository), and a couple of other repos I normally configure.

That is all for the migration of my build, let's now take a look at how to use it!

Building and Distributing

To build the project I can simply run:

$ gradle build

The 'build' word is just one of the tasks the java plugin for Gradle has. We have many options i.e. clean, test, etc, just like we would expect from Maven out of the box. For a list of tasks we can run, please take a look at:

Gradle Java Plugin

Also I can use tasks from the application plugin to run my app:

$ gradle run

And this runs the app from the defined main class. This application plugin has also some very interesting options for me to distribute this app, for example I could create a distribution zip file, tar file, and even os-specific startup scripts, for more information on what you can do with this plugin, just take a look at:

Gradle Application Plugin

Conclusions

This configuration is just scratching the surface of what you can do with this very powerful build system and also since this is just my first ride, there should be things that I could have done better, for example maybe there is a way to define the default set of repositories for each build.

My overall feeling with this build system is that the configuration is more concise, and making complex configurations that would normally take creating Mojos and a lot of reading, can be simply done with a small amount of groovy.

Even though I din't get the exact same result in my distribution, I like what I had out of the box. My previous distribution was based as well on accepting what I got from an archetype, so in this case, I'd need to say that what comes out of the box is good enough.

What I didn't like is that maven does not regard itself as a mere build tool but it is aimed to standardize projects, I've got the feeling that this idea has been lost on Gradle.

Gradle has surprised me with its simplicity and yet it looks like you can tackle simple and complex things in the same way, this is, of course, thanks to the pre-built plugins, that are, I believe, what makes the difference for the adoption of this tool.

Apache CXF Working with Spring

These days I have been playing with Apache CXF, which is great open source java-based library for creating both SOAP and REST web services. CXF is a great library, specially if you are using the Spring Framework and despite the outdated and inaccurate documentation, I managed to make it work and here is how to do it.

I have assembled a sample project which is on my GitHub repository.

A Small Introduction

CXF is designed with a very flexible architecture based on interceptors, this architecture allows the developer to make CXF work with different types of front end technologies such as JAX-WS, JAX-RS, CORBA and more!

CXF is also very friendly with the Spring framework so it is (or at least should be) very easy to integrate in this kind of applications.

Working with Maven

CXF artifacts are published on the central maven repository, so first of all, you need to add the dependencies into your project:

<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxws</artifactId>
    <version>${cxf.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-frontend-jaxrs</artifactId>
    <version>${cxf.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.cxf</groupId>
    <artifactId>cxf-rt-transports-http</artifactId>
    <version>${cxf.version}</version>
</dependency>

At the moment of writing this post CXF latest version is 2.6.2. Also you need to include dependencies for the Spring Framework, please refer to the sample project for these.

Spring Configuration

To start with this little how to, I created a service class with has mixed JAX-WS and JAX-RS annotations. This makes easy to export the same functionality as SOAP and REST web services:

@WebService
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
public interface MyWebService {

    @WebMethod
    String doSomeWork(String work);
    
    
    public String beRestful(String name);
    
    
    @WebMethod
    public ArrayList<Customer> findCustomers(CustomerRequest request);
}

And the implementation:

@WebService
public class MyWebServiceImpl implements MyWebService {
    
    @WebMethod
    @Override
    public String doSomeWork(String work) {
        return "Doing some work with this: "+work;
    }
    
    
    @Override
    @GET @Path("/beRestful") @Produces("text/plain") //REST Annotations
    @WebMethod //SOAP Annotations
    public String beRestful(@QueryParam("name") String name) {
        return "Your name is: "+name;
    }
    
    
    @WebMethod
    public ArrayList<Customer> findCustomers(CustomerRequest request) {
        
        
        ArrayList<Customer> ret = new ArrayList<Customer>();
        
        Customer customer = new Customer();
        
        customer.setCustomerName(request.getName());
        customer.setMembershipLevel(request.getMembershipLevel());
        customer.setCustomerSince(new Date());
        
        ret.add(customer);
        
        return ret;
    }
    
}

The Customer and CustomerRequest classes are pretty simple and therefore not shown here, please refer to the sample project for the source code.

These exposes three methods through SOAP and one through REST, CXF has its own XML namespaces for JAX-WS and JAX-RS, the header of the applicationContext.xml file looks like the following:

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:jaxrs="http://cxf.apache.org/jaxrs"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
          http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd/spring-spring-context-3.1.xsd-3.1.2.RELEASE.xsd
          http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util-3.1.xsd
          http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
          http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd
">

CXF also has its own configuration files included inside the JAR files, even though these files look empty, the documentation suggests to include them so here are the lines for it:

    <!-- import cxf webservices -->
    <import resource="classpath:META-INF/cxf/cxf.xml" />
    <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

Finally, we need to declare the bean we just created as a Spring Bean and reference it in a SOAP and a REST endpoint:

    <jaxws:endpoint 
        id="mywebservice" 
        implementor="#webserviceImpl" 
        address="/myws" />
    
    
    <jaxrs:server id="myrestservice" address="/rest">
        <jaxrs:serviceBeans>
            <ref bean="webserviceImpl" />
        </jaxrs:serviceBeans>
    </jaxrs:server>
    
    <bean id="webserviceImpl" class="com.juancavallotti.cxfdemo.MyWebServiceImpl" /> 

The last ingredient is configuring the CXF servlet in our web.xml file.

Configuration of web.xml

The configuration of this file is pretty standard, first I have declared the CXF servlet and map it to the /ws/* URL pattern, and then I just declared the standard listeners for the Spring Framework to work on a web environment.

    <!-- the cxf servlet -->
    <servlet>
        <servlet-name>cxfservlet</servlet-name>
        <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>cxfservlet</servlet-name>
        <url-pattern>/ws/*</url-pattern>
    </servlet-mapping>
    
    <!-- spring context and request listeners -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
    <listener>
        <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
    </listener>

Running the example

After following these steps we are ready to run the example application, if you have forked or cloned the sample application just run: $ mvn tomcat:run command line and after the startup, point the browser to: http://localhost:8080/CxfDemo/ws, you should see a very simple webpage that informs the webservices running on the CXF servlet and links to the WSDL and the WADL:

Conclusions

CXF is a very powerful and complete framework for exposing services as web services, I think it is the natural choice if you want to enable web services in your spring application. Be aware that you will find outdated documentation and be sure to read the documents about the architecture before planning to reverse-engineer the framework or else you'll find the task rather frustrating.

Concurrency Tests with JUnit

Sometimes in the life of a programmer, a concurrency test is needed to check if a given framework function doesn't break the data when used simultaneously by different threads.

JUnit provides some sense of AOP by using the @Rule annotation which allows us to modify how a given test runs. I was trying to create these kind of tests for my DTO framework (jDTO Binder) and inspired by this blog post, I created a test rule that allows the programmer to specify the number of threads to run a given test case and collect some little statistics about the running time of the test.

First of all I created an implementation of TestRule.


The previous gist may be used by anyone who would like to create concurrency tests and dont care that much about the execution exceptions but rather the overall results of the tests.

The code does the following:

1. Create a ThreadPoolExecutor with the size of the tests, you may use other executor implementation if you wish so.
2. Create a CountdownLatch to make sure all the tests start almost at the same time.
3. Create a CountdownLatch to block the test thread until all tests finish.
4. Add all the required tasks to the executor, which will wait until all all have been scheduled.
5. If some test fails, then a flag will be set to true.
6. Log the execution time.
7. Fail the test if some of the threads had an exception.

So at this point we're ready to use the rule on a simple concurrency test:


And as simple as that we have a concurrency test with some statistics on the running time.

Java architecture with DTOs

The DTO Discussion

The DTO (Data transfer objects) pattern is really useful if you intend to achieve a clean separation between the service layer and the presentation layer of the application. DTOs are part of the service layer API and therefore something that is best to have than not to.

DTOs also serve another purpose: Adapt model values, which in most cases are normalized, to view-friendly values, which most of the time presents particular values from an object graph and also calculated values.

Very often, applying the DTO pattern in a given architecture is not an easy task, you earn an application easy to maintain  by spending a lot of time (shallow) copying data from one object to another.

One solution for the data copy problem can be found by using a framework, in this case jDTO Binder. jDTO Binder makes easy for the programmer to achieve some tasks:

• Receive form values and copy them to target business objects.
• Create lists with data from particular properties of an object graph.
• Add to those lists calculated values.
• Change the format of the data to be more appropriate for display or network transmission.

I've taken the time to create a sample maven project with a very popular setup: Spring Web MVC, Spring Framework and Hibernate. Although you can use this project as a starting point to build a web application with this technologies, this project incorporates jDTO Binder into its ecosystem and demonstrates how it makes your life a lot easier.

To run the project, just unzip the file, open the terminal and type the following commands:

$ cd <path to the unzipped folder>
$ mvn clean install tomcat:run

Project Description and Walkthrough.

Required Skills: To go through this project, basic Spring Web MVC knowledge is required. Even though the important part is written on the service layer, Spring MVC and Spring Context knowledge helps a lot to put all the pieces together.

The DTOs

The following snippets shows the DTOs this project uses and its purpose:

public class PizzaDTO implements Serializable {
    
    @Source("id")
    private Long pizzaId;
    
    
    @Sources(value={@Source("pizzaName"), 
        @Source("price")}, merger=StringFormatMerger.class, mergerParam="%s ($ %.2f)")
    private String description;
    
    private double price;
    private int rating;
    ...
}

The first DTO to analyze is the PizzaDTO, this one is intended to serve in a listing of available pizzas. It has a description attribute which is intended for display and is created from the pizza name and the pizza price in a formatted string.

public class PizzaOrderForm implements Serializable {
    
    @NotEmpty //validation annotation
    @Source("whoOrderedName")
    private String customerName;
    
    @NotEmpty //validation
    @Source("contactNumber")
    private String customerPhone;
    
    @NotEmpty //validation
    private String customerAddress;
    
    @Size(min=1) //validation
    @DTOTransient
    private List<PizzaDTO> pizzas;
    ...
}

The second DTO is really the model of a form to take a pizza order, it does not only have DTO binding annotations but also standard JSR 303 bean validation annotations so the data can be validated automatically.

public class OrderDTO implements Serializable {
    private static final long serialVersionUID = 1L;
    
    private Long id;
    
    @Source("whoOrderedName")
    private String customerName;
    
    private String customerAddress;
    
    @Source("contactNumber")
    private String customerPhone;
    
    @Source(value="orderDate", merger=DateFormatMerger.class, mergerParam="MM/dd/yyyy hh:mm")
    private String orderDate;
    
    @Source(value="pizzas", merger=SumMerger.class, mergerParam="price")
    private Double orderPrice;
    ...
}

Next on the line is a DTO intended for a list of pizza orders, it contains most of the data the pizza order has but also it calculates the price of each order so you don't have to do it manually or save the amount in an extra field on your database table.

The Service Class

Now we've got to the interesting part, how the service layer takes advantage of these DTOs to make your life easier. The following is the declaration of the PizzaOrderService, I'll show separately the implementation methods so I can give a little more explanation of each without having you to scroll up and down repeatedly :).

@Service
@Transactional
class PizzaOrderServiceImpl implements PizzaOrderService, Serializable {

    private static final long serialVersionUID = 1L;
    @Autowired
    private HibernateTemplate hibernate;
    @Autowired
    private DTOBinder binder;
    @Autowired
    private Validator validator;
    
    ... //implementation goes here
}

This is a normal service class, it is transactional because it interacts with hibernate, it has injected an instance of the very helpful class HibernateTemplate, also has injected an instance of the DTOBinder (which is configured as a spring bean in applicationContext.xml), finally the JSR 303 standard bean validator to perform validations on objects (also declared as a spring bean).

This class is serializable because it may be serialized for example in a web session.

    @Override
    public List<PizzaDTO> listAvailablePizzas() {

        DetachedCriteria criteria = DetachedCriteria.forClass(Pizza.class);
        criteria.addOrder(Order.asc("pizzaName"));

        return binder.bindFromBusinessObjectList(PizzaDTO.class, hibernate.findByCriteria(criteria));
    }

This method queries the database for pizzas, and returns the list as a list of PizzaDTO by taking advantage of the DTO Binder. Please note that if we hadn't used the DTO framework, we would have had to iterate over the list returned by hibernate template and build the DTO instances ourselves by setting and formatting the values; all is taken care by the framework.

    @Override
    public boolean placeOrder(PizzaOrderForm form) {

        //may validate with hibernate validator
        if (!validator.validate(form).isEmpty()) {
            return false;
        }

        PizzaOrder order = binder.extractFromDto(PizzaOrder.class, form);


        order.setOrderDate(new Date());
        order.setPizzas(new ArrayList<Pizza>());

        for (PizzaDTO pizzaDTO : form.getPizzas()) {
            Pizza pizza = hibernate.get(Pizza.class, pizzaDTO.getPizzaId());
            order.getPizzas().add(pizza);
        }

        hibernate.save(order);

        return true;
    }

This method may look familiar to you if you had to build functionality for adding data to a database in the past :). In this case we get a PizzaOrderForm as a parameter, use the validation framework to check the data, extract the form values into a proper business object using de DTO framework, set data that was not inputted, relate the order with the actual pizzas and finally persist the order!

That's a lot for the few lines of code we've written! If we hadn't had use the DTO framework, then we would have had to manually copy each property of the form into the appropriate property of the business object, which can take several more lines.

    @Override
    public List<OrderDTO> listOrders() {
        DetachedCriteria criteria = DetachedCriteria.forClass(PizzaOrder.class);
        criteria.addOrder(Order.desc("orderDate"));

        return binder.bindFromBusinessObjectList(OrderDTO.class, hibernate.findByCriteria(criteria));
    }

The last method is much the same as the first one so no further discussion is needed.

A couple of final words.

As we may have noticed, this architecture is rather simple but full featured. It uses data validation, transactional behavior and the code is kept really small and clean thanks to the DTO Binding framework.

When used the right way, DTOs are a very powerful tool and makes our application even more bullet-proof by isolating completely the database code (persistent objects included) from the presentation tier.

Another thing to note is that, if you need to change from where data is acquired, add or remove fields is just a matter of configuring the DTO object and nothing else! Compare this to the traditional approach in which you would have added the extra field and then going through each loop when you populated the DTO and add the extra data copy operation.

Web Based VS Native - Mobile Application Development

I think one of the biggest challenges of mobile application development is supporting an acceptable number of devices, which have different screen sizes (and generally speaking hardware abilities), which can be a real problem because developers need to build multiple versions of the application, say one per device they want to support. The question is: is there any way around this?

Well, some would say, "just build the thing web-based", of course, this has some advantages (at first sight at least) you code it in javascript with HTML 5 and it theoretically will run on most of the devices since most of them have webkit-based web engines!  This approach has proven on the past to work really well for desktop environments, so let's listen to the story of an embedded-web app development.

The story of a mobile web development.

Say we start building the app with this approach. For now everything is working fine, we spent 3 or 4 days just coding plain html and javascript with one framework like Sencha touch or jQuery Mobile and it runs fine on the device (say iphone) emulator, then we spent 4 to 6 days coding a data layer using local storage or web SQL and finally a couple more of days testing on a real device. 

Well, let's try it on the Android emulator.... "DANG! those animations were supposed to work!, and also why the layout is so off? And this looks like an iOS app, my android users won't dig that!

After going through the first experience you realize, you need a theme engine!! and switch the theme for each device... also it would be nice to add some code to adapt the components layout for each screen size and done! after 4 more days of writing javascript your app works fine on the iphone and android, now what? My friend has a blackberry!! Well, a couple more days to build the blackberry theme...

And the story could go on and on while testing on tablets of different brands and screen sizes, but finally... why the app is so slow?? it leaves me without enough battery to make phone calls!

Well finally we wrote just one application that works (awful) on every device, and also we as developers had to deal with thinks like there's no javascript debugger on the device emulators.

The story of a native mobile app development.

After going through the mobile experience we decided to give native application development a try, so started eclipse with the Android plugin and created the user interface with the visual designer, after a couple of hours we have the same 10 screens our web app used to have, with android user experience, ok, we found we have frameworks for data storage so after two days of work we have the same app running.

Ok, now let's bring the iPhone version! We create an Xcode project, after a couple of hours we have the iPhone and iPad user interface, then by taking advantage of the data APIs build the business logic and done!, the app is ready to test on the new platform.

Same story goes for blackberry, and other mobile platforms, now we take a look at the apps, they're working fine but oh no!! we have the same codebase all over the place, in different programming languages and development environments! That's not good for sure.

Time for comparison.

After telling the two stories we had a not-so-happy ending for each. So we need to choose now!! What should we do for our mobile apps.

Well It depends of a few things: manly development costs, delivery time constraints and importance of the user experience, so let's take a look of each point for both platforms.

Development Costs.

On the one hand for a web development you need a web developer with basic knowledge of each platform on the native side, this is because even though embedded web applications are mostly wrote on javascript, you need to build and embedded app environment (or use something like PhoneGap which entails the same basic knowledge), also you need the native development environment to build and package the embedded app environment for each platform. 

On the other hand you need an application developer who has medium to advanced skills on building native mobile applications and also the same native development environments. 

Adding features to the application is relatively simple for embedded web applications while adding features to native applications would take to over and over add the same thing for each platform codebase. We can think here that since the user experiences and the capabilities of mobile devices are different, adding a feature would also be an easy thing for native but complex for web.

Another important thing is tooling, web applications have somehow basic tooling while native applications have very powerful tooling and also the ability to debug and profile the code.

So in my opinion, at the end od the day, the cost is greater for embedded web apps than native web apps even considering that the codebase is repeated.

Delivery Timing.

As the year 2012, people has a lot of experience writing web applications, we have a lot of frameworks and tools to write these things, but most of this is by taking advantage of powerful servers and helping the developers on not writing HTML and CSS, because writing HTML and CSS is a slow process! They're not meant for creating user interfaces but for creating documents, so we made a lot of things to manage achieving the look and feel of user interfaces. Even though frameworks like Sencha Touch or jQuery mobile makes creating the user interfaces rather simple, you still have the three to four days time to create a 10 screens app, and then lots of time and hacks to make it look native for each platform.

With the availability of developer tooling, native applications can be built very quickly, the pitfall is having to deal with lots of programming languages, a not-so-skilled developer could find writing code on different programming languages a hard task, but let's face it, data-driven mobile apps actually entails caching data locally and sending it to (or reading from) a server, with some documentation and examples the logic should be done in a couple of days.

So speaking of time, for web apps, you could have say three developers working on the same codebase, but truth is, the more developers are working on the same codebase the more they get into each others way.

If you have three targeted platforms and three developers you can start the development for each platform at the same time and see it code-complete in 4 to 6 days.

So in my opinion, at the end of the day, you can make delivery rather quicker if you pick native development since the tooling is better and you can have people working independently, with proper project management all the platforms will be finished mostly at the same time.

User Experience.

Finally, the user experience, every platform has its own user experience, meaning for touch gestures, ways of navigating through screens and so on, for example android apps have a back button and a home button which removes the need for applications to provide a "software" navigation button, iOS phones doesn't have this button but all the applications have the same set of ways for navigating.

Also widget layout, colors, sizes and icon meanings are different, also you may have to provide localization and so on. This on an embedded web app will take lots of lines of javascript, and the more lines of javascript you write, the more battery you consume which is also a really bad thing for user experience.

Finally, HTML user interfaces need to be parsed, and rendered by a relatively slow processor so the user would notice some degree of unresponsiveness while interacting with the application.

Native apps doesn't have this advantages, they are built for each platform and for that, you just build the user experience the platform has and later you don't need to adapt it for another platform (maybe only phone/tablet adjustments), so they run fast, very responsive and with low battery consumption.

Conclusion

At this point I hope you're more than convinced that creating embedded web apps for different mobile devices has only the advantage of one single codebase, which is also a drawback because on different platforms things are different. Taking the approach of creating unified user experiences will result on confusing the user and making him to learn new things while he only wants to get the task done; this only works for a little set of apps that has really well-known user interface interactions (like facebook).

In my opinion, building native apps is way better than building embedded web apps, specially thinking on the user experience.

It would be really nice to have a serious scientific study for this, but at least for me, I'm a lot more skilled for web development than native development and with all that, it takes me a lot less time to build the same app native than web based.

Best Web Framework for Liferay Portlet Development

Over the past months I've tried several web frameworks for portlet development on the liferay community portal.

The options I've tried are:

• The framework liferay provides. (MVC Portlet, Alloy UI)
• Spring Portlet MVC
• Vaadin
• Java Server Faces (Portletfaces and Primefaces components)
• Java Server Faces (Portletfaces and IceFaces components)
• Apache Wicket.

In my opinion, I would rate these frameworks in the following way:

1. JSF Primefaces
2. Spring Portlet MVC
3. Vaadin
4. Liferay Framework
5. JSF IceFaces
6. Wicket.

This is the discussion of each:

JSF Primefaces

This is the one I found best, easy to configure, most of the components working out of the box, and easy spring integration. The con is, if you're used to JSF 2 and greater you'd find some missing features which are kind of important like view scoped managed beans and you loose the ability to send parameters over EL (this is because of the spring integration). But in general terms this framework fits great for general portlet development.

Spring Portlet MVC

This framework really gets along with the portal and is the ideal thing if you like to code tons of javascript and have fine grained control over everything. The con is the increased development time and if you have a project with lots of portlets then you'll have a lot of xml files.

Vaadin

Vaadin does a great job also for portlet development most of the components work out of the box, but it has some annoyances: 

• Every time you change something you need to re deploy your portlet.
• You need to have the same vaadin library you're developing deployed on your portal which may cause problems with older vaadin portlets.
• Compile-time weaving for spring integration.
• Some features mising.

Liferay Framework

This framework works really well on liferay, but is really a developer nightmare, not well documented, lots of javascript and java code, difficult to integrate with your own spring context. In general terms, this is only well-suited for really simple portlets with no ajax support.

JSF IceFaces

This is supposed to be the best option for liferay JSF portlet development, or at least that's what the creators say, nevertheless I couldn't really make it work after several hours of configuration and web browsing, but as it is a JSF framework, the basic jsf features work well, and I think with the proper documentation this could get really good.

Wicket

Even though I love wicket and was the first option I tried, I was disappointed that it barely worked. No wicket magic for ajax support and also wicket dropped support for portlets on 1.5 so really, is not a good option for liferay.

Well, that's it with the frameworks, I hope this short review can help you to find the best framework for developing liferay portlets.

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).

jDTO Binder - Java DTO Framework

DTO design pattern is mainly used to make a clean separation between layers. The DTO objects are meant to be part of the API of each application layer. Even though they're quite good on separation, they do have some costs associated: If not well managed, you'd probably end up by having lots of them, sometimes with mostly the same attributes between one another; on the other hand you might mitigate this by making a huge DTO with lots of information but ending up with the loss of lazy loading from the persistence layer. The previous costs must be managed by the developer and there's not much a framework can do besides generating the DTO classes, which have it's own disadvantages.

One really painful thing about using the DTO pattern is that the developer must take care of copying the data from one side to another and that's where jDTO Binder framework comes in handy. This framework is also an implementation of a bigger concept which I like to call "Object to Object Mapping" or simply OOM, and this concept is vey similar to another related and existing concepts like Object Relational Mapping (ORM) and Object XML Mapping (OXM).

This framework is still under development, but is quite stable to be used in production environments, in fact it is being used successfully on production environments.

The url for the full documentation can be found here:
https://github.com/juancavallotti/jDTO-Binder/wiki/jDTO-Binder---Java-DTO-framework.

And here's how to get started:

An example project can be found for download here.

First of all, we need to add the dependencies to our pom.xml file:

<dependency>
    <groupId>com.juancavallotti</groupId>
    <artifactId>jdto</artifactId>
    <version>0.4</version>
</dependency>
<dependency>
    <groupId>commons-lang</groupId>
    <artifactId>commons-lang</artifactId>
    <version>2.6</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.6.2</version>
</dependency>

I've decided the framework shouldn't have too many dependencies, so I've picked up those which must be (IMHO) in every serious java project:

• SLF4J - So you can log the output with your favorite logger.
• Commons Lang - This library is really useful, so if you're not using it, you should!

And also the repository to get jDTO:

    <repositories>
        <repository>
            <id>com. juancavallotti</id> 
            <name>jdto</name> 
            <url>http://juancavallotti.com/maven2</url> 
            <layout>default</layout>
        </repository>    
    </repositories>

Next we need to create some classes to act as source business objects, note that jDTO uses the property accessor methods (AKA getters and setters) to read property values from source beans, you should consider this and you can take advantage of this fact because you can read information without necessarily accessing a field.

A typical person class:

public class Person  implements Serializable {
    private long id;
    private String firstName;
    private String lastName;
    private Date birthDay;
    //GETTERS AND SETTERS
}

And a bill class with it's items:

public class Bill {
    private String clientName;
    private Date billExpiration;
    private List<BillItem> items;
    //GETTERS AND SETTERS
}

public class BillItem {
    private String itemName;
    private double price;
    private int amount;
    private double taxPercentage;
    //GETTERS AND SETTERS
}

These classes are used to show some of the features of the framework.

So we're now ready to start filling out some DTO's.

First we'll take a look a the PersonDTO, this one is rather simple, but it shows some of the key features of jDTO framework, binding by convention (default behavior), formatting fields and composing one field out of multiple fields:

public class PersonDTO implements Serializable {
    
    //bound by convention
    private long id;
    
    @Source(value="birthDay", merger=DateFormatMerger.class, 
            mergerParam="dd/MM/yyyy")
    private String birthday;
    
    @Sources(value={@Source("firstName"), @Source("lastName")}, 
            merger=StringFormatMerger.class, mergerParam="%s %s")
    private String fullName;
    //GETTERS AND SETTERS
}

And finally, we use the framework to bind the data:

DTOBinder binder = DTOBinderFactory.getBinder();

//bind a person to a person DTO
Person person = SampleData.samplePerson();
PersonDTO dto = binder.bindFromBusinessObject(PersonDTO.class, person);

It's really recommended you keep the DTOBinder instance as a singleton, so for that matter, the framework already provides you this facility, you  only need to call DTOBinderFactory.getBinder() and it's all done for you.

Next, we may want to build a DTO out of a bill but this time we just want the customer name and the amount of money the bill is worth, so here is how the DTO looks like:

public class BillDTO {
    
    //bound by convention
    private String clientName;
        
    @Source(value="items", merger=SumExpressionMerger.class, 
            mergerParam="(price * amount) * (1 + taxPercentage*0.01)")
    private double billTotalPrice;
    //GETTERS AND SETTERS
}

The final application code looks like:

public static void main(String[] args) {
        
    //get an instance of a singleton binder
    DTOBinder binder = DTOBinderFactory.getBinder();
    
    //bind a person to a person DTO
    Person person = SampleData.samplePerson();
    PersonDTO dto = binder.bindFromBusinessObject(PersonDTO.class, person);
    
    System.out.println(dto);
        
    
    Bill bill = SampleData.sampleBill();
    BillDTO billdto = binder.bindFromBusinessObject(BillDTO.class, bill);
    
    System.out.println(billdto);
}

And the output is:

PersonDTO{id=1, birthday=30/10/1982, fullName=Michael Princeton}
BillDTO{clientName=I'm a Client, billTotalPrice=22.0}

This is all for this small tutorial, please feel free to submit bug reports or feature requests on the issue tracker of the github project.

How to integrate Maven, GWT and Netbeans IDE

On the past I've created a web application based on GWT and in Netbeans IDE. I have to say it was a total nightmare! The version of GWT I worked with is 1.7, now things have changed, version 2.x is here for a long time and there are many tools to work with it.

A piece of advice.

For those who want to start a new GWT project, I still encourage them to use Eclipse IDE with the Google Plugin, the sad truth is eclipse is really MUCH better to work with GWT than Netbeans and has many tools such as visual designers and wizards to do things easy and all of that. Nevertheless, if you use maven you can work with both IDE's and take the best from both worlds!

Let's get started.

First of all you will want to have some help with code editing, refactoring, creating new files out of a template and so on, to do this you want to install the GWT4NB plugin, this plugin can be easily installed on the Netbeans plugin manager or downloaded from the Netbeans page.

This plugins enables the IDE with very helpful stuff, it also works fairly well with maven and ant projects. To use ant you should download the GWT SDK and instruct the plugin on where to find it.

Maven Dependencies

Now we want to have the actual GWT libraries to start coding our application, so we need to include two important dependencies:

• gwt-user: With this dependency we have the core GWT API, we may choose the version we like but the important thing is the scope of this library, we will add this library as provided because we'll only use it when compiling gwt code to javascript, if we don't set this dependency to provided, it will end up on the final WAR making it heavier.
• gwt-servlet: We need this to process RPC requests and it isn't really used on development so we'll set the scope for this dependency to runtime.

     <dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-servlet</artifactId>
    <version>${gwt.version}</version>
    <scope>runtime</scope>
  </dependency>
  <dependency>
    <groupId>com.google.gwt</groupId>
    <artifactId>gwt-user</artifactId>
    <version>${gwt.version}</version>
    <scope>provided</scope>
  </dependency>

Now that we have the GWT dependencies and we have no more problems to compile our JAVA code, we need a way to compile the client code into Javascript. Also we need a way to start GWT development mode to be able to test our code, to do this we'll use the Maven GWT plugin.

We can hook (or not) the Maven GWT plugin into our lifecycle, but the very annoying thing of working with GWT on Netbeans (at least for previous releases) is the fact that you end up compiling the GWT client side as many times as you compile the application, and believe me you don't want to waste two extra minutes of your life for each build, so I removed the build hook.

You can fire at will the gwt client side code compilation using the goal gwt:compile of the maven GWT plugin.

       <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <version>2.2.0</version>
      <executions>
        <execution>
          <goals>
            <!-- remove this to not compile gwt client every time -->
            <goal>compile</goal>
            <goal>test</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <hostedWebapp>${project.build.directory}/${project.build.finalName}</hostedWebapp>
      </configuration>
    </plugin>  

Running and Debugging in Development Mode

Something brilliant about development mode is the possibility to change code and see the changes as soon as you reload the browser, so we obviously want the ability to do that. The maven GWT plugin provides us with two goals to start the development mode: gwt:run and gwt:debug.

If we choose to use the gwt:debug goal, then the plugin tells us the parameters to attach out JPDA debugger to the hosted mode, and then set breakpoints at will.

Pitfalls and Gotchas

There are some pitfalls and gotchas when working with GWT. The most important one is: If you plan to use a J2EE full profile container (and with it use EJBs and persistence), my advice is: Do not use GWT, or use it in a way you lookup EJBs using JNDI. This is because GWT development mode deploys the application on a Jetty server who knows nothing about EJBs and such. A better solution would be to use the spring framework, not only because it's better but the spring framework doesn't have any problem on running on jetty.

That's all for now, hope you find it helpful.