ProblemApproachesConclusionsEmbedded Systems background research (Mike) CORBA background research (Walter)Becoming Familiar with the TINI Development Environment (all)Installing and configuring proprietary TINIConvertor (all)Test Program (Walter)Working with JacORB (all)JacORB core built (all)Running HelloWorld Distributed CORBA Test Program (Walter)Running Jcounter CORBA Performance Test Program (Walter)Converting to TINI (all)- Writing log file parsing program (Mike)TINI/CORBA ORB Project Final ReportTeam MembersMichael WortleyWalter LeungKen Koontz- mentorBackgroundAn increasing number of computer integrated surgical systems today require use of multiple computers, and as network connections get faster this trend will continue to evolve. Distributed real-time systems seem to be the logical next step for computer-assisted operating rooms, but for this to become a reality there must be a universal protocol for sharing information over a network. Common Object Request Broker Architecture, or CORBA, is the most likely candidate to fill this need because it is very high level, easy to use, and it is platform independent. CORBA specifications are maintained and updated by theObject Management Group (OMG), a consortium of about 400 companies and educational institutions world-wide. There are many CORBA Object Request Brokers, or ORBs, available, both commercially and as freeware, and all are compatible thanks to the OMG standard.Another problem relating to distributed systems in the operating room is space management. Often full personal computers including a monitor, keyboard, and mouse are used to perform specific tasks that only require a smallfraction of their resources. They space the take up can hinder a surgeon and his assistants, plus the health care provider has to pay for functionality that will neverbe used. It is desirable to replace these PCs with smaller, inexpensive, dedicated computers such as the embedded computers being used in many common devices these days. The problem is that embedded machines are usually difficult to program, built for very specific purposes, and often only manufactured in bulk to cut costs.Dallas Semiconductors has built an embedded computer called the Tiny Internet Interface (TINI). TINI has enormous potential for developers for several reasons. First of all it runs Java programs, making it much easier to program than your typical embedded machine. Furthermore they can be purchased one at a time for only about $70, so gaining access to a TINI board should never be aproblem, plus TINI boards also have built in RS-232 ports and Ethernet ports. It has a built in mail, ftp, and http servers, and the proprietary operating system, Slush, is very similar to Unix and thus familiar to most users. All this adds up to make TINI a compact and user-friendly tool with powerful network potential.TINI is not without its problems, however. The board contains only 1 Mb of memory, out of which are roughly 100 kb are already in use. Also, the Java Virtual Machine that runs on TINI supports a limited API (see the appendix for more information.) The good news is that TINI is still being developed, and with a growing group of TINI developers giving feedback to Dallas Semiconductors, there is a good chance that most of these shortcomings will be worked out within a few years.The process of building a TINI application involves first writing a Java program, compiling it against the TINI API, and then running it through another program call TINIConvertor. The details of this process are elaborated in the appendix.The goal of this project was to get a CORBA ORB to work on TINI, allowing the small and inexpensive TINI computer to take the place of a $1,000 PC in an operating room. The ORB we chose to try to move is called JacORB1.2.3. JacORB’s advantage over its competitors is that it is free, open source, and written in Java.ProblemThere are two major problems with putting JacORB applications on TINI. The largest obstacle is memory. All of the files associated with JacORB1.2.3 take up about 19 Mb, out of which about 8 Mb are essential to the operation of the ORB. There is a smaller version of the OMG CORBA standard called minimumCORBA, but this is not supported by JacORB1.2.3. The other problem is that JacORB relies on several classes from the JDK API that are not in the TINIAPI, most notably java.lang.reflect.Constructor. Also, there are some differences in the methods of classes that are supported by the TINI API.ApproachesWe have tried several different approaches to solving these two problems,none of which were successful, but each did serve to shed some light on the nature of the problem and bring about new ideas for a solution.First we tried the dumb luck approach: we tried to run all the JacORB class files through the TINIConvertor. This resulted in an “out of memory” error.Next we tried to determine what classes were necessary to run a simple JacORB client/server application by capturing the verbose output of the JVM as we ran a JacORB demo program on a PC. Eventually we wrote several simple programs: one that would parse the log files generated by the verbose output of the JVM, and another that would automatically get the files specified in the verbose output. Feeding these files through the TINIConvertor always resulted in“can not find class” error, so another program was written that would run the TINIConvertor, read the error message, get the desired class that TINIConvertor could not find, and then run TINIConvertor again. This program would add classes for several minutes before it could get to an error message “getMethodRef() failed.”The third phase of our project evolved from trying to decipher the getMethodRef() error. To do this we had to develop a deeper understanding of what the TINIConvertor was doing. First it would always explore the file hierarchy. Then it starts adding classes alphabetically from the root folder. Whenit adds a class it also looks to see if all the other necessary classes are present. After it adds the class with a main() method it starts adding methods. The ultimate result is a single file with a .tini extension. The getMethodRef() error occurs when a class includes an API class that exists in both the TINI and the JDK APIs, but is missing a method in the TINI API. After realizing the cause ofour error, the importance of compiling source files against the TINI API became