Inderjeet Singh's Blog

Community: Java Enterprise Archives

NetBeans module for Java SDK for Google Checkout APIs released

We provide convenient libraries and sample code for various languages including Java, C#, Perl and PHP. But for Java, we go the extra mile. We provide an open-source project Google Checkout Java SDK that provides convenient Java-based handlers to deal with the XML messages sent by the Google Checkout APIs notifications and callbacks.

Of course, tools can make this process even easier. So, I am happy to announce the public availability of the first version of a NetBeans module that provides a wizard-driven interface to integrate the Checkout SDK in any Web project. Here are the instructions to download and install this plugin module in your NetBeans IDE.

We hope to continue enhancing this module based on developer feedback. So, share your experiences with Google Checkout APIs, SDK or this module as comments to this blog. Thanks for reading.

Using Google Checkout SDK with Glassfish

Google Checkout is a Google service that enables a faster, safer and more convenient way to shop online. Online merchants can implement Google checkout on their websites, and then they do not need to worry about managing credit-cards information and privacy of user accounts. Besides, Google provides free credit-card processing until the end of 2007 and will later provide credit for adwords expenses in free credit card processing. It is trivial to implement an HTML version of the Google checkout process. However, Google also provides a REST-based XML API that can be used to automate order processing. In this blog, I will discuss how to use the Java SDK for Google Checkout to easily implement the XML API integration with Google checkout in your Web applications. You can then deploy your application on GlassFish or Tomcat to handle REST events.

The Checkout SDK provides a library jar and an XML configuration file that you will need to embed in your Web application. You can then configure your action handlers that will receive notification of various order processing events from Google as a user places an order. Here are the steps that you will need to follow:

1. Download and install Glassfish.
2. Download checkout-sdk-0.5.zip or a later version from its download page.
3. Unzip checkout-sdk-0.5.zip file. This will create a directory named checkout-sdk-0.5.
4. The top-level index.html has instructions on using the SDK. You can also browse the Javadocs for the classes contained in the SDK at docs/javadocs/index.html
5. Copy checkout-sdk/checkout-sdk.jar to your WEB-INF/lib
6. Copy checkout-sdk/web/WEB-INF/checkout-config.xml to your WEB-INF/ directory
7. Edit your WEB-INF/web.xml and cut-and-paste the contents from checkout-sdk/web/WEB-INF/checkout-fragment-for-web.xml
   1. If you need to add additional handlers to process checkout notifications, edit checkout-config.xml and change default value of the handlers to your classes.
   2. Use Checkout SDK Javadocs to extend notification handlers
8. Copy over the contents of checkout-sdk/web/checkout to a suitable directory in your application. For example, web/checkout
9. Your application is now ready to use Google Checkout APIs. Deploy it on glassfish to test the integration
10. Login to your Google checkout merchant account, click on Settings tab, and then click on Integration on the left menu. register the URL for your notification service in the API callback URL textfield. For example, if glassfish was running your application at http://foo.bar.com:8080/myapp then, the registration URL will be http://foo.bar.com:8080/myapp/notification

That is it! Try it out today, and share your experiences as comments to this blog. We will be try our best to improve the checkout SDK to enable easy implementation by your Web applications. Thanks for reading.

JavaOne sessions on Java EE 5 puzzlers and Google Checkout

My other session is related to using Google Checkout API in Java applications. In this session, we will describe how Java developers can use this API to enable payments for selling products on their websites. The integration can be as simple as an HTML FORM post, or a heavy duty one for integration with order processing systems using a REST based API. We will also demonstrate how the popular Web 2.0 Pet Store application can be modified to use Google Checkout.

When neither presenting or attending other sessions, I will be handing out goodies at the Google booth in the pavillion! So if you are coming to the conference and would like to meet up, drop by the booth or at either of the sessions. If there are any specific topics you would like us to cover in the sessions, you are welcome to share them as comments to this blog. Thanks for reading.

Moved on...

This blog is on a personal note. After being at Sun for 10 years, I have now left Sun and joined Google. I am currently working on Google Checkout, Google's solution to make online shopping faster, safer and convenient. If you have ideas on how to achieve these goals better, share them as comments to this blog.

When I joined Sun, it was my dream company in regards to the culture and the quality of work. It certainly delivered on the promise. I am proud to be part of the team that created the Java EE Platform. I enjoyed working with superbly smart and caring people on projects such as Java Web Server, Java Proxy Server, J2EE RI, Java BluePrints, Java EE SDK and Java Application Platform SDK. I also got wonderful opportunities to interact with the broader Java community, and make numerous friends. Thank you Sun for all these wonderful gifts! I will continue to remain involved in Java (as Google uses Java extensively), but less so in Java EE.

What is the difference between Java Application Platform SDK and Java EE SDK

1. Java EE 5 SDK: This bundle contains the Java EE 5 compatible Sun Application Server. This is same as GlassFish V2 beta. Additionally, it contains Java EE 5 API docs, a short tutorial, BluePrints, and samples. This bundle comes in two forms: with JDK (JDK 6) or without JDK.
2. Java Application Platform SDK: This bundles contains all the contents of Java EE 5 SDK and includes the following additional runtime components: Sun Web Developer Pack Release 1, Open ESB 2.0 Beta, Java Portlet Container 1.0, Sun Java System Access Manager 1.0. This bundle also comes in two forms: with or without JDK.
3. Java EE 5 Tools Bundle: This bundle includes Java Application Platform SDK, NetBeans 5.5.1 Beta, and NetBeans Enterprise Pack. This bundle does not contain JDK.

So, how do you decide which bundle to choose? Here are some guidelines:

• Download the Java EE 5 SDK bundle if you prefer command-line tools instead of NetBeans IDE, and are only interested in writing Java EE 5 applications.
• Download the Java Application Platform SDK bundle if you prefer command-line tools instead of NetBeans IDE, and are interested in writing applications that use Java EE 5 with additional components. The SWDP component provides support for writing Web 2.0 applications, the OpenESB component enables development of composite applications that use an Enterprise Service Bus (ESB), Java Portlet Container enables development of portlets and, finally, Access Manager enables using Web services security technologies.
• Download the Java EE 5 Tools bundle if you prefer using NetBeans IDE for developing Java EE 5 applications with additional features contained in the Java Application Platform SDK. In addition to regular Java EE application development, this tool provides visual development of composite applications using a BPEL editor, and easy configuring of Web services security.



Are the various bundle options confusing? Do you have suggestions on how we can make them better? Share your thoughts as comments to this blog. Thanks for reading.





Announcing the release of Java Application Platform SDK Update 3 Preview

Posted by inder on March 13, 2007 at 12:00 PM | Permalink | Comments (10)



As the tech lead for the project, I am happy to announce the availability of the new version, Update 3 Preview, of the Java Application Platform SDK. This version includes the following enhancements:

Sun Java System Application Server 9.1 Beta: Sun Java System Application Server has been upgraded from version 9.0 UR1 Patch 1 to 9.1 Beta. This version includes support for clustering, HTTP/EJB session persistence using in-memory replication, Web services interoperability technology (WSIT), and Java Business Integration (JBI) support. Other changes include a redesign of the administration tool and an automated update mechanism.

Sun Web Developer Pack Release 1: Sun Web Developer Pack helps you to leverage emerging web technologies and techniques to create interactive and dynamic web applications for the enterprise. This toolkit is a collection of technologies for Ajax, scripting and REST-based services development supported by a NetBeans plugin that simplifies the design and development of rich Internet applications.

Open ESB 2.0 Beta: Open ESB has been updated from the earlier 1.0 version to 2.0 Beta. This version significantly enhances composite application development through a JBI-based integration platform fully integrated with the application server. Support has been added for clustering and XA resource recovery. JBI components included in this release are: Service Engines for BPEL, Java EE, XSLT, Intelligent Event Processing, and SQL; and Binding Components for File, FTP, HTTP, JDBC, JMS, SMTP, and WebSphere MQ protocols.

Portlet Container 1.0: The Portlet Container has been updated from the earlier 1.0 beta version to 1.0 FCS.

Sun Java System Access Manager 7.1: Sun Java System Access Manager has been updated from the earlier 7.1 beta version to 7.1 FCS. Read Securing Communications in Web Services: A Tutorial.

The Java EE Tools bundle was also refreshed to take advantage of the updated SDK Update 3 contents. This bundle contains the NetBeans IDE 5.5.1 Beta with the Enterprise Pack along-with the Java Application Platform SDK contents.

All in all, lots of interesting new capabilities to work with. So, what are you waiting for? Download it here and share your thoughts on this release as comments to this blog, or at the SDK forum.





Can GroupThink result in poor decision making in strong open-source communities?

Posted by inder on February 05, 2007 at 11:24 PM | Permalink | Comments (6)



I recently came across a great article on GroupThink of Irving Janis. GroupThink is a behavior pattern that results in inferior decision making by a group of smart people when the cohesiveness of the group is too high. It happens because of a strong desire of the people to preserve the harmony in the group even if at the cost of better decision making.

Open-source projects are also typically run by groups of smart individuals who all have come together to solve a common problem. Sinc the team is working towards a shared goal, often voluntarily and to attain a higher ideal, the cohesiveness can be high. Moreover, for certain high-profile projects, the desire of the group members to remain associated with the group is strong because it gives them prestige and satisfaction due to the project's impact on the society.

As the article describes, cohesion in the group is a necessary but not sufficient condition for GroupThink. It also requires structural faults in the group because of poor leadership, lack of process and norms. Finally, for the group to slide into GroupThink, a provocative situational context needs to exist such as a recent failure, high stress or low self-esteem.

Have you seen an open-source group slide into GroupThink? Have you had experiences in an open-source project where the group collectively made some poor decisions just to preserve the group harmony? Share your thoughts as comments to this blog! Thanks for reading.





Fortifying Web 2.0 Pet Store

Posted by inder on January 08, 2007 at 01:11 PM | Permalink | Comments (0)



Folks at FortifySoftware are running a program where they run their static analysis tool for code checking and security analysis for free on open-source projects. They were kind enough to run their tool on our Web 2.0 Pet Store application and report bugs to us. In this blog, I share my experiences with some of the subtle errors that their tool caught.

Some of the bugs that fortify reported were spurious because, presumably, the tool doesn't know about Java EE 5 annotations yet. For example, it failed to notice the following dependency injection:

@Resource UserTransaction utx;

The tool reported the above statement as uninitialized variable that may result in a null pointer exception or cause other errors. But since this code belongs to a Java EE managed component, the container will initialize the utx object correctly when the component is instantiated.

The next bug is something we all know academically, but sometimes run into because of oversight. This has to do with integer division when the two operands are roughly of the same magnitude. The result can contain significant value in the fraction, so it is a good idea to store it in a double. So, that is what the petstore code tried to do:

Line 1. int w = image.getWidth();
Line 2. int thumbWidth = thumb.getWidth();
Line 3: double powerW = thumbWidth / w;


However, there is a bug in the above code that fortify caught: In line 3, both thumbWidth and w are int, so the expression thumbWidth /w is an integer division with result converted to an int thereby losing any fraction value that might have been generated. The result is then promoted to a double so that it can be assigned to powerW, but it is a little too late.

The solution, of course, is to cast one of the elements to double before the division so that the operation becomes a double division operation. So, here is the corrected code:

Line 1. int w = image.getWidth();
Line 2. int thumbWidth = thumb.getWidth();
Line 3: double powerW = thumbWidth / (double) w;


Lesson re-learnt.

That brings us to the final type of bug that fortify reported. This relates to cross-side scripting attacks. Essentially, in the petstore we were using some user-submitted data without first validating it. Here is an example:

Line 1:String itemId=request.getParameter("itemId");
Line 2:out.print(itemId);


In this code, we are using the value of the user-submitted paramater itemId without validating it first. A malicious user, can insert escape characters in it that may result in a JavaScript injection attack. Similarly, if this value was being used as a database query parameter, it was amenable to a SQL injection attack. The correct fix is to validate the itemId parameter before using to ensure that it does not contain characters that we do not expect to be there.

Needless to say that we have fixed most of these bugs in the petstore application, and intend to fix the remaining ones soon as well. What are your thoughts on a tool like Fortify? Have you run into similar silly bugs as well? Share your experiences as comments to this blog. Thanks for reading.





Improving support for generics in the Java Persistence API

Posted by inder on January 03, 2007 at 11:42 AM | Permalink | Comments (15)



The Java Persistence API comes in handy for creating object relational mapping. I recently came across a warnings that the compiler generates on some code that uses these APIs in our Web 2.0 Pet Store project. Upon a closer look, I concluded that the warning was bogus and came up with a suggestion for the Persistence API expert group to better support generics. Here is the warning in question:

D:\ws\petstore\ws\apps\petstore\src\java\com\sun\javaee\blueprints\petstore\model\CatalogFacade.java:47: warning: [unchecked] unchecked conversion
found : java.util.List
required: java.util.List<com.sun.javaee.blueprints.petstore.model.Category>


Here is the code that causes this warning to be generated:
Query query = em.createQuery("SELECT c FROM Category c");
List<Category> categories = query.getResultList();

Essentially, the compiler is complaining that query.getResultList() returns just List whereas we are expecting it to be List<Categories>. This warning is unfortunate because we know that the query results are going to be list of Category objects, and we would like to express it somehow. Ideally, javax.persistence.Query should allow us to express this by providing an additional method:
List<T> getResultList(Class<T> c);

This will enable us to write the following code:
List<Category> categories = query.getResultList(Category.class);
and the warning will get eliminated and we will have improved type-safety.

I hope the Java Persistence expert group will look at this issue and add a generic version to ensure better type-safety. I hope they will look at other API methods as well to see if better support for generics can be added.

What is your opinion on this matter? Do you have other suggestions for improving the Java Persistence API? Share your thoughts as comments to this blog. Thanks for reading.





Announcing the release of Java EE SDK and Java Application Platform SDK Update 2

Posted by inder on December 14, 2006 at 03:34 PM | Permalink | Comments (0)

We have refreshed the Java EE SDK and Java Application Platform SDK to take advantage of the newly minted JDK 6. We also threw in a new component, the portlet container for good measure. Past components, such as Access Manager, JBI Runtime with BPEL continue to be available.

The SDK bundles are actually compiled with JDK 5.0 to ensure that they continues to works fine with JDK 5.0 as well. This is a really important thing since not all users want or are able to upgrade to the latest and the greatest, JDK 6.

Besides these changes, the Application Server included in the SDKs contains a fix for a performance-related bug that allows us to brag about our record breaking price/performance on the application tier. Our SPECjAppServer result of 521.42 JOPS@Standard is a 19% improvement from the previous version 8.2. This is the only SPECjAppServer result published so far on an open-source application server. It is also the first and only SPECjAppServer result published on an application server that is certified to the Java EE 5 specification. Check out Scott Oaks' blog on this topic.

The Java EE Tools bundle was also refreshed to take advantage of the updated SDK Update 2 contents. This bundle contains the NetBeans IDE 5.5 with the Enterprise Pack along-with the Java Application Platform SDK contents. The tools support for developing portlets is available through NetBeans plugins which can be downloaded here. See Deepak's blog and Satya' blog on how to develop portlets with these plugins.

All in all, lots of goodies just in time for Christmas, and the shipping is free. So, what are you waiting for? Download it here and experiment during the relaxing break in December. You are welcome to share your thoughts on this release as comments to this blog, or at the SDK forum.



How to do black-box testing for AJAX Applications?

Posted by inder on October 11, 2006 at 04:50 PM | Permalink | Comments (1)

Web developers are rushing to use AJAX in their Web applications to enhance user-experience. However, testing is a pre-requisite for creating production-quality applications. In this blog, I discuss my attempts on writing automated blackbox tests for the popular Web 2.0 petstore application.

I started out looking for a JUnit based solution. This is because we use NetBeans for developing the petstore application, and it is a breeze to write JUnit tests with NetBeans. Selenium seems quite promising, but it requires that a person runs it in a browser. That requirement makes it unsuitable for ant-based testing that can be done in an automated manner. I am also interested in using JavaScript Unit Tests, and JSUnit. However, those primarily test client-side JavaScript without invoking any of the server-side calls. It is also necessary to simulate how a user will interact with the application by writing a black-box test that mimics a Web client. For this, I chose a JUnit extension, HttpUnit. HttpUnit provides extensive support for making Web requests, parsing HTML, navigating links or clicking buttons. HttpUnit also have basic support for JavaScript but it could not handle dojo, and promptly failed on the very first call.

For now, I am disabling the testing of any of the AJAX calls, but limiting myself to walking through all the pages of the application, and invoking Non-AJAX methods. This is better than no testing, but obviously leaves most of the AJAX invocations untested. Not a good solution.

What do you use for black-box testing of your AJAX applications? Have you written an automated test suite using JUnit? Share your experiences as comments to this blog. Thanks for reading.





Executing Tasks Portably at the Startup or Shutdown of a J2EE Application Server

Posted by inder on June 29, 2006 at 04:42 PM | Permalink | Comments (6)

Enterprise applications often need to execute some tasks at the startup or shutdown of the Application Server. Many application servers provide proprietary ways of doing this, but there is a standard portable way as well. In this blog, I will discuss how this can be done using the Servlet API. This feature has been available since Servlet 2.3.

First, you need to write a class that implements the ServletContextListener interface:

public class MyStartupUtil implements ServletContextListener {
  public void contextInitialized (ServletContextEvent evt) {
    ServletContext sc = evt.getServletContext();
    // Place your code here that needs to be executed at application server startup
  }

  public void contextDestroyed (ServletContextEvent evt) {
    ServletContext sc = evt.getServletContext();
    // Place your code here that needs to be executed at application server shutdown
  }
}


This class needs to be configured in the web.xml deployment descriptor:

<listener>
    <listener-class>MyStartupUtil</listener-class>
</listener>

That's it. Now, whatever code you place in MyStartupUtil will get executed at the application server startup and shutdown.

Have you used this technique before? If so, what have been your experiences? Did it work well for you? Feel free to share your opinions or alternate techniques for doing the same through comments on this blog. Thanks for reading.



The New New Petstore.... with Web 2.0 features including AJAX

Posted by inder on May 12, 2006 at 11:51 AM | Permalink | Comments (8)

This ain't your father's petstore! The Java BluePrints team has created a new version of the popular Java Pet Store reference application to illusrate how the Java EE 5 platform can be used to create AJAX-enabled Web 2.0 applications.

The first striking feature of the application is the use of AJAX to create a highly interactive GUI experience. The GUI does minimal page refreshes by updating various GUI elements asynchronously using AJAX. The catalog is presented not as a boring list of items, but through an interactive slider which previews various listed items, and provides collapsable sections for more details. It also allows searches of the pets by location, a much more natural way of finding pets around your neighborhood than using a keywords based search.

Even though this application is called Java Pet Store, and uses the immortal petstore graphic, dont be fooled by the looks. Inside, it is a completely different application showing different use-cases targeting Web 2.0. The earlier petstore was a standard ECommerce website where the enterprise owning the site generated all the content. In the Web 2.0 petstore, all the content is uploaded by the user community itself. Whenever a site allows users to submit content, it needs a way to prevent automated systems to add graffiti to the site. The Web 2.0 petstore uses a captcha JSF component to discourage graffiti. The content is not just community-generated, but community rated as well. The petstore uses an AJAX-enabled JSF component to show aggregated ratings on an item, as well as allows users to submit their own rating.

The Web 2.0 petstore also demonstrates how to create mashups with other Web services. For location-based searches, it uses a mashup with Yahoo Geocoder to obtain longtitude and lattitude for an address, and then uses Google maps service to display the pets on the map. For payments, it uses a JSF component that uses PayPal service to send payments to a seller's email address. The petstore also demonstrates how an RSS feed can be integrated by displaying recent news announcements from blueprints in the banner of its Web pages.

So, here it is, the new new petstore. Download it now, and run it on the Java EE 5 SDK. See this page to learn about the various JSF components used in the petstore and how to use them in your applications for free. Finally, share your thoughts on this new petstore. We are keenly listening.





Using command-line Ant-based build structure that is Netbeans-friendly

Posted by inder on January 30, 2006 at 11:42 AM | Permalink | Comments (0)



Do you use Netbeans to write your Java EE applications? If so, did you ever want to run the build files through command-line only to discover that they can only be run through Netbeans? In this blog, I will describe how you can use the Java BluePrints build system to make your Netbeans generated Java EE projects command-line friendly.

The Java BluePrints Build System is essentially a set of Ant files that provide targets for compiling, deploying, undeploying, and running, Java EE projects with GlassFish. These ant files detect whether they were invoked from with-in Netbeans or from command-line and automatically either use Netbeans native build system, or the command-line targets. The result is that the project behaves like a native Netbeans project when loaded in Netbeans, while still completely usable from command-line.

You can download and use the early access release of the Java BluePrints build system from the Java BluePrints Conventions project. Start with reading the detailed (by my standards, at least) guide available in README.html after installation.

Please be aware that this is really early access code, with likely obviously broken things. Having said that, we have been using it in all of the applications in Java BluePrints Solutions Catalog quite successfully for a while..



A new version of the Java BluePrints Solutions Catalog for J2EE 1.4 is now available

Posted by inder on January 30, 2006 at 06:36 AM | Permalink | Comments (0)



The J2EE 1.4 SDK just got updated, and we could not be left behind with our solutions catalog that runs on it. This version of the solutions catalog uses J2EE 1.4, and covers the following topics:

• Asynchronous JavaScript and XML (AJAX)
• Web services
• Web Tier Design with JavaServer Faces
• Business Tier Design

Download it here.This version is also integrated in the Netbeans 4.1 and 5.0 IDEs: access it by clicking on "Java BluePrints Solutions Catalog" menu under "Help".

We have also been working on a solutions catalog for the upcoming Java EE 5 platform. You can get that version here.



Looking for a Great Recent College Grad

Posted by inder on December 05, 2005 at 04:04 PM | Permalink | Comments (0)



Update: This position is NOT available anymore. Please do not send any more resumes. Thanks!

We are hiring! We have an opening for a recent college graduate in the area of Java EE and XML. The position is in the Bay Area (Santa Clara), California. The candidate will be responsible for working with different technology and product teams to develop sample applications that will be bundled as part of Sun's Enterprise Application Server. Job requires a candidate with solid engineering and communication skills who is a team player and can work under pressure to create code samples that showcase the latest features of the Java Platform, Enterprise Edition.

Send me an email, if you are interested, or know someone who would be. We would love to get a super candidate who is strong in computer science fundamentals, algorithms, and is prolific in writing code. Minimum qualification is an MS in computer science.



Presentations on GlassFish and Java EE 5 at JavaPolis 2005

Posted by inder on December 05, 2005 at 01:52 PM | Permalink | Comments (1)

JavaPolis 2005 conference will take place Dec 12-16 in Antwerp, Belgium, and I will be attending it. This will be my first time at JavaPolis, and I am all excited to be there. I have heard lots of good things about the conference: seems like a small conference with high-quality speakers and attendees. I guess my only gripe is the time of the year: I wish it was a couple of months sooner; that would have made it pleasant, weather-wise. But I guess the positive side is that we will get more work done this way, and focus more on the conference itself, instead of on distractions like sight-seeing.

I will be presenting on two topics:

• Friday, Dec 16, 3:30pm-4:30pm: Java EE 5: How the Next Version of the J2EE Platform Greatly Simplifies the Development of Web-enabled Enterprise Applications
• Thursday, Dec 15, 3:30pm-4:30pm: GlassFish Community: Building An Open Source Java Application Server for the Java EE 5 Platform.

If you are going to the conference, and would like to meet up, drop me an email, or just show up at either of the sessions. It would be great to exchange ideas about how Java EE 5 and project GlassFish are affecting the world of enterprise Web applications.



Securing Web-application state stored on the clients and a lesson in ease of development using cryptography

Posted by inder on May 18, 2005 at 03:42 PM | Permalink | Comments (10)



Web applications can store their state on the client to reduce the server-side overheads, as well as solve problems like navigating through the browser back button. We wrote about the benefits and risks of storing state on the client in an FAQ entry on the Java BluePrints website a couple of years back. Recently, Greg Murray and I developed a reusable JSP tag and associated Java classes that JSP developers can use to store state on clients securely. This solution is described in detail in the Java BluePrints Solutions Catalog and Greg recently wrote a blog on the topic. In this blog, I will continue that discussion to present the various security aspects of our solution. I will also discuss a tip that the crypto library writers will, hopefully, use in the future to make crypo easy-to-use by regular Java developers.

The state that needs to be stored on the client is first serialized into a byte array. This byte array is then encrypted using industrial-strength 3DES with cipher-block-chaining (CBC) and an initialization vector. To make the content tamper-resistant, we then create a message authentication code (using HmacSHA1 algorithm) from the encrypted content and the initialization vector. The initialization vector, the message authentication code, and the encrypted content is then combined in a single byte array. Finally, this resulting byte array is converted into a base64 string which is stored in a hidden FORM field on the client.

This solution is secure because it uses a strong crypto algorithm and also uses a MAC for tamper-resistance. We also generate all the random numbers (for example, to generate the initialization vectors and the password) using the cryptographically-secure SecureRandom class. Note that the encryption keys are NEVER sent to the client or sent on the wire. These keys are used only on the server-side to encrypt and decrypt the state. One challenge is to decide what encryption keys to use. The encryption keys should not be known to the client, but still be associated with the client. We solve this problem by generating these keys from a password that is generated randomly and stored in the HttpSession. This strategy for key generation through password is pluggable in our solution and can be changed if needed.

Now to the lesson in ease of development: Why is the javax.crypto library so hard to use? To build my solution, I had to learn so many esoteric concepts like the various KeySpec classes, SecretKeyFactory, IVParameterFactory and so on. Note that this is over and above the crypto concepts that I needed to learn such as encryption algorithms, MAC algorithms, encryption keys, secure random, and initialization vectors. A user should NOT need to learn any of these concepts for most common uses of crypto. Ideally they will use a utility class like the one I wrote: ByteArrayGuard. The users of ByteArrayGuard just call the encrypt method passing in a byte array, and they get back a byte array of encrypted content. Similarly, for decryption they just call the decrypt method passing in the encrypted byte array and get back a decrypted byte array. I hope a future version of the crypto package will include such convenience classes or mechanisms so that crypto can be used (with default selection of algorithms) by regular Java programmers easily.

The source code from Java BluePrints Solutions Catalog including this reusable JSP tag library is available under a BSD style license. You are welcome to use it royalty-free.

I learnt all the cryptographic concepts from an excellent Stanford class CS255 taught by Dan Boneh. I highly recommend that class if you would like to learn more about cryptography.

What do you think about our solution? How can this reusable tag be improved? Is storing encryption passwords in HttpSession a good strategy? If not, how will you do it? And how about the crypto package? Do you think that it is too hard to use? If so, what are your suggestions for simplifying it?



Guidelines on using AJAX added to the Java BluePrints Solutions Catalog

Posted by inder on April 14, 2005 at 04:59 PM | Permalink | Comments (1)



Anyone who has used Flickr, GMail, Google Suggest, or Google Maps will realize that Web applications are not limited to plain and boring HTML-only user interfaces anymore. These applications provide very slick UIs and the hot, but not-so-new, technology behind them is Asynchronous JavaScript and XML (AJAX). We, the Java BluePrints team at Sun, are starting to address this area by developing a set of solutions around common use-cases where AJAX is applicable. This work is available through our java.net project Java BluePrints Solutions Catalog. We also provide working sample code that illustrates these guidelines. Check out the sample applications available under the java.net CVS. Note that AJAX is an emerging technology, and hence the solutions presented are, by no means, best practices. They are likely to change as this field develops further.

Have you used AJAX? What were some of the big pain points? Do the BluePrints solutions make sense? What additional use-cases would you like us to cover? Let us know, we would love to have feedback on this content.





Guidelines on using AJAX added to the Java BluePrints Solutions Catalog

Posted by inder on April 14, 2005 at 04:59 PM | Permalink | Comments (1)



Anyone who has used Flickr, GMail, Google Suggest, or Google Maps will realize that Web applications are not limited to plain and boring HTML-only user interfaces anymore. These applications provide very slick UIs and the hot, but not-so-new, technology behind them is Asynchronous JavaScript and XML (AJAX). We, the Java BluePrints team at Sun, are starting to address this area by developing a set of solutions around common use-cases where AJAX is applicable. This work is available through our java.net project Java BluePrints Solutions Catalog. We also provide working sample code that illustrates these guidelines. Check out the sample applications available under the java.net CVS. Note that AJAX is an emerging technology, and hence the solutions presented are, by no means, best practices. They are likely to change as this field develops further.

Have you used AJAX? What were some of the big pain points? Do the BluePrints solutions make sense? What additional use-cases would you like us to cover? Let us know, we would love to have feedback on this content.





Which do You Prefer: Properties or Environment Entries

Posted by inder on March 15, 2005 at 10:50 AM | Permalink | Comments (8)



J2EE applications, both Web and EJB, often need to set configurable parameters such as a timeout value, retry count, and so on. To avoid hardcoding some arbitrary values for these parameters in code, the applications need to externalize these values so that a deployer can change them without recompiling the code.

The portable solution in J2EE for such configurable parameters is environment entries as specified using env-entry in the deployment descriptors for a Web or EJB module. Here is an example (from Java BluePrints Adventure Builder Reference application):

<env-entry>
    <env-entry-name>param/OrderStatusTimerInitialExpiration</env-entry-name>
    <env-entry-type>java.lang.Integer</env-entry-type>
    <env-entry-value>1</env-entry-value>
</env-entry>
</code>

However, the same can also be achieved by using properties. Essentially, the developer externalizes these values in a property file, and loads up the properties at runtime. There are issues such as how to portably specify the location of the property file. If the property is not expected to be changed much (so a recompile/repackaging is okay) then the property file can be bundled with the classes, and then it can be portable looked up. If the properties are expected to be modified at deployment time (or later), then it gets tricky since then you need to ensure that the property file is available at a certain location in all deployments. This is often an annoyance even while developing the application, when more than one developer are working on the codebase, since the filepaths are often different for different developers.

The big advantage of using env-entries is that they are portable, and can be easily changed at the deployment time using the deployment tool provided by the application server. The main advantage of properties is that they are really simple to write, and avoid dealing with the deployment descriptors. It is also possible to write code such that the properties are allowed to change even at runtime.

So, which do you prefer, properties or enviroment entries?



SOA: A look from the reusability point of view

Posted by inder on June 02, 2004 at 05:25 PM | Permalink | Comments (7)



Service Oriented Architecture (SOA) is the new buzzword in the world of enterprise development these days. What does it really mean and why is it important? To me, it is just the evolution of software development trying to find the optimum unit of reusability. What exactly is being reused is what is being refined over the years.

First, the rage was structured programming epitomized by the C language. The focus in structured programming is on resuable functions. That is why we all took extensive care in writing each C function in its own file. The beauty of structured programming is its simplicity and performance. Most of the concepts in structured programming are quite easy to understand. Since the language constructs (automatic variables, function calls, basic types, pointers) map directly to the underlying hardware, a well-written C program can often achieve a very high level of performance.

However, the structured programming has its limitations as far as reusability is concerned. The problem is that the data is defined separately from the functions that operate on it, and the data is open to anyone for modifications. All data items are also in a single public namespace, so you have to ensure that they all have unique names. These limitations are usually not an issue for small projects, but for large projects involving hundreds of thousands lines of code spread over thousands of files, this can become quite a challenge. What happens is that most functions end up not being really reusable.

Then came object-oriented programming (OOP). OOP improved the unit of reusability by focussing on the reusability of objects. The key advantage here is that the data lives with the methods that operate on it. You can also define namespaces, for example, using the package facility in Java. You can also restrict who accesses which data. Other advantages include separation of interface with implementation, polymorphism through subclassing and method overloading. All of these help you define a simple formal interface that promotes reusability.

OOP came with a great promise but people started realizing that objects were probably too fine-grained as a unit of reusability. Thus software components were born. What people realized was that a class Account was not as reusable, but a component Customer (composed of multiple classes Account, Profile, Address, etc.) was. This notion of components was further extended (for example, by the J2EE platform), to include information such as resources, deployment descriptors to make it an even more complete unit of reusability.

Now let us look at the Service-oriented architectures (SOA). The focus here is not on software reusability but on Service reusability. The other approaches discussed above focussed on reusing a piece of code that was then deployed in a new system. SOA does not focus on a piece of code, but on a running service providing the same functionality. For example, instead of reusing the Customer component, I can use a Customer service that provide functionality to create, read, update and delete the customer, provide a service to login the customer, get their preferences and so on. SOA is also benefitting tremendously from Web services since an SOA can be based on Web services. A service in this world is available through SOAP over HTTP, and is published using WSDL. Note that SOA is not specific to Web-services, it can be implemented with any distributed system technology such as CORBA, RMI, etc. However, it is clear that the industry momentum is behind implementing SOA with Web services.

Is SOA really an improvement over the paradigms that precede it? I guess we will know the answer in a couple of years when we have more experience with it to know what works and what does not. However, some benefits are apparent: you need to know very little to use a service. Essentially you just look at its WSDL, which for a well-designed service focusses primarily on what you as a user need to know about the service. The reusability is high since the code is not available and hence everyone is forced to use the service through its interface. If your service is being used by many users, their demands will quickly ensure that you actually have something that is reusable. For that reason, SOA probably provides a very good unit of reusability. Moreover, since the each service is deployed in one place, it can be better controlled, managed, and evolved. Services can also be deployed on a variety of hardware/software platforms. For these reasons, SOA also enables outsourcing of services which adds to the business motivation.

Some of the downsides of an SOA are that you are forced into a distributed computing environment which is quite a challenging environment to operate in. All service invocations are remote calls and, hence have high overheads. If you thought remote EJBs were expensive, wait till you make a SOAP call. A distributed system also comes with enormous security considerations, especially when using a public network. A distributed system also needs to take into account the fact that other nodes in the system can fail or may become overloaded. The versioning of the service may also be a challenge: the remote service may be running a different version of the software or the protocols. As a user of the service, you may not be able to do anything about it but be forced to adapt.





This work is licensed under a Creative Commons License.



Powered by
Movable Type 3.01D