第1页 / 共21页
第2页 / 共21页
第3页 / 共21页
第4页 / 共21页
第5页 / 共21页
第6页 / 共21页
第7页 / 共21页
第8页 / 共21页
JSP相关英文文献翻译.doc
Infrastructure for Automatic Dynamic Deployment
Of J2EE Application in Distributed Environments
1 前言
2 J2EE背景知识
Infrastructure for Automatic Dynamic Deployment
Of J2EE Application in Distributed Environments
CIMS Technical Report: TR2005-867
Anatoly Akkerman, Alexander Totok, and Vijay Karamcheti
Department of Computer Science
Courant Institute of Mathematical Sciences
New York University,NewYork,NY,USA
{akkerman,totok,vijayk}@cs.nyu.edu
Abstract: in order to achieve such dynamic adaptation, we need an infrastructure for
automating J2EE application deployment in such an environment. This need is quite evident
to anyone who has ever tried deploying a J2EE application even on a single application server,
which is a task that involves a great deal of configuration of both the system services and
application components.
Key words: j2ee; component; Distributed; Dynamic Deployment;
1 Introduction
In recent years, we have seen a significant growth in component-based enterprise application
development. These applications are typically deployed on company Intranets or on the
Internet and are characterized by high transaction volume, large numbers of users and wide
area access. Traditionally they are deployed in a central location, using server clustering with
load balancing (horizontal partitioning) to sustain user load. However, horizontal partitioning
has been shown very efficient only in reducing application-related overheads of
user-perceived response times, without having much effect on network-induced latencies.
Vertical partitioning (e.g., running web tier and business tier in separate VMs) has been used
for fault isolation and load balancing but it is sometimes impractical due to significant
run-time overheads (even if one would keep the tiers on a fast local-area network) related to
heavy use of remote invocations. Recent work [14] in the context of J2EE component based
applications has shown viability of vertical partitioning in wide-area networks without
incurring the aforementioned overheads. The key conclusions from that study can be
summarized as follows:
• Using properly designed applications, vertical distribution across wide-area networks
improves user-perceived latencies.
• Wide-area vertical layering requires replication of application components and maintaining
consistency between replicas.
• Additional replicas may be deployed dynamically to handle new requests.
• Different replicas may, in fact, be different implementations of the same component based
on usage (read-only, read-write).
• New request paths may reuse components from previously deployed paths.
Applying intelligent monitoring [6] and AI planning [2, 12] techniques in conjunction with
the conclusions of that study, we see a potential for dynamic adaptation in industry-standard
J2EE component-based applications in wide area networks
Through deployment of additional application components dynamically based on active
monitoring. However, in order to achieve such dynamic adaptation, we need an infrastructure
for automating J2EE application deployment in such an environment. This need is quite
evident
to anyone who has ever tried deploying a J2EE application even on a single
application server, which is a task that involves a great deal of configuration of both the
system services and application components. For example one has to set up JDBC data
sources, messaging destinations and other resource adapters before application components
can be configured and deployed. In a wide area deployment that spans multiple server nodes,
this proves even more complex, since more system services that facilitate inter-node
communications need to be configured and started and a variety of configuration data, like IP
addresses, port numbers, JNDI names and others have to be consistently maintained in
various configuration files on multiple nodes.
This distributed deployment infrastructure must be able to:
• address inter-component connectivity specification and define its effects on component
configuration and deployment,
• address application component dependencies on application server
configuration and deployment,
• provide simple but expressive abstractions to control adaptation through dynamic
deployment and undeployment of components,
• enable reuse of services and components to maintain efficient use of network nodes’
resources,
• provide these facilities without incurring significant additional design effort on behalf of
services,
their
application programmers.
In this paper we propose the infrastructure for automatic dynamic deployment of J2EE
applications, which addresses all of the aforementioned issues. The infrastructure defines
architecture description languages (ADL) for component and link description and assembly.
The Component Description Language is used to describe application components and links.
It provides clear separation of application components from system components. A flexible
type system is used to define compatibility of component ports and links. A declaration and
expression language for configurable component properties allows for specification of
inter-component dependencies and propagation of properties between components. The
Component (Replica) Assembly Language allows for assembly of replicas of previously
defined components into application paths by
Connecting appropriate ports via link replicas and specifying the mapping of these component
replicas onto target application server nodes. The Component Configuration Process evaluates
an application path’s correctness, identifies the dependencies
of application components on system components, and configures component replicas for
deployment. An attempt is made to match and reuse any previously deployed replicas in the
new path based on their configurations. We implement the infrastructure as a part of the JBoss
open source Java application server [11] and test it on several
Sample J2EE applications – Java Pets tore [23], Rubies [20] and TPC-W-NYU [32]. The
infrastructure implementation utilizes the JBoss’s extendable micro-kernel architecture, based
on the JMX [27] specification. Componentized architecture of JBoss allows incremental
service deployments depending on the needs of deployed applications. We believe that
dynamic
and
undeployment of system services is essential to building a resource-efficient framework for
dynamic distributed deployment of J2EE applications. The rest of the paper is organized as
follows. Section 2 provides necessary background for understanding the specifics of the J2EE
component technology which are relevant to this study. Section 3 gives a general description
of the infrastructure architecture, while section 4 goes deeper in describing particularly
important and interesting internal mechanisms of the infrastructure. Section 5 describes the
implementation of the framework, and related work is discussed in section 6.
through dynamic deployment
reconfiguration of
application servers
framework, which establishes
2 J2EE Background
2.1 Introduction
Component frameworks. A component framework is a middleware system that supports
applications consisting of components conforming to certain standards. Application
components are “plugged” into the component
their
environmental conditions and regulates the interactions between them. This is usually done
through containers, component holders, which also provide commonly required support for
naming, security, transactions, and persistence. Component frameworks provide an integrated
environment for component execution, as a result significantly reduce the effort .it takes to
design,
implement, deploy, and maintain applications. Current day industry component
framework standards are represented by Object Management Group’s CORBA Component
Model [18], Sun Microsystems’ Java 2 Platform Enterprise Edition (J2EE) [25] and
Microsoft’s .NET [17], with J2EE being currently the most popular and widely used
component framework in the enterprise arena.
J2EE. Java 2 Platform Enterprise Edition (J2EE) [25] is a comprehensive standard for
developing multi-tier enterprise Java applications. The J2EE specification among other things
defines the following:
• Component programming model,
• Component contracts with the hosting server,
• Services that the platform provides to these components,
• Various human roles,
• Compatibility test suites and compliance testing procedures.
Among the list of services that a compliant application server must provide are messaging,
transactions, naming and others that can be used by the application components. Application
developed using J2EE adhere to the classical 3-Tier architectures – Presentation Tier,
Business Tier, and Enterprise Information System (EIS) Tier (see Fig. 1). J2EE components
belonging to each tier are developed adhering to the
Specific J2EE standards.
1. Presentation or Web tier.
This tier is actually subdivided into client and server sides. The client side hosts a web
local vs.
browser, applets and Java applications that communicate with the server side of presentation
tier or the business tier. The server side hosts Java Servlet components [30], Java Server
Pages (JSPs) [29] and static web content. These components are responsible for presenting
business data to the end users. The data itself is typically acquired from the business tier and
sometimes directly from the Enterprise Information System tier. The server side of the
presentation tier is typically accessed through HTTP(S) protocol.
2. Business or EJB tier.
This tier consists of Enterprise Java Beans (EJBs) [24] that model the business logic of the
enterprise application. These components provide persistence mechanisms and transactional
support. The components in the EJB tier are invoked through remote invocations (RMI),
in-JVM invocations or asynchronous message delivery, depending on the type of EJB
component. The EJB specification defines several types of components. They differ in
invocation style (synchronous vs. asynchronous,
remote) and statefulness:
completely stateless (e.g., Message-Driven Bean), stateful non-persistent
(e.g., Stateful Session Bean), stateful persistent (e.g., Entity Bean). Synchronously invocable
EJB components expose themselves through a special factory proxy object (an EJB Home
object, which is specific to a given EJB), which is typically bound in JNDI by the deployer of
the EJB. The EJB Home object allows creation or location of an EJB
Object, which is a proxy to a particular instance of an EJB 1.
3. Enterprise Information System (EIS) or Data tier.
This tier refers to the enterprise information systems, like relational databases, ERP systems,
messaging systems and the like. Business and presentation tier component communicate with
this tier with the help of resource adapters as defined by the Java Connector Architecture
[26].The J2EE programming model has been conceived as a distributed programming model
where application components would run in J2EE servers and communicate with each other.
After the initial introduction and first server implementations, the technology, most notably,
the EJB technology has seen some a significant shift away from purely distributed computing
model towards local interactions 2. There were very legitimate performance-related reasons
behind this shift, however the
Distributed features are still available. The J2EE specification has seen several revisions, the
latest stable being version 1.3, while version 1.4 is going through last review phases 3. We
shall focus our attention on the former, while actually learning from the latter. Compliant
commercial J2EE implementations are widely available from BEA Systems [4], IBM [9],
Oracle [21] and other vendors. Several open source implementations, including JBoss [11]
and JOnAS [19] claim compatibility as well. A
Recent addition to the list is a new Apache project Geronimo [1].
2.2 J2EE Component Programming Model
Before we describe basic J2EE components, let’s first address the issue of defining what a
component is a software component is a unit of composition with contractually specified
interfaces and explicit context dependencies only. A software component can be deployed
independently and is subject to composition by third parties [31].According to this definition
the following entities which make up a typical J2EE application would be considered
application components (some exceptions given below):
• EJBs (session, entity, message-driven),
• Web components (servlets, JSPs),
• messaging destinations,
• Data sources,
EJB and Web components are deployed into their corresponding containers provided by the
application server vendor. They have well-defined contracts with their containers that govern
lifecycle, threading, persistence and other concerns. Both Web and EJB components use JNDI
lookups to locate resources or other EJB components they want to communicate with. The
JNDI context in which these lookups are performed is maintained separately for each
component by its container. Bindings messaging destinations, such as topics and queues, are
resources provided by a messaging service implementation. Data sources are resources
provided by the application server for data access by business components into the enterprise
information services (data) tier, and most commonly are exemplified by JDBC connection
pools managed by the application
Server. A J2EE programmer explicitly programs only EJBs and Web components. These
custom-written components interact with each other and system services both implicitly and
explicitly. For example, an EJB developer may choose explicit transaction demarcation (i.e.,
Bean-Managed Transactions) which means that the developer assumes the burden of writing
explicit programmatic interaction with the platform’s Transaction Manager Service through
well-defined interfaces. Alternatively,
the developer may choose Container-Managed
transaction demarcation, where transactional behavior of a component is defined through its
descriptors and handled completely by the EJB container,
thus acting as an implicit
dependency of the EJB on the underlying Transaction Manager service.
2.3 Links Between Components
2.3.1 Remote Interactions
J2EE defines only three basic inter-component connection types that can cross application
server boundaries, in all three cases; communication is accomplished through special Java
objects.
• Remote EJB invocation: synchronous EJB invocations through EJB Home and EJB Object
interfaces.
• Java Connector outbound connection: synchronous message receipt, synchronous and
asynchronous message sending,
Database query using Connection Factory and Connection interfaces.
• Java Connector inbound connection: asynchronous message delivery into Message-Driven
Beans (MDBs) only, utilizing Activation Spec objects. In the first two cases, an application
component developer writes the code that performs lookup of
these objects in the
component’s run-time JNDI context as well as code that issues method invocations or sends
and receives messages to and from the remote component. The component’s run-time JNDI
context is created for each deployment of the component.
Bindings in the context are initialized at component deployment time by the deployed
(usually by means of component’s deployment descriptors). These bindings are assumed to be
static, since the specification does not provide any contract between the container and the
component
to inform of any binding changes In the case of Java Connector inbound
communication, Activation Spec object lookup and all subsequent interactions with it are
done implicitly by the MDB container. The protocol for lookup has not been standardized,
though it is reasonable to assume a JMX- or JNDI-based lookup assuming the underlying
application server provides
to control each step of deployment process,
facilities
establishment of a link between J2EE components would involve:
• Deployment of target component classes (optional for some components, like destinations),
• Creation of a special Java object to be used as a target component’s proxy,
• Binding of this object with component’s host naming service (JNDI or JMX),
• Start of the target component,
• Deployment of referencing component classes,
• Creation and population of referencing component’s run-time context in its host naming
service,
• start of the referencing component.
However, none of modern application servers allow detailed control of the deployment
process for all component
is possible by limited options in their
deployment descriptors 4. Therefore our infrastructure will use a simplified approach that
relies on features currently available on most application servers:
• Ability to deploy messaging destinations and data sources dynamically,
• Ability to create and bind into JNDI special objects to access messaging destinations and
data sources,
• Ability to specify initial binding of EJB Home objects upon EJB component deployment,
• Ability to specify a JNDI reference 5 in the referencing component’s run-time context to
point to the EJB Home binding of the referenced EJB component. In our infrastructure which
is limited to homogeneous application servers,
to control
intercomponent
in
context of heterogeneous application servers, simple JNDI references and thus simple
descriptor manipulation are insufficient due to cross-application-server
Classloading issues.
2.3.2 Local Interactions
Some interactions between components can occur only between components co-located in the
same application server JVM and sometimes only in the same container. In the Web tier,
examples of such interactions are servlet-to-servlet request forwarding. In the EJB tier, such
interactions are CMP Entity relations and invocations via EJB local interfaces. Such local
deployment concerns need not be exposed at
the level of a distributed deployment
links through simple deployment descriptor manipulation. However,
types beyond what
these options are sufficient
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
