EJB Application Development and Deployment

Transcription

1 A Framework for Optimal Deployment Schema in Component-based Systems Nicolae Dumitrascu Liam Murphy Department of Computer Science University College Dublin Ireland { nicolae@eeng.dcu.ie liam.murphy@ucd.ie } Abstract: The performance of distributed applications depends on the location of each component within a network. In this paper we propose a conceptual framework for component-based software deployment. Our framework helps to establish a viable mapping of software components to network nodes which optimises application performance. The paper is organized as follows: Section 2 presents the related work and an overview of EJB technology. Section 3 is a description of the overall framework architecture proposed. Conclusions and future work are presented in Section INTRODUCTION Software architecture design is an important part of software development. For distributed software application the architectural activity involves the identification of distributable software components and their interconnections and interfaces. Designing and developing distributed software for complex software systems involves aspects of traditional software design but also involves activities related to component distribution. For distributed systems additional information may be necessary such as where components are to be located in a network and how communication protocols or middleware are to be used. The performance of distributed systems depends on many factors that range from the efficiency and scalability of abstract algorithms used in the systems to the capabilities of underlying communication networks and processing nodes in the networks. The performance of a particular system that is designed as a collection of interacting components also depends on how the components are deployed in a specific network. In this paper we propose a framework for deployment of components in distributed systems for large-scale distributed applications. The goal is to obtain an optimal distribution of application components over a network that minimizes remote communications among components and maximizes application performance. Our framework is focused on deploying EJBcomponents on J2EE architecture taking into account characteristics of Java s J2EE Technology. Our architecture design combines the flexibility and high performance of application servers for component-based software applications. Our nodes are application servers in which EJB-components are running. 2.1 Related work 2. BACKGROUND There has been a significant amount of research in improving the performance of systems by optimal allocation of tasks or objects in a distributed environment. Barroso et al [2] proposed a way for allocating tasks on multiple processors. The goal is to execute a number of unspecified tasks on a parallel machine in any order and as quickly as possible. The tasks are maintained by a central monitor that will hand out batches of a variable number of tasks to requesting processors. A processor works on the batch assigned to it until it has completed all tasks in the batch at which point it returns to the monitor for another batch. They introduce a new allocation strategy the BOLD strategy and show that it outperforms other strategies suggested in the literature in a number of simulations. Gomaa and Menasce [3] describe the component interconnection patterns of synchronous and asynchronous communication with a multi-threaded server. They use the interconnection patterns to analyze the performance of the software architecture executing on various system configurations. An algorithm for optimal object deployment is proposed by Bastarrica et al [4]. They use Z language for describing an object-oriented application and derive a BIP model. The objective of the optimal deployment algorithm is to minimize remote communication between objects. Marvie et al [5] describe a flexible deployment process supported by a dynamic CORBA Component platform. Using the Niched Pareto Genetic-Algorithm Choi and Wu [6] describe a model for partitioning and allocation of object-

2 oriented applications to heterogeneous distributed systems. The goals are to minimize the amount of communication between objects and to maximize the degree of parallelism for executing distributed object-oriented programs. There is a lot of work ([9-12]) related to allocating tasks process threads components e.g. in COM DCOM CORBA but none of them is related to EJB-based systems or J2EE architecture. Many of the concepts in EJB came out of CORBA. In a sense we can think of EJB as CORBA with a new look. EJB and J2EE bring a Java-centric component-based approach to traditional middleware programming architecture suitable for rapid application development. synchronization process management state management resource pooling data access system administration support failure recovery high availability distributed object protocol and clustering. The EJB Application Servers provide an application framework in which to run EJB containers [8]. They have to contain at a minimum a naming service and a transaction service to the beans. EJB 1 EJB 2 EJB n MIDDLEWARE - SERVICES 2.2 EJB Overview The Enterprise Java Bean (EJB) is a server-side component architecture for deployable server-side components in Java. There is an agreement between components and application servers that enable any component to run in any application server. EJB components (called enterprise beans) are deployable and can be imported and loaded into an application server which hosts those components [1]. EJB technology defines three different types of enterprise beans: Session beans model business processes (e.g. pricing engine catalog engine credit card authorizer); Entity beans model business data (e.g. product order employee credit card); Message-drive beans are the new types of EJB introduced in EJB Sun s specification 2.0 [7]. They are similar to session beans in that they are actions but one can call them only by sending messages (e.g. receive stock trade messages credit card authorization messages or workload messages). EJBs are described by the remote interface local interface home interface bean class and deployment descriptor. The remote interface duplicates every business method that the beans expose. The local interface specifies the business methods that can be access locally which means by the other beans that are in the same JVM as the bean accessed. Home interface presents the methods to create and destroy EJB objects. The implementation of the home interface is the home object which is generated by the container tools. Bean Class is simply a Java class that conforms to a well-defined interface and certain rules. Deployment descriptor describes a bean s middleware requirements to the container. Physically a deployment descriptor is an XML document. Each enterprise bean resides in an EJB container. An EJB Container provides the deployment and runtime environment for enterprise beans including middleware services such as security transaction deployment thread management and Messaging - Java Mail - JMS Services - JDBC JNDI - JIA Fig. 1. EJB container Communication - TCP/IP HTTP - RMI/IOP EJB containers provide management services to one or more beans. They communicate with the EJB servers in order to access the services that beans needs. The server provides services to the bean but the container interacts on behalf of the beans to obtain those services. 3.1 Overview 3. FRAMEWORK Performance of EJB-based distributed systems depends on many factors such as: availability scalability efficient use of hardware capabilities of the underlying communication network and the processing nodes etc. Moreover the way the components are deployed in a specific network influences the application s performance. Components that are connected to the same node (the node can be a Java Virtual Machine (JVM) or a physical machine) interact by local communication while the components that are connected to the different node interact by remote communication. Since remote communication is both slower and more expensive as compared to local communication we consider minimizing the remote communication as a way of improving performance. We are proposing a framework for the deployment of EJB components. The framework takes into account both the

3 application and the network characteristics. The general view of our framework is shown in Figure 2. The main components are: Resource Architecture Selector Component Allocator Performance Model and Performance Evaluator. Resource Architecture Selector (RAS) selects one of the resource architectures that are suitable for the application. We have to analyze the hardware/software resources (e.g. CPU memory database) that our application needs. We select another deployment schema and re-evaluate it until we are satisfied with the deployment solution obtained. The policies list implemented by the Performance Evaluator is characterized by parameters such as response time and throughput. If we are still not satisfied with the performance of the solution we select another resource architecture proposed by the Resource Architecture Selector. In this paper we focus on Component Allocator (CA) that takes into account the characteristics of components remote communication and characteristics of application server. 3.2 Component characteristics We consider three parameters that characterize the components. 1. Component Size characterizes the granularity of one component. It is calculated as the sum of the product between the execution time and the invocation rate of each method within the component. The execution time of one component s method is calculated as the sum of all instruction s execution time within that method. For COTS (Commercial Off The Shelf) components because we don t know the source code we measure the time necessary to complete an invocation of each method. ComponentS ize = exectime (m) invocrate (m) m Method (EJB) exectime (m) = exectime(inst) inst Operation(m) Fig. 2. Framework overview Component Allocator (CA) is responsible for determining a possible component allocation on the given hardware platform. It implements the Policies List that is defined by the deployment algorithm. The component allocator will not provide only one solution for the allocation of the components. It will provide several good deployment schemas. Performance Model builds the performance model of the application taken into account the software architecture software behavior deployment schema and workload model. We will use LQNs as a modeling tool. The performance model will provide estimation of the performance metrics such as response time throughput and utilization. Performance Evaluator evaluates the solution provided by the Component Allocator. If the solution does not conform to our performance goals then we return to Component Allocator. invocrate (m) = arrivalrat e m openarriva l 1 m periodicar rival period(m) invocrate (m 0 ) Pr obinvoc(m 0 m) m0 predecesor (m) 2. Communication Overhead characterizes the interaction between components. It is calculated taken into account the fact that the components could be on the same JVM/physical machine or not. CoV(EJBEJB 1 2) = 0 CoV(mEJB 2) ( )m EJB1 { ref(ejb) 1 loc_ref(ejb) 1 } { ref(ejb) loc_ref(ejb) } 1 1

4 where: ref(ejb1) means all EJBs that are remotely called from methods of EJB1; loc_ref(ejb1) means all EJBs called from methods of EJB1 and reside on the same JVM as EJB1. When a method m1 EJB 1 calls a method from we have the following formulas: the characteristics of remote communication and EJB server. Our algorithm is able to capture the coupling between components that interact more. Grouping these components and putting each of these groups on a certain container we can minimize the remote communications. CoV(m EJB ) = 2 invocrate(n) ( )n Meth(EJB 2 ) CoCost(m n) 3.4 Performance Evaluator 0 cocost(m n) = cocost(m n) cocost(m n) + NCoV m pred(n) loc_ ref (n) ref (n) where: invocrate (n) represents how many times method n is called and CoCost (m n) represents the necessary time to call method n that can be on same JVM or not. The parameter NCoV captures the difference between the cases where two components which are not on the same JVM are collocated on the same physical machine or not. 3. Component Weight characterizes the importance of one component within the software application. We understand the importance of one component to mean how many times a component is used in the application. We express the importance of a component in terms of probability. We note: CompWeight (EJB i ) = W i. Let CW be the vector that contains the weights of components. EJB1 CW = W1 3.3 Component Allocator... W2... EJBi... Wi... EJBn Wn Component Allocator takes into account characteristics of the EJB servers such as scalability and performance of the RMI implementation used. Because RMI relies on the Java serialization the performance of the Java serialization has to be taken into account. Scalability describes the ability of EJB application server to serve connections from several clients at the same time. Also we have to consider the number of bean instances in the application server. Unfortunately EJB servers often limit the number of clients allowed to simultaneously connect. We will propose a deployment algorithm that takes into account the characteristics of components such as component size and the importance of components in the system and also Based on the solution generated by Component Allocator we evaluate this result using Performace Evaluator. As performance models queueing models have been widely used. However a shortcoming of these models is that they can only model software components that demand one-at-a-time resources. Simultaneous resource demands and parallel subpaths require a more sophisticated model such as Extended Queueing Networks Performance Petri Nets Stochastic Activity Networks and Stochastic Process Algebras. Layered Queueing Networks (LQN) are a new adaptation of the Extended Queueing Network defined especially to represent the fact that software servers are executed on top of other layers of servers and processors giving complex combinations of simultaneous resources. We will consider LQN as a modelling approach. 4. CONCLUSION We feel that our framework clarifies the issues in componentbased software deployment. We propose a framework that automatically discovers the performance problems and drives possible improvements of the system under study. Future work includes developing deployment algorithm detection techniques and implementing these techniques to automatically build analytical deployment models for component-based systems. REFERENCES [1] Ed Roman Scott W. Ambler and Tyler Jewell Mastering Enterprise JavaBeans-second edition John Wiley & Sons Inc 2002 [2] A.M. Barroso J.R.A. Torreão and J.C.B. Leite A Heuristic Approach to Task Allocation in Real-Time Distributed Systems CAA - Applied Computing and Automation Centro Tecnológico Universidade Federal Fluminense Rua Passo da Pátria Brazil 1998 [3] Hassan Gomaa and Daniel A. Menasce Design and Performance Modeling of Component Interconnection

5 Patters for Distributed Software Architectures School of Information Technology and Engineering George Mason University USA 2000 [4] M. Cecilia Bastarrica Steven A. Demurjian and Alex A. Shvartsman Software Architectural Specification for Optimal Object Distribution Computer Science & Engineering Dept. The University of Connecticut Storrs USA 1998 [5] Raphael Marvie Philippe Merle and Jean-Marc Geib Towards a Dynamic CORBA Component Platform Laboratoire d Informatique Fondamentale de Lille France 2000 [6] Seunghoon Choi and Chisu Wu Partitioning and Allocation of Objects in Heterogeneous Distributed Environments Using the Niched Pareto Genetic-Algorithm Department of Computer Science Seoul National University Kwanak-Gu Seoul Korea 1998 [7] Enterprise JavaBean Specifications 2.0 Sun Microsystems Inc [8] Radek Pospisil Marek Prochazka and Vladimir Mencl On Performance of Enterprise JavaBeans Distributed Systems Research Group Charles University Prague Czech Republic 1999 [9] Allen Parrish Brandon Dixon and David Cordes A Conceptual Foundation for Component-Based Software Deployment Department of Computer Science The University of Alabama Tuscaloosa USA 2000 [10] Wolfgang Emmerich Distributed Component Technologies and their Software engineering Implications Department of Computer Science University College London London UK 2002 [11] Takanobu Ando Dynamic Deployment Distributed System Object Technology Center Tokyo Japan 1998 [12] Sophie Dumas and Georges Gardarin A Workbench for Predicting The Performances of Distributed Object Architectures Laboratoire PRISM Universite de Versailles France 1998