Method Execution on a Distributed Image Processing Back-end

Method Execution on a Distributed Image Processing Back-end Franz Niederl, Alois Goller {niederl,goller}@icg.tu-graz.ac.at Computer Graphics and Vision, Graz University of Technology M¨ unzgrabenstraße 11, A-8010 Graz, Austria Abstract The rapid grow of both, the size of remote sensing data and the number of users in this field requires systems which are easy to use, platform independent and mighty. Currently, many users are not able to process or even access data the way they would like to. Utilizing upcoming technologies like WWW, Java and CORBA, we propose a distributed system that connects users, data bases and method bases. Latter ones help users to find an appropriate sequence of methods for processing, and incorporating a broker they schedule execution onto fast remote processing units (backends). We discuss design considerations concerning the interaction of the back-end with other system components, and strategies for effective job distribution. Keywords: Platform independent computing, distributed processing, inter-networking

1

Introduction

Since processing of images becomes more and more important, it should no longer be restricted to a small community, which has appropriate methods, computers and special skills. The booming World Wide Web (WWW) with new technologies like Java makes it possible to access and invocate methods all over the world. Our idea is to use the internet and its resources for a distributed processing framework. Up to now a lot of work was done to illuminate the possibilities of platform independent and distributed computing (Java[7], CORBA[4]). With the improvement of network capabilities like increasing the bandwidth (TEN-34 [17]) or using ATM [13], transferring data to the methods located on a specialized computer becomes faster than the other way around. Image processing software such as Khoros [12] or KB-Vision [11] needs specialists who know all the available methods and inherently used expressions. To overcome this limitation, a much more general access pattern to the methods is required. Accordingly, we

have to turn our attention from the procedures towards the data-sets and particularly towards the expected outputs. In this paper we describe a data driven distributed image processing system. The user specifies the inputdata and the desired result and the system automatically searches for possibilities to execute this job, proposes several solutions and dispatches the job to the selected components. Scheduling, network performance and charging are some of the observed problems. Java RMI [8] , CORBA and distributed queuing systems [5] were investigated for their qualification as scheduler and broker.

2 2.1

Systems Design Method Description

Most available image processing systems are based on processing. The user himself has to choose the proper procedure and apply it to his data, as shown in figure 1, part b). Often, several procedure blocks must be applied in a certain sequence to get the desired result. This requires in-depth knowledge of the image processing system, because it is by no means trivial to choose the proper function at a certain stage of processing. If a good way of “how to process” was found, it is difficult or even impossible to store the processing sequence within the system. Packages like Khoros [12], KBVision [11] or AVS [2] overcome this disadvantage by providing a tool to set up the processing sequence. Usually, this is a directed, acyclic graph (DAG), illustrated in figure 1 part a). Although this approach is quite valuable, the blocks to be connected are rather small and sometimes it is not clear why they are necessary. Apart from some demos, there are no sequences a user may apply to his data immediately. Consequently, first of all the user must program the system according to his own needs, which forces him to learn about system’s peculiarities.

Data Input Specification

Data Input Specification

Method A

a)

b) Method B

Method C Method E

Choose the Proper Method

Method D

Method F Data Output

Data Output

Figure 1: a) Data driven method sequence; b) Program driven method pool. In case a) the user specifies the input data as well as the desired output product, and the system proposes a method sequence; in case b) the user himself has to choose the proper methods in the correct sequence. In contrast to these procedure based systems we propose a data driven approach. Key element is a data description platform, where the user can specify the input data and the desired result. According to these specifications, a method (data-)base is searched for method sequences which match users’ constraints. Thus, the user gets a DAG which shows a way how to reach the desired data product as shown in figure 1 part a). Individual parameters to certain methods may be changed. However, since sequences are to be chosen, the default parameters of a particular method change from sequence to sequence to optimally configure every single method to render this certain data product. Of course, the data based approach is not that flexible, since all method sequences must be contained in the method base and nothing can be done without having specified a method sequence. However, especially when processing remote sensing images, only a limited amount of different data products are available, and mostly only certain products are requested. If the images are searched in distributed catalogs (using CIP [3]), input data specification may be omitted since all necessary information can be retrieved from the catalog automatically. Thus, the approach based on data flow shows the user how the goal can be achieved immediately, without knowing system’s interior. After some experience,

users may change both, the flow sequence and the default parameters, or even add some method sequences.

2.2

Components

Based on the data driven approach from section 2.1, we propose an image processing system which is able to execute different methods on different distributed computers. The system consists of • WWW-Server, • Graphical User Interface, • Broker and • Back-end. Since we use HyperWave [14] as WWW-Server of the second generation, we refer to the book of Hermann Maurer. Here we will concentrate on the other components and their interaction, as shown in figure 2.

2.3

Graphical User Interface

The graphical user interface (GUI) as the first point of contact with the system depends on user requirements as described in [6], because only the user decides whether the system is good or not. An easy and uniform access to the collected methods is provided by means of new technologies. Since almost all programs have their own GUI installed locally, an important aspect of our GUI is that nothing new must be

data base

User Identification Search function Method documentation Help

WWW-Server

remote distributed processing HTML Java HTML Java HTML

Backend

GUI

Java

Broker

? Figure 2: The four main parts of the system and their tasks installed. In other words, the user needs not to take care about installation, updating and other software maintenance work. Therefore, we require a common WWW-browser of the new generation (i.e Netscape Communicator [16], Microsoft Internet Explorer [15]) as base for our GUI. Most internet users already have installed one of them. Other important issues are simple expansion and search facilities, individual configuration by setting a couple of parameters, and interactivity. Since the GUI should work within a WWW-browser it must consist of components this browser can interpret. HTML-pages are used for method description (see 2.1) and for presentation of an extensive help system to support the user. These pages are arranged like a tree with links between different branches to lead the user from an overview to detailed information. Additionally a search machine, which is integrated in a second generation WWW-server like HyperWave [14], provides a quick and easy access to specific information. The second part of the GUI are Java applets which are responsible for data-input, user input verification and for connecting to the broker (see 2.4). Another

task of them is to support interaction between the user and the system.

2.4

Broker

The broker, which is the link between GUI and the back-end, is the second physically fixed part beside the WWW-Server. In this position it is responsible for the entire communication and interaction between the GUI and the processing back-end. We will realize it by a combination of a specific server, for instance a Java-server [9], and a scheduler. The specific server is the “brain” of the entire system. It must communicate with databases, control and check all the received requests from the GUI and translate them automatically into an executable sequence of order. The scheduler establishes the connection to the processing back-end, supervises the execution and sends at least results to the user and to the WWW-Server. One of the most important functions of the broker is to ensure good workmanship to the requests it gets. It will check registration and other qualification certificates to make sure no encumbrances exist. A detailed knowledge of the procedures is essential, particularly which algorithms are available on which

machine. This means the broker urgently needs information about every method and machine to be able to convert the request. Such information may be retrieved from a database or a special call of the method. A wide range of general facilities for the interface between the broker and the back-end is needed, because communication shall be platform and computer independent (see section 3.5). On the contrary, the HTTP-protocol is used between the broker and the GUI or the WWW-Server, respectively.

2.5

Back-end

The back-end is the processing part of the system. It is a collection of distributed tools like methods, single and multi processor machines, hard-disks and so on, which can work together in many variable combinations. Thus it is very dynamic and easy to extend. To add a new machine, only a few parameters are necessary to describe the functionality and the way how to access it. Moreover it is much more complicated to add a new method than a new machine (see 2.1). The ingredients used for a task depend mainly on the request and on the broker. The request makes stipulations how to do it and the broker chooses the suitable method and the right machine. Thus the backend is newly configured by the broker for each different job and it exists in this combination only until this job is done.

3

Broking Requests to the Back-end

3.1

Specifications

When designing a distributed image processing back-end it is necessary to define the working environment. As we use the internet as a base for our system platform independence, software recycling or security should be more than slogans. Furthermore we need not take care about user’s needs, because the GUI (see 2.3) is clearly separated from the processing part. On one site the distributed image processing backend is the cooperation of components, which can be located physically and logically at different places. The only requirement is that each of them must be reachable via a network connection. The processing components can be summed up into four groups: • data-sets (radar and optical images in different formats, DEM, ...) • methods (crop, rotate, classification, matching, SfS, ...) • computers (workstations and PC’s, multi processor computer, ...)

• platforms (Unix, MS-Windows, Java OS, ...) On the other site a broker (see 2.4) is managing the interaction between these four groups and the dispatching of jobs. Therefore, we investigate the use of Java RMI, CORBA and distributed queuing systems (see 3.5). The expansion of the system is another important design aspect. It is imperative for an internet based system that new components can be added to from everywhere. This means that remote administration is as possible as remote invocation. So, the management part of the back-end consisting of HTML-pages and Java-applets is platform independent and available all over the internet. The disadvantage of such an open system is to keep it secure. Data transfer, user registration and remote invocation of methods are only some points out of many where security is needed (see [6]).

3.2

Performance Estimation

In order to distribute methods, the scheduler needs some performance figures on which it can rely and which are then used for execution time prediction. Based on these predictions and according to the chosen scheduling strategy, the methods are dispatched to the back-end computers. Performance figures can be classified into: • Algorithm — Every algorithm has a certain complexity in time and space (memory). Commonly, figures in this area describe asymptotic behavior for large n and are stated in O-Notation. They are useful to extend the performance model obtained from real time measurements. • Method — The implementation of the algorithm on a specific computer. Every method execution gives a distinct point, but generally it is difficult to get a performance model. It is also difficult to distinguish between method and computer performance, especially if a method is not ported to other platforms. It further depends if the method is running in parallel or sequentially. • Computer — To evaluate overall performance figures of computers, benchmarks are widely used. However, the best benchmark is the application itself. Computer performance mainly depends on the resources like clock rate, number of CPUs, main memory and disk I/O bandwidth. • Network — Since data are not located at the back-end computer, network performance sometimes becomes the most important factor. Generally, only statistical statements can be made.

A lot of work was done in performance modeling, and also in performance modeling for parallel and distributed systems, as Wagner [18] summarizes. Structural modeling obtains information from user description and compiler analysis. This very accurate approach seems too expensive since it incorporates user interaction and source code analysis. A rather pragmatic way is to use analytic modeling which abstracts the features as a set of parameters — scalar or statistical — or parameterized functions. Algorithms are already described by functions, computers generally are described by scalar and networks by statistical values. Thus, describing the methods and especially the whole system is best done by a combination of all three, with a bias toward functional modeling, because inter- and extrapolations can easily be performed. Moreover, functional modeling is widely used and usually inexpensive, but not very accurate due to simplification. However, we hope that it is sufficiently accurate for the resource estimates within the scheduler, since parameters may be adaptable on the fly when the system is in operation.

3.3

Accounting and Charging

As the computer capacities are not boundless at any time and nobody wants to offer it free of charge, we have to control access to the system. In addition to the restricted computer resources, execution of methods may be charged for. In order to provide a well kept service it is necessary to restrict the access to the processing back-end with accounting and charging. Accounting is needed to regulate the access rights as time limits and number of accesses at the same time and to relate a job to the user as a base for charging. In fact, every user needs an account and all actions are recorded. The charge of a task depends on many parameters like bandwidth of the network for data transfer, utilized method(s) or the computer resources. Hence, we have to estimate the costs for every used component and to sum them up. As the execution time raises according to the amount of data a price per byte or for images per pixel make sense. In other words, we estimate the cost for one byte or pixel from every used component and sum them up depending on the data size. Additionally to these ”variable costs” also ”fix costs” like a fee for the right to use a method or a computer independent from execution time or the amount of the data-set can be added.

3.4

Scheduling and Load Balancing

When machine and algorithmic figures as well as user desires are known, the scheduler can determine the best way how to dispatch the job. Below, some

parameters are listed onto which a user may specify soft limits, ranges or just preferences. • Starting time of execution. It sometimes is desirable to set up a batch process, but to start it not immediately. • Execution time of the whole job (method sequence). • Cost, accumulated by network traffic, processor hours, and maybe algorithm/software license fees. • Priority. High priority jobs can overtake queued ones or even suspend currently running methods. • Allow special hardware. High performance computers are usually more expensive than COWs. This setting may reduce the number of possible configurations and thus helps the scheduler. Generally, a job is a method sequence best to be illustrated as DAG. The first step is to find machines which are able to execute the methods included in that particular DAG. If there are several possibilities, all of them must be evaluated. In a second step, machines in question are asked for their current work load and for the time to wait until the new job will be dispatched. It is obvious that concerning these parameters is useful only if the estimates about time and resource allocation are correct. Especially in this area of scheduling and load balancing, more research is necessary to proof that this simple approach is satisfying, or to find more elaborate strategies. Finally, the optimal union according to user’s requirements and machine load must be found. This includes analysis of the DAG for parallel execution, critical path evaluation as well as solving the max-flowmin-cost problem. Latter is needed to find an optimal way for sending data between the various back-end processors. It might be better to process the data on an easily reachable (“near”) but slow processor than on a fast parallel machine with (currently) a poor network connection.

3.5

Platforms

To design and build a distributed image processing back-end as described above, it is beneficial to (re-)use already available software. As it shows, there already exist solutions to distributed computing. However, it is not yet clear which one is most suitable or which combination is best. We currently investigate the following three products:

CORBA (Common Object Request Broking Architecture) and DCE (Distributed Computing Environment) are two standards especially designed for distributed applications. Whereas DCE is based on remote procedure calls, CORBA is fully object oriented. With the CORBA 2.0 specification implemented, a huge tool is available for broking arriving requests. CORBA uses IDL (Interface Description Language) to describe a platform and language independent interface of the object. The object itself might be encoded in C++, Smalltalk, Lisp, Java, or other languages depending on the implementation. The core element of CORBA is the ORB (Object Request Broker) which brings together the incoming request and a server which is able to execute the method of the object. Additional services like security, transactions, licensing, naming and change management are already included. This allows fast implementation and easy integration of other services. Since the user interface is based on HTML pages and Java applets, the recent announcement from Netscape that their new product, Communicator, can talk to any CORBA-compliant networked object, is an important addition for enterprises wishing to access both legacy data and custom network applications [16]. Java Since Java is platform independent, it is the language best suited for distributed applications. Java provides an object oriented counterpart of RPC called RMI (Remote Method Invocation) which seems to be the basic structure for communication in Java. Although several services included in CORBA are not available in Java, difficult interface descriptions are not necessary since it’s the same language on every platform. We want to check how Java servers can execute and how this execution can be controlled and scheduled. Agents and beans are to be investigated as well. Since the front-end is at least partially designed around Java, it is meaningful to keep the same language for the back-end as well. DQS To also utilize massively parallel systems or clusters of workstations (COWs), queuing systems will be evaluated. Such systems, like NQS (Network Queuing System) or DQS (Distributed Queuing System [5]) allow various scheduling concepts, mixed parallel and sequential execution, machine load optimization and have some other features. It will be of great interest whether and how such queuing systems can interoperate with CORBA or Java on top, if they can be slightly expanded to fully substitute an ORB, or if the

idea of queuing and batch processing is better to be implemented entirely new (in Java).

4

State of the project

We started the realization of the project with the evaluation of DQS, CORBA, and Java RMI. Some tests with DQS showed us that it is not powerful enough to fulfill the requirements of our system. For the investigation of the usability of CORBA we used JaCorb [10] a free ORB entirely written in Java. The clearly benefits of CORBA are the platform independence and the existing services, which reduce the expense for software development. Additionally to the reuse of software components it is also easy to replace our test ORB by a fully supported commercial ORB. But even CORBA is not powerful enough for our system. On the contrary Java RMI, which has nearly the same functionality than CORBA, has no components comparable to the services of CORBA. In other words, all components, which already exist in CORBA, must be developed new. Thus, we prefer CORBA instead of Java RMI. As a result of our investigations we decided that a combination of DQS and CORBA will be the best solution for the back-end processing.

5

Conclusion and Outlook

The proposed image processing system is much easier to handle and turns more attention to the data and the desired results than existing systems do. Furthermore it is accessible all over the world with common WWW-browsers and is therefore not restricted to special platforms. In a first implementational step the broker can select a method or a sequence of methods to fulfill user’s request. In future steps the broker will automatically construct new method sequences on the fly whenever no method base entry can be found for the current problem. Furthermore the method base query should be connected with an expert system.

References [1] Arpaci, R. H., et al. (1995) The Interaction of Parallel and Sequential Workloads on a Network of Workstations; SigMetrics’95, also at: http://now.cs.berkeley.edu/Papers2/ [2] Advanced Visualization Systems; at http://www.avs.com and http://www.avsuk.com [3] Catalogue Interoperability Protocol; CIP Spec V2.2, ICS URD V2.2, and ICS SDD V1.2, at ftp://styx.esrin.esa.it/pub/od/CIP/

[4] OMG CORBA 2.0 Specifications http://www.acl.lanl.gov/CORBA/#DOCS [5] Distributed Queuing System http://www.scri.fsu.edu/~pasko/dqs.html [6] Goller, A., F. Niederl (1997) An Internet Based Distributed Image Processing System; submitted to Journal of Supercomputing [7] Java; http://java.sun.com/products [8] Java Remote Method Invocation http://java.sun.com/products/jdk/rmi/ [9] Java Server Group http://jserv.javasoft.com/index.html [10] Brose, Gerald (1997) JacORB — A Java Object Request Broker; Technical Report B 97-02; Freie Universitt Berlin, Germany fubinf.inf.fu-berlin.de/pub/reports/ [11] N. N. (1995) The KBVision System: User’s Guide; Amerinex Applied Imaging, Series 3.1 [12] Khoros with GUI Cantata; http://www.khoral.com/ [13] McDysan, David E., Darren L. Spohn (1994) ATM — Theory and Application; McGraw-Hill Series on Computer Communications [14] Maurer, H. (1996) HyperWave — The Next Generation Web Solution; Addison-Wesley, also at: http://www.iicm.edu/hgbook [15] Microsoft Internet Explorer; http://www.microsoft.com [16] Netscape Communicator; http://www.netscape.com/ [17] TEN-34; http://www.dante.net/ten-34/ [18] Wagner, Meira, Jr. (1995) Performance Modelling of Parallel Programs; Technical Report 589, Computing Science Department, University of Rochester, NY 14627