Tuesday, January 31, 2006

IBM DB2 Free

IBM has released a free version of DB2 named DB2 express-C. It is free for development, deployment, and redistribution. It is supported on the x86 and x86-64 architectetures and is runs on Linux and Windows (2000, 2003, XP). Added to that, this version is seamlessly upgradable to DB2 UDB, if the requirements change. The catch here is: DB2 Express-C is designed to only run on systems with a maximum of two processor cores, or dual-core processors and upto 4GB memory.
It is available for download on IBM downloads.
There is also a DB2 express forum, where you can get community support for this product.

Friday, January 27, 2006

Generate PDF files from Java applications

There is a new article in IBM developerworks, which explains the usage of iText in simple steps Generate PDF files from Java applications dynamically. Although a it is open source, my personal experience with iText was not so happy. Using iText in Java Web Applications was quite easy. But once implemented, it took a lot of memory and CPU time, and that was for a single page PDF file. If you run the example that is provided with the article, you can see a spike in CPU usage. This was not acceptable for our applications, and we had to switch to Adobe LiveCycle forms for generating PDFs.

Generating PDFs from Web Applications using Adobe LiveCycle form server is easier than it is with iText (once you get the hang of it, the documention is one of the worst). It does perform better but it comes with a heavy price tag, and needs an application server to run on. Currently Adobe LiveCycle Forms can be integrated with WebSphere and JBoss Application servers. It is not designed for handling heavy loads, but definetely performs better than iText for low to medium loads.

While iText is free, it comes with a performance penalty and while Adobe LiveCycle Forms offers better performance, it also comes with a heavy price tag. Both are equally easy to implement. It is your requirements and budget that will govern your choice.

Wednesday, January 25, 2006

Form based authentication - logout

When using form based authentication in a J2EE application, the standard way to logout the user would be to invalidate the user session on the web server. In a simple servlet, the logout steps would look like this:

public void doGet(HttpServletRequest req, HttpServletResponse resp) throws
ServletException, IOException

This is quite simple way for implementing logout. There is also another, easier, way to logout the user when using WebSphere Application Server. All you have to do is have a form with the action set to "ibm_security_logout".
ACTION="ibm_security_logout" NAME="logoutForm" >
Click this button to log out:
< input type="submit" name="logout" value="Logout" >
< INPUT TYPE="HIDDEN" name="logoutExitPage" VALUE="/myapp/" >
< /form >

In the above example, the hidden field "logoutExitPage" is the page the user is sent to after logout.

Thursday, January 19, 2006

Java 5 Static Imports

Java 5 introduces the static import feature for allowing better access to the static members of a class. According to sun, this feature helps programmers avoid the "constant interface antipattern".

The problem:
It is a general practice to declare all your constants as public static final members of an interface and access them throughout the application. For ex.

package mypackage;
public interface Constants {
public static final double PI = 3.14;
public static final double PHI = 1.61803399;
public static final int RAD = 50;

These constants may be accessed from another class thus

package mypackage;
import mypackage.Constants;
public class StaticImportTest {
public static void main(String args[]) {
double area = Constants.PI * Constants.RAD * Constants.RAD;



(you can always use the constants and methods of java.lang.Math for such operations)

While this is an correct implementation, most programmers would prefer a cleaner approach to this where you can write:

double area = PI * RAD * RAD;

To achieve this, programmers tend to implement the interface, so that they can avoid typing the interface name and also have readable code. The problem with this approach is that:
  1. You are making the constants in the interface a part of the contract of your class, so any client using your class can access the constants. If they do, then any change in the constants will mean that the all the clients have to be recompiled.
  2. More importantly, you are making the constants a part of your class' API, which exposes your implementation details.

The solution:
Java 5.0 provides a solution for this problem in the form of static imports. Now you can import all the constants in the interface using a single "import static" statement thus:

import static mypackage.Constants.*;
package mypackage;
import static mypackage.Constants.PI;
import static mypackage.Constants.RAD;
public class StaticImportTest {
public static void main(String args[]) {
double area = PI * RAD * RAD;

System.out.println("2 " + area);


Although this avoids the "Constant Interface Antipattern" it also comes with some problems which can be avoided by a little careful programming:
  1. If you have multiple static imports, it becomes difficult for the reader to understand where the constant is coming from.
  2. You may end up having naming conflicts in your program.

So, here are a couple of things to remember while using static imports

  1. Always import the full path of the constant, without the wildcards. For ex:

    import static mypackage.Constants.PI;
  2. Use static imports to improve readability not to avoid typing too much.
** The code was tested on Windows XP with JDK1.5.0_06**

Tuesday, January 17, 2006

Secure only login page

Web applications that do not use SSL to protect all their resources run faster than the ones that do. However, passing sensitive information about the users (user id's and passwords) over the network unencrypted is not a fair trade for improving performance. The best way is to protect only the login page and leave the rest of the pages unencrypted, that is if you do not have to encrypt each and every user transaction. In this way you will be able to successfully implement authentication and authorization on your web application without significantly impacting performance.
J2EE based web application can use container provided features to protect only certain pages of the application with SSL and leave the rest unencrypted. This is done by placing a security constraint (in the web deployment descriptor) on the specific page (login.jsp) and add a user-data-constraint to it. The user-data-constraint element contains a single required child element transport-guarantee. Assigning a value of CONFIDENTIAL to this element will enable secure transport for the selected resource. The following table shows the security constraint definition in the web deployment descriptor.

Sunday, January 08, 2006


Anyone who has used google maps or gmail would certainly have noticed their responsiveness is far better than most other websites. And if you are a developer, it is highly likely that you have heard about AJAX is used to "power" these websites through.

So what is AJAX? Simply put, AJAX is a way for making asynchronous calls to the server using a new object named XmlHttpRequest. Coupled with XML technology, we have an effective programming tool for web applications. Hence, the name "Asynchronous JavaScript and XML". IBM developerworks has a series of articleson AJAX which discusses in better detail about how AJAX works, Mastering Ajax, Part 1: Introduction to Ajax is the first one in the series and seems to be worth following. This is an essay by Jesse James Garrett on AJAX.

So how does AJAX work with J2EE? Being Javascript based, AJAX can be used in conjuction with any web application platform be it J2EE or .NET. Philip McCarthy wrote a series of articles "AJAX for Java Developers" that introduce AJAX to Java developers they are titled, Building Dynamic Java Applications, Java object Serialization for AJAX and AJAX with Direct Web Remoting. Sun has a section in the Java blue prints on AJAX with Java Server Faces (JSF). This is only a start. We will be seeing many framworks for building AJAX enabled web applications with Java. AJAX patterns site has lists a few Java based frameworks for AJAX.

Thursday, January 05, 2006

Security Tools for Eclipse from alphaWorks

I recently found IBM alphaworks security lifecycle management tools for the eclipse platform. I was not able to run the tool in eclipse platform or WebSphere studio. Turns out that the tools were tested only on Rational Software Architect and Rational Application Developer. When run on RSA the tools run just fine and personally, I found the Tivoli Access Manager API code samples, which can be accessed through the right-click menu, quite useful (well, that's what I have been working for quite some time now). Apart from the code samples for the TAM API, the download also comes with some good documentation about the utilities and best practices for using the TAM API. A sample project is aslo provided, which illustrates the use of WebSEAL Extended Authentication Interface (EAI). I did not look into the WebSEAL trace analyzer that is a part of the security tools download.
The tools are available for download on alphaWorks.

Wednesday, January 04, 2006

Missing PDPrincipal with TAI+

We configured websphere trust association with Tivoli Access Manager. It works fine when we tested it with individual logins. But when we tried to load test the authentication and authorization using TAM and TAM's Authorization API , the PDPrincipal of the subject was lost in a significant number of cases. When we contacted IBM about this, they suggested that we apply PK00852 to websphere, which is available from websphere cumulative fix pack Although the fix does not directly address the problem at hand, we could load test TAM authentication and authorization with Azn API successfully. Probably TAI+ creates a custom cache key and modifies the subject with information that cannot be retrieved from the user registry alone. For more on custom JAAS subjects and cache keys in websphere, refer to this article in the WebSphere technical Journal. This is what IBM has to say about the APAR fix mentioned above.

IBM - PK00852: SSO tokens with custom cacheKey from TAI are not handled
correctly: "When using the security attribute propagation token framework or the
cacheKey property within a Hashtable login to affect the custom cache key of a
Subject, an SSO token containing this custom cache key will result in a cache
miss at a backup server. This will cause either a DynaCache hit (if configured)
or an MBean retrieval to get the Subject contents. In cases where the
originating server is down, the LTPA token will be used to login, but it's
unlikely the custom attributes will be preserved in that situation. To
accommodate the behavior of a new challenge whenever these custom attributes
cannot be retrieved, any SSO token containing the custom cache key that cannot
retrieve the originating attributes will, by default, result in a new
authentication challenge. However, there will be a property that can be used to
change to the old login using the token behavior."

Popular Posts