6-22-99: Met with Tom this morning to kickoff my involvement with the Gateway project. He needs me to learn how to install and configure the Jigsaw webserver. Jigsaw is written is Java and thus runs naturally on both Windows and Unix machines--that is, servlets can be easily run. Apparently this is not so true with Apache, which is Unix-centered. Also, I'm going to write an Ising model application in Fortran that will read be used as a test of the system. My idea is to use Gateway to farm out the code, each copy getting a different value for the temperature. I then calculate the energy and the magnetization for different values of the temperature around the phase transition. The Ising model program has been written in Fortran. It compiles and runs with f77 but not f90, and I don't know why. The W3C written server Jigsaw has been installed on circe. I also noted that nothing was running on port 8001 (jigsaw's default port) on osprey2, so I may want to run it there as well, since that is where some of the WebFlow stuff is located (on the ospreys, that is. I know there is stuff on osprey4.) I've installed jigsaw on osprey. The command to start the httpd daemon is java org.w3c.jigsaw.Main -root /tmp/Jigsaw/Jigsaw. The distribution is located in the tmp directory. The option "-root" just specifies the root directory for the webserver and has nothing to do with the root user. After the server has started, you go to the web page http://osprey:8001. The JigAdm tool can be started with the command java org.w3c.jigadm.Main -root /tmp/Jigsaw/Jigsaw http://localhost:8009 Finally, web documents are placed under the WWW directory of Jigsaw/Jigsaw. 6-24-99: Met with Erol yesterday to get a quick look at WebFlow. First, on one of the osprey machines, login as webflow. A simple test of webflow can be found in the directory ~/WEBFLOW/BeanContext_2.2/test/. To get it to work, do the following: 1. I'll assume I'm logged into osprey4, which is where I did this test. Open another xterm on this machine. 2. In both windows, set the CLASSPATH so that it reads the correct classes: setenv CLASSPATH /npac/home/webflow/WEBFLOW/BeanContext_2.2/cla sses/:$CLASSPATH 3. In the first window, start the master program: java WebFlow.test.Server master.conf 4. In the second window, start a client: java WebFlow.test.Client1 http://osprey2:1998/IOR/master.ref 5. The slave should fire off an event roughly every second to say hello to the master. All of the messages are reported in the master's window. The slave window should have a prompt (not a unix prompt, though). 6. To stop execution of both processes, enter the command "ri0" at the client's prompt. This shutsdown everything. Don't use ^C, as it won't work in the master's window and will stop the client without terminating the master if executed in the client's window. If you do use ^C by accident, just restart the client and then execute ri0 when you get the prompt. I think a few words about the directory structure are in order, since I assume that other applications follow a similar plan. All of the directories below are under /npac/home/webflow/WEBFLOW/BeanContext_2.2/ The java source code is located in test and test/Webflow/test. The compiled programs are in classes/WebFlow/test. 6-25-99: Found the Webflow download package and installed it in the /tmp directory of osprey2. Also restarted the Jigsaw server there. The demos seem to be the simple test that Erol showed me the other day. The following are some useful URL's: (1) aga.npac.syr.edu:1951/tom/WEBFLOW: This is the Webflow entry page on Tom's computer. Start here. (2) From there, under osprey4, the useful links are osprey4 admin, (A), and, osprey4 portal page. Might need to write my own admin page so that it starts up on my screen. **Don't forget to set your CLASSPATH before starting the web browser. I'm using the following path (I'm logged on as webflow): CLASSPATH=.:/npac/home/webflow/WEBFLOW/BeanContext_2.2/classes:\ /npac/home/webflow/WEBFLOW/JIGSAW/Jigsaw/WWW/Gateway/WF:\ /npac/home/webflow/WEBFLOW/JIGSAW/classes/jigsaw.zip:\ /npac/home/globus/akarsu/ORBacus/JOB-3.1.2/lib/OB.jar:\ /npac/home/webflow/WEBFLOW3/QS/kskim/Swing-1.1.1-beta1/swingall.jar:\ /npac/home/webflow/WEBFLOW/XML:\ /npac/home/webflow/WEBFLOW/JSDK2.0/lib/jsdk.jar:\ /npac/home/webflow/WEBFLOW/Telnet/:\ /npac/home/webflow/WEBFLOW/WWW/MoveFile At the portal page, any username and password will work. Make sure you give it the right display and server (use osprey4). Hitting enter takes you to the Gateway User Page. 6-27-99: Had some problems getting started. The administrator page is supposed to be able to execute commands to turn the WebFlow server on and off, but something didn't work, so I had to start the server by hand. I used the command java WebFlow.Server /npac/home/webflow/WEBFLOW/JIGSAW/Jigsaw/WWW/\ WFconf/QSmaster.txt After starting up the server, I could then go to the Portal page and log on. Ok, now I want to add an application to the window. It's a convoluted process--the file structure is quite baroque. Here's what I under stand so far: 1. The applet that controls the menu bar is called gw.java and is located in the directory npac/home/webflow/WEBFLOW/JIGSAW/Jigsaw/WWW/Gateway/WF/EDU/syr/npac/\ Gateway. This class defines other classes, such as TaskPanel, that comprise the clickable menu. The "Jobs" button is an extension of the labelPanel class and currently does nothing but display some text. This is where I will put my job (?). The only thing that seems to be fully implemented right now (and it's not working today) is the "Files" button, which when clicked causes the FileBrowserCtr object to be executed. This program and its executable are located in the ../frontend directory (one up and over from the path given above). 6-28-99: Ok, I'm still trying to figure out the file structure. Once you are successfully logged into the Gateway system, your browser will point to servlets/GatewayPortal. In the righthand from, you should see a menu table. This is run by an applet called gw, located in the EDU.syr.npac.Gateway package (and in the corresponding directory). All of the buttons, etc are controlled by other classes in this same directory, so if you want to add something under the "Jobs" button, you have to do it there. Now, the file GatewayPortal.java in the same package installs the modules. Thus if you make a button in gw.java that is action- enabled, so that clicking it should produce some result somewhere else in the file structure, then you must add it in the GatewayPortal.java code. Right now, the following modules are added: 1. FileBrowser 2. XmlFileBrowser 3. RemoteFile When each of these is created, a file WWW/IOR/QS/userName.FileBrowser.txt, etc, is created. This file apparently contains some addressing information needed by Corba, but I'm not sure. As an example, I can add a module called SimpleJob. There must be code for this, something like SimpleJobCtr.java, located somewhere in the EDU/syr/npac/Gateway structure. There is a correpsonding program called SimpleJobImp.java (Imp for implementation) located in the directory WEBFLOW/BeanContext_2.2/QS/. This is wrapper code that wraps around the executable file. So, in summary, if I understand things, you must first create an event-enabled button in the gw.java applet. Then you must modify the code GatewayPortal.java so that your new module is added to the control list. Then by clicking your botton on the control panel, you are calling your wrapper program (myJobImp) located under the BeanContext_2.2 directory. (Note this directory is created by the Orblets release). The wrapper myJobImp will contain a command for running your executable, something like Runtime.getRuntime().exec("java my_calc") where there is a class my_calc.class in the same directory as your wrapper myJobImp.class. It may be wise to include the entire directory path. I've finally gotten the file GatewayPortal to add my module. I cut and pasted the code for one of the prexisting modules to the end of the module section and changed the variables to something relative. A sticking point for a long time was that I also had to modify the method createSlaveConf() at the end of the code. I had to add a line that was appropriate for the new module: fw.write("SimpleJob "+idlFile+" WebFlow.QS.SimpleJobImp\n"); I'm not sure what this does, but when I added this line the module SimpleJob was finally added. Quick notes: I'm working on rat.npac.syr.edu. The admin page is /WFconf/admin_rat.html. To reach my portal, it's /mpRatPortal. Both are under osprey4:8001. The portal is the gateway to my test gateway page, /servlet/mpGatewayPortal. You can't get there directly. 6-29-99: I've written a little applet called mpgw.java which includes a class mpJobLabel. This is a simplified version of gw.java, which is the applet control panel used by Gateway. mpJobLabel includes a button that, when clicked, will fire the simple job. In GatewayPortal.java, modules are added and text references of the objects are created and stored in WWW/IOR/QS/ as, for example, userName.SimpleJob.txt. In the applet, I want to reverse the process by looking up the appropriate text file and converting it back to an object. This will be done with a command of the form org.omg.CORBA.Object my_obj=anAppl.getORB().string_to_object(ref); where ref is a string that gives the path name to the file userName.SimpleJob.txt. After doing my conversion, I can use any of the methods that are available to my_obj. Thus my program mpJobLabel.java will first do the conversion just outlined above and then will, when the button is clicked, invoke methods such as my_obj.run() or my_obj.solveAllProblems(). For the above to work, first an orb must be created in the mpgw applet: ORB orb=ORB.init(this,java.util.Properties()); One of the methods of mpgw is getORB(), which just returns the orb. Now when the JobPanel is called, it is called as JobPanel myJobPanel=newJobPanel(this,"Title"); where "this" refers to the applet mpgw. Inside the class JobPanel, I have the constructor mpgw anAppl; public JobPanel(mpgw anAppl,String s) { this.anAppl=anAppl; ... } When the modules, such as SimpleJob, are added by GatewayPortal, they do so using a Helper program like SimpleJobHelper. These helper files are created automatically by the jidl compiler from modules included in the file qs.idl under the directory WEBFLOW/BeanContext_2.2/QS/. If you want to add a new module, you add it here, as an interface. Then use make to invoke jidl. Compiling it makes a directory structure called generated/ underneath QS/. This can't be seen by Jigsaw, so it must be copied under the directory /npac/home/webflow/WEBFLOW/JIGSAW/Jigsaw/WWW/Gateway/WF/WebFlow/QS Don't forget to reset the $CLASSPATH as needed so that the compiler can find packages. 6-30-99: Lessons not learned the first time: (1) Before anything else, make sure the classpath is correctly set. (2) Start jigsaw. All standard output messages generated will go here. (3) Start the webflow server. (4) Go to the portal page and login. New lesson: after modifying the applet, recompile and use -Reload in Netscape. This flushes the old applet out of the cache. Here's a quick guide to using ORBs. Let's say I have a program for calculating the expectation values of the Ising model. I want this to be run as a client/server where the client initiates requests for job runs to the server, and the server actually initiates the jobs. The program will be implemented as a class called Ising, which will have typical methods. 1. On the client side, I need a file IsingClient.java (or something like that). This can be an applet, which will initiate an orb object. This orb is then used to access the remote object: I create a new CORBA object ("my_obj") and use the orb's string_to_object() method to convert the string reference to the remote object to the object and store it as my_obj. I can then use the command IsingHelper.narrow(my_obj) to create an instance of the Ising class. From there I can invoke methods such as Ising.run(). 2. On the server side, I need to files initially: an implementation file IsingImp.java and an idl file Ising.idl. The idl file contains interface definitions and can be as simple as this: interface Ising{ void run(); }; The file IsingImp.java contains a run() method that executes the command Runtime.getRuntime().exec("java ising"), where ising is yet another file (in this case a compiled java program ising.class) that actually does the work. IsingImp works only as a wrapper. Now for this to work I must first use the jidl compiler to convert the interface into some java code. jidl Ising.idl will produce the following: a. Ising.java b. IsingHelper.java c. IsingHolder.java d. IsingOperations.java e. StubForIsing.java f. _IsingImplBase.java The name of (a) is specified by your interface. The Helper file is needed to convert objects to string references and back again. The Stub is needed by the client. The _ file is called a skeleton and is needed by the server. After producing these files, they must be compiled with the javac compiler. Note also that they must be located under a directory that the webserver can access. 7-2-99: I'm playing with Orbacus. Here's the step-by-step instructions for getting a simple program to work (Counter.java): 1. Create and idl file Count.idl. This will create the interface for the Count class and define any methods, etc, used by that class. 2. Run jidl --package Counter Count.idl. This will create a directory called Counter under the cwd and place the generated java files there. 3. Create an implementation file CountImp.java. This extends the generated file _CountImplBase.java. Put it into the Counter package: "package Counter;" should be the first line. The actual functionality of the program goes here: this is where you need to define the functions for initialization, incrementing the counter, etc. It does not have the main() method, however. This goes in the next class. 4. Create a server file, CountServer. This will have a main() method. This will also set system properties, initialize the orbs and boas, create an instance of the CountImp class, create the file Counter.ref, "stringifies" the orb object, and listens for incoming requests with the impl_is_ready() method. This is also in the Counter package. 5. Create a client file called CountClient.java. This will also set system properties and initialize orbs. The file Counter.ref is read, and the contents of this file are used to create a CORBA object using the orb.string_to_object() method. After the object is made, it is converted into an instance of the Count class using CountHelper.narrow(). This is also in the Counter package. 6. Compile everything with javac *.java Counter/*.java. 7. Move the CountImp.class, CountServer.class, and CountClient.class files into the Counter directory (one under the cwd, where all of the generated java files are located). 8. Start the server with "java Counter.CountServer". I note that this is picky about where things are located. To be concrete, let's say that I'm located in the directory marlon. My classpath is set to find OB.jar ***and the current working directory***, but has not been otherwise modified to find the package Counter. My implementation, server, and client class files (from the java files that I wrote, not the generated ones) must be moved to the Counter directory. To correctly run the program, I must run the server with the following command java Counter.CountServer from the directory marlon. Running this command from the Counter directory results in the error Exception in thread "main" java.lang.NoClassDefFoundError: Counter/Cou ntServer The same thing will happen if you run java CountServer //Won't work from either the marlon or Counter directories. Anyway, if the server is running on some particular machine, I can run the CountClient program from any other machine that has the stubs and the CountClient.class file. For example, I can start the server on osprey4 as the user webflow. I can then, as user mpierce, ftp the java files to another machine, say kyle, recompile and make sure everything is in the right directory structure and run the client program from kyle as mpierce, causing the server on osprey4 (run by webflow) to respond. ***I must also send the Counter.ref file to kyle***. Furthermore, the client doesn't need all of the files. StubForCounter.class is needed, but _CountImpBase.class is not. The latter is the skeleton file needed by the server. Also, the OB.jar file is not needed. I've modified the programs so that I can also call an executable through the CounterImp. I modified Counter.idl so that it includes the new method, run(). The run() method is defined in CountImp.java. It is called from CountClient.java with count.run(). The server doesn't have to be modified. The run method invokes the command "java simpler_job", where simpler_job is a class generated from simpler_job.java. Note that simpler_job.class doesn't have to be in the Counter directory with all of the other class files. It can be anywhere in the $CLASSPATH. In fact, I can't seem to be able to get it to *NOT* work, even if I erase the file simpler_job.class entirely. Anyway, note that simpler_job.java doesn't have to be in the Counter package. Small mystery solved, as I found other versions of simpler_job.class in the directory tree. I note that I get no error if the RunTime method doesn't actually find the file simpler_job.class. Nothing happens, but the program doesn't care. SimpleJob is finally working. I found some mistakes in the implementation file that have been removed. The Makefile for qs.idl also has been updated to make sure that all the class files get put in the correct directory. This is important, as I talked about above. 7-4-99: A few projects that I have in mind: 1. Finish the applet frontend to my corba server. 2. Need to understand the WebFlow API, particularly the "context" business. 3. XML--see if Tom has any suggestions about what I should learn. 4. Need to understand how to add multiple hosts to the Gateway master so that Gateway can be used for running services on multiple hosts. For example, if I want to have 10 hosts running copies of my Ising model executable, I need to be able to add the 10 hosts in some manner. a. Need to know what happens when the first slave registers itself with the master. b. Would this work something like a MUD or talk client/server system? 7-5-99: I've been trying to turn the CounterClient program into an applet. ***The IOR file must be renamed Count.txt***. This is because the Jigsaw webserver only understands specific extensions that you give it. The extension .ref is not one of these, but .txt is. To see this, go to the URL http://osprey4:8001/marlon/Counter/, the directory where this stuff is located. You will see a listing of all the files with known extensions, but you will not see everyfile that is in the directory. In particular, Counter.ref and Makefile don't show up. 7-6-99: Tom has modified the GatewayPortal servlet, so I'm going over his modifications to make my own version. I want to add SimpleJob to the list. I also need to modify the Job panel so that it uses Choices instead of Buttons to initiate jobs. Ultimately, jobs will be generated from the Tasks card via XML files. In case I haven't said this before, the top level for the package WebFlow.QS is /npac/home/webflow/WEBFLOW/JIGSAW/Jigsaw/WWW/Gateway/WF Typical members of this package are FileBrowser.class and associated files created by from the qs.idl file at compilation. I should actually say that these files are the compiled java classes, and the above directory is the correct place for them, so that the gw applet can find them. 7-9-99: Had problems running the new gw applet. It would not load and I got security errors in the java console. The problem was that the $CLASSPATH was too extensive. You only need the OB.jar and the swingall.jar files in your path. Putting too much in the path will actually cause the applet (of the client) to fail because netscape thinks it is granting too much permission. The problem was that the $CLASSPATH included too many things. The applet will work if you only have OB.jar and swing in the path. 7-14-99: I've added the IsingImp.java file to the modules and I've modified qs.idl to use its methods. Basically, this file just executes a precompiled a.out (from fortran). If I have the input/output files hard-coded the fortran program Ising.f, everything gets executed properly when invoked from the gw applet. However, I wanted to make things more flexible, so I decided to use standard input/output. From the command line, the command to be executed is a.out < input.dat > output.dat Gateway choked on this when I tried to run this as an external process from withing IsingImp: Process p = Runtime.getRuntime().exec(command); where "command" is given above. The java class didn't know how to handle standard I/O in an external command. The way around this is to execute a script: Process p = Runtime.getRuntime().exec(myscript); where myscript is an executable shell script that contains the above command: #!/bin/sh a.out < input.dat > output.dat This script could be written dynamically.