Transcript Cross Platform Development using Software Matrix Vijay Appadurai Advisor:
Cross Platform Development using Software Matrix
Vijay Appadurai Advisor: Dr. James Fawcett Mar 23 rd 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.
2
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 3
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 4
Software Matrix : The Framework
Simple XML Messaging Interface Cross-platform messaging protocol Sync and Async Message Passing Pluggable service oriented architecture - Advertises services using Capability Lists - Communicates with other cells using XML Messages - Queries the framework to discover other cells.
Cell
Discovery
Software Matrix Matrix Container Cell
XML Messages
Cell
- Monitors a Plugin directory for Cells - Loads all the Cells found into the Framework - Provides discovery service for cells using Capability Lists 5
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 Incoming Messages
Matrix Cell Structure Send Queue Receive Queue Cell ID Capability List Functionality
Outgoing Messages 6
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 7
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 8
Repository Testbed Framework
Single code base One Test-bed Server for every platform RTClient is the UI to interact with the servers Repository Server: All Platforms ` RTClient: win32 Platform TestBed Server : win32 Platform ` RTClient : linux Platform TestBed Server : linux Platform 9
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 10
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 11
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. 12
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.
13
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.
14
Version Control
M1.1.xml
M1.1 : win32 M1.1 : linux 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 F1.1.cpp
F1.1.h
F1.1.doc
F1.2.cpp
M2.1.xml
M2.1 : win32 M2.1 : linux M1.2.xml
M1.2 : win32 F1.3.cpp
F1.2.h
F1.2.doc
M2.2.xml
M2.2 : win32 F2.1.h
F2.1.cpp
F2.2.doc
F2.2.h
F2.2.cpp
15
XML Metadata of an Item
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 17
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 18
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 19
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 20
RTClient : Check-In
21
RTClient : Repository Browsing
22
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 23
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 ProcessSniffer ProcessSnifferWin32.cpp
ProcessSnifferLinux.cpp
ProcessSniffer.h
FileIO FileIO.h
FileIOLinux.cpp
SnifferServer SnifferServer.cpp
SnifferServer.h
Threads Threads.cpp
Threads.h
Locks Locks.cpp
Locks.h
PortSniffer PortSniffer.h
PortSnifferWin32.cpp
PortSnifferLinux.cpp
24
Windows Build
Extracts the Sniffer Server from the Repository Builds the Sniffer Server Component for the Win32 Platform 25
Linux Build
Extracts the Sniffer Server from the Repository Builds the Sniffer Server for the Linux Platform 26
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 27
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 28
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 29
Thank You
30