原创毕业设计翻译—J2EE—外国论文原文+翻译资源-CSDN文库

共2个文件

pdf：1个

docx：1个

毕业设计

J2EE

外国论文

JAVA

3星 · 超过75%的资源需积分: 9 3 浏览量 2010-12-03 09:37:21 上传评论收藏 196KB RAR 举报

这篇毕业设计翻译主要聚焦在J2EE（Java 2 Enterprise Edition）技术和Aspect Oriented Programming（AOP，面向切面编程）上，这是两个在IT领域尤其是企业级应用开发中至关重要的概念。我们来详细了解一下这两个核心知识点。 **J2EE**，是Java平台的一个版本，专为构建和部署分布式企业级应用程序而设计。它提供了一个开放的标准框架，支持多种服务如Web服务器、应用服务器、数据库连接、事务处理、安全性和多层架构。J2EE的核心组件包括Servlets（用于处理HTTP请求的Java小程序）、JSP（Java Server Pages，用于创建动态网页）以及EJB（Enterprise JavaBeans，用于实现业务逻辑）。这些组件协同工作，允许开发者构建可扩展、高可用性的系统。 **Aspect Oriented Programming (AOP)**，是软件设计的一种范式，旨在解决传统面向对象编程中的横切关注点问题。在AOP中，关注点被分解为独立的模块，称为“切面”。这些切面可以是日志记录、事务管理、安全性等跨多个类和方法的功能。AOP通过“编织”（weaving）切面到主程序代码中，实现了代码的解耦，提高了可维护性和复用性。在Java中，AspectJ是一个常用的AOP框架，它能够与J2EE环境无缝集成。论文原文部分可能涵盖了J2EE技术在实际项目中的应用，如何利用J2EE组件构建复杂的系统，以及AOP如何增强这些系统的可维护性和性能。翻译部分则提供了对原论文的深入理解和本地化解读，对于学习和研究这些主题非常有帮助。作者将这两个技术结合到毕业设计中，表明他们已经掌握了高级的软件开发理念和技术。这不仅反映了作者对J2EE的深入理解，还展示了其在AOP实践中的能力。这样的毕业设计对于提升个人技能，尤其是在企业级Java开发领域的就业竞争力，具有极大的价值。这个翻译项目为读者提供了一个全面了解J2EE和AOP结合使用的窗口，有助于深化对这两项技术的理解，并可能启发新的设计和开发策略。对于那些正在寻找J2EE和AOP实践案例的人来说，这是一个宝贵的资源。同时，由于是原创翻译，它还展现了作者的学术研究和语言翻译能力，对于学术界和业界都是一个有价值的贡献。

资源推荐

资源详情

资源评论

收起资源包目录

翻译.rar （2个子文件）

翻译

翻译1.0.docx 84KB

AspectJ2EE.pdf 211KB

AspectJ2EE = AOP + J2EE

Towards an Aspect Based, Programmable and Extensible

Middleware Framework

Tal Cohen

and Joseph (Yossi) Gil

{ctal, yogi}@cs.technion.ac.il

Department of Computer Science

Technion—Israel Institute of Technology

Technion City, Haifa 32000, Israel

Abstract. J2EE is a middleware architecture augmented with supporting tools

for developing large scale client/server and multi-tier applications. J2EE uses En-

terprise JavaBeans as its component model. The realization of these components

by a J2EE application server can be conceptually decomposed into distinct as-

pects such as persistence, transaction management, security, and load balancing.

However, current servers do not employ aspect-oriented programming in their

implementation. In this paper, we describe a new aspect language, AspectJ2EE,

geared towards the generalized implementation of J2EE application servers, and

applications within this framework. AspectJ2EE can be easily employed to ex-

tend the ﬁxed set of services that these servers provide with new services such as

logging and performance monitoring. Even tier-cutting concerns like encryption,

data compression, and memoization can be added while avoiding the drags of

cross-cutting and scattered code.

AspectJ2EE is less general (and hence less complicated) than AspectJ, yet

demonstrably powerful enough for the systematic development of large scale

(and distributed) applications. The introduction of parameterized aspects makes

aspects in AspectJ2EE more ﬂexible and reusable than aspects in AspectJ.

AspectJ2EE also generalizes the process of binding services to user applications

in the application server into a novel deploy-time weaving of aspects. Deploy-

time weaving is superior to traditional weaving mechanisms, in that it preserves

the object model, has a better management of aspect scope, and presents a more

understandable and maintainable semantic model.

1 Introduction

The term enterprise applications is used to describe the large-scale software programs

used to operate and manage large organizations. The world’s largest and most important

software systems are enterprise applications; this includes the programs used to run

government organizations, banks, insurance companies, ﬁnancial institutes, hospitals,

and so forth. Enterprise applications make the world go around.

Contact author

Research supported in part by the IBM faculty award

In many cases, enterprise applications are based on a heterogeneous platform

conﬁguration, connecting various independent systems (called tiers) into a coherent

whole. The various tiers of an enterprise application can include, e.g., legacy main-

frame servers, dedicated database servers, personal computers, departmental servers,

and more.

The core functionality served by enterprise applications is often quite simple. It does

not involve overly elaborate computation or pose complex algorithmic demands. How-

ever, developing enterprise applications is considered a daunting task, due to orthogonal

requirements presented by most of these applications: uncompromising reliability, un-

yielding security, and complete trustworthiness.

The staggering demand for rapid development of enterprise applications initiated

a series of component-based middleware architectures. A prime example of these,

and emphasizing client/server and multi-tier structures, is Java 2, Enterprise Edition

(J2EE) [1] which uses Enterprise JavaBeans (EJB) [2] as its component model.

Aspect-oriented programming (AOP) [3], the methodology which encapsulates the

code relevant to any distinct non-functional concern in aspect modules, can also be

thought of as answering the same demand [4, 5]. As it turns out, the functionality of

J2EE application servers can be conceptually decomposed into distinct aspects such as

persistence, transaction management, security, and load balancing. The effectiveness of

this decomposition is evident from Kim and Clarke’s case study [6], which indicates that

the EJB framework drastically reduces the need for generic AOP language extensions

and tools.

Yet, as we shall see here, the EJB support for functional decomposition is limited

and inﬂexible. In cases where the canned EJB solution is insufﬁcient, applications resort

again to a tangled and highly scattered implementation of cross-cutting concerns. Part

of the reason is that current J2EE servers do not employ AOP in their implementation,

and do not enable developers to decompose new non-functional concerns that show up

during the development process.

A natural quest then is for a harmonious integration of middleware architectures

and AOP. Indeed, there were several works on an AOP-based implementation of J2EE

servers and services (see e.g., the work of Choi [7]).

The new approach and main contribution of this paper is in drawing from the lessons

of J2EE and its implementation to design a new AOP language, AspectJ2EE, geared

towards the generalized implementation of J2EE application servers and applications

within this framework. In particular, AspectJ2EE generalizes the process of binding

services to user applications in the J2EE application server into a novel deploy-time

weaving mechanism. Deploy-time weaving is superior to traditional weaving mecha-

nisms in that it preserves the object model, has a better management of aspect scope,

and presents a more understandable and maintainable semantic model.

As a consequence of its particular weaving method, and of staying away from spe-

cialized JVMs and bytecode manipulation for aspect-weaving, AspectJ2EE is similar

to, yet (slightly) less general than, the AspectJ programming language [8]. Neverthe-

less, standing on the shoulders of the J2EE experience, we can argue that AspectJ2EE

is highly suited to systematic development of enterprise applications. Perhaps the main

limitation of AspectJ2EE when compared to ApsectJ is that it does not directly support

ﬁeld read and write join points, and hence cannot be employed for low-level debugging

or nit-picking logging. If however the design of a software solution is such that the

management of a certain ﬁeld can be decomposed into several aspects, then this ﬁeld

can be realized as a J2EE attribute, with join points at its retrieval and setting.

The semantic model of applying an aspect to a class in AspectJ2EE is shown to be

conceptually similar to the application of a generic type deﬁnition to a class, yielding

a new type. This has both theoretical and practical implications, since maintaining the

standard object model makes AspectJ2EE easier to understand and master, a crucial

consideration for the widespread adoption of any new technology in the ﬁeld of en-

terprise application development

. Despite the similarities, we show that AspectJ2EE

aspects are more ﬂexible and expressive than generics when used to extend existing

types.

AspectJ2EE also introduces parameterized aspects. These constructs, combined

with AspectJ2EE’s aspect binding language, make aspects in AspectJ2EE more

reusable than AspectJ aspects.

We stress that unlike previous implementations of aspects within the standard object

model, AspectJ2EE does not merely support “before” and “after” advices and “method

execution” join points. AspectJ2EE supports “around” advices, and a rich set of join

points, including control-ﬂow based, conditional, and object- and class-initialization.

Using AspectJ2EE, the ﬁxed set of standard J2EE services is replaced by a library of

core aspects. These services can be augmented with new ones, such as logging and per-

formance monitoring. Moreover, the AspectJ2EE language has speciﬁc support for the

composition of aspects that are scattered across program tiers (tier-cutting concerns),

such as encryption, data compression, and memoization.

Terminology. The article assumes basic familiarity with standard AOP terms, in-

cluding join point (a well-deﬁned point in the program’s execution), pointcut (a spec-

iﬁcation of a set of join points), advice (code that is added at speciﬁed join points),

weaving (the process of applying advices to join points), and aspect (a language con-

struct containing advices).

Outline. Section 2 makes the case for AspectJ2EE by explaining in greater detail

how J2EE services can be thought of as aspects. Discussing the beneﬁts of using AOP

for these services, we present the main points in which the design of AspectJ2EE is

different than standard AOP. The deploy time weaving strategy is discussed in Sect. 3.

Section 4 shows how the AspectJ2EE approach introduces AOP into the OOP model

without breaking it. Section 5 introduces some of the ﬁne points and innovations in the

language, and discusses implementation details. Section 6 lists several possible innova-

tive uses for AspectJ2EE, some of which can lead to substantial performance beneﬁts.

Section 7 concludes.

Historically, the developers of enterprise applications are slow to adopt new technologies; a

technology has to prove itself again and again, over a long period of time, before the main-

tainers of such large-scale applications will even consider adopting it for their needs. It is not

a coincidence that many large organizations still use and maintain software developed using

some technologies, such as COBOL [9], that other sectors of the software industry view as

thoroughly outdated.

2 The Case for AOP in J2EE

2.1 J2EE Services as Managers of Non-Functional Concerns

Ideally, with the J2EE middleware framework (and to a lesser extent in other such

frameworks), the developer only has to implement the domain-speciﬁc business logic.

This “business logic” is none other than what the AOP community calls functional con-

cerns. The framework takes charge of issues such as security, persistence, transaction

management, and load balancing which are handled by services provided by the EJB

container [10, Chap. 2]. Again, these issues are none other than non-functional con-

cerns in AOP jargon.

Suppose for example that the programmer needs data objects whose state is mir-

rored in persistent storage. This storage must then be constantly updated as the object

is changed during its lifetime, and vice versa. Automatic updates can be carried out

by the Container-Managed Persistence (CMP) service of the EJB container. To make

this happen, the objects should be deﬁned as entity beans [2, Chap. 10]. Bean types

are mapped to tables in a relational database with an appropriate XML conﬁguration

ﬁle. This deployment descriptor ﬁle also maps each bean attribute (persistent instance

variable) to a ﬁeld of the corresponding table.

Another standard J2EE service is security, using an approach known as role-based

security. Consider, for example, a ﬁnancial software system with two types of users:

clients and tellers. A client can perform operations on his own account; a teller can per-

form operations on any account, and create new accounts. By setting the relevant values

in the program’s deployment descriptor, we can limit the account-creation method so

that only users that were authenticated as tellers will be able to invoke it.

Other services provided by the EJB container handle issues such as transaction

management and load balancing. The developer speciﬁes which services are applied

to which EJB. Deployment descriptors are used for setup and customization of these

services. Thus, J2EE reduces the implementation of many non-functional concerns into

mere conﬁguration decisions; in many ways, they turn into non-concerns.

And while this work focuses on EJBs, the J2EE design guideline, according to

which the developer conﬁgures various services via deployment descriptors, is not lim-

ited to EJBs only. It is also used in other parts of the J2EE platform. For example,

servlets (server-side programs for web servers) also receive services such as security

from their container, and access to speciﬁc servlets can be limited using role-based

security. This is also true for Java Server Pages (JSPs), another key part of the J2EE ar-

chitecture. Hence, in our ﬁnancial software example, certain privileged web pages can

be conﬁgured so that they will be only accessible to tellers and not to clients.

The various issues handled by EJB container services were always a prime target

for being implemented as aspects in AOP-based systems [11, pp. 13–14]. For example,

Soares et. al. [4] implement distribution, persistence and transaction aspects for soft-

ware components using AspectJ. Security was implemented as an aspect by Hao et.

al. [5]. The use of aspects reduces the risk of scattered or tangled code when any of

these non-functional concerns is added to a software project.

Conversely, we ﬁnd that J2EE developers, having the beneﬁt of container services,

do not require as much AOP. Indeed, Kim and Clarke [6] present a case study where

they investigate the relevance of AOP to J2EE developers. The case study comprised of

an e-voting system which included ﬁve non-functional concerns: (1) persistent storage

of votes, (2) transactional vote updates, (3) secure database access, (4) user authentica-

tion, and (5) secure communications using a public key infrastructure [6, Table 1]. Of

these ﬁve non-functional concerns, not one remained cross-cutting or introduced tan-

gled code. The ﬁrst three were handled by standard J2EE services, conﬁgured by setting

the proper values in the deployment descriptors. The last two were properly modular-

ized into a small number of classes (two classes in each case) with no code replication

and no tangled code.

The implementation of services in J2EE also includes sophisticated mechanisms for

combining each of the services, as conﬁgured by the deployment descriptors, with the

user code. We will discuss these mechanisms, which can be though of as the equiva-

lent of aspect weaving, in detail below (Sect. 3). Sufﬁce to say at this point that the

combination in J2EE is carried out without resorting to drastic means such as byte code

patching and code preprocessing—means which may break the object model, confuse

debuggers and other language tools, and even obfuscate the semantics.

2.2 Limitations of the Services-Based Solution

Even though the J2EE framework reduces the developer’s need for AOP tools, there are

limits to such beneﬁts. The reason is that although the EJB container is conﬁgurable,

it is neither extensible nor programmable. Pichler, Ostermann, and Mezini [12] refer to

the combination of these two problems as lack of tailorability.

The container is not extensible in the sense that the set of services it offers is ﬁxed.

Kim and Clarke [6] explain why supporting logging in the framework would require

scattered and tangled code. In general, J2EE lacks support for introducing new services

for non-functional concerns which are not part of its speciﬁcation. Among these con-

cerns, we mention memoization, precondition testing, and proﬁling.

The container is not programmable in the sense that the implementation of each of

its services cannot be easily modiﬁed by the application developer. For example, current

implementations of CMP rely on a rigid model for mapping data objects to a relational

database. The service is then useless in the case that data attributes of an object are

drawn from several tables. Nor can it be used to deﬁne read-only beans that are mapped

to a database view, rather than a table. The CMP service is also of no use when the

persistent data is not stored in a relational database (e.g., when ﬂat XML ﬁles are used).

Any variation on the functionality of CMP is therefore by re-implementation of

object persistence, using what is called Bean-Managed Persistence (BMP). BMP sup-

port requires introducing callback methods (called lifecycle methods in EJB parlance)

in each bean. Method ejbLoad() (ejbStore()) for example is invoked whenever

memory (store) should be updated.

The implication is that the pure business logic of EJB classes is contaminated with

unrelated I/O code. For example, the tutorial code of Bodoff et. al. [13, Chap. 5],

demonstrates a mixup in the same bean of SQL queries and a Java implementation

of functional concern. Conversely, we ﬁnd that the code in charge of persistence is scat-

tered across all entity bean classes, rather than being encapsulated in a single cohesive

module.

评论收藏

内容反馈

JoJo_Adventure

2015-07-08

积分好高！和这个分不太配吧。。和我自己的毕设不太对口所以并没有用上。

wza13579

粉丝: 5
资源: 10

原创毕业设计翻译—J2EE—外国论文原文+翻译

毕业设计外文翻译论文原文及译文

依据VB原创库存管理系统（开题报告+外文翻译+论文正文+毕业设计源代码+可执行程序）

VB原创库存管理系统（开题报告+外文翻译+论文正文+源代码+可执行程序）_计算机毕业设计源代码.rar

FPGA数字频率计的设计中英对照外文文献翻译毕业设计论文人工翻译原文

VB毕业设计——VB原创库存管理系统（开题报告+外文翻译+论文正文+源代码+可执行程序）.zip

(J2EE)+Design+Specification+Template

java毕业设计——基于J2EE的B2C电子商务系统的设计与实现(论文+系统+开题报告++答辩PPT+中期报表+说明书).zip

jsp ssh mvc java web j2ee网络商城+论文+源码 购物系统网页设计

毕业设计 j2ee 相关 外文翻译论文

搞定J2EE：STRUTS+SPRING+HIBERNATE整合详解与典型案例 (1)

开发者突击·Java Web主流框架整合开发(J2EE+Struts+Hibernate+Spring)源码

Wrox+-+Expert+One-on-One+J2EE+Design+and+Development

程序天下 J2EE struts+spring+Hibernate源码(上)

精通J2EE——Eclipse+Struts+Hibernate+Spring整合应用案例(pdf完整版).part2-1

程序天下 J2EE struts+spring+Hibernate(中2)

程序天下J2EE structs+pring+Hibente源码（4）

程序天下 J2EE struts+spring+Hibernate(中1)

开发者突击:Java Web主流框架整合开发(J2EE+Struts+Hibernate+Spring)(第2版) 带封面和目录、前言(6/6)

J2EE+1.6++API j2eeapi

j2ee外文期刊以及相应的中文翻译

[毕业设计]Java J2EE B2C电商系统设计(论文+系统+文档+开题报告).zip

J2EE-java版+struts2做的oa

开发者突击:Java Web主流框架整合开发(J2EE+Struts+Hibernate+Spring)(第2版) 带封面和目录、前言(4/6)

开发者突击:Java Web主流框架整合开发(J2EE+Struts+Hibernate+Spring)(第2版) 带封面和目录、前言(3/6)

[毕业设计]Java B2C电商平台构建(J2EE+文档+代码+答辩+开题报告).zip

适合练手、课程设计、毕业设计的Java项目源码：基于J2EE的B2C电子商务系统开发（论文+系统+开题报告+答辩PPT）.rar

J2EE平台下SSH+JBPM+ExtJs

Flex+J2EE实例（cairngorm+blazeDS+hibernate+spring）完整版本

基于JAVA毕业设计-J2EE的B2C电子商务系统开发（论文+系统+开题报告+文献综述+任务书+答辩PPT+中期报表+外文文献

毕业设计 基于J2EE的B2C电子商务系统开发（论文+系统+开题报告+文献综述+任务书+答辩PPT+中期报表+外文文献+说明书）

最新资源

jsp ssh mvc java web j2ee网络商城+论文+源码购物系统网页设计

毕业设计 j2ee 相关外文翻译论文

毕业设计基于J2EE的B2C电子商务系统开发（论文+系统+开题报告+文献综述+任务书+答辩PPT+中期报表+外文文献+说明书）