A Corba Soil Server

Let us consider the Soil component developed in Chapter 8, The Kraalingen Approach, and implement a simplified version of it as a server using CORBA. This means that the soil class/component will provide its services to any other class/component or system residing in the same address space or in other servers located anywhere in the network. Therefore, the behavior of this class/component will be slightly different; besides the behavior needed in the simulation process, the component will be provided with additional behavior to function as a CORBA server. For simplicity reasons, we will provide soil component only with the behavior needed to provide information about its soil depth and wilting point values.

One of the first tasks the server should accomplish is to obtain references to ORB and BOA. After which, ORB and BOA objects will be created and the server makes them available for use to any other object outside the system. Then, the server executes a dispatch loop to wait for other objects invoking its services. Clients must connect to the object residing in the server to use its services.

Although CORBA interfaces are defined in a very general manner, different vendors, while respecting the general definition of interfaces, have implemented their behavior slightly differently. Therefore, the implementation of a CORBA service may be different in different products. The most well-known commercial vendors of CORBA technology are BORLAND'S Visibroker (http://www.borland.com/visibroker/) and IONA's ORBIX (http://iona.com).

The Integrated Development Environment (IDE) used to implement the examples is Borland's JBuilder (http://borland.com) which uses Visibroker technology for CORBA. The use of the Visibroker technology implies some particularities that make this implementation slightly different from the cases where other CORBA technologies (such as IONA's ORBIX, http://iona.com) are used. Figure 11-6 shows the class diagram for the SoilCORBA server.

Figure 11-6. Class diagram for SoilCORBAServer.

To implement the SoilCORBA server, first its interface SoilCORBAInterface should be defined using CORBA's Interface Definition Language (IDL), as shown in Figure 11-7. The interface will define the functionalities that this server will provide remotely to any client. The interface SoilCORBAInterface is similar to Soillnterface, as shown in Figure 11-6. The only difference is that SoilCORBAInterface provides capabilities for sending/receiving messages through the Internet. Therefore, SoilCORBAInterface inherits the required behavior from CORBA's main Object that is part of CORBA's arsenal for moving objects across the Internet, as shown in both Figures 11-6 and 11-7. Every interface inherits from CORBA.Object.

1 public interface SoilCORBAInterface extends org.omg.CORBA.Object {

2 public double getSoilDepth();

3 public double getWiltingPoint();

4 public void initialize();

Figure 11-7. Interface definition for class SoilCORBA.

When the interface is compiled, the IDL compiler automatically generates a few classes that are needed for moving objects across the Internet, as shown in Figure 11-8. The generated classes are divided in three groups: stubs, skeletons, and helper files. The stub files are needed to create a proxy in the client side that can be used as a local object in the client application.

h (Bl SoilCORBA.ipr

% SoilCORBA.html ; ^ SoilCORBA.java

^ S oilCO R BA1 nterf aceH elper. ¡ava s^j S oilCO R BAlnterfaceH older, ¡ava S oilCO R B A! riterfaceO perations. ¡ava _S oilCO R BAI nterfacel mplB ase. ¡ava oilCO R BAI interface, ¡ava Jie_S oilCO R BAI interface. ¡ava

Figure 11-8. Files created by CORBA's IDL compiler.

The skeleton files reside in the server and are used to help the implementation of the behavior defined in the interface. One of these classes is _SoilCORBAInterfaceImplBase, which will enable our SoilCORBA class to provide server-like capabilities. This class inherits part of its behavior from a standard class referred to as Skeleton, which implements our interface SoilCORBAInterface, as shown in Figure 11-6. Figure 11-9 shows the implementation of class SoilCORBA in Java.

1 public class SoilCORBA extends _SoilCORBAInterfaceImplBase {

2 Soillnterface soil = new Soil();

3 public double getSoilDepth() {

4 return soil.getSoilDepth();

6 public double getWiltingPoint() {

7 return soil.getWiltingPoint();

9 public void initialize() {

10 soil.initialize();

12 static void main(String args[]){

14 System.out.println("Starting SoilCORBA Server");

15 org.omg.CORBA.ORB orb =


16 org.omg.CORBA.BOA boa -((com.visigenic.vbroker.orb.ORB)orb).BOA_init();

17 SoilCORBA soilServer - new SoilCORBA();

18 boa. obj_is_jeady (soilServer);

19 System.out.println(,fRegistering server");

20 com.visigenic.vbroker.URLNaming.Resolver resolver =

21 com.visigenic.vbroker.URLNaming.ResolverHelper.narrow(

22 orb.resolve_initial_references("URLNamingResolver"));

23 String ior = "";

24 resolver.force_register_url(ior, soilServer); 2 5 soilServer. initialize();

28 catch (Exception e) {

29 System.out.println("CORBA server is not running, check the server");

Figure 11-9. Java implementation of class SoilCORBA (Part 2 of 2).

Classes SoilCorba and Soil provide similar behavior as their interfaces they implement are similar. SoiUnterface and SoilCORBAInterface define similar but yet not identical, behavior. What makes the behaviors defined by these interfaces different is the environment in which the corresponding classes are implemented. SoiUnterface is defined to be implemented by classes that reside in a local computing environment. SoilCORBAInterface is defined to be implemented by classes residing in a distributed computing environment. Classes that implement SoiUnterface need only to provide the behavior defined in the interface. Classes implementing SoilCORBAInterface, besides the behavior defined by interface, need to provide server-like capabilities, as they make available their services from a remote server where they reside.

Line 1 in Figure 11-9 defines the class SoilCORBA as inheriting from class JSoilCORBAInterfacelmplBase, generated by the IDL compiler. Line 2 creates an instance of class Soil to whom class SoilCORBA will delegate the receiving method calls for execution. Lines 3 through 11 show the implementation of methods defined in SoilCORBAInterface. Note that each of the methods delegates the receiving call for execution to object soil. Therefore, class SoilCORBA reuses the behavior defined in class Soil. Lines 12 through 30 define the static method main. This method initializes the environment of the class and must create an instance of the class itself. Line 15 obtains a reference to the ORB and line 16 obtains a reference to a BOA object. Line 17 creates an instance of the class SoilCORBA that plays a twofold role in this application: First, it will provide the behavior needed in the simulation process and second, the behavior of a server. Line 18 notifies the BOA about the existence of object soilServer created in line 17; object soilServer is passed as a parameter to the BOA. Line 26 notifies that the BOA is ready to receive requests.

Distributed objects are identified by object references that are known as IOR (Interoperable Object Reference). Lines 20 through 24 associate the URL with object's OIR. Once a URL has been bound to an object, client applications can obtain a reference to the object by specifying the URL as a string. The URL Naming Service is the mechanism that lets a server object associate its IOR with a URL in the form of a string in a file. The IOR is composed of server's IP number, a communication port number, and the name assigned to the file. Client programs can then locate the object using the URL pointing to the file on the Web server. Lines 20 through 22 obtain the Resolver that will be used to register objects. Line 23 creates a string of the association URL-IOR. Object servers register objects by binding to the Resolver and then using the force_register_url method to associate a URL with an object's IOR. Line 25 populates object soil with its initial data. Line 26 shows that the server enters a dispatch loop and waits for incoming invocations.

Was this article helpful?

0 0

Post a comment