Inderjeet Singh's Blog

Web Services and XML Archives

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

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..

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

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

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.

SOA: A look from the reusability point of view

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.