John Reynolds's Blog

August 2006 Archives

Thoughts on "The Modular JRE" and Open Sourcing Java

David Herron posted a clarification of "what it means to be Java" on his blog, and the examples that he used got me thinking...

David made it clear that anyone can add whatever they like to their version of the JRE (Java Runtime Environment) and still call it Java... but if they leave anything out then it is most certainly not Java. The example he sited was the hypothetical incusion of SWT (the windowing toolkit used by Eclipse) in a version of the JRE. This version could still label itself as Java as long as AWT and Swing (the windowing toolkits in the Java specifications) are not excluded.

This makes sense to me... but I'm hoping that the folks who are opening Java also take another look at the basic definition of what must be in the JRE. Let me explain my concern...

Many Java applications (maybe even most) have no desktop-based user interface at all (they are browser-based web applications)... and if the adoption of Web Services and SOA continue we'll see more and more "headless" Java-implemented Services (Services that have no user interface at all). In a world where it is quite legitimate to have a large percentage of Java applications with zero need for any windowing toolkit, why carry around those toolkits in the JRE?

I know that code that isn't used doesn't really "cost" much, but let's assume that you are really into Grid computing, and you have thousands of nodes in your cluster... and each node has a JRE with unused windowing toolkits on it. Seems wasteful.

Windowing toolkits in the base JRE are fairly easy to throw stones at, but there are many other components that really should be optional. For an example, just take a look at the recent "discussions" on whether or not JavaDB should be included in the Java Developer Kit (I shudder to think of the threads that would be spawned if JavaDB is ever packed into the JRE).

My impression is that there is a large consensus that the JRE should be more modular, broken into logical chunks that are installed based on need. A modular JRE does pose some rather interesting technical challenges (to get the code that you need when you need it), but I had overlooked the challenge posed by the current definition of Java itself.

If I'm reading David right... a modular JRE wouldn't quite meet the current definition for "Java"... it's all or none. If I never install the "windowing-toolkit" chunk on my application servers, then they aren't really "Java" application servers.

Just something to think about...

Is the End of Tiered-Based Computing in Sight?

This morning I came across a whitepaper from GigaSpaces entitled: Space-Based Architecture and The End of Tier-based Computing

Perhaps the most widely adopted style of software architecture is the N-Tier architecture... the separation of concerns based on stacked tiers of functionality. The "Three-Tier" architecture is perhaps the best known N-Tier approach, with functionality separated into Presentation Logic, Business Logic, and Data Access Logic.

The premise put forward by GigaSpaces is that N-Tier solutions are hitting a wall in terms of scalablity, or more specifically that the increasingly complicated schemes necessary to scale an N-Tier solution are hitting a roadblock.

The basic approach to scaling an N-Tier solution is to deploy multiple instances of any Tier that is having trouble meeting the necessary performance goals. For example, if the EJBs in your Business tier can't keep up with the requests from your Presentation tier, then deploy copies of the EJBs on additional servers.

This approach to scaling an N-Tier application works pretty well unless you need to deploy many copies of your Business tier... the middleware necessary to deploy the EJBs and to load balance requests becomes increasingly complicated, not to mention the overhead incurred when sending messages to remote tiers.

GigaSpace suggests a different approach to scaling, which they have christened Space-Based Architecture:

"Space-Based Architecture (SBA) represents a new model that combines distributed caching ("Data Grid"), content-based messaging ("Messaging Grid") and parallel processing ("Processing Grid") for transforming existing tier-based applications into linear, dynamically scalable services. These new middleware components are implemented on top of a distributed shared memory space that provides common clustering, high availability, location transparency and consistency services across all tiers."

Radically simplifying SBA (you really ought to read the whitepaper), the gist seems to be that tiers are not deployed separately. The tiers required to process the application logic are grouped into a single logical processing unit, and scaling is achieved by running multiple instances of those units on multiple machines. To contrast this with the typical approach to scaling an N-Tier application, instead of creating multiple instances of the tiers, the approach is to create multiple instances of the application:

"The power of spaces comes from not having to separate various parts of an application into discrete physical runtimes — and then wiring those together in complex, hard-to-scale, and performance-consuming tangles of middleware. A space doesn’t care if an application has been “tiered.” Whether it has or not, the same program code will instantiate multiple times on the same machine or on multiple machines automatically — and even dynamically - in response to runtime parameters like CPU utilization." - Nati Shalom - CTO, GigaSpaces Technologies

So what do you think? Is Space Based Architecture and the emergence of Grids and Service-Oriented Architecture going to change the way most software architects approach their designs... or is this just a niche that won't make much of an impact?

Disconnected Browser-Centric Clients

There is a huge paradigm gap between writing a desktop application with something like Swing, and writing a browser-based application with something like Java Server Faces. Frameworks like NextApp's Echo2 go a long way towards narrowing the gap, but there are still underlying disconnects that just won't go away...

Just from the practical standpoint of learning how to program, this is a big deal.

I know that some folks wish that browser-based applications would disappear... but I think that adopting that credo would be a mistake. The "old school" desktop applications aren't truly suited to a mobile lifestyle where an individual may connect to the Web from a variety of devices. In a single day I might use my home computer, PDA, mobile phone, work computer, and public kiosk to access my applications and data.

That said, I must admit that most of the current crop of browser-based applications don't quite cut the mustard: If you can't connect to the Web, then you can't use your applications.

We need a blend... We need applications that can be accessed from any device connected to the Web, but with persistent components that reside on the devices that we actually own.

I'll use Google's Calendar to illustrate what I have in mind: I love having a calendar that I can access from any web connection (actually, it doesn't work from my PDA yet, but hopefully they are working on that). I also love the ability to share my calendar with others (particularly with my wife).

What I don't love is losing access to my appointments when I am not online.

I want a persistent component of my calendar on all of the devices that I own. I want my devices to "synchronize with the mother ship" when connected to the Web, updating themselves from a central data store, and passing along any appointments that I might have recorded while offline.

Fortunately, Google has thoughtfully provided a Web Service Interface to their Calendar, so it is quite possible to create a client application to satisfy my wants and needs... I can have a desktop application in addition to my browser-based application if I so choose.

The down side to dual applications is that there's something clunky about this approach...
Accessing a desktop application when not online, and a browser-based application when I am online seems rather like a kludge.

Call me crazy, but what I'd like would be to always start from my browser, type in or select a URL, and have the appropriate version of the application run... If I am online, give me access to the full blown web application. If I am offline, give me access to the persistent components on my local machine. Adam Bosworth has written extensively on the subject of disconnected web applications... but his solutions always seem to end up relying on making changes to the browsers themselves, and I just don't think that's likely given the vested interests of browser manufacturers.

Roshan Shrestha's article "Take Your Tomcat On The Road" gave me an idea for supporting disconnected web applications that does not require the support of browser manufacturers: Create a locally hosted web application to do your bidding.

In my Calendar example, write a locally hosted web application that interacts with the Google Calendar web service. To access this application, simply enter the proper URL in the browser. If the device is offline, the local web application displays the "disconnected client" interface... If the device is online, the local web application redirects the user to the "online client" interface provided by Google.

I might be the only person on the planet who finds this approach attractive... but then again maybe there are a lot of other odd people out there who want something similar.

The biggest obstacle that I see to this approach is the installation of the "disconnected client" on the local machine. Roshan has demonstrated that it's a breeze to bundle a fully functional web application in a neat little package... but how to get that package onto a user's devices?

Would it be possible to use Java Web Start to install something like Roshan's "Tomcat On The Road" package on a user's machine? I'm really not sure... but hopefully somebody out there can help me find out.

Continue Reading...

This work is licensed under a Creative Commons License.