06.02.07

Validation Framework Consolidation : where are we ?

Posted in Java at 8:20 am by skoobi

A Validation Framework Consolidation JSR was started last year. Like others, I appreciate the initiative, but given that there’s not much activity around this JSR, are we going to see some consolidation in this area anytime soon ?

Anyways, just a note explaining why I think it IS a good idea to consolidate the validation frameworks :

More and more people are now pushing Domain Driven Design (DDD), which is more or less a clear re-affirmation of what a good Object-Oriented Design of the Domain (e.g. business logic) is supposed to be. Basically, DDD is what everybody learned at school while studying UML (remember those Software engineering courses : Cars, Drivers,… ?), but nobody applied because it is too easy to forget about that and focus on the technical stuff.
Aspect-Oriented Development (AOP) is slowly becoming popular because if you want to express your domain correctly, you must avoid to clutter it with technical stuff at all costs. So, that means you have to extract the cross-cutting concern ( Security, Caching, … See AspectJ) out of your code, and apply it globally using Aspects.
Validation can be seen as a cross-cutting concern that is tightly coupled with the domain logic : Validation IS business logic, but it also IS spanned everywhere in the code, at every tier : First you check the constraints using Struts2/Spring MVC built-in mechanism (Annotation, XML..), then you pass it to your business layer which does additional checks, which then passes it to the Data Access Layer (DAOs..), which also has its set of constraints (which can evolve, with time, into something that is not compatible with the constraints checked at the View/Controller level. And this doesn’t take into consideration complex applications where additional batches or gateways are created, where duplicating the validation code is the rule, not the exception.

Currently, if you do not want to duplicate the validation logic, you have to :

Either throw exceptions at the data access level (what do you do for objects that are not persisted ?) and catch these exceptions in the view. Then manually handle the exceptions to display error messages. In other words: bye bye struts2 validation framework, that does everything for you.
Either place the validation logic somewhere in the domain, and “hope” the miscellaneous developers of the various tiers will call the validation logic. If they don’t, then nothing will get validated

What would happen if such a JSR were to be implemented in all major products (Hibernate, Struts2, GWT, whatever else …) :

You would write your domain logic as usual (i.e. using DDD)
You would write your cross-cutting technical concerns as Aspects
You would use a set of standardized Java5 Annotations to specify the validation rules on the Domain Objects, as well as write a set of custom Annotations if you need more than that.
The bottom line: everything would be magically checked at every level of the application : The view technology (struts2, spring mvc) would display nicely formatted error messages without even submitting the form (AJAX…), the data access layer would throw exceptions if the constraints are not fulfilled, and the developers wouldn’t need to care about validation anymore.

The good news is that validation is now believed to belong to the domain thanks to ruby on rails ?), so this kind of design should soon be possible..

Permalink Comments

12.16.06

Java, from different viewpoints

Posted in Java at 1:56 am by skoobi

Here is a funny, satirical comment from Daniel Spiewak on Java code produced by different people (student, professor, developer…).

We can probably draw a parallel with the funny quotes about Java I previously cited.

My opinion is that every Java developer is aware that everything he does is far more complex than it should be. However, abstraction is the key foundation of Computer Science, and most people agree that C is a good abstraction over ASM and Java/.Net are good abstractions over C. So, what is the limit of abstraction ? Are frameworks, Design Patterns, Factories and new abstractions all over the place a good thing ?

What is sure is that people who start using frameworks and libraries use even more of them. So, even if it is not a perfect solution, there is something great in that.

Permalink Comments

12.11.06

J2SE 6 : will web development finally be productive thanks to scripting ?

Posted in Java, Web Development at 12:14 pm by skoobi

Sun just announced J2SE 6 and many java bloggers are relaying the information..

Something important for the web development community in this release is the support for scripting languages. In fact, the trend, that has been started with Java Hotswap, is to create tools that allow Web Frameworks to be more productive for developers.

Indeed, developers are tired of the develop / build / deploy cycle, and would prefer to work with the PHP-like develop / reload in browser development cycle. Well, scripting is a step in that direction, and would allow to :

Keep the domain layer as strongly-typed POJOs, that are unit-tested and constantly refactored to keep a good design.
Write the Web Controllers (the C in MVC) in any scripting language (the view being written in any already-existing templating language, such as JSP or Freemarker). This allows rapid development and since the view is hardly reusable anyways, it’s better to throw it away and recreate something from scratch when needed.

Efforts toward that direction have already been started, as relayed by these few blog entries and articles :

So, now the next step is to have universal support for that kind of development, and have better IDE support that will allow refactoring both in the scripted controllers and the view (JSP, Freemarker..). In fact, there is currently no way to make sure nothing is broken besides writing functional (Selenium, Canoo Webtest, HttpUnit…) tests.

Permalink Comments

12.10.06

Validation in a (Web) Application

Posted in Java at 11:28 am by skoobi

Glen has a short tutorial on how to perform validation using Spring Valang (which is part of Spring Modules, which provide additional modules to integrate external projects with Spring, like OSCache, etc..) . While it is certainly better practice to choose XML validation instead of writing Validator classes manually, I personally prefer the @Annotations approach that is possible using Webwork / Struts 2.

Not only does it make people more productive by avoiding the need to edit 5 files at the same time (The Java class + the HTML/JSP/Freemarker template is all we should need to edit while creating a web application… Take a look at Tapestry 5 ), but it also shows the validation code at the same place at the code, and thus helps to maintain both.

However, I believe both approaches are not the way to go. We all use the validation features provided by our lovely MVC frameworks because it is handy, but when you think about it, validation should be part of the domain. The domain classes should be intelligent, they should have as much behavior as possible, and validation is one of the thing the domain should provide, in order to maintain integrity. For instance, if a domain layer has 2 User Interfaces (Web, and Swing, let’s say) interacting with it, the validation rules should only be implemented once, in the domain, not twice, because the integrity checks must be centralized.
But the frameworks are not quite there yet :

Declarative (using annotations, for instance) is built into MVC frameworks and as such, are only tightly integrated to the view, not the domain. So, it requires more efforts to do validation on the domain. (Think of it as Spring MVC or Webwork validation, that automatically returns to the form and repopulates the data in case of an error VS throwing an exception that you have to handle manually)
Validation defines constraints, and as such, is best expressed declaratively. However, if one wants to check constraints in the domain, it is necessary to either programmatically do it, or use AOP (maybe coupled with Annotations) to do so. However, it is still unclear whether AOP is a good thing to implement domain features. Lots of people tend to think of AOP as a way to implement cross-cutting TECHNICAL concerns, such as security, cache, or transaction demarcation.

Has anyone ever thought about that issue ? Have you implemented (programmatic) domain validation (maybe using Hibernate Validator, which is limited to persisted classes ?) on a real-life project ? What do you think about it ?

Permalink Comments

12.09.06

Design Patterns and the Art of software design

Posted in Java at 3:02 pm by skoobi

Jurgen - whom I totally agree with - has written a very nice post about Procedural-Object programmers.
Most people tend to forget that Designing/Coding a piece of software is not about getting things to work, but more importantly, about getting things to work in an elegant way.
And the biggest problem is that it is really hard to define what “elegant” means. My personal opinion is that the Open Source world is full of very good practices that help drive the decisions. Sure, some software are crap, but looking at how Spring, Compass, Hibernate or other Java developers solve technical problems is in any case very informative.

Another problem is about designing the domain. For that part, I urge anybody to look at “Domain Driven Design Quickly” or Eric Evan’s Domain Driven Design book.

Permalink Comments

12.06.06

Java HotSwapping support and Developer productivity

Posted in Java at 9:20 am by skoobi

Java HotSwap support is being improved with each release. More information about it can be found in Jonas Bonér and Geert Bevin posts.

The goal of hot swapping is to allow the JVM to take new versions of the classes into considerations without reloading the JVM/Application.
Jonas believes it is a bad idea, but I think he refers to the ability of HotSwap to be used for AOP-like byte code instrumentation. Jonas seems to be heavily involved in AOP framework development, so I am not going to contradict any of his claims.

However, I DO believe that HotSwap can be used to improve the developer’s experience. Consider a web application that contains 100 Hibernate classes and takes 20-30 seconds to load. Most of the development time is spent loading and reloading the context, for each slight change in the Controller and View layers. Baiscally, if you want to add some stuff in a web page, you have to

1] Modify the action (Struts/Webwork Action, Spring MVC Controller, or Tapestry Page) to load the data from a database

2] Modify the view (.jsp/.jtl for Spring/Struts/Webwork, .html for Tapestry)

3] Deploy the application (30 seconds)

4] Test it. See that there is an error.

5] Correct the error, re-déploy the application (another 30 seconds)

and so on…

So, one of the solution is to use Jetty to deploy the application (for instance, using the Maven2 Jetty6 Plugin). This allows for hot-redeployment of JSP pages, but does not take the new classes changes into consideration. Jetty + Tapestry 5 is an attractive option for developers since it allows for hot deployment of both the HTML and Java code. This is awesome, except that I believe it should not be the MVC Framework’s job to do all the gory details of detecting new classes, re-loading the new ones, and so on. It is necessary to have a generic solution that will benefit all frameworks without specific support from them.

And this solution is called Java HotSwap. I am looking forward to having IDE support for that, that will allow to forget, once for all, this costly change-build-redeploy process.

Permalink 1 Comment

Character sets issues and guidelines

Posted in Java, Web Development at 3:04 am by skoobi

With globalization, Character Set problems are becoming more and more frequent, and are sometimes even a headache, as Mark Pilgrim and Scott Balmos highlight it in their respective posts entitled Determining the Character encoding of a feed and String encodings - another thorn in interop. Character sets are no more than a simple mapping between characters and numbers, and some encodings, such as Unicode UTF-8 tackle the interoperability issue correctly.

So, the real solution to all these problems would be to leverage UTF-8 as the default encoding for every application. If communication is necessary with a legacy system that does not support UTF-8, then whatever ISOxxx encoding is acceptable in a small wrapper that translates the stream to a UTF-8 one. In order to accomplish this :

Make sure the default locale on all your systems are UTF-8. Recent linux distributions like Ubuntu luckily default to that.
When writing or reading anything to a stream, Java (and I believe other languages too) defaults to the default encoding on the system. Do NOT trust this value, and make sure to only use the Reader/Writer constructors (example: OutputStreamWriter provides a few constructors that take the Charset. Use these constructors at ANY COST, and possibly write Jalopy rules that prevent the use of the default ones).

From a more general point of view, it would be desirable to have UTF-8 everywhere : Domain Name System (which stil uses ASCII), SMTP (which reverts to ugly hacks to allow people to write non-ASCII characters), etc…

The internet is an international place, and as such, should not be ASCII-centric. This means that if the standardization organisms (IETF, ..) do not realize this, we are going to see more and more forking such as China’s reform to its DNS, which is obviously a bad thing for the community since it creates more interoperability issues.

Permalink Comments

11.28.06

Interview concerning GPL Java

Posted in Uncategorized, Java at 7:17 am by skoobi

Dalibor Topic has been interviewed (post here) concerning the recent announcement of Sun to make Java GPL, its implication on the Kaffe project.

As far as I am concerned, I strongly believe that Open Sourcing Java will open the door to more innovation and wider adoption around/of this technology. When it comes to high-level languages, the only truly Free (Libre) option on the linux/*NIX desktop was to use Mono/C# (more and more GNOME applications are written in C#). Adding more competition by releasing Java Open source will most probably lead to better, easier to maintain applications.

Another important point about the GPL’ing of Java is that Java itself will benefit from the change. Look at GCJ, for instance, which tries to get rid of the JVM and directly compile java to machine Code. It is yet to prove whether this approach would actually make Java faster, but in any case, it would help to better integrate Java with the unix-way of doing things, instead of having Java on one side, and the whole OS on the other side. Few to no efforts have actually been done in order to mix high-level languages with the system. GCJ is currently struggling to implement both the language and classlib aspects of Java. Once the classlib will be released as Open Source software, GCJ developpers will be able to concentrate on the compiler itself, and on the integration of Java with C/C++ code, which will be an incentive for the people who don’t like JVMs to use Java (after all, Java will just be a simpler C++ that provides a decent library by default).

Permalink Comments

11.27.06

HOWTO: Use Direct Web Remoting (DWR) with Spring Framework and Java5 Annotations

Posted in Java, Web Development at 12:20 am by skoobi

DWR is an Open Source Java library that allows to write AJAX-enabled Web Sites. Since the “AJAX” term is used to to describe pretty much anything from rich Web User Interfaces to auto-completing combo boxes to asynchronous communication between the web client and the server, here is a more technical introduction that explains what DWR allows to do :

DWR is basically a Remote Method Invocation framework that allows to “export” server-side Java Objects to the javascript-enabled web client thanks to a transparent communication layer that dynamically (at runtime) generates the client stubs. So, in other terms, You have server side Java methods that you want to run from the client. DWR takes these classes/methods and provides you with a javascript file (generated on-the-fly) that provides javascript classes/methods that once called, will handle all the method calls, marshalling/unmarshalling, etc..

DWR does not provide any UI-abstraction layer. In order to create nifty graphics, you have to complement it with another framework like Dojo toolkit, or Script.aculo.us
Since the official documentation isn’t particularly clear on how to get DWR to work with Spring-managed beans and Java5 Annotations, here is a mini-HOWTO that completes it. (Anyone is free to use this HOWTO under any OSI-approved Open Source license). Nothing is easier to understand than a simple example, so we are going to create a Client Side Logger API that logs the events on the server-side thanks to Log4j. (A real-world example should use some abstraction layer like Commons-Logging , and should result in the creation of a backend to some of the popular Javascript logging frameworks, like Log4Javascript, instead of reinventing yet another logging API).

As a sidenote, DWR is part of the typical Bleeding Edge Web-Framework Stack that I wrote about in a previous post. Surely, not everybody uses this Stack, but it gives an idea of what the current trend in the Java world is. The current java world is full of innovation. Every 2 days, a new framework arrives on the scene, and beginners are more and more afraid of the overall complexity of the platform (if we can call this a platform, because it more looks like a set of unrelated tools that people struggle to use together, in opposition to Microsoft .Net’s stack that we can safely call a “solution” because of the tight integration between the components). Innovation is doublessly a very good thing, and nothing should prevent innovation from happening. However, I believe it is also very important to document the best practices and tools and try to gather the community around a limited set of paradigms and frameworks. It doesn’t make sense to have a different framework for each programmer in this world. And in my humble opinion, using such an RMI-like system for communicating between Java classes and Javascript is definitely one of the best and efficient (from the developers viewpoint) practices around.
Java class

The first step is to create the annotated Java5 class that will be exported to the Javascript client. All exported methods must be annotated thanks to the @RemoteMethod annotation, and the @Create annotation is used at the class level to tell DWR that the class is instantiated using the Spring Framework. The beanName parameter must reflect the name of the bean in Spring’s application context file.

@Create(creator = SpringCreator.class, creatorParams = { @Param(name = “beanName”, value = “clientSideLogger”) })
public class ClientSideLogger {

public static Logger logger = Logger.getLogger(ClientSideLogger.class);

/**
* @param arg0
* @see org.apache.log4j.Category#debug(java.lang.Object)
*/
@RemoteMethod
public void debug(String arg0) {
logger.debug(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#error(java.lang.Object)
*/
@RemoteMethod
public void error(String arg0) {
logger.error(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#fatal(java.lang.Object)
*/
@RemoteMethod
public void fatal(String arg0) {
logger.fatal(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#info(java.lang.Object)
*/
@RemoteMethod
public void info(String arg0) {
logger.info(arg0);
}

/**
* @param arg0
* @see org.apache.log4j.Category#warn(java.lang.Object)
*/
@RemoteMethod
public void warn(String arg0) {
logger.warn(arg0);
}

Spring Configuration

In order to instantiate the ClientSideLogger class with Spring, we can create the following dwr.xml file, that is going to create a “clientSideLogger” singleton :

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:aop=”http://www.springframework.org/schema/aop” xmlns:tx=”http://www.springframework.org/schema/tx”
xsi:schemaLocation=”http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd”>

<bean id=”clientSideLogger” class=”fr.cvf.vodoo.ihm.portal.dwr.ClientSideLogger” />

</beans>

Web.xml glue

The next step is to write the usual glue (setup the DWR/Spring servlet, etc…).

In your web.xml, you can add :

<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:spring/dwr.xml</param-value>
</context-param>

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!– DWR servlet , that should list all annotated classes–>
<servlet>
<servlet-name>dwr-invoker</servlet-name>
<display-name>DWR Servlet</display-name>
<servlet-class>org.directwebremoting.servlet.DwrServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>classes</param-name>
<param-value>
package.ClientSideLogger
</param-value>
</init-param>
</servlet>

<servlet-mapping>
<servlet-name>dwr-invoker</servlet-name>
<url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

Javascript Code
The final step is to use the logging using the automagically generated javascript API.

First, make sure the following javascript files are included :

<script type=’text/javascript’ xsrc=’/dwr/interface/ClientSideLogger.js’>
</script>
<script type=’text/javascript’ xsrc=’/dwr/engine.js’></script>
<script type=’text/javascript’ xsrc=’/dwr/util.js’></script>

And you can use the API :

ClientSideLogger.error(”error message”);

That’s all you have to do !

Permalink Comments

11.18.06

The typical bleeding-edge Web Application Framework Stack

Posted in Java at 6:20 am by skoobi

Most developers now agree they should avoid heavyweight frameworks like EJB2. Maintenance is a nightmare, and more importantly, developers don’t enjoy anything that deals with the generation of stubs and skels (The same applies to technologies like CORBA).

So, what is the recommended technology stack for developing web applications today ? It looks like nowaday’s buzz goes toward :

Apache Maven2 for build-management, and managing profiles (development, integration, production) and its set of plugins which ease application development, like Jetty6 plugin, which avoids constantly redeploying wars to tomcat.
A so-called “lightweight” JEE framework, like the famous Spring Framework, that everybody raaaves about.
A Object Relational Mapping framework, like Hibernate, or any of the Java Persistence API implementations (Hibernate EntityManager, OpenEJB, or Oracle TopLink)
An MVC framework, which is either Action/Request Based (The 2 most popular ones being Spring MVC and Webwork2/Struts2 ), or Component Based (The 2 most popular ones being Apache Tapestry and Java Server Faces )
A security framework like Acegi to handle authentication and authorization.
In addition, other secondary frameworks are often used, like DWR for transparent AJAX, or the client side Dojo Toolkit Javascript framework.

From a methodology viewpoint, the current hype is about :

Test-Driven-Development, thanks to some Unit testing frameworks like JUnit+Easymock, and functional-testing framework like Canoo Webtest.
Inversion Of Control : Each technical (technical or functional) component must be described by an interface, and the inversion of control container - usually Spring - takes care of instantiating the right objects to avoid the need to create hundreds of Factories and Singletons).
Aspect-Oriented Development (AOP) : User code should not be polluted by cross cutting aspects such as Security, performance, Transaction Management, etc. AOP is what allows to factor out this kind of code into reusable aspects.
Domain Driven Development (DDD), to design rich domain POJOs. Since designing rich domain objects implies that the objects will be smart and will need to access technical objects like DAOs, and directly accessing the implementations would lower the testability of the application, DDD often means using something similar to Spring’s @Configurable annotation in addition to Spring’s AspectJ integration, to magically dependency-inject domain objects (which cannot be managed by spring, since they can be instantiated everywhere)

From my experience, integrating all these frameworks doesn’t work out-of-the-box. It is often necessary to play with the miscellaneous versions of each framework, and it sometimes causes headaches. Classpath issues and human errors are also a great cause of trouble.

If the proliferation of frameworks continues (and I believe it will) , integrated stacks (like AppFuse, but backed by commercial support) will emerge as a de-facto need for kickstarting developments. How many developers out there actually use the whole IoC/AOP/DDD/TDD fuzz ? By looking at the amount of problems I get by using all these frameworks, I have the feeling that not so many people do ……

A simple example of that, is for instance, the use of Spring AOP declarative Annotation-based (@Transactional) transaction management. Nobody tells you that you cannot use @Transactional on a Spring MVC controller, or that you have to activate CGLib proxying to use @Transactional on Webwork Actions. Sure, once you’ve run into the problem and analyzed the cause, the reasons seem obvious, but I still believe that something needs to be fixed with the integration of all these frameworks. Everything works as expected in isolation, but once you start to deal with dozens of frameworks, problems arise more often, and their cause isn’t always obvious. The access to the right frameworks should be eased to improve the overall quality of applications in the software industry.

Permalink 1 Comment

Sami Dalouche

06.02.07

Validation Framework Consolidation : where are we ?

12.16.06

Java, from different viewpoints

12.11.06

J2SE 6 : will web development finally be productive thanks to scripting ?

12.10.06

Validation in a (Web) Application

12.09.06

Design Patterns and the Art of software design

12.06.06

Java HotSwapping support and Developer productivity

Character sets issues and guidelines

11.28.06

Interview concerning GPL Java

11.27.06

HOWTO: Use Direct Web Remoting (DWR) with Spring Framework and Java5 Annotations

11.18.06

The typical bleeding-edge Web Application Framework Stack

Pages

Archives

Categories

Search

Meta