A graphical deployment and management tool for distributed applications ⋆ Anders Andersen and Thomas Aanensen Department of Computer Science University of Tromsø, Norway aa@cs.uit.no,thoaan@online.no Abstract. OOPP is a component based middleware platform with sup- port for complex distributed applications. The main goal of OOPP is to create an expressive programming model for distributed applications where by default details are hidden for the programmer. When neces- sary, reflection is used to expose and sometimes modify these details. All interaction with an OOPP component are specified by its component model and a at set of well-defined interfaces. The component model spec- ifies how a component interacts with the runtime. The set of interfaces specifies how a component interacts with other components. An OOPP application is created by combining a set of OOPP components. OOPP Studio can be used to create and manage such an application. This pa- per gives an overview of the OOPP programming model and discusses in more details OOPP Studio. OOPP Studio is a powerful graphical tool used to build, deploy, and manage a distributed OOPP application. 1 Introduction Middleware is used to help programmers to create distributed (and complex) applications [1, 2]. It presents a set of high-level programming abstractions hiding the details of distributed programming and the platform services (i.e. providing transparencies). Software components makes it possible to develop different parts of the application independently, and then later combine and deploy them for a specific application setup. The main motivation for this is to have manageable code (code with well defined functionality and well defined interfaces) that can be easily reused. OOPP (Open-ORB Python Prototype) [3] is a middleware platform support- ing software components. It has an expressive (high-level) programming model inspired by the ISO Reference Model for Open Distributed Processing (RM- ODP) [4]. One consequence of high-level programming abstractions is that the middle- ware providers have made a lot of decisions on behalf of the programmer about the behavior of the provided abstractions. This might not be feasible for the ⋆ This work has been supported by the Norwegian Research Council (IKT 2010, project number 146986/431).