A Framework for Optimal Deployment Schema in Component-based Systems
Nicolae Dumitrascu, Liam Murphy
Department of Computer Science, University College Dublin, Ireland { [email protected], [email protected] }
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.
1. 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 EJB-components 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.
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 4.
2. BACKGROUND 2.1 Related work
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-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.
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
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.
EJBn EJB1 EJB2 MIDDLEWARE - SERVICES Messaging - Java Mail - JMS Services - JDBC, JNDI - JIA Communication - TCP/IP, HTTP - RMI/IOP
Fig. 1. EJB container
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. FRAMEWORK 3.1 Overview
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
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.
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.
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.
) m ( invocRate ) m ( execTime ize ComponentS ) EJB ( Method m ∗ ∑ = ∈ ∑ = ∈Operation(m) inst ) inst ( execTime ) m ( execTime ∑ × ∈ ∈ = ∈ invocRate(m ) ProbInvoc(m ,m) rival periodicAr m , ) m ( period 1 l openArriva m , e arrivalRat ) m ( invocRate 0 ) m ( predecesor m0 0
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(m,EJB) EJB ref(EJB) loc_ref(EJB)
) EJB ( ref _ loc ) EJB ( ref EJB , 0 ) EJB , EJB ( CoV 1 1 2 EJB m ) ( 2 1 1 2 2 1 1
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 calls a method from , we have the following formulas:
1 1 EJB m ∈ EJB2 ) n , m ( CoCost ) n ( invocRate ) EJB , m ( CoV ) EJB ( Meth n ) ( 2 2 × ∑ = ∈ ∀ ∈ + ∈ ∉ = ) n ( ref EJB , NCoV ) n , m ( coCost ) n ( ref _ loc EJB , ) n , m ( coCost ) n ( pred m , 0 ) n , m ( coCost 2 2
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 (EJBi) = Wi . Let CW be the vector that
contains the weights of components.
= n i 2 1 n i 2 1 W ... W ... W W EJB ... EJB ... EJB EJB CW 3.3 Component Allocator
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
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.
3.4 Performance Evaluator
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 sub-paths 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 component-based 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
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., 2001
[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
