1 Automatic Application Partitioning: The J-Orchestra approach (position paper) Eli Tilevich and Yannis Smaragdakis Center for Experimental Research in Computer Science (CERCS), College of Computing Georgia Tech Atlanta, GA, 30332 USA {tilevich, yannis}@cc.gatech.edu Abstract. Application partitioning is the task of breaking up the functionality of an application into distinct enti- ties that can operate independently, usually in a distributed setting. Many distributed applications are created by partitioning their centralized versions. Traditional application partitioning entails re-coding the application func- tionality to use a middleware mechanism for communication between the different entities. This process is tedious and error-prone. Automating the partitioning process while preserving correctness and ensuring good performance of partitioned applications can greatly facilitate development of a large class of distributed applications. We review the main advantages and challenges of automatic application partitioning and present the J-Orchestra system. J- Orchestra is an automatic partitioning system for Java programs. J-Orchestra takes as input Java applications in bytecode format and transforms them into distributed applications, running on distinct Java Virtual Machines. The present paper is a high-level supplement of our paper in the ECOOP 2002 technical program [12]. Here, we do not describe specific technical contributions, but instead we concentrate on the high level design decisions for an automatic partitioning system and argue that the J-Orchestra decisions make sense. 1. Introduction Programming distributed applications used to be a task reserved for high-performance computing and large, geographically separated systems, always designed from scratch with distribution in mind. With the widespread use of the Internet, distribution over the network became an issue for a large number of appli- cations that before would operate in a single location. Distributing such applications leaves the functional- ity they offer to the user virtually unchanged. Physical constraints are the reason dictating the distribution. For instance, a traditional business application should continue to work the same, but now its user is geo- graphically separated from the data storage facility or the main computing engine. The Java applet model is a good example, when viewed as an instance of distributed computation. An applet is a piece of code that originally exists on a server machine but gets copied on a client machine to be executed on a user’s Web browser. Typically, the applet is executed on the client machine not because this machine is faster than the server that the applet came from, but because the applet needs to use a local resource—the graphical screen of the user machine. Since the graphics have to reach the user screen and the code is initially on the server machine, distribution is inevitable. The main issue is how the distribution should take place. In the case of applets, the answer is hard-coded and it is the same for each applet: the code is downloaded and executed on the user side. Nevertheless, one can imagine many other solutions that are customizable for individual programs. Perhaps, the functionality should be split, with the core part executed on the server, while the user interface is executed on the client. Communication between the two parts could be performed with standard distributed computing techniques (e.g., CORBA [9], or Java RMI [11] middleware). Perhaps, objects should migrate on demand, or according to an application-specific pattern. Such circumstances give rise to application partitioning. Application partitioning is the task of breaking up the functionality of an application into distinct entities that can operate independently, usually in a distrib- uted setting. Application partitioning is advocated strongly in computing magazines (e.g., [8]) as a way to use resources more efficiently. For instance, a scientific application, collecting data from several sensors,