Archived Posts from this Category

My Talk @ SD West 2009 on “Managing Software Debt”

Posted by on 27 Mar 2009 | Tagged as: Acceptance Testing, Agile, Architecture, Distributed Computing, DotNet, General, IASA, Java, Jini/JavaSpaces, Leadership, Maven, Open Source, Podcasts, Product Owner, Ruby, Scrum, Software Architecture, TDD, User Stories, XP

I have uploaded the talk I did at SD West 2009 on Yahoo! Video and here it is:

The Maven Jini Project has Moved

Posted by on 11 May 2006 | Tagged as: Jini/JavaSpaces

A very exciting announcement was sent to the JINI-USERS mailing list on April 12th which I hope will rejuvenate Jini technology. One of the items mentioned was the possible incubation of Jini/JavaSpaces as an Apache project. In my humble opinion, I see this as a great move for Jini technology. Jini has lived in a world where many were not sure about the licensing and Sun‘s support of the product in marketing and financial terms. I think that Sun has done a great job over the past couple of years in working with the Jini community which lead to this point.

Another item mentioned was the need for relocating the projects which lived on the jini.org web site. This means that I have to move the Maven Jini plugin from it's old jini.org location. I made the move last night and am awaiting approval from the java.net administration for the project. It is already up and running at https://maven-jini-plugin.dev.java.net/.

If you are using the Maven Jini plugin, let me know if and how it has worked out for you. Also, send me any things that you would like to see in the plugin. Thanks.

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.

Maven Jini Plug-in Version 1.0 Released

Posted by on 25 Oct 2005 | Tagged as: Jini/JavaSpaces

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

  • Generate a Jini service project by running the “jini:genapp” goal
  • Starting/Stopping of Jini starter kit services: Reggie, Mahalo, Phoenix, Fiddler, Norm, Mercury, Outrigger, Browser, and HTTP daemon
  • Configurable RMI runtime using either JRMP, JERI, or JERI/JSSE

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

Declarative Programming in Jini/JERI/RMI – (Annotations)

Posted by on 03 Oct 2005 | Tagged as: Jini/JavaSpaces

I am working on a personal project right now where I am developing Jini-aware services. Working with a “true” SOA is quite nice once you have the mindset. There are a few areas of Jini development which still cause me some grief though:

  • Jini starter kit distribution- the lack of base service startup scripts for the reference implementation which are downloaded with the starter kit bundle
  • Security – the creation of policy files can be somewhat tedious
  • Proxies – choosing and implementing different proxy options can also be somewhat tedious
  • Proprietary configuration – this is not as big of a deal, but it would be nice to have options in this area and many have created such options (RIO for instance)

I have initiated an attempt at alleviating grief point number one above, the lack of scripts for base reference implementation services in the Jini starter kit bundle, by creating a Maven Jini plug-in which downloads the starter kit, starts the services, and generates a generic service project. Unfortunately, the next two are entirely different and complicated beasts and the last is just a personal problem.

To tackle such large beasts in a distributed system framework, such as Jini, I am thinking initially that these considerations in your services should be done at object/class level and at a service distribution level. Within a service, there is the possibility to have a complicated security policy file to describe Java runtime access permissions.

grant codeBase "file:${jiniHome}${/}lib${/}jsk-lib.jar" {
permission java.security.AllPermission;

grant codeBase "file:${jiniHome}${/}lib${/}reggie.jar" {

permission java.lang.RuntimePermission "accessDeclaredMembers";
permission java.lang.RuntimePermission "accessClassInPackage.sun.util.logging.resources";
permission java.lang.RuntimePermission "accessClassInPackage.sun.net.www.protocol.c";
permission java.lang.RuntimePermission "getClassLoader";

permission java.io.FilePermission "${appHome}${/}example${/}reggie${/}jeri${/}config${/}activatable-reggie.config", "read";
permission java.io.FilePermission "${appHome}${/}example${/}reggie${/}jeri${/}config${/}nonactivatable-reggie.config", "read";
permission java.io.FilePermission "${appHome}${/}example${/}reggie${/}jeri${/}config${/}transient-reggie.config", "read";

permission java.io.FilePermission "${persistDir}",      "read,write,delete";
permission java.io.FilePermission "${persistDir}${/}-", "read,write,delete";
permission java.io.FilePermission "${java.io.tmpdir}jeri-reggie-log",      "read,write,delete";
permission java.io.FilePermission "${java.io.tmpdir}jeri-reggie-log${/}-", "read,write,delete";
permission java.io.FilePermission "${/}tmp${/}jeri-reggie-log",      "read,write,delete";
permission java.io.FilePermission "${/}tmp${/}jeri-reggie-log${/}-", "read,write,delete";

permission java.net.SocketPermission "", "connect,accept";
permission java.net.SocketPermission "", "connect,accept";
permission java.net.SocketPermission "*", "resolve";
permission java.net.SocketPermission "*:1024-", "connect,accept";
permission java.net.SocketPermission "*:80", "connect";

permission java.util.PropertyPermission "java.io.tmpdir",   "read";
permission java.util.PropertyPermission "serverHost",       "read";
permission java.util.PropertyPermission "serviceClasspath", "read";
permission java.util.PropertyPermission "serviceConfig",    "read";
permission java.util.PropertyPermission "serviceName",      "read";
permission java.util.PropertyPermission "interfaceName",    "read";
permission java.util.PropertyPermission "implName",         "read";
permission java.util.PropertyPermission "persistDir",       "read";
permission java.util.PropertyPermission "jiniHome",         "read";
permission java.util.PropertyPermission "appHome",          "read";

permission net.jini.discovery.DiscoveryPermission "*";
permission net.jini.export.ExportPermission "exportRemoteInterface.com.sun.jini.reggie.Registrar";

permission com.sun.jini.phoenix.MonitorPermission "java.rmi.activation.ActivationMonitor.inactiveObject";
permission com.sun.jini.phoenix.SystemPermission "java.rmi.activation.ActivationSystem.unregisterObject";

grant {
permission java.util.PropertyPermission "com.sun.jini.reggie.enableImplToStubReplacement", "read";

This is the policy description created by Brian Murphy for launching Reggie using his reference implementation startup scripts. By the way, this is downloaded automatically when using the Maven Jini plug-in to launch the starter kit services. At first glance of these policy files, I thought that these might be a good candidate for annotations. Then after some brief thought and a little bit of clarity I remembered what I think is a great rule of thumb for deciding on usage of annotations, “Is the configuration in question class level meta data?”. Most of the above policy declarations have to do with external resources or remote access permissions.

So, I then moved on to proxy implementation options. If you look at Chapter 11: Choices for Service Architecture in Jan Newmarch's Guide to Jini Technologies you will see a large selection of proxy implementations depending upon your need to do all processing on the service host, some processing on the service host and some on the client side, or move all the code to the client for processing. Another variable in the proxy implementation decision could be whether you want to use RMI or not. The introduction of JERI as the preferred RMI implementation to use with Jini services has allowed a lot of flexibility in conjunction with the Jini 2.x configuration framework. Yes, I mention this configuration framework in the general grief area of this blog entry, but that is only regarding the proprietary syntax implementation for which you could develop your own version based upon the interfaces in this package.

Although there is the capability to develop your service launcher in an infinite number of ways, I think it would be a substantial “ease of use” feature to enable a significant set of these proxy options using annotations. An example might be something like the following:

public class MyServiceImpl implements IMyService, java.io.Serializable {

public MyServiceImpl(String[] configArgs) {


This would hopefully generate your main service starter class with proxy registration for clients to locate your service. Besides allowing the developer to create their generic Jini-aware services easily, this could also allow developers who wish to use the service to gain neccessary usage information quickly by acknowledging the generic proxy usage requirements.

While looking around for others who have commented on the subject of annotations and Jini (either directly or indirectly), I ran into this article at Clark Richey's blog about Jini accomplishing 80% of the perfect SOA qualities. He describes the last 20% missing in Jini being derived from it‘s ease of use or lack there of. I entirely agree with Clark on this subject and believe it is up to the Jini community to create the missing linkages for enabling developers in the use of Jini related technologies. If there are others out there who believe that annotations could alleviate some of the barriers to Jini development or somebody has another idea that they believe is better, I would be more than happy to help in developing a community project to implement it.

As a side note to this whole conversation, I thought it would be a good to post an article to reminisce on the launch of Davis (Jini 2.0), Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo. Also, since I mentioned Jan Newmarch, I thought that I would plug his book which I think is possibly the best reference on Jini so far, A Programmer's Guide to Jini Technology.

Jini Dependencies Now in Ibiblio.org Maven Repository

Posted by on 28 Sep 2005 | Tagged as: Jini/JavaSpaces

After some restructuring and multiple submissions, the Jini starter kit jars and the starter kit zip archive itself are now located at the main Maven repository. You may find these artifacts in the net.jini and com.sun.jini groupId directories. I did notice that the Jini starter kit and the start example scripts from Brian Murphy were not located on the site yet, but the POM and license for each were. I am hoping that the site will show these zip archives by morning.

I will be releasing the Maven Jini plug-in code into the project web site. The document on how to build or install the plug-in will be following in the next few days.

Odds and Ends

Posted by on 27 Sep 2005 | Tagged as: Jini/JavaSpaces

I have progressed a bit on the Maven Jini plug-in over the past few weeks in my spare time. It has been quite an experience working with Jelly, JEXL, and Ant commands to create a somewhat cohesive environment. I have learned many of the limitations with Maven in terms of property and variable scope, advanced Ant support, and how my own assumptions can lead me down some tedious paths.

All in all, the plug-in is almost ready to release for consumption by others who are interested. I will most likely put the code up on the main Jini site in the Maven Jini plug-in project's source code repository for others to download. Also, I will create a page to describe how users may install the plug-in from this remote site into their local Maven cache. Although this project has not taken much time to create, I think that I have only touched the surface of what the plug-in will probably be after another iteration and more hands working on it. I hope to get some participation by those in the Jini community who see the advantages of integrating their projects into a strong project management tool such as Maven.

Also, over the past few weeks, I have come across the archaic world of signing J2ME MIDlet archives. I have to say that the process is quite an experience. The certificate authorities chosen by each device, key size constraints, and key algorithm constraints have all led me into a very gnarly endeavor of aligning these all into a successful build procedure for the product. So far there has been no success, but I am seeing a small nugget of hope in my Google trails for an answer. Hopefully I will come away with something that can be used by others and maybe even be helpful to the J2ME Ant task called Antenna.

If anybody has some ideas on the MIDlet signing issues I am having, please contact me. I would be thrilled to hear of some successes in this area.

Jim Waldo's Talk on SOA

Posted by on 17 Sep 2005 | Tagged as: Jini/JavaSpaces

All of you who are already on the Jini users mailing list probably have already heard about this great talk put on by Jim Waldo, a distinguished engineer at Sun Microsystems. I believe the ideas delivered during this talk are some of the most important for the true revolution in technology and business. The reason I believe this is because of our current stalemate in business technology with reliance on relational databases, XML, and physical software installations.

There must be a better way to enable business in the next technology wave. I think that this is the realization of “the network is the computer” idea. Managed services are appearing in many forms such as in JBI (Java Business Integration) with ESB (Enterprise Service Bus), Microsoft‘s BizTalk, and some other EAI enabling technologies such as Tibco‘s Rendezvous. Many of these technologies bring their own view on the technology future, but in my opinion they do not bring a large advantage to our current software methods.

There seems to be another family of technologies which have network awareness such as Jini, Globus OGSA, and SUMO (Suggested Upper Merged Ontology) for agent messaging models. Over the past few years, like others in the Jini community I have been trying to figure out how to enable business in embracing this network awareness for a financial advantage. I have met a few people in the Jini community who have had success in this area such as GigaSpaces and some people who are working on Wall Street.

Although there has been some success and particular markets have seen the advantages, there has not been a large movement in the enterprise. I think that the relational database is a technology which has started to show it‘s limitations. A few years ago there were OODB (Object-oriented Database) vendors trying to cross the data storage barrier set by relational databases. They did not succeed at a scale which was noticible in this huge market, but they did increase awareness of the limitations. Now that we have broadband in a substantial amount of homes and almost every business, the network has come of age. Those who create the data, enable the data, and position the data on the network will probably hold an advantage over the current persistence with reporting model.

The push for real-time data feeds, security data policies, and terrorism or natural disaster response should drive technology into this new era of network awareness. Which technologies and vendors will get in front of this push is still up in the air. I hope that Jini didn‘t already miss it‘s chance by being too forward thinking. I think it is a great technology which is enhanced by great services such as Rio, GigaSpaces, ServiceUI, and Neon. I hope that those of you who have been burnt by their use of Jini in the past will try it again with open minds. And those of you who have not seen this technology in action, please check it out. I believe it‘s time is coming.

Next Page »