January 2006

Monthly Archive

The Success Factor – Lisp?

Posted by on 23 Jan 2006 | Tagged as: Software Architecture

Right out of the gate, I will let everybody out there know that I only know Lisp from configuring my Emacs environment. Lately, I have been reading many articles and blog entries regarding Lisp along with Python and Scheme.

This blog entry from Bill Clementson, Lisp is for Entrepreneurs, really got my attention. Over the years I have been quite successful in most of my projects using Java (including J2EE/J2ME as well), C/C++, and even PERL. Based on these experiences I have found Java easiest to develop applications in. This includes the J2EE APIs which have come under fire over the past few years.

Due to my ignorance of Lisp for application development, I was bewildered by how Lisp had such an impact in time to market for both organizations in the article, Viaweb and Naughty Dog. This perception of Lisp‘s impact on their product‘s time to market from the developers interested me enough to start some more research on it. Also, to pursue some of the other languages, such as Python and Scheme, to learn how they may improve project delivery.

I am continually looking for ways to improve development team productivity through language, development style, and framework usage. Most of the recent development improvements I have seen came from service-oriented and test-driven application development methods. I hope to find another route through programming language to further improvement.

Let me know if you have any ideas on the subject of alternative languages for improving application development productivity. I am quite eager to learn more from others with good and bad experiences in this arena.

Jini – An SOA for the LAN

Posted by on 19 Jan 2006 | Tagged as: Jini/JavaSpaces

On Tuesday, I had the pleasure of presenting on Jini at the Seattle Java Users Group meeting. During the presentation I found myself speaking about the importance of mobile code in developing an SOA solution. Attempting to define SOA in an explicit way seems to be a daunting challenge. Most of the definitions that I come across tend to include web services as the building block of choice. I do agree that the use of web services at the edge of our LAN makes sense. When two entities have interest in sharing data between themselves, WSDL lends itself well to defining service contracts between those entities. Also, vendor and community support of web service standards increases it‘s value for such usage.

Inside the LAN, there are many other alternatives to web services which may improve our service-oriented environments. They can do this by increasing network performance through creation of smaller data sets to transfer, decreasing computational power needed to unmarshall the data sets, and mobile code in their support of mobile agents and smart proxies. There are many technology platforms which pose a viable alternative to web services on the LAN and meet some or all of the improvements mentioned. One of those technology platforms is Jini.

Jini by itself does not solve the problem but containers built on top of the Jini platform do. Containers remove some of the Jini programming complexity by handling codebase downloading and service deployment. Here are a few example containers:

  • Rio – A dynamic services platform which involves a federation of container nodes onto which services are deployed. Upon deployment of a service, the platform identifies nodes which meet the service level agreement (SLA) declared in the Rio deployment descriptor called an operational string.
  • Harvester – A container environment for Jini services and clients. A particularly interesting feature of Harvester is it's ability to load services and clients written in the Python language.
  • Neon – An agent framework and application grid fabric which allows your Jini services to be deployed without writing all of the associated plumbing code. An good introduction to Neon's capabilities may be found here.

Mobile code is an important reason why Jini is a good alternative to web services on the LAN. Many Java developers are aware of RMI (remote method invocation) but have not heard of the Jini RMI impelementation called JERI (Jini extensible remote invocation). JERI provides important features over it‘s older counterpart: a pluggable transport layer with security support, an extensible marshalling layer, and runtime configuration. JERI provides the ability to export your service proxy for use by a remote service consumer. Your proxy class may be a “smart” proxy which means that some, if not all, invocation processing is performed using the consumer‘s resources.

A basic case for using a smart proxy is the calculation of tax versus gratuity. The process of calculating tax for an electronic order may include identification of local tax codes. The order itself may contain items with different tax calculations. Calculating the tax on an order lends itself better to server side processing. Gratuity, on the other hand, is based on a particular percentage of the order. At some restaurants I have seen a 15% gratuity either added to the bill because I was part of a large party or printed so that I don‘t have to calculate it myself. Calculating 15% on your order is quite simple and could easily be done on the client side. Here is some example code of what the service proxy may look like:

import java.rmi.Remote;

public class OrderProcessor implements IOrderProcessor {

private Remote remoteService = null;

public OrderProcessor(Remote remoteService) {
this.remoteService = remoteService;

public Money calculateTax(Order order) {

public Money calculateGratuity(Order order) {
return new Money(order.getSubTotal() * 0.15f);


As you can see, only the calculateTax(Order) method invokes a remote service call. Not everyone will have this particular use case but I am sure that if we take another look at our service calls we will see similar scenarios. For instance, validation of input is another potential candidate for smart proxies. Before making the remote call you can validate that the data created by a user is correct. Some web application developers use a similar method by validating input using JavaScript in the client‘s web browser.

In conclusion, a strict definition of SOA as web services and XML messaging may blind us to supporting technologies. As we consume SODA (Service-Oriented Development of Applications) into our software development conscience we should keep in mind that service implementations may be achieved by other supportive technologies. Jini services may be exposed at the edge of the LAN through web services. For that matter, a web service may be exposed which could interact with multiple Jini services depending upon it's need. As Dan Creswell wrote in a comment on one of my previous posts:

Possibly the biggest thing that these companies have done is accept that one technology doesn‘t address all problems thus they‘ve stopped relying just on app servers and RDBMS or WebServices or JINI/JavaSpaces. Rather they knit them all together with well separated roles and responsibilities and keep everything behind interfaces…

Presentation on "The Jini Landscape" to SeaJUG Tomorrow

Posted by on 16 Jan 2006 | Tagged as: Jini/JavaSpaces

Tomorrow night I will be presenting “The Jini Landscape” to the Seattle Java Users Group at 7pm. If you are in the Seattle metropolitan area, please stop by. I am anxious to find out the level of Java community interest in Jini and the questions that will arise from this topic.

Also, if you have any recommendations on the slides, please let me know through this entry‘s comment section. Thanks.

Maven Jini Plug-in Version 2.0 Released

Posted by on 12 Jan 2006 | Tagged as: Jini/JavaSpaces

The Maven Jini plug-in has been released at version 2.0. Installation instructions may be found at http://maven-jini-plugin.jini.org/. The 2.0 release allows a users to:

  • Archetype for Jini service project creation
  • Starting/Stopping of Jini starter kit services: Reggie, Mahalo, Phoenix, Fiddler, Norm, Mercury, Outrigger, Browser, and HTTP daemon
  • Configurable RMI runtime: JRMP, JERI, or JERI/JSSE
  • Configurable activation and persistence modes: transient, activatable, nonactivatable

Basic usage instructions are available at http://maven-jini-plugin.jini.org/. Please try it out and let me know if you have any issues.

Perspective on Maven 2.0

Posted by on 04 Jan 2006 | Tagged as: Maven

The Maven version 2.0 release is definitely an advancement for business-driven software development. Many organizations struggle to keep up with all of their IT projects and the high cost of maintenance due to differing project build, documentation, design, and deployment processes. Maven is a great tool to help alleviate these costs by creating structure across projects and still allowing implementors to innovate within their own internal team processes. These processes are usually provided as Maven plug-ins, also called Mojos, which can be shared with other projects.

An extremely interesting result of the 2.0 release is the extension capabilities of the architecture. Carlos Sanchez wrote a blog entry recently entitled “Maven Ruby Mojo Support”. This support for other languages inside Maven is a great benefit to the overall tool usage. With the increased popularity of interoperable platforms such as Java and .NET, all of these projects can have the same build tool. This ability would decrease project delivery, maintenance, and deployment costs tremendously for an organization who uses the tool wisely. This link shows the support for other languages in Maven 2.0. Besides the C and C++ plug-ins shown there, a C# plug-in is being created which will support compiling with the Windows .NET and Mono compilers along with NUnit and Visual Studio project support.

My own experience with writing a Maven 2.0 plug-in was extremely pleasant. The Maven Jini plug-in was originally created for Maven version 1.1 and took approximately 2 weeks to create due to issues with Jelly. Using the new Java Mojo style of developing plug-ins for version 2.0, I recreated the functionality of the original plug-in within 1 day. The Maven Jini plug-in version 2.0 will be released in the next couple of days on the default Maven 2.0 repository at http://www.ibiblio.org/maven2/. Please go to the Maven Jini plug-in home page for more details on how to use it.

Overall, Maven 2.0 is well worth the investment to learn about it‘s capabilities. There are multiple improvements over the 1.x versions such as transitive dependencies, performance, configurable build life cycle, built-in multiple project handling, and a highly flexible architecture to build upon. I recommend taking it out for a spin if you get a chance.