Java should become simpler - or more easily. The goal is no controversial, but the way to achieve the goal is quite discussed. In the persistent layer and business layer, EJB proves to people that in the J2EE field, Sun has no ability to propose a full package like Microsoft .Net; try to solve all problems in one time EJB to finally only a kind of available Reference selection - if it is not a worse.
Java's simple way is not in this direction. Take advantage of the simplicity of the Java language itself, give full play to the power of OOD, fully with the energy of the Open Source community, with multiple frames or libraries - each focus on only one purpose, "Do Only One Thing Do IT Well" - Combination to complete the task, this is the Java walking forward.
Recently, we often say that Hibernate simplifies the assembly of components. Let us see how they help Java become simple.
------------
SIMPLER JAVA
NOVEMBER 2003
Discuss this article
Introduction
Many Java vendors and open-source projects focus on complex tools, built to solve complex problems, often under the umbrella of "enterprise" Java development. Witness the explosion of complexity in J2EE, EJB, and XML. True, there's often a tradeoff between simplicity and power, but some key architects in the Java community are working to swing the pendulum from monolithic frameworks back toward cleaner, simpler ones. A number of new projects are helping to buck the trend toward complexity, choosing instead to build lighter, focused frameworks That Can Power Simpler Applications.
In this article, we'll examine a few frameworks, and look at the basic principles that they use to embrace simplicity. We'll look at a lightweight container and a persistence framework. Then, we'll look at how the larger J2EE vendors Are Supporting The Paradigm Shift.
Starting over
A few notable projects use very little of J2EE as a foundation. They are basically attempting to build a simplified notion of what it means to be a persistent object, or a container. Lightweight containers like Pico and Spring provide fewer services, but with a much Less Invasive Architecture Than EJB. Hibernate, a Persistence Framework, Provides a Persistence Alternative for EJB Container Managed Persistence (CMP) .TRANSPARENT PERSISISTENCE
Java Specification Request (JSR) 12 was one of the earliest requests for the Java Community Process (JCP). It was a request for transparent persistence in the form of JDO, and expressed the idea that EJB entity beans were not going to cut it. for a while, JDO faltered, but it's seen a resurgence in the last couple of months with endorsements from the SunOne and JBoss application server development groups. with two strong JDO products in Kodo and Lido, you could say that transparent persistence has arrived.
Along the same lines, Hibernate is an open source project, founded by Gavin King, that provides transparent persistence for Java applications. I must confess that though I give an introductory Hibernate session at several conferences, I did not predict the early success of Hibernate, and guessed that it would be a bit player at best After all, it's proprietary;. it has relatively modest development resources compared to many of the commercial OR-mapping juggernauts; and it's an open source project, which can often work against it in larger IT Departments. Still, Hibernate Has Burst Onto The Scene with Tremendous Early Momentum, Providing a surprisingly Rich and fast framework.
Unlike JDO or EJB, it's not based on byte code enhancement or code generation. It uses reflection. It has a small footprint, and runs with very low resource contention, aside from the database itself. I believe that Hibernate is successful primarily for three reasons : It's Focused, Simple, And Fast. Let's Look at some of the principles That Have Made The Hibernate Project Successful.
Do one thing, and do it well. Hibernate is an object-relational mapping framework, solely for Java applications on relational databases through JDBC. That's the lion's share of the Java persistence community. It's also a focused problem. By limiting the problem domain to relational databases, Hibernate is able to make some pragmatic decisions that can dramatically impact performance. for example, since the designers knew that they would be using SQL over JDBC, they could take advantage of special algorithms and extensions for high-performance outer joins. Many other persistence frameworks are not limited to relational database back ends. Hibernate effectively trades a looser coupling for higher performance. Strive for simplicity. The Hibernate team has invested heavily in effective documentation, and also in good examples. They also have a simple API. I Was Able To Get My First Application Running In Under Fifteen Minutes. I Notice Hibernate's Simplicity In Many Places. ITS Methods Are well named, and the abstraction layers are clear. I can work with pure Java beans, instead of building complex components. Ant integration and XDoclet support is already included. A framework should strive to provide the simplest support possible for its users. Pick your battles . If you decide to build simpler applications or frameworks, you're going to have to decide where to focus your attention. you can not adopt every design pattern, or make every performance enhancement. Some of my early Hibernate reservations, I'll Admit, WERE Related To Reflection. Gavin King and His Team Rightfully Assumed That The Reflection Overhead Would Be Minimal Compared To The Performance of The Sql Queries That Hibernate Would Generate.
Instead of optimizing reflection, the team focused on the number and efficiency of queries by delaying updates, rolling many SQL statements into one, detecting "no-ops" (like an insert immediately followed by an update and a delete), and so on. The result is a surprisingly fast framework, with the transparency afforded by reflection.Through simplicity and better focus, the Hibernate team has settled into a nice, rapid release rhythm, and it's served them well. The user community is growing, and they've Just Completed The Second Major Release. But Persistence Isn't The Only Place That The Trend Toward Simplicity Is Taking Root.
Lightweight Containers
Lightweight containers strive to provide services for the simplest components possible. Spring and Pico are probably the most popular. If you've not seen them before, you may be tempted to skip this section, believing that the last thing we need is yet another container . Do not. Lightweight containers like Spring are spreading rapidly, because they can solve problems that other containers can not. While these frameworks are not as well known as Hibernate, at least one of them may be soon. I'm starting to hear the familiar buzz of the early stages of a successful open source project from the Spring camp. The most interesting aspects, to me, are the transparency of the objects, clean and pluggable services, and the light footprint. All of these goals lead to A Simple, Effective Framework:
Strive for transparency. When you're building a solution for developers, the simplest solutions are usually the best ones. Spring is not invasive. In fact, the objects that you snap into the container are pure POJOs, plain old Java objects, or JavaBeans , to be more precise. Objects do not depend on the container. They can run outside of the container for better testability, or address other objects as POJOs. Allow for extension. Spring supports some simple services out of the box, like JTA and JDBC layers for transaction and database support. Spring also provides a nicely layered API that allows rapid extension by third parties. for example, you can already use both Hibernate and JDO objects within a Spring container. Keep a small footprint. Spring's simplicity lets it keep a small footprint. As such, it can be used in ways that you might not expect to use your average J2EE container. It starts quickly enough to be included in tests, even if you plan to run many of them with each bui ld. You can use Spring on the client, or within a mobile device.Since lightweight containers work with POJOs and clearly separate concerns of various services, they are well-suited for the next generation of program paradigms like aspect oriented programming (AOP). Both Hibernate and Spring Present Simplified Abstractions. How do we know if The Abstractions Will be enough?
Leaking Abstractions
It's clear that cleaner, simplified abstractions are coming back, but it's not enough to be simple. All abstractions leak. We'll never be able to capture all of the complexity of a native database API in a simplified framework, and a lightweight container will never be able to do everything that a heavyweight container does. For this reason, it's important to expose the abstraction layer immediately below the new one. For example, Hibernate has no notion of stored procedures. Instead, it gives you full access to the JDBC connection, so that you can call stored procedures outside of Hibernate.Also, an adaptable, pluggable architecture, with loose coupling in appropriate areas, lets you snap out inappropriate services, and snap in ones that are more robust. For example, Spring allows pluggable Persistence and transactions.
.
Alternative approaches
Of course, building simpler frameworks from the ground up is only one way to gain simplicity. The Java community is also trying other approaches. Some are trying whole new programming paradigms, like model driven architecture (MDA), or aspect oriented programming (AOP) . Others Are Trying a More Incremental Approach, Like Letting Tools Shield US from Some of the Complexity.
Simplifying Tools
Some vendors, especially those with a significant investment in J2EE, might view lightweight containers, Hibernate, and frameworks like them as too radical a departure from the status quo. They would rather not burn J2EE to the ground to start over. Instead, many of them would rather use a smarter set of tools to insulate developers from complexity. Sun's Rave and BEA's Workshop favor this approach.Taking a page from Visual Studio's book, BEA and Sun have built tools to shield inexperienced developers from the complexities of J2EE. The hope Is That Smarter Tools with aggressive code generation Can Shield The Most Common J2ee Developers from That Level of Detail.
The ability to build loosely coupled applications, especially through Web services, is a fundamental capability of BEA's Workshop. They intend to provide a series of simplified abstractions that allow users to be much more productive. To succeed with Workshop, the challenge for BEA is twofold . They must abstract away most of the J2EE complexity for their users, and still allow enough of the underlying abstractions to peek through so that their customers can use Workshop in ways beyond the intentions of the original design team.
Which approach Wins?
Will either approach step up and slay the complexity dragon? In truth, for the foreseeable future, we're likely to see many more attempts to battle complexity. We're simply getting to the upper bound of what most modern application development teams can handle . But we will not be limited to any single approach. Vendors with larger investments in existing Java enterprise frameworks will tend to favor better tools that free their customers from tedious details. Other efforts, like Hibernate and Spring, will attempt to take a more radical and fundamental approach. Still others will try to make the case that Java has taken us as far as it can, so we need to move on to the next language or paradigm like C # or AOP. The playing field has been set. Let the Games Begin.Resources
Check out Hibernate, and related documentation here: http://www.hibernate.org/ Read Introduction to Hibernate: http://www.theserverside.com/resources/article.jsp?l=Hibernate Download chapters from Manning's Hibernate In Action : http://www.theserverside.com/resources/HibernateReview.jsp Get the Spring framework here: http://www.springframework.org/ Read Introducing the Spring Framework: http://www.theserverside.com/resources/ Article.jsp? l = SpringFramework Hear An Interview with Gavin King Here: http://www.theserverside.com/events/library.jsp #king
About the Author
