Dr. Dobb's Journal - November 2007 - (Page 28)

d11zeid_p6db 9/10/07 11:02 AM Page 28 Core Technology GRID-ENABLING RESOURCE-INTENSIVE APPLICATIONS snippets (known as “JavaBeans”) downloadable from both Sun and associated vendor’s websites. .NET is similar to the Java solution in that it provides libraries of coded solutions to common program requirements and manages the execution of programs written specifically for the framework. The ideal language to use for this project with .NET would be C#, which is based on Java and C++. The drawbacks of using .NET for this project were: • We were not familiar with C# and we had a tight schedule. • .NET Remoting does not have built-in security. • An application created with .NET can only talk to Windows machines. Although our solution only needed to run on Windows machines, this could be a limitation in the future if that requirement changes. Java Native Interface (JNI) is a programming framework that lets Java code running in the Java VM call and be called by native applications and libraries written in other languages, such as C, C++, and assembly. The JNI can be used to wrap an existing application (such as CodeMatch), written in another programming language (in this case, C), and enable its functions to be accessible to Java applications. The main advantage of this tool is that legacy application code can be integrated with new Java code and not have to be rewritten in Java. The main drawbacks of using JNI are: • JNI is not an easy API to learn. • There is no garbage collection for JNI and memory allocated by the C program will have to be explicitly deallocated. JavaBeans are simply software components written in Java that have a standard format that makes them ideal for reuse in many different projects. JavaBeans are also independent objects that can exist outside of a program. JavaBeans are intended to handle common functions leaving you free to concentrate on the particular program at hand. Enterprise Java Beans (EJBs) let highly scalable, platform independent, complex systems be built quickly and cost effectively. The main drawback of using EJBs is that the API is very complicated with many interfaces to implement, and many complex XML deployment descriptors. Conclusion Most of the architectures and communication strategies we have discussed here have similarities and overlaps because they have all basically evolved from the same concepts, or from each other. This makes the comparisons a bit blurred. Also, there are many different programming languages available for use, and any one of them could probably have been used to develop this software. We chose Java mainly because we felt it had the most to offer as far as applicable library routines, and would be the least restrictive as far as future portability. Also we felt development time would be shorter because of Java’s lack of pointer issues. Our other decisions were of course heavily influenced by our choice to use Java. From our research we decided that RMI was the most advanced technology to use for the communications between client and server. From what we read we knew that JNI would be difficult to use but that a JNI wrapper would be needed for the function calls to the CodeMatch DLL. As it turned out, we ran across SWIG (www.ddj.com/184410484),, which can automatically generate JNI wrappers for programs written in a multitude of languages. While SWIG had a learning curve of its own, the automation of wrapper generation probably saved us a couple of weeks on this project. The architecture we chose is a distributed objects model. The workers all remotely call methods on the master and viceversa. The program uses the “pull” model with the workers requesting new jobs as they complete jobs. Each worker sends back the results of its work and then the master sorts and formats all results into a database file from which various types of end-user reports can be generated. The resulting performance from this project has been excellent with the run times being cut almost by the number of worker machines. While small jobs (fewer than 40 files or so) are still quicker with the standalone CodeMatch due to the extra overhead of the network initialization, overall we can now run large jobs in a fraction of the time it once took. DDJ Figure 2: CodeGrid master worker paradigm. Figure 3: CodeGrid work distribution. 28 Dr. Dobb’s Journal l www.ddj.com l November 2007 http://www.ddj.com/184410484 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2007

Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Smart Compilers - But Smart Enough? Conversations Grid-Enabling Resource-Intensive Applications Distributed Computing: Windows and Linux Adobe AIR: Desktop/Web Convergence Transparency on Demand Reusable Associations Effective Concurrency The Agile Edge Swaine’s Flames

Dr. Dobb's Journal - November 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.