Jini Dependencies Now in Ibiblio.org Maven Repository

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.

Open Spaces in SIG Meeting

Tomorrow night we are having our monthly IASA (International Association of Software Architects) Puget Sound chapter meeting in the Jefferson Room, building 43 room 1560, located on the Microsoft Campus. We are going to be trying out a new way to conduct the meeting, “open spaces”.

We are deviating somewhat from one of the principles that there is no pre-planned topic or speaker. We are declaring two topics, “SOA Best Practices“ and “What is architecture?”, but we are not going to force these topics to play out for the entire meeting. The reason for the deviation was an attempt to get past the initial shock of that one might feel initially. Hopefully, by having a topic to begin with there will be a quicker initiation into the actual discussion.

I will have some paper available to the group which will hopefully contain some interesting thoughts at the end of the meeting. The ultimate intent is to drive the topics into something that the group decides is worth discussing rather than holding to the original topics. If this happens, I would call this meeting a success.

Odds and Ends

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

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.

AJAX with DWR

I have been working on some personal projects using DWR. When it comes to web frameworks which are easy to work with, I haven't seen any that top this one. Besides the great "Getting Started" tutorial, there are also some examples around the web linked to here.

I believe that the biggest features of this project are ease of use and the separation between design and development it creates. The basic idea of DWR is to expose POJO as JavaScript objects for use on the client. Once you make a POJO available via the dwr.xml configuration file, you can import the resulting JavaScript source like this:

<script type="javascript" src="/dwr/interface/MyPojo.js">

The framework has many useful features such as:

  • Utilities to map data to callback script functions
  • Remote Call Batching – Similar to a Transaction of Remote Service Calls
  • Remote Call Ordering – Since AJAX is Asynchronous, this allows for Ordering the Responses
  • Error and Warning Callback Handler Functions
  • Remoting Pre and Post Hooks – These Hooks are Called whenever Remote Calls are Made or Finished
  • Access to Servlet Session Objects – Allows ExecutionContext.get().getServletContext()
  • Struts, Hibernate, and Spring Integration

A very important aspect to consider when using DWR is security. Since a user is exposing their Java code via generated JavaScript classes, you have to make sure that only your application is allowed access to these functions.

For those of you who are experienced in web design, JavaScript, and Java, I think that you will find this framework to be quite elegant.

Data Management for the Future

I have been rambling to colleagues about how much I despise relational databases for many reasons. These include the hierarchical formation of data, the finite set of relationships between tables, their inability to distribute themselves, and the maintenance overhead that they create for application and integration development projects.

One approach that I thought was a very viable alternative to the relational database is a grid of services with the ability to persist only those data elements which are worth the effort. I would contend that a large amount of current data sets do not need to be persisted into a relational database and are either temporary or reference data. Persisting this type of data becomes a hindrance to maintenance objectives as a database grows over time and possibly, or even probably, after an initial release.

I happened to have a magazine laying around that I got at the Java One Conference this year. It was the Dr. Dobbs Journal which had an article called High-Performance Data Management with Java inside. This was quite a coincidence since I had just come back from a lunch conversation with some colleagues where I was trying to communicate my distaste for relational databases and the use of grids for data access as an alternative. I thought that the article was a great overview of this approach to data management. The sub title for the article I thought described the high level parts quite well:

On-disk persistent storage, in-memory data storage, & cache management

If you get a chance, please take a look at the article. I hope to see a revolution in the data persistence layer of our future applications which will remove some shortcomings of the current relational hell.

The Perks of Being "Lean"

Mary Poppendieck (of Poppendieck,LLC) just gave a talk on “Lean Softwae Development” in Redmond, WA. I must say that I was impressed with her engaging speaking style and the amount of detail and examples she was able to cram into a 90 minute talk. There were three specific comments which interested me the most during this talk:

  1. Software architectural design – I am paraphrasing this but a question was asked whether there was a tension between Lean and Agile methodologies and the use of software architectural design. I thought the answer from Mary on this subject was quite inspirational. She said yes there is a tension, but there are definitely contexts in which smart design is the most agile or lean route. There are some people who are able to either perceive issues or flexibility in a design before there are specific customer needs. I believe that specific experience and domain knowledge within a group are driving factors into whether these types of design decisions should be made.
  2. Try more than one implementation of a design – If a developer is not sure about a specific design implementation or framework, then implement the design in multiple ways and then choose the best one based on your objectives. This was somewhat surprising since it seemed to go against the main “lean” principle, “Deliver Value Quickly, Efficiently, Reliably”. If you are implementing your design in multiple ways, isn't this making you less efficient? The answer is no since you are finding the most reliable method of implementing the module and there may be lessons learned for other projects which will have objectives more inline with one of those methods not chosen. There are other reasons that Mary gave and I wish that I could remember them all, but I waited too many days to blog on this subject. ;>)
  3. Deploying quicker as a fiscal advantage – There was a great graph which Mary used to describe this point. The first version of the graph showed a product which pushed the release out to encompass the growing feature set. This was to show that there was a growing burn rate over the product development cycle and that it took more time to see value returned from the product. In the second graph, she depicted 2 releases in the same time frame as the original product release which decreased the burn rate and got value from the company's product investment quicker. The “release quick and often” concept allows for earlier feedback and therefore a product which is also more in tune with your client's needs and desires.

Overall, there was so much information that I am still digesting it through thought provoking conversation with friends and my own imaginary assessment of how it could have helped projects I was involved with in the past. If you get a chance to attend one of Mary‘s seminars, please do. You won‘t regret it.

Alternatives to Current Jini Configuration Scripting

When first working with the Jini 2.0 betas a while back, I quickly became aware of the new configuration scripts which had a Java-like syntax. I liked the idea of a more programmatic configuration because I thought it might be more robust. Since I was somewhat enthralled with the idea of this type of configuration, I think that I lost site of the bigger picture. Who is going to configure my services in a production environment?

Recently I spoke with a detractor of the 2.x configuration approach. He gave some good examples of why this approach may be unappealing such as it‘s close relationship to Java, but not quite Java feeling. Now, he did go further in a direction I didn‘t expect and that is to create a configuration approach based entirely on Java classes. This made me think more about what would be a good approach for configuration of Jini services in a production environment.

I came up with some possible ideas for Jini service configuration: JavaScript, XML, dependency injection, and Apache-like properties files. It looks like the usual suspects to me. So, I asked a friend of mine who is a system administrator what they thought would be the best mechanism. This person had a small bout with a Jini production system in the 1.x days and I thought they could provide me with some good answers on both fronts. Their response was that the service developers could provide any mechanism for their distribution configuration that they wished, but that it was probably a better choice to provide a nice user interface to control the deployment and runtime configuration for production systems. This is probably the basis for AdminUI and ServiceUI in the overall scheme of things.

Well, that gets me back to the base service module configuration. How do we configure Jini services with their security policies, exporters, communication protocols, and service specific options? I was at a Seattle mobile SIG a couple months back and there was a product presentation which spoke about JavaScript configuration deployment from a carrier administration console to their application running on a customer‘s mobile device. The company‘s name is SnapIn, located in downtown Seattle, and their speaker was Tom Trinnear who is a well respected figure in the telecommunications community. Is this scheme of allowing the mobile operators to deploy scripts with JavaScript syntax a plausible way of configuring a system in runtime? If so, can all of the Jini service configuration parameters be allotted a value at runtime or during service deployment into a container/grid such as Rio?

I think that I am more apt to believe in JavaScript configuration over the current configuration approach and other ideas I thought of for the following reasons:

  • Current configuration is not Java-like enough and is quite proprietary in nature to the Jini environment. This makes it another barrier to entry for developers. I think that an all Java configuration (which you can do, but is not touted often) would be a better solution, but…
  • All Java class configuration makes it a build time procedure. This is not conducive to production systems which may need to modify configuration parameters due to network and system environment modifications.
  • Apache-like properties files are not robust enough to configure complicated services since it lacks object instantiation. In the J2EE world, properties files have been used to configure environments such as JNDI and I think that is one of the many reasons J2EE has become a difficult environment to develop in for many enterprises.
  • I find that XML configuration is just barely a step up from Apache-like properties files and therefore suffers from some of the same issues. The hierarchical nature of XML also does not lend itself easily to object instantiation.
  • Dependency injection (or IoC container type configuration) is another good solution in my opinion. This type of configuration is usually done through XML but is usually a language constructed of markup which is digested by factories or builders of factories which create the actual objects based on configuration parameters and inject them into the objects which reference them. (more information at Martin Fowler's web site http://www.martinfowler.com/articles/injection.html) The one knock I have on this approach as opposed to JavaScript configuration files is the amount of markup that must be created in order to define the dependencies of a Jini service to be created. When using Spring I have found that there is a substantial amount of XML to define quite simple entities.

I believe that the use of JavaScript is a natural approach to bridge Jini service development and deployment configuration. In the “mustang” release of the Java SDK there will be built in support for JavaScript as a scripting language to work with Java virtual machine environments (see JSR 223 and the Language section of “Core Java Technology Features in Mustang” announcement for more details). It seems like as good a contender as any to replace a configuration approach which I believe is a distraction from the overall goal of Jini to enter the mainstream market.

Real World Application of Agile and Lean in Technology and Business