Distributed Crop Simulation Model

In Section 4.1, Conceptual model for the Kraalingen approach, of

Chapter 8, we presented all the classes involved in the simulation such as Soil, Weather, and Plant, linked by corresponding associations. In the case where a local computing architecture is selected, all the objects will reside in the same address space in the same machine. If a distributed computing architecture is selected, objects may reside in different address spaces and even in different platforms. The fact that objects are located in different machines and platforms does not affect their already conceived behavior. Distributed objects will communicate through a middleware component that in our example is Java's RMI. The middleware provides a common set of management services made available to all classes that have agreed to use this infrastructure, regardless of their location [Bro99]. The process of developing a distributed component-based system can be considered as a three-phase process. In the first phase, a stand-alone application using a local computing architecture is developed. During this step, interfaces and the behavior of the objects/components are designed and carefully tested. Focus is on providing objects with the right behavior and the right interfaces. The entire simulation-based application is tested in order to make sure that the system delivers correct results. In the second phase, an implementation middleware is selected to implement the distributed application. Issues such as how objects will interact remotely and how they would be instantiated are addressed. The third phase deals with issues of developing and implementing objects that would interact remotely, using the selected middleware.

The three-phase layered approach was used to develop the distributed crop simulation model. Issues concerning an object-oriented approach to crop simulation modeling were addressed in developing a stand-alone model programmed in Java [PBJ01]. During this phase, the main focus was on providing flexible objects with the required behavior so they can be reused in the future. Results taken from the object-oriented approach were compared to the ones provided by the existing FORTRAN code presented by [PBJ99]. After successfully finishing the first phase, the next step was selecting the middleware environment needed for developing the distributed application. As the programming language used in the first phase was Java, the following options were available: Using OMG's CORBA or Java's Remote Method Invocation technologies. Any of these technologies could be used as they are conceptually very similar. We chose Java's RMI, as the rest of the application was developed using the Java programming language.

Figure 11-18 shows the interaction among the elements involved in the simulation in a very general manner, without considering any programming language or other implementation details. Defined interfaces describe the messages objects should respond to in order to perform the simulation. Each of the interfaces represents some functionality that is provided by a class/component. To illustrate issues that need to be addressed during the component development of our system, we will focus only on the Plant component, as the development of others is carried out in the same manner.

Figure 11-18. Conceptual diagram for the Kraalingen crop simulation model.

As the selected architecture is distributed, the core objects (Soil, Plant, and Weather) will communicate with each other remotely. Remote communication requires a middleware component that will send messages from one object to another. Figure 11-19 shows the links between objects and interfaces of component PlantRMI needed for the remote communication.

Figure 11-19. Links between objects and interfaces for remote communication.

The interface PlantRMIInterface is similar to the Plantlnterface defined in the conceptual diagram, with the only difference being that it provides capabilities for sending/receiving messages through the Internet. Therefore, PlantRMIInterface should inherit the predefined Remote interface that is part of Java's arsenal for moving objects in a network. The PlantRMI object is functionally similar to the Plant object defined in the standalone developed model, as it will play the same role in the simulation process. In addition, PlantRMI object should be provided with capabilities of a remote object to be able to remotely communicate with other objects. The behavior of the Plant object was defined by Plantlnterface and the behavior of the object PlantRMI is defined by PlantRMIInterface. PlantRMI will be able to provide the functionality required for the simulation by delegating simulation-related messages to object Plant. Plant is part of object PlantRMI [GHJ95], [Gra98]; the association linking objects PlantRMI and Plant is a composition. Because PlantRMIInterface inherits from Remote interface, the PlantRMI object will provide the capabilities for sending/receiving messages over a network. In addition, as the PlantRMI object will provide its services from a remote server, it should be able to instantiate itself with server-like capabilities. Therefore, the PlantRMI object should inherit the server-like behavior from a predefined Java server class named UnicastRemoteObject. Figure 11-20 shows the entire class diagram for the application.

Figure 11-20. Class diagram for Kraalingen distributed system.

As shown in Figure 11-21, the center of the class diagram is the SimulationController class. This is a controller type of class that will coordinate the communication between entity classes, by sending them the right message at the right time. In addition, SimulationController will supervise the communication with the boundary class. In Figure 11-20, the communication with boundary class is not shown. SimulationController has access to interfaces PlantRMIInterface, SoilRMIInterface, and WeatherRMIInterface. The association between the control class and interfaces is modeled as a composition; SimulationController being the "whole" and the interfaces being the "parts." Therefore, SimulationController is responsible for creating instances of classes implementing these interfaces and controlling the flow of messages objects sent to one another. By having access to interfaces, the SimulationController is able to use any other class that provides similar behavior, provided that the class implements the required interface. Note that classes PlantRMI, SoilRMI, and WeatherRMI have similar relationships with other classes of the diagram because they will provide their services in the same way, as a server.

Was this article helpful?

0 0

Post a comment