在 Java EE 容器中扩展云特性毕业论文外文资料翻译.doc

《在 Java EE 容器中扩展云特性毕业论文外文资料翻译.doc》由会员分享，可在线阅读，更多相关《在 Java EE 容器中扩展云特性毕业论文外文资料翻译.doc（25页珍藏版）》请在三一办公上搜索。

1、 毕业设计(论文)外文资料翻译学生姓名： 学 号： 所在学院： 电子与信息工程学院 专 业： 计算机科学与技术 指导教师： 2011年 12月 25 日English Data Original TextTranslates the foreign materials: Author: Jayakrishnan Ramdas(jkramdas), Senior Technology Architect, Infosys LTD J. Srinivas(jsrinivas), Principal Architect, Infosys LTD Book title (or paper topic)

2、: Extend Java EE containers with cloud characteristics Publishing house (or publication name): Publication time (or registration number): august 2011Extend Java EE containers with cloud characteristicsStrategies and patterns to extend JEE containers/apps with parallelism, elasticity, multi-tenancy,

3、and securityThe Java Enterprise Edition (JEE) architecture is based on components with features that effectively manage application transactions and statefulness, multi-threading, and resource pooling. A JEE application is easier to write even with complex requirements since the business logic is or

4、ganized in reusable components and the server provides the underlying services in the form of a container for each component type.We thought it would be a novel idea to add even more power to the concept of container services in JEE by adding support for some of the powerful ideas of cloud computing

5、 namely parallelism, elasticity, multi-tenancy, and security. This article describes the strategies and patterns to extend JEE containers and applications with cloud computing characteristics. It includes: An outline of each cloud characteristic we integrated. A layout of the existing characteristic

6、s of JEE applications. A description of our approach to extend the JEE container to the cloud. A design strategy for this type of migration, one that includes the concepts of parallelism, synchronization, storage, elasticity, multi-tenancy, and security.Cloud characteristicsFigure 1 explains what cl

7、oud is and the different cloud deployment models.Figure 1. A birds eye view of cloud service models and their componentsAt the bottom of the cloud stack is the Infrastructure as a Service (IaaS) level. Here the infrastructure has moved to cloud and the cloud now facilitates the deployment of softwar

8、e including business applications. However the IaaS does not have an application-development environment or any testing services. As the figure shows, the top level of abstraction is elasticity, automated deployment, and utility computing.The Platform as a Service (PaaS) level provides an environmen

9、t for application software to be created, deployed, and maintained. The PaaS provider has to give the basic life cycle services like build, deploy, testing and building block services like state management, transaction, and security, as well as resource management services through the runtime.The So

10、ftware as a Service (SaaS) level provides an environment for the end-user to access an application and use it.The basic cloud characteristics that an application needs to support are elasticity and multi-tenancy. Other characteristics, like provisioning and automation, are supported through the depl

11、oyment features of the application server and do not have much of an impact on the code. Parallelism, distributed storage needs, and security enhancements act as supporting characteristics that need to be addressed to achieve elasticity and multi-tenancy.Lets look at each in more detail.ElasticityEl

12、asticity is the ability to scale up and down the infrastructure based on need. During peak load times, more instances are added to the cluster and when the load comes down, the number of instances comes down. This should be done dynamically. This function is enabled by features of the application se

13、rver to support dynamic clustering techniques.Elasticity is not just an application server solution; the application itself should be able to support elasticity. This means the application needs to be designed to handle the resources that it uses to support concurrency. By designing or customizing a

14、n application to support elasticity, you imply that youve also implemented parallelism, statelessness, and transaction support in your application.The design strategy section describes how to implement elasticity that has all the resources support statelessness in execution and parallelism.Multi-ten

15、ancyMulti-tenancy means your application has the ability for a single application instance to cater to multiple customers; this means that if five customers are using a content management service, then all five customers can use the same application instance with adequate segregation of data and exe

16、cution parameters. To support multi-tenancy, your application needs to engage distributed storage, parallelism, security, and loose coupling.There are two approaches to support multi-tenancy: A single physical storage for all tenants. Multiple physical storage resources for tenants.Parallelism and t

17、ransaction supportIn the content of this article, parallelism is the ability to execute multiple requests in parallel or to split a large dataset task into multiple subtasks which are executed in parallel. This makes better use of available resources. Employing parallelism has a positive impact on t

18、hroughput and performance. Transaction support ensures reliability by guaranteeing that changes in state of any resource are synchronized. These two concepts sit on opposite ends of a spectrum - if you do more of one, you do less of the other.The right mixture of parallelism and transaction support

19、is essential to balance these opposing characteristics. The strategies section introduces four strategies, two each for parallelism and transaction support: A synchronous and asynchronous approach for parallelism. A thread-completion and a data-arrival synchronization approach for transaction suppor

20、t.The migration strategy described follows non-functional approaches to parallelism, but there are some that require functional changes. Like the Google framework MapReduce; MR describes a way of implementing parallelism using the Map function which splits a large data into multiple key-value pairs.

21、 (See Resources for articles on MapReduce and the cloud.)Loose coupling and statelessnessLoose coupling ensures that every call to a service is made through a standard interface; this enables the called component and caller component to be changed without one impacting the other. Loose coupling is i

22、ntroduced by a proxy which invokes the call. Statelessness is a property of loose coupling in which every call to a service does not depend on the previous call. It is achieved by managing state changes in a persistent storage.Both of these are complimentary characteristics that make system calls mo

23、re independent of dependencies.Distributed storageDistributed storage is a means to persist data so that the location of the data is not important. It also means that there are different places where the same data can be stored. This characteristic improves elasticity and statelessness, but can nega

24、tively impact transaction support, so it will require a balancing act.Four strategies for distributed storage include: Replicated nodes: Data is available at different nodes and is replicated immediately to other nodes. Replication on-demand: Triggers are defined that cause data replication manually

25、 or automatically. One-way replication with failover: The master-to-child node plan; during a master node fail, replication duties are assigned to a specific child. File system sharing: Used when replication is costly like with file system resources.SecurityCloud application security impacts certain

26、 characteristics strongly: Multi-tenancy, parallelism, and loose coupling introduce additional security needs. And if your application is deployed as a hybrid (for example, a cloud component and a local system component), you need to ensure a cross-domain, single sign-on capability which carries add

27、itional security implications.There are also security issues with distributed storage, parallelism, and transport.Now that you are familiar with cloud application characteristics, lets look at a Java EE container structure.Java EE container application characteristicsTraditional JEE applications dep

28、end on container services and use: Sticky sessions for connection state management RDBMS either directly through SQLs or stored procedures indirectly using ORM JMS objectsThey may also use message-driven Beans and Session Beans and web services implemented using the framework provided by the contain

29、er. The newly built applications might use asynchronous processing, as well as caching services or JavaMail services.Lets examine some attributes and functions of JEE container applications in detail.Data and operationEvery bit of programming logic can be abstracted into a data- (or memory-) related

30、 part and an operation- (or execution-) related part which interacts with each other so that the operation works on data and data is used by operation. The entire JEE package, container and application, can be abstracted in the same manner.ContainerThe quality of data aspect is measured by the abili

31、ty to ensure reliability of data accessed, availability of data accessed, being able to allow concurrency as well as security of the data in storage. The quality of operation aspect is measured by being able to ensure a listeners ability to listen to arrival of data, ability to invoke a remote call

32、as well as access control and transport security.Table 1. Providing quality for the data and operation aspect of a JEE applicationQuality attributeImplementation attributeImplementationDataReliabilityTransactionTransactions provide synchronized access to the data.AvailabilityPersistenceThe type of p

33、ersistence determine availability of data.ConcurrencyState managementThe state management mechanism ensures how many concurrent requests can be processed.SecuritySecurityThe encryption in storage and transit.OperationAsynchronous communicationListenerThe trigger for asynchronous calls.Synchronous co

34、mmunicationRemote invocationThe synchronous call outside the current process.SecuritySecurityThe access control check as well as transport security.The responsibility of container is two-fold:1 To have a mechanism to ensure that the quality attributes of data and operation are maintained.2 To contro

35、l the usage of system resources like heap memory, number of execution threads, etc.This leads to two distinct patterns you should be concerned with the managed resource pattern and the managed task pattern.Managed resource patternA managed resource provides a data-related service and it implements s

36、ession management, transaction, persistence, and security. The caller uses the naming directory to locate the resource manager. The resource manager uses the object pool provided by the container to manage system resources. A typical managed resource has the pattern you see in Figure 2.Figure 2. The

37、 managed resource patternThe container or application can get a handle on the resource manager through JNDI. The resource manager implements the object pool and it gets the managed resource that implements persistence, security state management, and transaction.Managed task patternA managed task pro

38、vides operation-related services that implements remote invocation, listener, and security and it uses the thread pool and naming directory services provided by the container. In addition, a managed task most likely encapsulates one or more of the managed resources that it works on. The managed list

39、ener is triggered by the container based on data arrival the data can be in the form of time, message, or request. It also can be triggered by the application as well.Figure 3. The managed task patternEvery service that container provides can be decomposed into one of the patterns or into a combinat

40、ion of the two patterns. For example, Java Message Service (JMS) has a managed resource pattern for JMS Destinations and a managed task pattern for JMS MessageListener. Similarly JDBC Connection is a managed resource pattern.Now that we have covered how the JEE container application functions, lets

41、look at how to extend a container application to the cloud.Extending containers: The basic approachThe approach for extending container to cloud is to:1 Decompose the cloud characteristics into the implementation attributes and then2 Enhance the managed resource pattern and managed task pattern with

42、 the implementation attribute-related changes.The strategy section shows how the managed resource pattern is extended to the cloud resource pattern and the managed task pattern is extended to the cloud task pattern.The managed resource pattern employs the following extensions to create the cloud res

43、ource pattern (see Figure 4): CloudResource Isolator Replicator LockManager LockDataResource StateDataResourceSimilarly the managed task pattern is extended with Proxy and StateManager to create the cloud task pattern (see Figure 5).Lets discuss some of these components.Cloud resource patternThe clo

44、ud resource pattern includes the list of extensions just mentioned. Here is a description of each component and their interactions with each other.CloudResourceThe CloudResource extends the managed resource to include distributed transactions and state persistence logic, if needed.StateDataResourceT

45、he StateDataResource is an instance of CloudResource that represents a state change for the given cloud resource. The state persistence logic itself is executed in a stateless manner.IsolatorThe Isolator uses a control field in the input to identify the customer tenant and applies the relevant secur

46、ity and partition logic to store in the correct place. The Isolator ensures that the application code is not cluttered with the multi-tenant storage strategies and ensures that right multi-tenant strategy is applied. The Isolator in itself is a collection of CloudResources.ReplicatorThe Replicator i

47、s used only if replicated nodes and replication on demand storage strategies are used. The Replicator ensures that the data is persisted in all the replicated nodes as a single distributed transaction. The difference between Isolator and Replicator is that Isolator ensures data goes into correct sto

48、rage based on the tenant and Replicator ensures data goes into all the storages replicated for same tenant.LockManager and LockDataResourceThe functionality of LockManager is to lock a particular data for a thread in a process across all Replicators. The LockManager ensures the same view of status across all replicated nodes. It means that if data is locked for a thread in a server pr