《J2EE Development Frameworks外文翻译原文.doc》由会员分享，可在线阅读，更多相关《J2EE Development Frameworks外文翻译原文.doc（5页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、J2EE Development FrameworksJava 2 Enterprise Edition has excelled at standardizing many important middleware concepts. For example, J2EE provides a standard interface for distributed transaction management, directory services, and messaging. In addition, Java 2 Standard Edition(J2SE),which underpins
2、 J2EE,provides a largely successful standard for Java interaction with relational databases.However, as the”J2EEs Lack of Application Programming Support” sidebar explains, the platform has failed to deliver a satisfactory application programming model.Sun Microsystems and the large application serv
3、er vendors have traditionally responded to this problem by advocating development tools as a way to hide J2EEs complexity. However, 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 sup
4、port is generally inferior to that of the Microsoft.NET platform. Many J2EE tools are themselves complex, as is the code they generate.Many in the open source community, especially smaller vendors, have chosen the alternative of developing frameworks designed to simplify the experience of building J
5、2EE applications. Popular frameworks such as Struts, Hibernate, and the Spring Framework play an important role in many of todays 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
6、application. Whereas application code and thus manages the flow of control. This is often referred to as the Hollywood principle:” 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 unkno
7、wn contexts is challenging. However, the framework approach is well adapted to the complexities of J2EE development because 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 wr
8、ite only the code they need to write;They dont get bogged down working directly with low infrastructure APIs. This is the key value proposition.* A well-designed framework can provide structure and consistency to an application. The structure will be clear to additional developers joining the projec
9、t.* An easy-to-follow framework can promote best practice through examples and documentation.* Successful open source frameworks 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
10、 is likely to adopt an open source framework only if it delivers clear benefits. J2EE itself defines several frameworks. For example, an Enterprise JavaBeans(EJB) container or Servlet engine relies on the Hollywood principle, with the J2EE runtime instantiating and invoking managed objects. Open sou
11、rce Web application frameworks such as Struts add their own framework over the standard Servlet framework. The emphasis is on frameworks above J2EE, which provide a simpler programming model or other benefits.OPEN SOURCE FRAMEWORKS EMERGEMost large J2EE projects have traditionally used in house fram
12、eworks to hide the platforms complexity. Only recently has a consensus emerged about the generic problems that provide good 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
13、frameworks sudden popularity is the platforms increased maturity. Developers now recognize areas in which the standard APIs 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 out
14、standing documentation and the support of a focused development team, without imposing licensing fees.StrutsThe trend toward 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 handl
15、ed incoming requests as well as static template data. This meant that JSP often contained both business logic and complex HTML or other markup.With no standard framework in place J2EE specification support, developers responded with their own Front Controller implementations. These moved business lo
16、gic to Java classes, thereby eliminating the need to maintain such hybrid artifacts.The Front Controller pattern is often referred 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 misleadi
17、ng in that Web MVC views must pull information from the model, whereas in classic MVC, the model pushes events to views.) Initial 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 fr
18、amework, Struts worked well enough to quickly become the de facto standard.Struts demonstrated all the benefits of open source 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 ser
19、ious J2EE Web developer was familiar with it.The near-universal adoption of Struts commoditized an important chunk of the J2EE architectural stack. Even conservative organizations accepted its use in a prominent part of their software infrastructure and agreed to the Apache licenses terns.HibernateT
20、he next domino to fall was persistence. J2EE “out of the box” provided two means for accessing persistent stores-most often, 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 e
21、ntity.JDBC is error-prone programming model inhibited object-oriented design by forcing developers to work with relational concepts 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 e
22、ven taking into account management of relationships between persistent objects; it made applications difficult to test; and 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 prob
23、lem came in the form of object-relational mapping, which provides transparent persistence for plain old Java objects, a concept 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,
24、to .NET developers, who seem to regard it with suspicion.Commercial ORM tools such as Oracles TopLink were well established 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. Neverth
25、eless, they usually achieved better results in practice than JDBC or entity beans, thus proving the case for POJO persistence.Java Data Objects, which appeared as a Java Community Process specification in 2001, offered generic POJO persistence to any persistent store (although implementations typica
26、lly provided their best support for relational database). However, Suns lukewarm attitude toward JDO, coupled with J2EE vendors 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 wa
27、s widespread realization that entity beans had failed in practice, and that developers should ignore that part of J2EE specifications. 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 tec
28、hnologies.The second factor was the arrival of Hibernate, the first popular, fully featured open source ORM solution. Hibernate offered fewer features than TopLink but delivered a robust implementation of the most desirable ones, and its focused development team aggressively sought improvements. Hib
29、ernate wasnt particularly innovative, building on the extensive understanding of ORM, but it offered a more intuitive programming 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 impl
30、ementations of the JDO specification that targeted relational databases, giving developers a rich choice. Meanwhile, TopLink 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
31、2003-2004. Although some projects still built their own persistence frameworks, the existence of Hibernate, TopLink, and leading JDO implementations made this extremely difficult undertaking unnecessary and indefensible.Another part of the application stack was now within the domain of popular frame
32、works, yet large gaps remained. For example, a typical Web application using Struts and Hibernate still lacked framework support for business logic. Although J2EE specifications address some of these issues, primarily through EJB, they dont provide an adequate application programming model.SpringJ2E
33、E frameworks have inexorably moved into application frameworks, which aim to provide consistent programming in all tiers and 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
34、inversion of control and aspect-oriented programming (AOP)-both described in the sidebar, “The Noninvasive Framework: Power 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( a
35、nd thus reusable in various environments). Spring also provides an alternative to EJB in many applications for example, delivering 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 lar
36、ge enterprise applications.Other products in the same space include HiveMind, which is conceptually to Spring but has a somewhat different take on IOC, and NanoContainer, which combines the Pico Container IOC container with services. Collectively, these products are referred to as lightweight contai
37、ners to distinguish them from traditional J2EE approaches.By decoupling a POJO model from J2EE APIs, which are hard to stub 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 s
38、erver or to simulate an application server environment. Given the increased-and deserved-popularity of test-driven development, 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
39、projects, as well as delivering better speed to market and higher maintainability. Todays best frameworks offer excellent quality. 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
40、 between J2EE “standards” and open source innovation, and the growing importance of AOP.The open source versus standards conflict 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 Stru
41、ts. In the middle tier, EJB 3.0 offers a dependency injection capability reminiscent of a subset of Springs capabilities, mixed 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
42、ASP.NET, while the open source Tapestry project-a mature implementation of many of the same concepts-owes much to Apples commercial 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
43、 important features, which seems inevitable. EJB 3.0 also attempts a new departure in entering the application programming space: 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 wides
44、pread, certain uses of AOP, such as declarative transaction management, are declarative transaction management, are already 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
45、 as Aspect J will likely experience wider adoption in the next few years as well.Significantly, the Java Community Process shows 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 propriet
46、ary AOP technology.The next-generation J2EE specifications as a whole are embracing a simpler, POJO programming model, similar 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.