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

2. 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.

3. 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

4. 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

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

6. 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

7. 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

8. 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

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

10. 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

11. 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

12. 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.

13. 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.

14. 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.

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. RTClient : Check-In

22. RTClient : Repository Browsing

23. 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

24. 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

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

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

27. 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

28. 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

29. 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

30. Thank You