John Reynolds's Blog

Community: Sun Grid 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?

This work is licensed under a Creative Commons License.