October 2005

Monthly Archive

IASA Meeting Tonight – Managing Investment Across the Project Life Cycle

Posted by on 29 Oct 2005 | Tagged as: IASA

Tonight we are having our monthly Puget Sound IASA meeting on the topic of “Managing Investment Across the Project Life Cycle”. Here is the abstract for tonight‘s meeting:

Scott Came, Monica Yap, and Tamara Sulaiman will be conducting a panel discussion about managing investment in projects from conception to delivery. Scott will discuss how enterprise architecture can be used as a mechanism to guide enterprise technology investment planning, and will illustrate how state government is doing so. Scott will also touch on SOA, and how to view technology investments as the provisioning of capabilities rather than technologies per se. Monica Yap will be discussing how her project teams are meeting investment costs through lean development methods and portfolio P&L (profit & loss) to validate business value. Tamara Sulaiman will discuss how she manages earned value by applying waterfall calculation techniques to agile projects.

Meeting Location:
Microsoft Campus – Building 43, Room 1560
Jefferson Room
Map: http://research.microsoft.com/projects/gridforum/campus.gif

If you are in the Seattle metropolitan area tonight, come and check out the local IASA meeting. It is usually a place of great discussions and intelligent thoughts. I learn a lot while at the meetings. See you there.

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.

NFJS 2005 in Redmond

Posted by on 18 Oct 2005 | Tagged as: General

I spent the last weekend attending the best conference in the land, No Fluff Just Stuff. If you haven‘t been to this Friday-Sunday event, go to it when it‘s in your town. There are no vendors to derail you into web services or ESB. Just good ol‘ software development tools, howtos, and methodologies.

Right from the start, I must state that I think David Hussman is the best speaker that I have seen. Besides the incredible amount of information that he delivered in his presentations regarding agile methodologies such as XP and Scrum, he also created an amazing feeling within the room with his presence. If you are even semi-interested in agile methodologies you should attend one of his talks. I think that it could be the talk which takes you over the wall to running your projects agile.

On Saturday, I attended a BOF session on software architecture with Mark Richards of IBM and Neal Ford of ThoughtWorks hosting. We had a magnificent conversation about what we do as software architects. I was most impressed that the concepts of test-driven development was brought up during this conversation and used as a basis for technical architecture. Lately, I have been involved with colleagues who have introduced me to Fit which is a tool for “enhancing collaboration during software development”. It is used by tools such as Fitnesse and Selenium to create acceptance tests using a library of fixtures for things such as web, .NET, and Java applications. They allow a team to work with their customer on creating acceptance test criteria which will show when your user stories have been completed. This can be a very liberating tool for software developers when faced with tight deadlines with continually moving release dates.

A buzz was eminating from the speakers regarding Ruby. Since many of the speakers are quite influential in the open source development domain there may be a flash flood of Ruby work in the near future. Considering the capabilities of Ruby in the real world, I can't see it becoming a sustained movement. Konstantin Ignatyev posted a great message on the Seattle Java users group mailing list with details regarding this topic which I entirely agree with.

All in all, this was a great conference. I could not do it justice to regurgitate what I heard and learned at this conference. When it comes to your town, just attend. You won‘t be disappointed.

Nokia Communicator 9500 and J2ME

Posted by on 10 Oct 2005 | Tagged as: Java

I am currently working on a project which allows me to get down and dirty with J2ME on multiple devices. My main focus has been on the Nokia Communicator 9500 which has a flip-up application screen and a full keyboard.

I ran into a huge issue using the new JSR 75 – PIM and file system access optional packages for the J2ME platform. The Nokia Communicator 9500 has both the CLDC 1.1 with MIDP 2.0 profile and the CDC with personal profile support. When I looked at the specifications for the phone, it gives the following J2ME options which are supported:

CLDC 1.1
Wireless Messaging API (JSR-120)
Mobile Media API (JSR-135)
CDC (JSR-36)
Foundation Profile (JSR-46)
Personal Profile (JSR-62)
FileConnection and PIM API (JSR-75)
Bluetooth API (JSR-82 No OBEX)
MIDP 2.0
Nokia UI API

After looking at this list, I was quite sure that the phone must support JSR 75 optional package on it‘s CLDC 1.1 with MIDP 2.0 profile. This is not entirely correct. I found out in this article that the JSR 75 support was only available in the CDC/Personal profile runtime. This is somewhat correct, but even this is not the extent of the situation. Here are three different scenarios which further extract what the actual state of JSR 75 support is on this phone:

  • Untrusted (without signed MIDlet) – JSR 75 API calls work but with annoying questions each time you access the file system or PIM categories. If you are doing much of this type of access (using the JSR 75 API normally) then this would make your application mostly unusable.
  • Trusted with MIDlet-Permissions set for JSR 75 access – The application will not even install on the phone.
  • Trusted without asking JSR 75 permissions – The application installs on the phone, but once you actually make a JSR 75 API call it breaks.

Now, if the application did not even have access to the JSR 75 API in untrusted installations I would not have “much” of a problem, but that is not the case as you can see above. Instead, they allow the API access from CLDC mode which makes the application quite annoying with all of the questions prompted to the user.

My reason for posting this is not neccessarily for the Nokia Communicator J2ME developers only, but to the J2ME community as a whole. There are many issues in this arena with the same type of conditional behavior. We need to let the device manufacturers know about these problems so that they may be remedied in the near future. The promise of the J2ME environment is substantial and therefore it needs a strong feedback loop from the developers and vendors to make it work.

The Context is What Matters

Posted by on 06 Oct 2005 | Tagged as: General

Lately, I have been in many discussions regarding best practices and patterns. The discussions started out with an attempt at defining “what is a ‘best practice‘?“. While speaking about the relevance of a “best practice”, I saw this blog entry from Ted Neward which asserted there is no such thing as a best practice. After much debate, I agree with this assessment. Without a context there seems to be no “best practice“. When there is a context there are usually multiple practices which can bring successful results in that context.

From this, we started to have discussions on whether a “best practice“ can be defined as a pattern to achieve success within a context. If an organization defines “best practices“ which are to be used within their designated contexts would this enable higher business success? I believe that the first paragraph somewhat answers this question. If there are two contexts which look similar in nature, is it always correct to use the same “best practice“? Since there may be many practices which will succeed within the defined contexts similarities, would it not be more agile to choose the practice which is better suited at that point in time?

During one of my conversations with a colleague, I remembered some of the thoughts that I had a couple of years ago regarding design patterns. Design patterns are defined in terms of a context and can be implemented in multiple ways depending upon the circumstances of the context. In order to use design patterns in software, a developer must either have access to a library of design patterns or they are using them from experience with the context. In either case, experience is a required attribute of the developer. In the case of a design patterns library, I believe that the lack of success for CASE tools has shown weaknesses in the ability to gather design patterns into a valuable library. With many companies hiring developers with less experience, the use of design pattern libraries becomes a detriment rather than an asset. These developers are more worried about syntax, data structures, and learning APIs than whether to use a “composite“ or “decorator” design pattern.

This all leads me back to the experienced developer who has worked within the context before and has found viable solutions for it. What is the important part of this equation in creating or finding solutions? I believe it to be the context itself. If we can define a library of contexts within a domain, such as software development or requirements gathering, we may then gather contributions from our teams into a useful knowledge management system. Without the contexts, it will be near impossible to find practices which are helpful to those looking for practices to use in their current contexts. Also, the library of contexts should be continually refactored by the teams in order to keep them current.

All of this could have been somewhat derived from Ted‘s original blog entry and probably is within some knowledge management theory paper somewhere. Books and magazines have been an outlet, as well, for the definition of contexts in some respects but I believe that most are not focused enough to define real world contexts. I think this topic is important to solve as we move towards real-time competitive markets and our IT infrastructure is further challenged with providing the competitive edge.

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.