Cross Platform Development using Software Matrix Vijay Appadurai Advisor: Dr. James Fawcett Mar 23rd 2007

Cross-Platform Cross-platform software consists of applications which work on multiple system platforms (eg. Linux/Unix, Mac OS, Windows) This may mean supporting all common platforms or simply more than one eg. standard libraries, game development, developer toolkits etc.

Research Overview Our work mainly centers on simplifying cross-platform development We develop a framework to help facilitate the process of cross-platform programming We show how the Software Matrix can be used for the development of such frameworks We demonstrate that simple XML Messaging is effective in developing cross-platform software

Need for Cross-Platform Software Software Industry works in an environment with many different operating systems and processors The software has to be built, tested and deployed on all platforms of interest Cross-platform software can be run everywhere and it can be proposed as a standard

Software Matrix : The Framework Simple XML Messaging Interface Cross-platform messaging protocol Sync and Async Message Passing Pluggable service-oriented architecture

A Closer Look at Matrix Cells Message Queues for communication with other cells Unique Cell ID Capability List for Advertising services Functionality which is the processing for the services provided

Improvements to the Software Matrix : Efficiency In previous models, messages were passed to the Mediator for every cell to cell communication We use a light-weigth Mediator, providing only discovery services for other cells in the Matrix Cells now query the Mediator using a “Matrix Query” message Once the location of a destination cell is known, messages are sent directly

Repository Testbed System We’ve developed the RTB framework for supporting cross-platform development Repository is the system component which contains source code for all platforms Testbed consists of a build process specific to each platform RTClient is an integrated user interface to both the Repository and the Testbed

Repository Testbed Framework Single code base One Test-bed Server for every platform RTClient is the UI to interact with the servers

Software Matrix and RTB system RTB consists of parts that reside on different machines with different platforms Software Matrix technology used for communication between the different parts XML is cross-platform and the Software Matrix messaging protocol is lightweight Repository and Testbed were developed using C++ in windows and linux whereas RTClient was developed using C# in windows We seamlessly integrate parts on different platforms written in different programming languages effectively using Software Matrix technology

Repository Contains the source code for all the platforms of interest Uses XML meta-data to store information and organize the various items in the Repository in a dependency hierarchy Provides source-code control services such as check-in, check-out, extract and versioning Supports browsing of all items and their dependencies in the Repository

Repository Definitions Version: A version is a number generated in sequence by the Repository Server that is assigned to a file. This number is encoded in the file specification using the convention: filename.VersionNumber.Extension Item: An item is a named, versioned XML metadata and all the files on which it holds references, excluding references to other items. Each item refers directly to one or more source code files and configuration files associated with the source code files. XML Manifest: A named, versioned XML file that groups together items with the same name but which may be intended for different platforms. All items within the manifest have the same name and the same version.

Definitions Component: A component is one root item and all the items it references, either directly or indirectly. That is, a component is a top-level item and the closure of all its references. Check-In: The process of storing all the files of an item in the repository and providing sequenced version numbers as described above is called a check-in. On check-in, the item is given a unique name for a given platform and a version number. Check-Out: The process of transferring files of an item from the Repository Server to the RTClient for the purpose of modification is called a check-out. Items checked out can be checked back in to create newer versions.

More Definitions . . . Extraction: The process of transferring a component’s files from the Repository Server to the RTClient and/or Testbed Server is called Extraction. Browsing: The process of viewing the items and components in the Repository Server and their dependencies is called Browsing. Browsing an item shows all the files it is dependent on and their relationships with other items.

Version Control M1 and M2 are items which can run on multiple platforms M1 is dependent on M2 M1 contains different implementations for windows and linux M2 contains the same implementation for both windows and linux

XML Metadata of an Item <manifest> <platform> <pinfo>   <name>Threads</name>   <version>1</version>   <description>Thread class</description>   <compiler>VC++</compiler>   <status>closed</status>   <pname>win32</pname>   <outputType>exe</outputType>   <outputFilename>threads.exe</outputFilename>   <checkedout>no</checkedout>   <miscCompilerOptions />   <miscLinkerOptions />   <references>Lock.1.xml:win32</references>   <sourcefiles>threads.1.h</sourcefiles>   <sourcefiles>threads.2.cpp</sourcefiles> </pinfo> </platform> </manifest> Every item in the Repository has metadata associated with it The combination of name + platform in unique in the Repository Metadata contains information about item name, version, checked-out status, build information and references to other items Also references the source files, documentation files and related configuration files for the item

TestBed Server Dedicated server running in each platform the application has to be deployed on Accepts test requests from the RTClient Uses the services of the Repository to extract components Testbed Server consists of a Builder and a Test Harness

Builder Builds test libraries and executables from the source code files in the Repository Each item has a specification for its build in its meta-data This meta-data is used by builder to generate compiler command on-the-fly for each item This compiler command is executed on the command line and produces output files as requested

Test Harness Contains a test-aggregator that loads the libraries built by the builder Each test library is required to support a ITest interface, so the aggregator creates instances of each test it loads Executes the test by invoking test() function declared in the interface and implemented by each of the test libraries Test results are sent back to the RTClient

RTClient Integrated user-interface to access the services of the Repository Server and the Testbed Server Used for check-in, check-out and insert of code into the Repository Items in Repository can be shown as a tree view and browsed comfortably Also used to issue test requests to the Testbed Server

RTClient : Check-In

RTClient : Repository Browsing

Test Application : Process and Port Sniffer Truly cross-platform client-server application with the user interface written using Java and the server written using C++ We demonstrate development of the server module written using C++. The client and server communicate using XML and sockets The server monitors the running processes and the open ports in the target machine and reports the client which displays the information in the user-interface Parts of the server application can run on both windows and linux while part of the application runs only on one platform

Design: Process and Port Sniffer SnifferServer SnifferServer.cpp SnifferServer.h ProcessSniffer ProcessSnifferWin32.cpp ProcessSnifferLinux.cpp ProcessSniffer.h PortSniffer PortSniffer.h PortSnifferWin32.cpp PortSnifferLinux.cpp Threads Threads.cpp Threads.h Locks Locks.cpp Locks.h FileIO FileIO.h FileIOLinux.cpp SnifferServer: Executive module listening to client requests on a socket. ProcessSniffer: Monitors running processes in a system – OS specific implementation Port Sniffer: Gets port information – OS specific FileIO: Basic Directory and FileIO services for linux Threads: Thread class for both win32 and Posix – runs on all platforms Locks: Sync primitives for win32 and Posix – runs on all platforms

Windows Build Extracts the Sniffer Server from the Repository Builds the Sniffer Server Component for the Win32 Platform

Linux Build Extracts the Sniffer Server from the Repository Builds the Sniffer Server for the Linux Platform

Execution of Sniffer Application on WinXP Shows Java client displaying running processes and open ports in a listview Server application displaying XML messages with these information on the console

Execution Of Sniffer Application on RHEL 4.0 Shows Java client displaying running processes and open ports in a listview Server application displaying XML messages with this information on the console

Conclusion Cross-platform development is important and we have developed a framework to support it The Software Matrix was effective in developing and tying together a large heterogeneous application Simple XML Messaging is the most-effective solution for cross-platform applications Simplifying cross-platform development in this way will help improve productivity in the software industry

Thank You