Patrick Logan posted a blog entry entitled "Many-Node has many more implications than Many-Core
," saying that the many-core discussions miss a crucial point: many cores imply many nodes. Programming models that rely on cores sharing system resources like RAM or hard drive space are going to have to change.
The many-core era will also be a many-node era. You will not have a C: drive except for those legacy systems running in their little jars of formaldehyde.
You will have a lot of computing power "out there" and several kinds of displays that are not directly attached to "your computer". You probably will not be able to locate an "application" as being installed on your C: drive and running on the CPU on the mother board that has a ribbon running out to the disk that has C: formatted on it.
Hardware will be too cheap to be organized this way. We need to begin reorganizing our software now or five years from now, we'll be really bad off, without any excuses.
If your current programming models distinguish between "these threads threads" and "those other processes over there" then it's almost certainly the wrong model for today, not to mention tomorrow.
The good news for Java is that the "Pure Java" initiative - apparently downplayed in the last few years - is ideally geared for a "many-node" deployment, with an emphasis on platform neutrality.
Java EE takes that one step further, recommending that filesystem access not be used. See section 17.2.3 in the EJB 3 specification:
The EJB architecture does not define the operating system principal under which enterprise bean methods execute. Therefore, the Bean Provider cannot rely on a specific principal for accessing the underlying OS resources, such as files. (See Subsection 17.6.8 for the reasons behind this rule.)
We believe that most enterprise business applications store information in resource managers such as relational databases rather than in resources at the operating system levels. Therefore, this rule should not affect the portability of most enterprise beans.
The reference to principals obscures the remote nature of EJBs in the first place. A clearer example might be an illustration of a remote EJB deployment.
Imagine an enterprise application deployment, where web application 'A1' is on machine 'M1', and it looks up EJBs that are hosted in a cluster of machines 'M2' and 'M3'.
On the first invocation ("I1") of A1, it finds an instance of an EJB on M2, which stores information on the local filesystem, in - let's say - a Lucene index.
The second invocation ("I2") of A1 finds an instance of the EJB on M3 instead, which then looks for the information to update on the local filesystem.
However, the update from I1 isn't on the local filesystem of machine M3; it's on M2. You now have an error.
This is why one uses relational databases or remotable resources more than filesystems. Even JCR uses a client/server model for content repositories, to address this issue.
No matter how well the platform is prepared for multi-node deployments, though, programmers have to anticipate the requirements. Java's there to help, but you have to know what you're about.
How well are you prepared to deploy to a cluster, now that they're becoming commodities rather than specialized deployments?