Spring in Action: A Spring Jump Start. Part 1
Spring in Action: A Spring Jump Start. Part 1
Written by Craig Walls and Ryan Breidenbach and reproduced from "Spring in Action" by permission of Manning Publications Co. ISBN 1932394354, copyright 2005. All rights reserved. See https://www.manning.com for more information.
This chapter covers
|
In 1996 the Java programming language was still a young, exciting, up-and coming platform. Many developers flocked to the language because they had seen how to create rich and dynamic web applications using applets. But they soon learned that there was more to this strange new language than animated juggling cartoon characters. Unlike any language before it, Java made it possible to write complex applications made up of discrete parts. They came for the applets, but they stayed for the components.
It was in December of that year that Sun Microsystems published the Java- Beans 1.00-A specification. JavaBeans defined a software component model for Java. This specification defined a set of coding policies that enabled simple Java objects to be reusable and easily composed into more complex applications. Although JavaBeans were intended as a general-purpose means of defining reusable application components, they have been primarily used as a model for building user interface widgets. They seemed too simple to be capable of any "real" work. Enterprise developers wanted more.
Sophisticated applications often require services such as transaction support, security, and distributed computingservices not directly provided by the Java- Beans specification. Therefore, in March 1998, Sun published the 1.0 version of the Enterprise JavaBeans (EJB) specification. This specification extended the notion of Java components to the server side, providing the much-needed enterprise services, but failed to continue the simplicity of the original JavaBeans specification. In fact, except in name, EJB bears very little resemblance to the original JavaBeans specification.
Despite the fact that many successful applications have been built based on EJB, EJB never really achieved its intended purpose: to simplify enterprise application development. Every version of the EJB specification contains the following statement: "Enterprise JavaBeans will make it easy to write applications." It is true that EJB's declarative programming model simplifies many infrastructural aspects of development, such as transactions and security. But EJBs are complicated in a different way by mandating deployment descriptors and plumbing code (home and remote/local interfaces). Over time many developers became disenchanted with EJB. As a result, its popularity has started to wane in recent years, leaving many developers looking for an easier way.
Now Java component development is coming full circle. New programming techniques, including aspect-oriented programming (AOP) and inversion of control (IoC), are giving JavaBeans much of the power of EJB. These techniques furnish JavaBeans with a declarative programming model reminiscent of EJB, but without all of EJB's complexity. No longer must you resort to writing an unwieldy EJB component when a simple JavaBean will suffice.
And that's where Spring steps into the picture.
1.1 Why Spring?
If you are reading this book, you probably want to know why Spring would be good for you. After all, the Java landscape is full of frameworks. What makes Spring any different? To put it simply, Spring makes developing enterprise applications easier. We don't expect that to convince you at face value, so first let's take a look at life without Spring.
1.1.1 A day in the life of a J2EE developer
Alex is a Java developer who has just started on his first enterprise application. Like
many Java 2 Enterprise Edition (J2EE) applications, it is a web application that
serves many users and accesses an enterprise database. In this case, it is a customer
management application that will be used by other employees at his company.
Eager to get to work, Alex fires up his favorite integrated development environment
(IDE) and starts to crank out his first component, the CustomerManager
component. In the EJB world, to develop this component Alex actually has to
write several classesthe home interface, the local interface, and the bean itself.
In addition, he has to create a deployment descriptor for this bean.
Seeing that creating each of these files for every bean seems like a lot of effort,
Alex incorporates XDoclet into his project. XDoclet is a code generation tool that
can generate all of the necessary EJB files from a single source file. Although this
adds another step to Alex's development cycle, his coding life is now much simpler.
With XDoclet now handling a lot of the grunt work for him, Alex turns his
attention to his real problemwhat exactly should the CustomerManager component
do? He jumps in with its first method, getPreferredCustomer(). There are
several business rules that define exactly what a preferred customer is, and Alex
dutifully codes them into his CustomerManager bean.
Wanting to confirm that his logic is correct, Alex now wants to write some tests to validate his code. But then it occurs to him: the code he is testing will be running within the EJB container. Therefore, his tests need to execute within the container as well. To easily accomplish this, he concocts a servlet that will be responsible for executing these tests. Since all J2EE containers support servlets, this will allow him to execute his tests in the same container as his EJB.
Problem solved!
So Alex fires up his J2EE container and runs his tests. His tests fail. Alex sees his coding error, fixes it, and runs the tests again. His tests fail again. He sees another error and fixes it. He fires up the container and runs the tests again. As Alex is going through this cycle, he notices something. The fact that he has to start the J2EE container for each batch of testing really slows down his development cycle. The development cycle should go code, test, code, test. This pattern has now been replaced with code, wait, test, code, wait, test, code, wait, get increasingly frustrated!
While waiting for the container to start during another test run, Alex thinks, "Why am I using EJB in the first place?" The answer, of course, is because of the services it provides. But Alex isn't using entity beans, so he is not using persistence services. Alex is also not using the remoting or security services. In fact, the only EJB service Alex is going to use is transaction management. This leads Alex to another question: "Is there an easier way?"
1.1.2 Spring's pledge
The above story was a dramatization based on the current state of J2EE - specifically EJB. In its current state, EJB is complicated. It isn't complicated just to be complicated. It is complicated because EJBs were created to solve complicated things, such as distributed objects and remote transactions.
Unfortunately, a good number of enterprise projects do not have this level of complexity but still take on EJB's burden of multiple Java files and deployment descriptors and heavyweight containers. With EJB, application complexity is high, regardless of the complexity of the problem being solved - even simple applications are unduly complex. With Spring, the complexity of your application is proportional to the complexity of the problem being solved.
However, Spring recognizes that EJB does offer developers valuable services. So Spring strives to deliver these same services while simplifying the programming model. In doing so, it adopts a simple philosophy: J2EE should be easy to use. In keeping with this philosophy, Spring was designed with the following beliefs:
Good design is more important than the underlying technology.
JavaBeans loosely coupled through interfaces is a good model.
Code should be easy to test.
Okay. So how does Spring help you apply this philosophy to your applications?
Created: March 27, 2003
Revised: March 07, 2005
URL: https://webreference.com/programing/spring/1
Find a programming school near you