Wednesday, June 28, 2006

Spring Vs EJB

In quite a few design brainstorming sessions, the debate between Spring and EJB results in a deadlock. There are developers who are damn passionate about Spring and hate EJBs. Let’s have a look at the main important differences between the two:

1) Distributed Computing – If components in your web-container need to access remote components, then EJB provides in-build support for remote method calls. The EJB container manages all RMI-IIOP connections. Spring provides support for proxying remote calls via RMI, JAX-RPC etc.
2) Transaction Support – EJB by default uses the JTA manager provided by the EJB container and hence can support XA or distributed transactions. Spring does not have default support for distributed transactions, but it can plug in a JTA Transaction manager. Both EJB and Spring allows for declarative transaction demarcation. EJB uses deployment descriptor and Spring uses AOP.
3) Persistance – Entity Beans provide CMP and BMP strategies, but my personal experience with these options has been devastating. Entity Beans are too slow!!!..They just suck..
Spring integrates with Hibernate, IBatis and also has good JDBC wrapper components (JdbcTemplate).
4) Security – EJB provides support for declarative security through the deployment descriptor. But again, this incurs a heavy performance penalty and I have rarely seen projects using EJB-container managed security.

DAO access in Struts Action?

In quite a few projects in the past, I have directly accessed the DAO methods from the Struts Action classes. This strategy makes a lot of sense when we are only retrieving data from the database and populating beans that would be binded to the JSP page.

But there are many who consider including any persistance code or business logic code in the Action classes as 'sacrilege'. Many prefer having a business service layer (aka business delegate) layer that encapsulates all persistance and business-logic.

But for simple CRUD operations, the service layer just becomes a thin layer around the DAO layer. But nevertheless, there are advantages of adding this business service layer.
  1. Consolidates the data access layer to all clients. Every method in the DAO need not be present in the ServiceLayer. You see only the methods that we wish to expose to the rest of the world.
  2. Serves as an attachment point for other services, such as transaction support. For e.g. using Spring.
  3. Presents a single common interface for other applications to use. For e.g. exposing the business functionality as a WebService.

Another reason this extra layer can be helpful is in a real-life scenario- For e.g. A more complex application there are often other business operations you might want to perform besides just calling you DAO. For example, maybe when an "update" is done you need to call some process that sends out an e-mail or some kind of notification. If you don't use a Service class you are stuck now between coding this business logic either in your Action class or in the DAO. Neither of those places is really a good place for that kind of logic - hence we provide an extra service class to handle business rules that shouldn't be in the Action and don't belong in a DAO. Of course for rapid development, you could possibly skip the Service classes and just use the DAOs directly within your Action.

But there is no absolute right or wrong answer. This reminds me of a quote:

"I'm always wary of absolutes. Know the rules, know the reasons behind the rules, know when and why to break the rules, proceed accordingly."

Friday, June 23, 2006

Struts - Forward Action Vs Direct JSP call

A recent developer asked me why should one use ForwardAction, when one can directly give a link to a separate JSP directly.

The reason is: When we use ForwardAction, the ActionServlet in Struts intercepts the request and provides appropriate attributes such as Message Resource Bundles and also FormBeans.
If we directly give a reference to a JSP page, then the behavior of the Struts tags may become unpredictable.

Another reason when ForwardAction would be necessary is when direct access to JSP files are prevented from direct access by using the "security-constraint" tag in web.xml.

Monday, June 19, 2006

Deployment options in Tomcat 5.0

Generally developers are used to deploy J2EE applications by dropping the war file or the application folder directly into the webapps directory of Tomcat.

But it is possible for the application to be deployed in a separate location also - even on a separate logical drive.
We just have to create a XML fragment file and place it in the following folder:
$CATALINA_HOME/conf/[enginename]/[hostname]/[applicationName].xml
If one opens this folder, then we can see the context XML descriptors of all applications deployed on Tomcat.

The files typically contain the docBase attribute that points to the physical location on the hard-disk and the web logical path.

<context path="/ASGPortal" docbase="ASGPortal">

So, if want to deploy the above webapp on a separate path, say d:/myApps/ASGPortal, I copy my webapp folder there and change the docBase attribute in Context. Zimple...... :)

Note: This comes really handy when we are using a Source-control tool and the check-in/check-out folders are not under Tomcat.

Diff btw MTS and COM+

During the good old days of WinNT, MTS used to provide the middle layer for distributed computing using MS technologies. The MTS (Microsoft Transaction Service) environment used to sit in between the client and database and provide distributed transaction services, object pooling, security and other services.

With Windows 2000, MTS was upgraded to COM+. While MTS was actually an add-on to Windows NT, COM+ was natively supported by Windows 2000. This simplified the programming model quite a bit. It was often said that MTS + COM = COM+.

Thus MTS/COM+ is the equivalent of EJB in the J2EE world.

In .NET, COM+ components can be written as .NET component services. The "System.EnterpriseServices" namespace provides us with classes that enable us to deploy a .NET component as a COM+ component. Existing COM+ components can be accessed using .NET remoting and COM-Interop.

Friday, June 16, 2006

OnBlur Javascript recursive loop

Recently some of the developers in my team were struggling with a javascript issue.
The problem was very simple. There were 2 textfields on the screen - one after the other. Both of which have an OnBlur call to a routine that simply validates that the fields are not left blank.

Now when the first field is left blank and a 'tab' is pressed, then the javascript goes into a recursive loop !!! The loop is started because we used the focus method in the javascript function: tabbing out of field one fires onblur and sets focus to field two. The function focusses back to field one, "taking focus off field two", which fires a new onblur, which makes your function put focus back on field two firing onblur for field one. This goes on forever.

The solution to this is very simple - Just keep a global variable that points to the current object being validated and check that inside the function. Here is the script for doing so:

var currentObjectName='';

function NoBlank(object, label)
{
if (currentObjectName!=''; currentObjectName!= object.name) return;

currentObjectName=object.name;

if (object.value == "")
{
lc_name = label;
alert(lc_name + " input field cannot be blank!")
object.focus();
return false;
}

currentObjectName='';
return true;
}

Thursday, June 15, 2006

Automatic Language Identification from text.

In one of my recent projects, there was a business requirement to identify the language of a text document automatically and segregate them.

I tried to do some research on the internet and came up with some open-source tools that can help in identifying a language. One such popular tool is "Lingua" - open source and written in Pearl.

Language identification happens by searching for common patterns of that language. Those patterns can be prefixes, suffixes, common words, ngrams or even sequences of words. More information about n-grams can be found here.

Other interesting links on the same subject:
http://staff.science.uva.nl/~jvgemert/mia_page/LangTools.html
http://odur.let.rug.nl/~vannoord/TextCat/Demo/
http://staff.science.uva.nl/~jvgemert/mia_page/demo.html#Lid

Thursday, June 08, 2006

Association - Aggregation and Composition

An aggregation is a special form of association between classes that represents the concept of "WHOLE -PART". Each object of one of the classes that belong to the aggregation (the composed class) is composed of objects of the other class of the aggregation (the component class). The composed class is often called "whole" andthe component classes are often called "parts".

A simple aggregation is an aggregation where each part can be part of more than one whole.

Composition is a special kind of aggregation in which the parts are physically linked to the whole. So, a composition defines restrictions with regard the aggregation concept:
- A part can not simultaneously belong to more than one whole.
- Once a part has been created it lives and dies with its whole.

Wednesday, June 07, 2006

XMI-XML Metadata Interchange

Recently, I started using Rational Software Modeller for UML modelling. The UML diagram files that the tool creates have a *.emx extension. I was expecting it to be some proprietary binary format, but when I opened the file in Notepad, I was suprised to see a XML format!!!. It looks like even IBM has decided to make its UML models XMI compatible.So what exactly is XMI?

The XML Metadata Interchange (XMI) is an OMG standard for exchanging metadata information via Extensible Markup Language (XML). It can be used for any metadata whose metamodel can be expressed in Meta-Object Facility (MOF). The most common use of XMI is as an interchange format for UML models, although it can also be used for serialization of models of other languages (metamodels).
Here's an excerpt from Wikipedia : http://en.wikipedia.org/wiki/XMI

XMI can be used to transfer UML diagrams between various modeling tools.At the moment there are severe incompatibilities between different modeling tool vendor implementations of XMI, even between interchange of abstract model data. The usage of Diagram Interchange is almost nonexistent. Unfortunately this means exchanging files between UML modeling tools using XMI is rarely possible.