Paul Duvall has done a very good feature comparison on the Continous Integration Servers available in the market. He has evaluated Cruise Control, Continuum and Luntbuild. The evaluation criteria is
* Features
* Reliability
* Longevity
* Target environment
* Ease of use

Check out the article here.

Filed in: J2EE

As the industry consolidates the ECM and Portal products, a dominant pattern is coming out, where the client is looking for business solutions provided by the best of the breed products. Means, I can have Portal Solution using FileNet as the document management, Interwoven as the content management and may be WebSphere Process Server as the middleware. Adapters are available for integration of these products into each other. So, the client instead of focusing on how to integrate these products can actually start worrying on how his business objective will be achieved. Idea is to be able to use 80% of the functionality out of the box and build just 20%. This change has led to the unique problem for the System Integration vendors.

Earlier, when the client gave the business requirements, the vendor will look at the functionality, decide on which application server, database, middleware product to use and estimate the effort. Now, with 80% of the functionality available out of the box, vendors are in dilemma, on how to estimate the effort for providing the business solution. Lot of business functionality will be available out of box, but this might require some customization to map to the requirement. Another 20% of the functionality needs to build from grounds up. In the days of pure Java development, segregating the requirements into high,medium and low and assigning a number would have sufficed. But, today, estimation has become all the more difficult, because how do you estimate if you do not what will be available out of box and what is not available. With every release, Software vendors and tom tomming about new features. But details on these features in terms of flexibility and ability to customize is missing. Hence, estimates for the integration solutions need to be really evaluated in a new light. I guess, that will again come from experience. As system integration vendors gain insight into the products, the estimates will become more scientific and less humane.

Filed in: Programming

Light is an Ajax and Java based Open Source Portal framework which can be seamless plugged in to any Java Web Application or as an independent Portal application. One of its unique features is that it can be turned on when users need to access their personalized portal and turned off when users want to do regular business processes.

Light helps you build Ajax and Java based portal applications quickly or make it possible to integrate portal application within your main web application if you don't want to or can not to transfer your web application to a portlet application.

A portal based on Light can make applications, database information and other data sources available to end-users through a single web site. Light provides a security infrastructure so that the information and functions made available to each user can be customized on basis of the user or a role that the user has.

Within a Light portal, individual portlets can be aggregated to create a page. Currently all portlets have to be in the same application with the portal.

Check out the details here.

Filed in: Open Source

One of the new features introduced in the WAS V6.1 is the Portlet Container. What this means is , the application server now has a dedicated container that can host portlets. Though the container will provide a limited set of services.

The Portlet container has a simple portal framework, provided by the PortletServingServlet servlet. The PortletServingServlet servlet registers itself for each Web application that contains portlets. Now one can use the PortletServingServlet servlet to directly render a portlet into a full browser page by a URL request and invoke each portlet by its context root and name.

One can deploy portlet war files like any normal web application. The portlet can be invoked directly through a Uniform Resource Locator (URL) to display its content without a portal aggregation.

Portlets can be aggregated on a JSP page by using an aggregation tag library.

This development will lead to a rethink on the use of Portal Servers. Application, which are not doing small pieces of content aggregation and are not using the Portal Server features, need not go through the whole Portal Server investment.

One can start with a vanilla portal application and as the application grows , the Portal Server features like Colloboration, Search, Aggregation, Integration will start coming into picture. At that time, all the investment made in developing Portlets on the WAS V6.1 can be reused without any changes and the upgradation to the full blown Portal Server becomes easy.

(The picture is from WAS V6.2 Infocenter)

Filed in: WPS

Last couple of months, I was working with a Team that developed standardised interface framework for accessing and using j2ee services (logging, exception handling, data access, search, cache, messaging, web services among others). Now, our next job was to sell this framework to the other teams doing IT development with in the corporation.

We developed sample applications around each of the j2ee services to showcase these.
Looking at the sample application, somebody asked a question jokingly, how do we know the framework services are really getting called and you have not hard coded some of the things.

The question got us thinking, on how we can demonstrate the actual method calls happening with out introducing or writing more code. We hit upon the idea of using AspectJ, we put in the point cuts at the service interface method calls and showcased these calls in a applet.
Now, when ever the sample application was run, the applet would display all the service interface calls being executed to the user. It was a beautiful way to get the call stack out in the open.

Filed in: Java