J2EE-Development-Frameworks--外文翻译原文.doc

《J2EE-Development-Frameworks--外文翻译原文.doc》由会员分享，可在线阅读，更多相关《J2EE-Development-Frameworks--外文翻译原文.doc（29页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-dateJ2EE-Development-Frameworks-外文翻译原文J2EE Development FrameworksJ2EE Development FrameworksJava 2 Enterprise Edition has excelled at standardizing many important middleware concepts. For e

2、xample, J2EE provides a standard interface for distributed transaction management, directory services, and messaging. In addition, Java 2 Standard Edition(J2SE),which underpins J2EE,provides a largely successful standard for Java interaction with relational databases.However, as the”J2EEs Lack of Ap

3、plication Programming Support” sidebar explains, the platform has failed to deliver a satisfactory application programming model.Sun Microsystems and the large application server vendors have traditionally responded to this problem by advocating development tools as a way to hide J2EEs complexity. H

4、owever, tools for managing J2EE artifacts arent nearly as good as tools for working with the Java language, with their sophisticated refactoring capabilities, and J2EE tool support is generally inferior to that of the Microsoft.NET platform. Many J2EE tools are themselves complex, as is the code the

5、y generate.Many in the open source community, especially smaller vendors, have chosen the alternative of developing frameworks designed to simplify the experience of building J2EE applications. Popular frameworks such as Struts, Hibernate, and the Spring Framework play an important role in many of t

6、odays J2EE development projects.WHY USE A FRAMEWORKA software framework is a set of classes that make up a reusable design for an application or, more commonly, one tier of an application. Whereas application code and thus manages the flow of control. This is often referred to as the Hollywood princ

7、iple:” Dont call us, well call you.” The application developer writes code that the framework will then call at runtime.Designing a framework for use in a wide variety of unknown contexts is challenging. However, the framework approach is well adapted to the complexities of J2EE development because

8、it can provide a simple, easy-to-use model for application programmers.Using a well-designed open source framework offers many advantages:* With a good framework, developers write only the code they need to write;They dont get bogged down working directly with low infrastructure APIs. This is the ke

9、y value proposition.* A well-designed framework can provide structure and consistency to an application. The structure will be clear to additional developers joining the project.* An easy-to-follow framework can promote best practice through examples and documentation.* Successful open source framew

10、orks are better tested than in house code.* Frameworks usually become popular only if they have something to offer. In-house frameworks are often mandated, while a J2EE project is likely to adopt an open source framework only if it delivers clear benefits. J2EE itself defines several frameworks. For

11、 example, an Enterprise JavaBeans(EJB) container or Servlet engine relies on the Hollywood principle, with the J2EE runtime instantiating and invoking managed objects. Open source Web application frameworks such as Struts add their own framework over the standard Servlet framework. The emphasis is o

12、n frameworks above J2EE, which provide a simpler programming model or other benefits.OPEN SOURCE FRAMEWORKS EMERGEMost large J2EE projects have traditionally used in house frameworks to hide the platforms complexity. Only recently has a consensus emerged about the generic problems that provide good

13、generic solutions. There is now a clear trend for frameworks to “standardize” more of the infrastructure that formerly was developed on a per-project basis.One reason for J2EE frameworks sudden popularity is the platforms increased maturity. Developers now recognize areas in which the standard APIs

14、are deficient and know from experience how difficult it is to write a good framework to fill the gap. In addition, many high-quality frameworks are now available that offer outstanding documentation and the support of a focused development team, without imposing licensing fees.StrutsThe trend toward

15、 open source frameworks began with Web applications. In 1999-2000, developers realized the deficiencies of the java Server Pages” Model 1”approach, in which JSP templates handled incoming requests as well as static template data. This meant that JSP often contained both business logic and complex HT

16、ML or other markup.With no standard framework in place J2EE specification support, developers responded with their own Front Controller implementations. These moved business logic to Java classes, thereby eliminating the need to maintain such hybrid artifacts.The Front Controller pattern is often re

17、ferred to as Web MVC after the classic Model View Controller architecture pattern that is common to GUI development in object-oriented languages. (The name is somewhat misleading in that Web MVC views must pull information from the model, whereas in classic MVC, the model pushes events to views.) In

18、itial Front Controller implementations varied greatly in quality. The Apache Software Foundations release of Struts in 2001-2002 changed all this. While not an ideal Web MVC framework, Struts worked well enough to quickly become the de facto standard.Struts demonstrated all the benefits of open sour

19、ce frameworks such as ease of recruiting personnel familiar with the structure it imposed. By late 2002, it was the natural choice for most J2EE Web applications, and every serious J2EE Web developer was familiar with it.The near-universal adoption of Struts commoditized an important chunk of the J2

20、EE architectural stack. Even conservative organizations accepted its use in a prominent part of their software infrastructure and agreed to the Apache licenses terns.HibernateThe next domino to fall was persistence. J2EE “out of the box” provided two means for accessing persistent stores-most often,

21、 relational database: JDBC, the J2SE standard API for relational database management system access; and entity beans, an EJB component type dedicated to modeling a persistent entity.JDBC is error-prone programming model inhibited object-oriented design by forcing developers to work with relational c

22、oncepts in Java code. Entity beans, despite hype from Sun and major J2EE vendors, likewise proved to be cumbersome: Initially, the technology was severely underspecified, not even taking into account management of relationships between persistent objects; it made applications difficult to test; and

23、it offered an inadequate query language. By 2003, developers largely ignored entity beans despite enhancements in EJB 2.0 and 2.1.Early effortsSolutions to the persistence problem came in the form of object-relational mapping, which provides transparent persistence for plain old Java objects, a conc

24、ept described in the sidebar, “The Noninvasive Framework: Power to the POJO.” Though not unique to Java, ORM is especially popular in the Java community-compared, for example, to .NET developers, who seem to regard it with suspicion.Commercial ORM tools such as Oracles TopLink were well established

25、by the late1990s, but only a minority of projects used them because they were expensive, complex, and appeared to conflict with the Sun-sanctioned entity bean standard. Nevertheless, they usually achieved better results in practice than JDBC or entity beans, thus proving the case for POJO persistenc

26、e.Java Data Objects, which appeared as a Java Community Process specification in 2001, offered generic POJO persistence to any persistent store (although implementations typically provided their best support for relational database). However, Suns lukewarm attitude toward JDO, coupled with J2EE vend

27、ors lack of interest in POJO persistence at that time, prevented the technology from achieving popularity.Hibernate arrivesRadical change came in 2002 for two reasons. First was widespread realization that entity beans had failed in practice, and that developers should ignore that part of J2EE speci

28、fications. By retarding rather than advancing the progress of ORM in Java, entity beans remain a prime example of how poor specifications can stifle development of superior technologies.The second factor was the arrival of Hibernate, the first popular, fully featured open source ORM solution. Hibern

29、ate offered fewer features than TopLink but delivered a robust implementation of the most desirable ones, and its focused development team aggressively sought improvements. Hibernate wasnt particularly innovative, building on the extensive understanding of ORM, but it offered a more intuitive progra

30、mming model than existing competitors and removed at one stroke cost and ease-of-use barriers to ORM.Around the same time, new commercial products offered highly efficient implementations of the JDO specification that targeted relational databases, giving developers a rich choice. Meanwhile, TopLink

31、 remained a good option, with its license becoming friendlier to developers.ORM triumphsTogether, all these factors converged to make ORM the norm rather than the exception by 2003-2004. Although some projects still built their own persistence frameworks, the existence of Hibernate, TopLink, and lea

32、ding JDO implementations made this extremely difficult undertaking unnecessary and indefensible.Another part of the application stack was now within the domain of popular frameworks, yet large gaps remained. For example, a typical Web application using Struts and Hibernate still lacked framework sup

33、port for business logic. Although J2EE specifications address some of these issues, primarily through EJB, they dont provide an adequate application programming model.SpringJ2EE frameworks have inexorably moved into application frameworks, which aim to provide consistent programming in all tiers and

34、 thereby integrate the application stack. The Spring Framework is the dominant product in this space, with adoption comparable to that of Hibernate.Spring essentially combines inversion of control and aspect-oriented programming (AOP)-both described in the sidebar, “The Noninvasive Framework: Power

35、to the POJO” with a service abstraction, to provide a programming model in which application code is implemented in POJO that are largely decoupled from the J2EE environment( and thus reusable in various environments). Spring also provides an alternative to EJB in many applications for example, deli

36、vering declarative transaction management to any POJO. The Spring approach has proven to deliver excellent results in many kinds of projects, from small Web applications to large enterprise applications.Other products in the same space include HiveMind, which is conceptually to Spring but has a some

37、what different take on IOC, and NanoContainer, which combines the Pico Container IOC container with services. Collectively, these products are referred to as lightweight containers to distinguish them from traditional J2EE approaches.By decoupling a POJO model from J2EE APIs, which are hard to stub

38、at test time, lightweight containers greatly simplify unit testing. Its possible to unit test in a plain J Unit environment, without any need to deploy code to an application server or to simulate an application server environment. Given the increased-and deserved-popularity of test-driven developme

39、nt, this has been a major factor in lightweight frameworks popularity.WHATS NEXT?Growing recognition and use of J2EE development frameworks is measurably reducing cost in many projects, as well as delivering better speed to market and higher maintainability. Todays best frameworks offer excellent qu

40、ality. Solid documentation, and numerous books and articles to support their use. Nevertheless, two areas in particular seem set for uncertainty in the J2EE space: the conflict between J2EE “standards” and open source innovation, and the growing importance of AOP.The open source versus standards con

41、flict looms in two areas. In the presentation tier, JavaServer Faces, backed by Sun and some of the largest vendors, competes with entrenched open source solutions such as Struts. In the middle tier, EJB 3.0 offers a dependency injection capability reminiscent of a subset of Springs capabilities, mi

42、xed with liberal use of J2EE 5.0 annotations.In both areas, innovation has traditionally come from open source rather than specifications. However, JSP is somewhat indebted to ASP.NET, while the open source Tapestry project-a mature implementation of many of the same concepts-owes much to Apples com

43、mercial WebObjects.Likewise, EJB 3.0 seems to be attempting to standardize dependency injection, though its unclear what benefit this bring-especially if results in the loss of important features, which seems inevitable. EJB 3.0 also attempts a new departure in entering the application programming s

44、pace: an area in which the J2EE specifications havent shone to date.Meanwhile, AOP is importance is steadily increasing within the J2EE community. While adoption isnt yet widespread, certain uses of AOP, such as declarative transaction management, are declarative transaction management, are already

45、popular. Solutions including Spring and dynaop, which offer what might be called “AOP with training wheels,” help to increase awareness of AOP. Full blown AOP technologies such as Aspect J will likely experience wider adoption in the next few years as well.Significantly, the Java Community Process s

46、hows no sign of any move to standardize AOP, although JBoss-which is overtly committed to working through the JCP with the EJB 3.0 specification-is vigorously pursuing proprietary AOP technology.The next-generation J2EE specifications as a whole are embracing a simpler, POJO programming model, simil

47、ar to that already offered by combinations such as Spring and Hibernate. J2EE developers are sure to benefit from recent trends, which are driven more by practical experience than by marketing hype. This is a welcome change from the platforms early days, when results often failed to live up to the promise held out by vendors.-