在 Java EE 容器中擴展云特性畢業(yè)論文外文資料翻譯

《在 Java EE 容器中擴展云特性畢業(yè)論文外文資料翻譯》由會員分享，可在線閱讀，更多相關《在 Java EE 容器中擴展云特性畢業(yè)論文外文資料翻譯（25頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、 畢業(yè)設計(論文) 外文資料翻譯 學生姓名： 學 號： 所在學院： 電子與信息工程學院 專 業(yè)： 計算機科學與技術 指導教師： 2011年 12月 25 日 English Data Original Text Translates the foreign materials: ① Author: Jayakrishnan Ramdas(jkramdas@), Senio

2、r Technology Architect, Infosys LTD J. Srinivas(jsrinivas@), Principal Architect, Infosys LTD ② Book title (or paper topic): Extend Java EE containers with cloud characteristics ③ Publishing house (or publication name): ④ Publication time (or registration number): august 2011 Ex

3、tend Java EE containers with cloud characteristics Strategies and patterns to extend JEE containers/apps with parallelism, elasticity, multi-tenancy, and security The Java Enterprise Edition (JEE) architecture is based on components with features that effectively manage application transactions an

4、d statefulness, multi-threading, and resource pooling. A JEE application is easier to write even with complex requirements since the business logic is organized in reusable components and the server provides the underlying services — in the form of a container — for each component type. We thought

5、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 — namely parallelism, elasticity, multi-tenancy, and security. This article describes the strategies and patterns to extend JEE containers a

6、nd applications with cloud computing characteristics. It includes: An outline of each cloud characteristic we integrated. A layout of the existing characteristics of JEE applications. A description of our approach to extend the JEE container to the cloud. A design strategy for this type of m

7、igration, one that includes the concepts of parallelism, synchronization, storage, elasticity, multi-tenancy, and security. Cloud characteristics Figure 1 explains what cloud is and the different cloud deployment models. Figure 1. A birds eye view of cloud service models and their components

8、 At 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 software including business applications. However the IaaS does not have an application-development environment or any testing

9、 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 environment for application software to be created, deployed, and maintained. The PaaS provider has to give the basic life cycl

10、e 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 Software as a Service (SaaS) level provides an environment for the end-user to access an application and use it. The

11、 basic cloud characteristics that an application needs to support are elasticity and multi-tenancy. Other characteristics, like provisioning and automation, are supported through the deployment features of the application server and do not have much of an impact on the code. Parallelism, distributed

12、 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. Elasticity Elasticity is the ability to scale up and down the infrastructure based on need. During peak load times, more

13、 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 server to support dynamic clustering techniques. Elasticity is not just an application server solution; the

14、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 an application to support elasticity, you imply that youve also implemented parallelism, statelessness, an

15、d 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-tenancy Multi-tenancy means your application has the ability for a single application instance to cater

16、 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 execution parameters. To support multi-tenancy, your application needs to engage distributed storage,

17、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 transaction support In the content of this article, parallelism is the ability to execute m

18、ultiple 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 throughput and performance. Transaction support ensures reliability by guaranteeing that c

19、hanges 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 is essential to balance these opposing characteristics. The strategies section introduc

20、es 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 support. The migration strategy described follows non-functional approaches to paralleli

21、sm, 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. (See Resources for articles on MapReduce and the cloud.) Loose coupling and sta

22、telessness Loose 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 introduced by a proxy which invokes the call. Statelessness is a property of l

23、oose 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 more independent of dependencies. Distributed storage Distributed storage i

24、s 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 negatively impact transaction support, so it will require a balancing act.

25、 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 or automatically. One-way replication with failover: The maste

26、r-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. Security Cloud application security impacts certain characteristics strongly: Multi-tenancy, parallelism, an

27、d 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 additional security implications. There are also security i

28、ssues 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 characteristics Traditional JEE applications depend on container services and use: Sticky sessi

29、ons for connection state management RDBMS either directly through SQLs or stored procedures indirectly using ORM JMS objects They may also use message-driven Beans and Session Beans and web services implemented using the framework provided by the container. The newly built applications might us

30、e asynchronous processing, as well as caching services or JavaMail services. Lets examine some attributes and functions of JEE container applications in detail. Data and operation Every bit of programming logic can be abstracted into a data- (or memory-) related part and an operation- (or executi

31、on-) 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. Container The quality of data aspect is measured by the ability to ensure reliability of dat

32、a 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 as well as access control and t

33、ransport security. Table 1. Providing quality for the data and operation aspect of a JEE application Quality attribute Implementation attribute Implementation Data Reliability Transaction Transactions provide synchronized access to the data. Availability Persistence The type of pers

34、istence determine availability of data. Concurrency State management The state management mechanism ensures how many concurrent requests can be processed. Security Security The encryption in storage and transit. Operation Asynchronous communication Listener The trigger for asynchronous

35、 calls. Synchronous communication Remote invocation The synchronous call outside the current process. Security Security The 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

36、 and operation are maintained. 2 To control 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 pattern A managed resource

37、provides a data-related service and it implements session 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 resourc

38、e has the pattern you see in Figure 2. Figure 2. The managed resource pattern The 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 managem

39、ent, and transaction. Managed task pattern A managed task provides 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 m

40、ore of the managed resources that it works on. The managed listener 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 pattern Every service that contain

41、er provides can be decomposed into one of the patterns or into a combination 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.

42、Now that we have covered how the JEE container application functions, lets look at how to extend a container application to the cloud. Extending containers: The basic approach The approach for extending container to cloud is to: 1 Decompose the cloud characteristics into the implementation attrib

43、utes and then 2 Enhance the managed resource pattern and managed task pattern with 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.

44、 The managed resource pattern employs the following extensions to create the cloud resource pattern (see Figure 4): CloudResource Isolator Replicator LockManager LockDataResource StateDataResource Similarly the managed task pattern is extended with Proxy and StateManager to create the

45、cloud task pattern (see Figure 5). Lets discuss some of these components. Cloud resource pattern The cloud resource pattern includes the list of extensions just mentioned. Here is a description of each component and their interactions with each other. CloudResource The CloudResource extends the

46、 managed resource to include distributed transactions and state persistence logic, if needed. StateDataResource The 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.

47、Isolator The Isolator uses a control field in the input to identify the customer tenant and applies the relevant security 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 righ

48、t multi-tenant strategy is applied. The Isolator in itself is a collection of CloudResources. Replicator The Replicator is 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

49、distributed transaction. The difference between Isolator and Replicator is that Isolator ensures data goes into correct storage based on the tenant and Replicator ensures data goes into all the storages replicated for same tenant. LockManager and LockDataResource The functionality of LockManager i

50、s 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 process in server 1, the server 2 process will see the status as locked even if it looks

51、 at a replica of storage. This feature is needed only for replicated nodes and replication on demand storage strategies. The overall changes to the pattern can be summarized as follows (Figure 4): The resource manager now provider Isolators which in turn provides a CloudResource directly or a Rep

52、licator depending on storage strategy. The cloud resource now supports distributed transactions and state management now handles state persistence as well. Figure 4. The cloud resource pattern now supports distributed transactions Cloud task pattern The cloud task pattern extends the manage

53、d task pattern with the Proxy and StateManager extensions. The Proxy determines the parallelism strategy and instructs the StateManager to control the persistence of state for the execution. Proxy The Proxy is the wrapper around the managed task with pre-process and post-process logic. The pre-pro

54、cess logic includes the message security, followed by formatting the input based on protocol and performing the task. Subsequent to the task execution, the post-process logic decides what to do with the output. StateManager The stateless execution of a task is to ensure that input to the task is t

55、he initial state and all final state related information is present in the output. Therefore, the StateManager takes care of input and output and moving them as a CloudResource. Figure 5. The cloud task patterns StateManager moves I/O as a CloudResource Table 2 shows the details of how each cl

56、oud characteristics and its corresponding design strategy impacts which JEE implementation attribute and what patterns are referenced. Table 2. Cloud characteristics and their impact on design and implementation strategy Cloud characteristics Design strategy Implementation attribute Pattern

57、Pattern extensions Statelessness Statelessness through state persistence Listener, remote invocator Cloud task StateManager Statelessness Statelessness through state persistence State management Cloud resource StateDataResource Distributed storage Replicated nodes, Replication on demand

58、 Persistence Cloud resource Replicator, LockManager, LockDataResource Distributed storage Replicated nodes, Replication on demand Transaction Cloud resource CloudResource Parallelism and synchronization All the strategies Listener, remote invocator Cloud task Proxy Loose coupling All t

59、he strategies Listener, remote invocator Cloud task Proxy Multi-tenancy All the strategies Persistence Cloud resource Isolator Security Encryption Persistence Cloud resource Isolator Security Encryption Listener, remote invocator Cloud task Proxy Extending containers: Approach for

60、 common container services Modify the existing container services to match the cloud resource and cloud task patterns and attach them to the application in as non-intrusive manner as possible. In a nutshell, we converted all services to cloud resource pattern; when the application interacts with th

61、e cloud resource pattern, it converts that pattern to the cloud task pattern and is ready for the cloud. The following list shows the service, the original method, and the approach we used. Service:JDBC Database Connections Legacy method:Managed resources.Approach: Go for the higher versions that

62、 support distributed transactions (two-phase commit), shareable connection that support thread pool and stateless invocation. Based on the higher versions that exist, the remaining functionality can be provided using a cloud resource pattern. Service:JMS objects Legacy method:The JMS Senders an

63、d Receivers are tasks and JMS messages and destinations are objects. Approach:Same approach as for JDBC Database Connections. The configuration can be changed to ensure that the JMS Server is also present on all the nodes where JMS client is also present to help elasticity. Service:Cache object

64、s Legacy method:Currently support in-memory or distributed cache services. Approach:All caches need to be converted to a distributed cache to take advantage of effective sharing. The cache services can be optionally wrapped by a cloud resource adapter. Service:Session Legacy method:Most of th

65、e applications use sticky sessions. Approach:The code can be changed in a non-intrusive manner by having a filter for all the requests and let the filter create a custom HttpServletRequestWrapper which can override getSession() to give it as a cloud resource. Eliminate sticky session as well. S

66、ervice:Persistence strategies Legacy method:The ORM-based container-managed persistence will be beneficial. Approach:The Object-Relational-Mapping-based container managed persistence does not clutter the application code with the relational nature of storage. This enables ease of changing the persistence layer to a non-relational DB as well. Hibernate Shards allows for distributed storage