Recent top five:
Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first
post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together
in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...
| Enterprise AJAX - Transcend the Hype |
| Memory Analysis in Eclipse |
| Oracle Compatibility Developer's Guide |
| Memory Analysis in Eclipse |
J2EE technology has been wildly successful in recent years. But provisioning, deploying, and managing J2EE applications has become a problem for many enterprises—the sheer number of server systems that must be configured and managed can tax the human and facilities resources available to today's data centers. A new technology called network attached processing can help tackle these consolidation and management challenges associated with J2EE development.
Management guru Peter Senge once observed that "today's problems come from yesterday's solutions." While Senge had business and governmental policy decisions in mind when he coined this saying, it applies equally well to software technology, and the rapid rate of change in software development practices makes it all the more easy to see the truth in this observation. For example, the client-server revolution of the early 1990s was intended to alleviate the difficulty and cost of developing mainframe applications, and make it more practical to tackle larger software problems.
But the world doesn't stand still in the wake of innovation. As the demand for ever more complex enterprise applications continued to increase, the limits of the client-server approach were soon realized. Distributed objects, Web applications, application servers, service-oriented architectures (SOA)—each of these generations of enterprise software development technology addressed some of the limitations of their predecessors and enabled the development of more sophisticated applications. But with each generation of technology, new problems surfaced, such as scalability, manageability, or development complexity.
As developers, we welcome these rapid changes in technology—they feed us with interesting new ideas to ponder and new techniques to master, increase the scope and complexity of problems we can solve with a given resource budget, and, of course, keep our skills in high demand.
The technology model of virtual machines and application servers has reached a similar point in its evolution: While it has become the dominant form of enterprise software development (Gartner estimates that by the end of 2008, 80 percent of all new e-business application development will be based on virtual machines), we are struggling with the consequences of this model's success—deployment complexity, challenges in capacity management and planning, and the difficulty of developing applications that scale well across a variety of clustering topologies. Application servers alleviate some of these problems, but they contribute to the complexity as well. Java technology has more than proven its value in high-throughput, transactional enterprise applications, but it may well have reached the point where it has become the victim of its own success.
Processing hardware today is incredibly cheap—for a few thousand dollars, you can buy commodity, rack-mount, fault-tolerant systems today that can outperform yesterday's mainframes. But today's applications are far more resource-hungry than yesterday's applications. The technologies we use to accelerate software development, improve software reliability, and manage software complexity consume much of the computational surplus; increased user expectations consume the rest and then some. As a result, most enterprise applications are too big to run on a single low-end server and are often distributed across clusters of inexpensive server hosts. The software technology for clustering J2EE applications is readily available, but it, in turn, imposes a cost in terms of additional resource consumption and in development, deployment, and management complexity.
| Subject | Replies |
Last post
|
|
By JavaWorld |
5 |
05/30/08 06:21 PM
by Anonymous |
|
By Anonymous |
1 |
05/24/07 04:54 AM
by Anonymous |