Summary
I had a conversation with my brother about Jini technologies. He got the difference in thinking, do you?

---

Advertisement

I was talking with my brother about a project that involved using Jini. He was using terms and technologies in his part of the conversation that are prevalent in the non-Jini way of thinking. So I tried to provide a useful example of how thinking the Jini way, and using the Jini technologies provided some recognizable benefit. Here's roughly what I said to him:

"In this application, you could just write some code that queried the SQL database and configure the security model of that database to allow certain people to do certain things with certain tables and rows. But, in the Jini world, we would manifest the operations that you wanted to perform as a Java interface, and then provide some code as a service that implemented that interface and did the database work.

If you need duplicity in the server, for fail over, you'd normally need to configure the database clients with the addresses of the servers. Also. if you wanted to use a different vendors database, you'd have to distribute new drivers potentially. What if the cost effective database can't do security in the model you need. What if its not fast enough, later on and you need a Object database or some other incore solution with write through caching etc. There are other things that you might end up with in your client code, that would really not be details that you wanted to be manifested everywhere. The Jini service concept used as a facade for the database operations can hide many of these types things.

If you buy into using a Jini service instead of SQL server, then you also now get the ability to use the lookup server to find the different database instances. Now you get ability to not distribute server addresses everywhere because you can use multicast discovery to find the database facade services through the Jini LUS.

Another interesting thing is that you've codified the exact actions of the system as an interface. You can use the Jini 2.0 security model against this model to protect specific actions of the system explicitly, in ways that people can understand. There aren't 10 different security constraints hidden in the database that provide the security model which might not work in another database.

Using the Jini 2.0 security mechanisms, you can implement the required security model you need through the use of the Jini 2.0 Configuration implementation. You could have fast databases that are only accessible to a select group of individuals, and slower, or time based access for others. This is all implementable completely separate from your database vendors security model.

So, in summary, this is not really magic, or amazingly complex technology. But, what it really is, is a way to think about problem solving that provides an enabling, flexible architecture.

1. You use a facade service to hide the details of what happens with databases, behind the scenes.
2. You can then use Jini multicast discovery to remove explicit IP addresses from the picture for database/persistent storage server access from the clients perspective.
3. Because you're using the LUS, you get leased presence in the system so that systems that are not up do not get in the way (a TCP SYN, sent to a non-visible IP address will typically cause a very long timeout delay). A database facade server that is not up, quickly disappears from the LUS list, and the clients will stop trying to access it.
4. When you want to change the implementation of the database storage, you can do that, and deploy a new service with the new implementation. It will appear in the LUS, and be accessible to those who have access as configured in the security model (including limiting it to developers for testing when complex interactions need special testing).

And, there are several other interesting capabilities and enabling factors that the Jini way adds to the picture."

What my brother recognized was that it wasn't magic or amazingly complex, but Jini provided a tremendous amount of flexibility in how the system was managed. It could be changed over time to use different technologies, The system was independent of the 3rd party technologies, such as databases, that could be likely to change on a moments notice.

All of the patterns that are prevalent in Jini technologies, don't always amaze people. But, if you put all of them together, and use them in your day to day problem solving, you will find yourself developing some rather amazing applications that will amaze people and will provide seemingly magic capabilities to repair, heal and extend themselves day in and day out.

Do you think like a Jinition?

Talk Back!

Have an opinion? Readers have already posted 21 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.