GeoTools : Decomposition of Operations API into Process Control and Data


I only had a few minutes while waiting to pick up my fiancee from the airport. I'll be back to edit this page later.


This doc briefly summarizes a rationale for separating the Operations API into a process control part and a data flow part. An example implementation of an org.geotools.terrain.viewshed package is given as an example of the process control requirements of a collection of Java Beans which cooperate among themselves to accomplish a task larger than any individual component. In the original implementation, the data flow was defined via events which each bean could listen to or fire, depending on their place in the chain. As it came time to write a process controller to instantiate the components and iterate over the viewshed, key capabilities were found to be lacking. This paper presents a process model where there are two separate communications networks present in a task: the process control network, where all processes are connected to a controller with a bidirectional communication path, and a data flow network, where the individual components are connected among themselves in an application dependant manner. The design of a process control API (which leaves unanswered the question of a data flow API) is presented.

The viewshed calculator

Describe the component architecture and the events connecting the pieces of the viewshed calculator.

Shortcomings in the viewshed calculator model.

There no clean way for the controller to get events from modules it is not directly interacting with.

Design of a process control framework.

Show how the process control framework addresses the shortcomings.