Cross Platform Development using Software Matrix

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

• Weve 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
  components 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
ltmanifestgt ltplatformgt ltpinfogt  
ltnamegtThreadslt/namegt   ltversiongt1lt/versiongt  
ltdescriptiongtThread classlt/descriptiongt  
ltcompilergtVClt/compilergt   ltstatusgtclosedlt/statu
sgt   ltpnamegtwin32lt/pnamegt   ltoutputTypegtexelt/out
putTypegt   ltoutputFilenamegtthreads.exelt/outputFil
enamegt   ltcheckedoutgtnolt/checkedoutgt  
ltmiscCompilerOptions /gt   ltmiscLinkerOptions /gt
  ltreferencesgtLock.1.xmlwin32lt/referencesgt  
ltsourcefilesgtthreads.1.hlt/sourcefilesgt  
ltsourcefilesgtthreads.2.cpplt/sourcefilesgt
lt/pinfogt lt/platformgt lt/manifestgt

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