10-06-2017, 07:08 AM
[attachment=2425]
\CROSS PLATFORM
PROJECT REPORT
Submitted by HARSHA H.NARAYAN SNEHA ANNA JACOB SURYA V.KRISHNAN
ABSTRACT
Cross-platform is a term which can refer to computer programs, operating systems, computer languages, programming languages, or other computer software and their implementations which can be made to work on multiple computer platforms. A cross-platform application could run on all common platforms, or simply more than one. This type of software could also correctly be called multi-platform software. In order for software to be considered cross-platform, it must be able to function on more than one computer architecture or operating system .Just because a particular operating system may run on different computer architectures, that does not mean that the software written for that operating system will automatically work on all architectures that the operating system supports.
There are different ways of approaching the problem of writing a cross-platform application program. One such approach is simply to create multiple versions of the same program in different source trees. Another approach that is used is to depend on pre-existing software that hides the differences between the platforms, called abstraction of the platform, such that the program itself is unaware of the platform it is running on. It could be said that such programs are platform agnostic. Programs that run on the Java Virtual Machine (JVM) are built in this fashion.
We have based our project based on the second approach .The concept of cross platform is used in a Local Area Network. A network can be an interconnection of computers which may or may not run on different platforms. These varied platforms may support different cross platform tools. The objective of our project is to create a software by the means of which the cross platform tools can be shared.
TABLE OF CONTENTS
CHAPTER TITLE PAGE NO.
ABSTRACT iv
LIST OF TABLES vii
LIST OF FIGURES vii
1. INTRODUCTION 1
1.1 PLATFORM 1
1.1.1 Hardware Platform 1
1.1.2 Software Platform 1
1.2 CROSS-PLATFORM PROGRAMMING 3
1.3 CROSS-PLATFORM PROGRAMMING TOOLS 4
1.4 CROSS-PLATFORM DEVELOPMENT
ENVIRONMENTS 4
2. SOFTWARE DEVELOPMENT LIFE CYCLE 5
2.1 SYSTEM ANALYSIS 5
2.1.1 System study 5
2.1.2 Existing System 5
2.2 SOFTWARE REQUIREMENTS 6
2.2.1 Hardware Requirements 6
2.2.2 Software Requirements 6
2.3 SYSTEM DESIGN 6
2.3.1 Logical Design 7
2.3.2 Physical Design 7
2.4 SYSTEM IMPLEMENTATION 8
2.5 SYSTEM TESTING 9
2.5.1 Static Testing Purpose 9
2.5.2 Dynamic Testing 9
2.5.3 Acceptance Testing 10
2.6 TEST PROCEDURES AND TEST REPORTS 11
2.7 MAINTENANCE 11
3. TOOLS 12
3.1 JAVA & JAVA COMPONENTS 12
3.1.1 Application Program Interface (API) 13
3.1.2 Java SE Platform 14
3.1.3 Core Components 14
3.1.4 Database Connectivity 15
3.1.5 MySQL 23
3.2 LINUX 24
3.2.1 Linux Kernel 26
3.3 WINDOWS 27
3.3.1 Introduction 27
3.4 REMOTE METHOD INVOCATION 29
4. TABLES 35
5. FIGURES 37
6. CONCLUSION 48 RESUME 49 REFERENCES 50
LIST OF TABLES
Table
4.1 USER TABLE
4.2 RESOURCE TABLE
4.3 C, C++ COMPILER TABLE
4.4 JAVA COMPILER TABLE
4.5 EXTENSION TABLE
Page
35 35 35 36 36
LIST OF FIGURES
Figure Page
3.1 Applications accessing via JDBC API 16
3.2 JDBC Connectivity using ODBC drivers 17
3.3 Connecting to a data source 18
3.4 Remote Method Invocation 30
5.1 User Regi strati on form 37
5.2 Main Menu form 37
5.3 Server settings form 38
5.4 Main Menu form 39 5. 5 Compiler form 40 5.6 Resource form 41 5. 7 Edit/Delete Java Compiler form 42 5. 8 Edit/Delete Resource form 43
5.9 View Form 44
5.10 Invoke Form 45
5.11 Client Details form 46
5.12 Change Password form 47
CHAPTER 1 INTRODUCTION
Cross-platform is a term which can refer to computer programs, operating systems, computer languages, programming languages, or other computer software and their implementations which can be made to work on multiple computer platforms. A cross-platform application could run on all common platforms, or simply more than one. This type of software could also correctly be called multi-platform software.
1.1 PLATFORM
A platform is a combination of hardware and software used to run software applications. A platform can be described as simply as an operating system or computer architecture, or it could be the combination of both. Probably the most familiar platform is Microsoft Windows running on the x86 architecture. Application software can be written to depend on the features of a particular platform either the hardware, operating system, or virtual machine it runs on. The Java platform is a virtual machine platform which runs on many operating systems and hardware types, and is a common platform for software to be written for.
1.1.1 Hardware Platform
A hardware platform can refer to a computer's architecture or processor architecture. For example, the x86 and x86-64 CPUs make up one of the most common computer architectures in use in home machines today. These machines commonly run Microsoft Windows, though they can run other operating systems as well, including Linux, Mac OS X etc.
1.1.2 Software Platform
Software platforms can either be an operating system or programming environment, though more commonly it is a combination of both. A notable exception to this is Java, which uses an operating system independent virtual machine for its compiled code, known in the world of Java as byte code. Examples of software platforms include:
> Microsoft Windows
> GNU/Linux x86
> Mac OS X PowerPC
> Mac OS X x86
> Java
The Java platform is an exception to the general rule that an operating system is a software platform. The Java language provides a virtual machine, or a "virtual CPU" which runs all of the code that is written for the language. This enables the same executable binary to run on all systems which support the Java software, through the Java Virtual Machine. Java executables do not run directly on the operating system; that is, neither Windows nor Linux execute Java programs directly. Instead, a special computer program called the JVM, or Java Virtual Machine, is run by the operating system, which in turn runs the Java program.
In order for software to be considered cross-platform, it must be able to function on more than one computer architecture or operating system. This can be a time-consuming task given that different operating systems have different application programming interfaces or APIs (for example, Linux uses a different API for application software than Windows does).
Just because a particular operating system may run on different computer architectures that do not mean that the software written for that operating system will automatically work on all architectures that the operating system supports. Web applications are typically described as [cross-platform] because, ideally, they are accessible from any of various web browsers within different operating systems. Such applications generally employ client-server system architecture, and vary widely in complexity and functionality. This wide variability significantly complicates the goal of cross-platform capability, which is routinely at odds with the goal of advanced functionality.
1.2 CROSS-PLATFORM PROGRAMMING
There are different ways of approaching the problem of writing a cross-platform application program. One such approach is simply to create multiple versions of the same program in different source trees in other words, the Windows version of a program would have one set of source code files and the Macintosh version could have another. While this is a straightforward approach to the problem, it has the potential to be considerably more expensive in development cost, development time, or both. The idea behind this is to create two different programs that look and act similar to each other. It is also possible that this means of developing a cross-platform application will result in more problems with bug tracking and fixing, because the two different source trees would have different programmers, and thus different defects in each version.
Another approach that is used is to depend on pre-existing software that hides the differences between the platforms called abstraction of the platform such that the program itself is unaware of the platform it is running on. It could be said that such programs are platform agnostic. Programs that run on the Java Virtual Machine (JVM) are built in this fashion.
Some applications mix various methods of cross-platform programming to create the final application. An example of this is the Firefox web browser, which uses abstraction to build some of the lower-level components, and the implementation of more than one scripting language to help facilitate ease of portability. Firefox implements XUL, CSS and JavaScript for extending the browser, in addition to classic Netscape-style browser plug-ins. Much of the browser itself is written in XUL, CSS and JavaScript, as well.
1.3 CROSS-PLATFORM PROGRAMMING TOOLS
There are a number of tools which are available to help facilitate the process of cross-platform programming:
> Simple Direct Media Layer an open source cross-platform multimedia library written in C that creates an abstraction over various platforms' graphics, sound, and input
APIs.
> WxWidgets an open source widget toolkit that is also an application framework. It permits applications written to use it to run on all of the systems that it supports, if the application does not use any operating system-specific programming in addition to it.
> Qt An open source widget toolkit and application framework which runs on Unix-like systems and Microsoft Windows.
> GTK+ An open source widget toolkit for Unix-like systems and Microsoft Windows.
> FLTK Another open source cross platform toolkit, but more light weight because it restricts itself to the GUI.
1.4 CROSS-PLATFORM DEVELOPMENT ENVIRONMENTS
Cross-platform applications can also be built using proprietary IDEs, or so-called Rapid Application Development tools. There are a number of development environments which allow developers to build and deploy applications across multiple platforms:
> Omnis Studio a proprietary IDE or Rapid Application Development tool for creating enterprise and web applications for Windows, Linux, and Mac OS X.
> Runtime Revolution a proprietary IDE, compiler engine and CGI builder that cross
compiles to Windows, Mac OS X (PPC, Intel), GNU/Linux, Solaris, BSD, and Irix.
CHAPTER 2 SOFTWARE DEVELOPMENT LIFE CYCLE
The prime objective of the system is to develop a user-friendly system, for satisfying all user requirements and it should be capable of handling large volume of data. The overall system must be fast and convenient. The classical System Development life Cycle (SDLC) method, the Waterfall model has been used here. It is the oldest and the most widely used paradigm for system development. This process demands a systematic, sequential approach to software development. The life cycle involves the following activities:
2.1 SYSTEM ANALYSIS
2.1.1 System study
System study should be conducted to analyze the current existing system and the improvements that are to be made for better operations. System studies results in finding out details of the existing methodologies that are being followed and that whether any developments is to be made. These studies considered both the existing and the proposed system.
2.1.2 Existing system
In the existing system resources in a Local Area Network can be shared provided that the resources are saved in the sharable drives. This aspect is made use of extensively in most of the Local Area Networks .The resources are accessed with the help of the system Internet protocol(IP)Address every time the access is needed which can be time consuming.
Moreover in a network varied platforms may coexist thereby causing a hindrance to the sharing the resources .Each of the platforms has its own distinct characteristics and functionality so it may not be viable to impose a common platform in a network. So it becomes imperative that different platforms coexist in a network
2.2 SOFTWARE REQUIREMENTS AND SPECIFICATION
2.2.1 Hardware Requirements
PROCESSOR : PENTIUM IV
CLOCK SPEED : 500 MHZ
SYSTEM BUS
RAM HDD
MONITOR KEY BOARD MOUSE FDD
: 32 BIT 128 MB 1.2 GB
SVGA COLOR 108 KEYS
LOGITECH 1.44 MB
2.2.2 Software Requirements
OPERATING SYSTEM
ENVIRONMENT FRONT END
SERVER SIDE SCRIPTING CLIENT SIDE SCRIPTING
BACKEND
: WINDOWS XP, FEDORA 3
: JDK1.5
: JAVA : JAVA : JAVA
: MYSQL SERVER 5.0
2.3 SYSTEM DESIGN
The importance of software design can be found with a single word, quality. Designing is the phase in which quality is fastened in a software development. Design is the only way that can accurately translate the Customer's requirements into a finished software product. A system, which is not properly designed, may fail when small changes are made. Thus, the primary objective of design phase is to determine how the system has to be developed. System design is a process that identifies inputs, outputs and explains functions of the system. This important phase is composed of several steps. It provides understanding of the procedural details, necessary for implementing. Emphasis has been given for translating the performance requirements. Understanding the data flow and the database that is to be designed forms an important aspect of the designing process. Generally System Design includes the following types:
2.3.1 Logical Design
Logical design describes the format of inputs, outputs, and procedures that meets the user requirements. The design covers the following:
> Reviews the current physical system.
> Prepares the output specification.
> Prepares the Input specifications.
> Prepares controls specifications.
2.3.2 Physical Design
This produces the working system by defining the design specifications that tell the programmers exactly what the system must do. The programmers write the necessary programs that accept inputs from the user, perform the necessary calculations, produce hardcopy of the report or display it on the screen.
> Design the Physical system.
> Specify the Input/Output media
> Design physical information flow through the system
> Plan system implementation
> Prepare a Conversion schedule and a target date
> Determine training procedure courses and timetable
> Coding
The design must be translated into a machine-readable form. The coding step performs this task. If design is performed in a detailed manner, then coding can be done mechanically.
2.4 SYSTEM IMPLEMENTATION
This is the stage of the project when the theoretical design is tuned into a working system. If the implementation stage is not carefully controlled and planned, it can cause chaos. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the users a confidence that the system will work and be effective.
The implementation stage in a project has its own right. It involves
> Careful planning
> Investigation of the current system and the constraints on implementation.
> Training of staff in the newly developed system
After the successful completion of the design phase, the next important step is the development of the system according to the specified design. The main procedure of this phase is coding of the deigned system, in order to satisfy the requirements. The detailed input/output, text manipulation, logic comparison and storage/retrieval operations during the system analysis stage provide input for the program preparation. Coding was carried out in a step-by-step manner. One or more programmers convert these operations into a program of instructions written in a language and form acceptable to the computer hardware. User inter-activeness was given stress and the system gives maximum flexibility. Proper validations were done for every user-defined function.
The principal activities performed during the development phase can be divided into two major related sequences. These are
1. External system development
2. Internal system development
The primary external system development activities include
> Implementation planning.
> Preparation of manuals and personnel training
> Equipment acquisition and installation
The principal internal system development activities are: Computer program development and performance
2.5 SYSTEM TESTING
No system design is ever perfect. Communication problems, programmer's negligence, or time constraints create errors that must be eliminated before the system is ready for user acceptance testing. A system is tested for online response, volume of transactions, stress, recovery from failure and usability. Then comes system testing, which verifies that the whole test of programs hangs together following system testing is acceptance testing, or running the system with live data by the actual user.
2.5.1 Static Testing Purpose
Code should be reviewed where necessary to ensure it follows project coding and design standards. Code reviews are not meant to check program logic. Adherence to acceptable programming standards is crucial for future maintenance. These will change over time as technology develops.
2.5.2 Dynamic Testing
The traditional 'waterfall' lifecycle breaks dynamic testing down into a number of phases such as unit, integration, system and acceptance testing. Whatever methodology is being followed, a software system is typically organized into a number of units comprising a single logical function or several related functions needing access to shared data. It is sensible and efficient to test these 'units' as they are developed. Black box and white box testing may be used for this purpose:
Functional (black-box) Testing means testing that the 'unit' does what it is supposed to do, and does not do what it is not supposed to do. In other words, it is tested against its functional requirements, both positive and negative, as stated in the specification. This is known as black box testing, since it requires no knowledge of the inner workings of the unit.
Structural (white-box) Testing is concerned with the degree to which test cases exercise or 'cover' the logic of the program. White-box testing may be covered using a variety of techniques such as walkthroughs, structured testing and test-harness software.
2.5.3 Acceptance Testing
The need for acceptance testing will vary from project to project. It is worthwhile noting the purpose of acceptance testing. It is not supposed to be an unsupervised ad hoc activity undertaken by the client. It should be strictly controlled. For that reason there are a number of requirements, which are applicable if acceptance testing proves necessary. The project manager should select these from the following that are applicable for a particular project.
Acceptance tests relate to the functionality of the system as stated in the requirements specification, and functional test cases must be selected to satisfy the agreed acceptance criteria. In the majority of cases, suitable test cases will exist among those used for system testing.
These tests cover areas such as performance, security, reliability, load/stress testing, volume testing, human computer interaction tests, configuration testing, compatibility testing, documentation, and human procedures. Sufficient tests must be devised to satisfy the agreed acceptance criteria.
Since acceptance tests in particular can make heavy demands on resources, and will have been performed as part of system testing, an alternative and equally acceptable procedure is to have the client witness a part of the system test. In that case client witnessed system testing must conform to the requirements for acceptance testing with respect to procedure, conduct, and documentation. It is recommended that this approach is adopted wherever possible as it ensures that testing is performed under carefully controlled conditions.
The acceptance test procedures must be documented. The acceptance test procedure should specify the steps to be taken in carrying out the tests, and for formal acceptance tests needs to be rigorous, complete and unambiguous.
The acceptance test procedure specification must be subject to review prior to the dry run. The results of both the dry run and the acceptance tests must be documented. A test log and any test observation reports should be completed as the tests are conducted. A test summary review should be completed as soon after completion of the tests as possible.
2.6 MAINTENANCE
Software will undoubtedly undergo changes after it has been delivered to the user. Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in external environment or because the user requires functional or personal enhancements. Software maintenance reapplies each of the preceding life cycle steps to an existing program rather than a new one.
The basic idea of the SDLC method is that there is well-defined process by which the application is conceived, developed and implemented. It gives the structure to a creative process. The phases in the SDLC provides a basis for management and control because they define segments of flow of work which can be identified for management purpose and specify the documents or other deliverables to be procured in each phase.
A thorough analysis of the existing system is done and the new requirements for the proposed system are studied. The entire application is modularized considering the features required for the proposed system.
CHAPTER 3 TOOLS
Java is an object-oriented programming language developed by Sun Microsystems in the early 1990s. Java applications are compiled to byte code, which at runtime is either interpreted or compiled to native machine code for execution. The language itself derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities. Sun Microsystems provides a GNU General Public License implementation of a Java compiler and Java virtual machine, in compliance with the specifications of the Java Community Process.
The Java Runtime Environment or JRE is the software required to run any application deployed on the Java Platform. End-users commonly use a JRE in software packages and Web browser plug-ins. Sun also distributes a superset of the JRE called the Java 2 SDK (more commonly known as the JDK), which includes development tools such as the Java compiler, Javadoc, and debugger.
3.1 JAVA & JAVA COMPONENTS
> Java libraries are the compiled byte codes of source code developed by the JRE implementor to support application development in Java. Examples of these libraries are: The core libraries, which include: Collection libraries which implement data structures such as lists, dictionaries, trees and sets ,XML Processing (Parsing, Transforming, Validating) libraries , Security ,Internationalization and localization libraries . The integration libraries, which allow the application writer to communicate with external systems. These libraries include: The Java Database Connectivity (JDBC) API for database access .
> Java Naming and Directory Interface (JNDI) for lookup and discovery .
> RMI and CORBA for distributed application development .
> User Interface libraries, which include: The (heavyweight, or native) Abstract Windowing Toolkit (AWT), which provides GUI components, the means for laying out those components and the means for handling events from those components ,the (lightweight) Swing libraries, which are built on AWT but provide (non-native) implementations of the AWT widgetry and APIs for audio capture, processing, and playback
> A platform dependent implementation of Java virtual machine (JVM) which is the means by which the byte codes of the Java libraries and third party applications are executed
> Plug-ins, which enable applets to be run in Web browsers
> Java Web Start, which allows Java applications to be efficiently distributed to end users across the Internet
> Licensing and documentation
3.1.1 Application Program Interface (API)
Sun has defined three platforms targeting different application environments and segmented many of its APIs so that they belong to one of the platforms. The platforms are:
> Java Platform, Micro Edition (Java ME) targeting environments with limited resources,
> Java Platform, Standard Edition (Java SE) targeting workstation environments, and
> Java Platform, Enterprise Edition (Java EE) targeting large distributed enterprise or Internet environments.
The classes in the Java APIs are organized into separate groups called packages. Each package contains a set of related interfaces, classes and exceptions. Refer to the separate platforms for a description of the packages available.
The set of APIs is controlled by Sun Microsystems in cooperation with others through the Java Community Process program. Companies or individuals participating in this process can influence the design and development of the APIs. This process has been a subject of controversy.
3.1.2 Java SE Platform
Java Platform, Standard Edition (also known as Java 2 Platform) lets you develop and deploy Java applications on desktops and servers, as well as today's demanding embedded and Real Time environments. Java SE includes classes that support the development of Java Web Services and provides the foundation for Java Platform, Enterprise Edition (Java EE)
3.1.3 Core Components
> Basic:
Java SE contains a rich set of APIs that enable developers to create sophisticated applications. They provide both fundamental system level support as well as more complex functionality such as multi-threaded programming and object manipulation on remote hosts.
> CORBA:
The CORBA (Common Object Request Broker Architecture) implementation in the Java platform provides standards-based interoperability and connectivity. Java IDL enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard OMG IDL (Object Management Group Interface Definition Language) and IIOP (Internet Inter-ORB Protocol)
> Hot spot VM:
The Java Hotspot Virtual Machine is a core component of the Java SE platform. It implements the Java Virtual Machine Specification, and is delivered as a shared library in the Java Runtime Environment. As the Java byte code execution engine, it provides Java runtime facilities, such as thread and object synchronization, on a variety of operating systems and architectures. It includes dynamic compilers that adaptively compile Java bytecodes into optimized machine instructions .
> Java Naming & Directory Interface (JNDI) :
The Java Naming and Directory Interface (JNDI) is part of the Java platform, providing applications based on Java technology with a unified interface to multiple naming and directory services. You can build powerful and portable directory-enabled applications using this industry standard.
> Tools APIs:
Java SE contains several APIs that can be used by tools such as compilers, debuggers, profilers, and monitoring & management tools.
> XML:
The XML technology in Java SE supports the W3C DOM APIs, parsing of XML documents, and transforming XML documents via XSLT.
3.1.4 Database Connectivity
> Java Database Connectivity (JDBC) Technology:
The Java Database Connectivity (JDBC) API is the industry standard for database-independent connectivity between the Java programming language and a wide range of databases - SQL databases and other tabular data sources, such as spreadsheets or flat files. The JDBC API provides a call-level API for SQL-based database access.JDBC technology allows you to use the Java programming language to exploit "Write Once, Run Anywhere" capabilities for applications that require access to enterprise data
> JDBC Architecture:
The JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is the lower-level JDBC driver API for driver writers. JDBC technology drivers fit into one of four categories. Applications and applets can access databases via the JDBC API using pure Java JDBC technology based drivers as shown in
fig 3.1
Fig 3.1 Applications accessing via JDBC API Left side, Type 4: Direct-to-Database Pure Java Driver:
This style of driver converts JDBC calls into the network protocol used directly by DBMSs, allowing a direct call from the client machine to the DBMS server and poviding a practical solution for intranet service.
Right side, Type 3: Pure Java Driver for Database Middleware:
This style of driver translates JDBC calls into the middleware vendor's protocol, which is then translated to a DBMS protocol by a middleware server. The middleware provides connectivity to many different databases.
The graphic fig 3.2 below illustrates JDBC connectivity using ODBC drivers and existing database client libraries.
Fig 3.2 JDBC Connectivity using ODBC drivers
Left side, Type 1:JDBC-ODBC Bridge plus ODBC driver
This combination provides JDBC access via ODBC drivers. ODBC binary code - and in many cases, database client code -- must be loaded on each client machine that uses a JDBC-ODBC Bridge. Sun provides a JDBC-ODBC Bridge driver, which is appropriate for experimental use and for situations in which no other driver is available
Right side, Type 2: A native API partly Java technology-enabled driver This type of driver converts JDBC calls into calls on the client API for Oracle, Sybase, Informix, DB2, or other DBMS. Note that, like the bridge driver, this style of driver requires that some binary code be loaded on each client machine.
> Key Features:
Full Access to Metadata:
The JDBC API provides metadata access that enables the development of sophisticated applications that need to understand the underlying facilities and capabilities of a specific database connection.
No Installation:
A pure JDBC technology-based driver does not require special installation; it is automatically downloaded as part of the applet that makes the JDBC calls. Database Connection Identified by URL.
JDBC technology exploits the advantages of Internet-standard URLs to identify database connections. The JDBC API includes an even better way to identify and connect to a data source, using a DataSource object, that makes code even more portable and easier to maintain.
Fig 3.3 Connecting to a data source
In addition to this important advantage, Data Source objects can provide connection pooling and distributed transactions, essential for enterprise database computing. This functionality is provided transparently to the programmer.
Included in the Java Platform:
As a core part of the Java 2 Platform, the JDBC API is available anywhere that the platform is. This means that your applications can truly write database applications once and access data anywhere. The JDBC API is included in both the Java 2 Platform, Standard Edition (J2SE) and the Java 2 Platform, Enterprise Edition (J2EE), providing server-side functionality for industrial strength scalability.
> Requirements:
Software: The Java 2 Platform (either the Java 2 SDK, Standard Edition, or the Java 2 SDK, Enterprise Edition), an SQL database, and a JDBC technology-based driver for that database.
Hardware: Same as for the Java 2 Platform.
> Security Components:
Java Security Technology: Java security technology includes a large set of APIs, tools, and implementations of commonly used security algorithms, mechanisms, and protocols. The Java security APIs span a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. Java security technology provides the developer with a comprehensive security framework for writing applications, and also provides the user or administrator with a set of tools to securely manage applications.
> Desktop Components:
Accessibility: Accessibility means building the services and support into an application that enable people with disabilities to use the software. Java accessibility technologies are implemented in the Java Foundation Classes (JFC) and they comprise two separate packages: Java Accessibility API and the Java Accessibility Utilities.
Java Plug-in Java Plug-in enables applets written to the Java 2 Platform 5.0 specification to be run in Mozilla and Internet Explorer web browsers. Java Plug-in comes with the 5.0 JRE/JDK.
JavaBeans: The JavaBeans component API extends the Java platform's Write Once, Run Anywhere capability to reusable component development. In fact, the JavaBeans architecture takes interoperability a major step forward your code runs on every OS and also within any application environment.
Abstract Window Toolkit (AWT): The Abstract Window Toolkit (AWT) supports Graphical User Interface (GUI) programming. AWT features include: a rich set of user interface components; a robust event-handling model; graphics and imaging tools, including shape, color, and font classes; layout managers ; data transfer classes, for cut-and-paste through the native platform clipboard.
Java Help System :This is an open source software, a full-featured, platform-independent, extensible help system that enables you to incorporate online help in applets, components, applications, operating systems, and devices.
Java Web Start:Java Web Start is an application-deployment technology that gives you the power to launch full-featured applications with a single click from your Web browser.
Java 2D :The Java 2D API is a set of classes for advanced 2D graphics and imaging. It encompasses line art, text, and images in a single comprehensive model.
Java 3D :This is the parent project for all Java 3D related sub-projects on java.net. These sub-projects include: j3d-core , vecmath , and j3d-core-utils (the Java 3D core utilities), among
Java Media Framework :The Java Media Framework API (JMF) enables audio, video and other time-based media to be added to applications and applets built on Java technology. This optional package, which can capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology.
Swing Project: Swing is the part of the Java Foundation Classes (JFC) software that implements a set of GUI components with a pluggable look and feel. Project Swing is implemented entirely in the Java programming language, and is based on the JDK1.1 Lightweight UI Framework. The pluggable look and feel lets you design a single set of GUI components that can automatically have the look and feel of any OS platform (Microsoft Windows, Solaris TM, and Macintosh.
There are two principal products in the Java SE platform family: Java SE Runtime Environment (JRE) and Java Development Kit (JDK).
> Java Runtime Environment:
The Java Runtime Environment (JRE) provides the libraries, the Java Virtual Machine, and other components to run applets and applications written in the Java programming language. In addition, two key deployment technologies are part of the JRE: Java Plug-in, which enables applets to run in popular browsers; and Java Web Start, which deploys standalone applications over a network. It is also the foundation for the technologies in the Java 2 Platform, Enterprise Edition (J2EE) for enterprise software development and deployment. The JRE does not contain tools and utilities such as compilers or debuggers for developing applets and applications.
> Java Development Kit(JDK):
The JDK is a superset of the JRE, and contains everything that is in the JRE, plus tools such as the compilers and debuggers necessary for developing applets and applications. The conceptual diagram above illustrates all the component technologies in Java SE platform and how they fit together.
> Java SE API:
The Java SE application programming interface (API) defines the manner by which an applet or application can make requests to and use the functionality available in the compiled Java SE class libraries. (The Java SE class libraries are also part of the Java SE platform.)
The Java SE API consists of core technologies, Desktop (or client) technologies, and other technologies.
Core components provide essential functionality for writing powerful enterprise-worthy programs in key areas such as database access, security, remote method invocation (RMI), and communications.
Desktop components add a full range of features to help build applications that provide a rich user experience - deployment products such as Java Plug-in, component modeling APIs such as JavaBeans, and a graphical user
> Java Virtual Machine:
The Java Virtual Machine is responsible for the hardware- and operating system-independence of the Java SE platform, the small size of compiled code (byte codes), and platform security.
> Java Platform Tools:
The Java SE platform works with an array of tools, including Integrated Development Environments (IDEs), performance and testing tools, and performance monitoring tools.
3.1.5 MySQL
MySQL is a multithreaded, multi-user SQL database management system (DBMS). MySQL works on many different platforms including AIX, BSDi, FreeBSD, HP-UX,
GNU/Linux, Mac OS X, NetBSD, Novell NetWare, OpenBSD,OS/2 Warp, QNX, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows
ME, Windows NT, Windows 2000, Windows XP and Windows Vista. A port of MySQL to
OpenVMS is also available.
> Features of mysql over RDBMS:
The following features are implemented by MySQL but not by some other RDBMSes:
Multiple storage engines, allowing you to choose the one which is most effective for each table in the application (in MySQL 5.0, storage engines must be compiled in; in MySQL 5.1, storage engines can be dynamically loaded at run time)
Native storage engines (MyISAM,Falcon,Merge, Memory (heap), Federated, Archive, CSV, Blackhole, Cluster)
Partner-developed storage engines (InnoDB, solidDB, NitroEDB, BrightHouse)
Community-developed storage engine
Custom storage engines
Commit grouping, gathering multiple transactions from multiple connections together to increase the number of commits per second.
Architecture Overview > Priorities of MySql:
The three priorities of the MySQL database server are:
Reliability - Little or no intervention required for constant uptime to be achieved.
Performance - High performance and fast response times for all database interactions.
Ease-of-Use - Installation and configuration of MySQL should take no more than 15 minutes (most times is much less). Very little management necessary for ongoing maintenance or traditional administration tasks.
To accomplish these objectives, MySQL uses the unique Pluggable Storage Engine Architecture
3.2 LINUX
Linux is a Unix-like computer operating system family. Linux is one of the most prominent examples of free software and of open source development; its underlying source code is available for anyone to use, modify, and redistribute freely.
The first Linux systems were completed in 1992 by combining system utilities and libraries from the GNU project with the Linux kernel, which led to the coining of the term GNU/Linux. From the late 1990s onward Linux gained the support of corporations such as IBM, Sun Microsystems,Hewlett-Packard,and Novell.
Predominantly known for its use in servers, Linux is used as an operating system for a wider variety of computer hardware than any other operating system, including desktop computers, supercomputers, mainframes, and embedded devices such as cellphones.Linux is packaged for different uses in Linux distributions, which contain the kernel along with a variety of other software packages tailored to requirements.
The primary difference between Linux and other contemporary operating systems is that the Linux kernel and other components are open source software.
Linux aims for interoperability with other operating systems, and by extension the software that runs on Linux aims for interoperability with other Linux and non-Linux software.. Interoperability also provides users free choice of software and data formats whilst not restricting them as a result of that choice.
Linux systems adhere to POSIX, SUS, ISO, and ANSI standards where possible, although to date only one Linux distribution has been POSIX.1 certified.
A priority is placed on open formats, public specifications for data that are freely available and free to implement, such that there can be multiple competing independent implementations to choose from, instead of only a single piece of software which can work with a specific format.
These contrast with closed formats, which are either poorly documented or not documented at all, and for which there exists no agreement between competing vendors. When standards exist for network communication protocols, data formats, and APIs, they contribute to the robustness and adoption of Linux. In some cases, free software projects are the reference implementation of these protocols, examples being the Apache HTTP Server, and the X.org implementation of the X Window System.
Examples of standard conformance include Mozilla Firefox which adheres strictly to World Wide Web Consortium recommendations, Jabber which formed the basis for the
XMPP standard recognized by the Internet Engineering Task Force in the domain of instant messaging, and office productivity suites such as OpenOffice.org and KOffice which brought to light the recent OpenDocumentt standard.
3.2.1 Linux Kernel
The Linux kernel is a Unix-like operating system kernel. It is the namesake of the Linux family of operating systems. Linux supports true preemptive multitasking (both in user mode and kernel mode), virtual memory, shared libraries, demand loading, shared copy-on-write executables, memory management, the Internet protocol suite, and threading.
Linux is a monolithic kernel. Device drivers and kernel extensions run in kernel space , with full access to the hardware, although some exceptions run in user space. The Linux graphics subsystem (the X Window System) is not part of the kernel, is optional, and runs in user space, in contrast with Microsoft Windows.
Kernel mode preemption means device drivers can be preempted under certain conditions. This latter feature was added to handle hardware interrupts correctly, and to improve support for symmetric multiprocessing (SMP). Preemption also improves latency, increasing responsiveness and making Linux more suitable for real-time applications.
Unlike traditional monolithic kernels, device drivers are easily configured as Loadable Kernel Modules, and loaded or unloaded while running the system.
Linux is written in the version of the C programming language supported by GCC (which has introduced a number of extensions and changes to standard C), together with a number of short sections of code written in the assembly language (in GCC's "AT&T-style" syntax) of the target architecture. Because of the extensions to C it supports, GCC was for a long time the only compiler capable of correctly building Linux.
Many other languages are used in some way, primarily in connection with the kernel build process . These include Perl, Python, and various shell scripting languages. Some drivers may also be written in C++, Fortran, or other languages, but this is strongly discouraged. Linux's build system only officially supports GCC as a kernel and driver compiler.
Linux supports the following machine architectures:Alpha architecture:,Argonaut RISC Core ,Fujitsu FR-V, Hewlett-Packard's PA-RISC family, IBM , Intel IA-64MIPS architecture, x86 architecture, OpenRISC Power Architecture:
The Linux kernel has extensive support for and runs on many virtual machine architectures both as the host operating system and as a client operating system. The virtual machines usually emulate Intel x86 family of processors, though in a few cases PowerPC or AMD processors are also emulated.
Linux 1.0 supported only the a.out binary format. The next stable series (Linux 1.2) added support for Executable and Linkable Format (ELF), which simplifies the creation of shared libraries . Linux supports many other binary formats, including binfmtmisc for associating files to a program (such as an interpreter) to run or display that file.
The version number of the Linux kernel currently consists of four numbers, following a recent change in the long-standing policy of a three-number versioning scheme. For illustration, let it be assumed that the version number is composed thus: A.B.C [.D] The A number denotes the kernel version. The B number denotes the major revision of the kernel. The C number indicates the minor revision of the kernel. A D number first occurred. Bug-fixes and security patches are now managed by the fourth number, whereas bigger changes are only implemented in minor revision changes (the C number).
3.3 WINDOWS
3.3.1 Introduction
Microsoft Windows is the name of several families of proprietary software operating systems by Microsoft.The OS family includes MS-DOS-based, Windows NT, Windows 9x, Windows CE, Windows 3.1x, Windows XP, Windows Vista.
Windows XP is a line of proprietary operating systems developed by Microsoft for use on general-purpose computer systems, including home and business desktops, notebook computers, and media centers.
The most common editions of the operating system are Windows XP Home Edition, which is targeted at home users, and Windows XP Professional, which has additional features such as support for Windows Server domains and dual processors, and is targeted at power users and business clients. Windows XP Media Center Edition has additional multimedia features enhancing the ability to record and watch TV shows, view DVD movies, and listen to music. Windows XP Tablet PC Edition is designed to run the ink-aware Tablet PC platform. Two separate 64-bit versions of Windows XP were also released, Windows XP 64-bit Edition for IA-64 (Itanium) processors and Windows XP Professional x64 Edition for x86-64 processors.
Windows XP introduced several new features to the Windows line, including:
> Faster start-up and hibernation sequences
> The ability to discard a newer device driver in favor of the previous one (known as driver rollback), should a driver upgrade not produce desirable results.
> A new, arguably more user-friendly interface, including the framework for developing themes for the desktop environment;
> Fast user switching, which allows a user to save the current state and open applications of their desktop and allow another user to log on without losing that information;
> The ClearType font rendering mechanism, which is designed to improve text readability on Liquid Crystal Display (LCD) and similar monitors;
The Remote Desktop functionality, which allows users to connect to a computer running Windows XP from across a network or the Internet and access their applications, files, printers, and devices.
Support for most DSL modems and wireless network connections, as well as networking over FireWire.
Microsoft has also customized Windows XP to suit different markets and there are now several different versions available. Five different versions of XP for specific hardware were designed, two of them specifically for 64-bit processors.
3.4 REMOTE METHOD INVOCATION
RMI applications often comprise two separate programs, a server and a client. A typical server program creates some remote objects, makes references to these objects accessible, and waits for clients to invoke methods on these objects. A typical client program obtains a remote reference to one or more remote objects on a server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application.
Distributed object applications need to do the following:
> Locate remote objects:
Applications can use various mechanisms to obtain references to remote objects. For example, an application can register its remote objects with RMI's simple naming facility, the RMI registry. Alternatively, an application can pass and return remote object references as part of other remote invocations.
> Communicate with remote objects:
Details of communication between remote objects are handled by RMI. To the programmer, remote communication looks similar to regular Java method invocations.
> Load class definitions for objects that are passed around. Because RMI enables objects to be passed back and forth, it provides mechanisms for loading an object's class definitions as well as for transmitting an object's data.
The following illustration Fig 3.4 depicts an RMI distributed application that uses the RMI registry to obtain a reference to a remote object. The server calls the registry to associate (or bind) a name with a remote object. The client looks up the remote object by its name in the server's registry and then invokes a method on it. The illustration also shows that the RMI system uses an existing web server to load class definitions, from server to client and from client to server, for objects when needed.
Fig 3.4 Remote Method Invocation
> The Advantages of Dynamic Code Loading:
One of the central and unique features of RMI is its ability to download the definition of an object's class if the class is not defined in the receiver's Java virtual machine. All of the types and behavior of an object, previously available only in a single Java virtual machine, can be transmitted to another, possibly remote, Java virtual machine. RMI passes objects by their actual classes, so the behavior of the objects is not changed when they are sent to another Java virtual machine. This capability enables new types and behaviors to be introduced into a remote Java virtual machine, thus dynamically extending the behavior of an application. The compute engine example in this trail uses this capability to introduce new behavior to a distributed program.
> Remote Interfaces, Objects, and Methods:
Like any other Java application, a distributed application built by using Java RMI is made up of interfaces and classes. The interfaces declare methods. The classes implement the methods declared in the interfaces and, perhaps, declare additional methods as well. In a distributed application, some implementations might reside in some Java virtual machines but not others. Objects with methods that can be invoked across Java virtual machines are called remote objects.
An object becomes remote by implementing a remote interface, which has the following characteristics:
A remote interface extends the interface java.rmi.Remote.
Each method of the interface declares java.rmi.RemoteException in its throws clause, in addition to any application-specific exceptions.
RMI treats a remote object differently from a non-remote object when the object is passed from one Java virtual machine to another Java virtual machine. Rather than making a copy of the implementation object in the receiving Java virtual machine, RMI passes a remote stub for a remote object. The stub acts as the local representative, or proxy, for the remote object and basically is, to the client, the remote reference. The client invokes a method on the local stub, which is responsible for carrying out the method invocation on the remote object.
A stub for a remote object implements the same set of remote interfaces that the remote object implements. This property enables a stub to be cast to any of the interfaces that the remote object implements. However, only those methods defined in a remote interface are available to be called from the receiving Java virtual machine.
Using RMI to develop a distributed application involves these general steps:
Designing and implementing the components of your distributed application.
Compiling sources.
Making classes network accessible.
Starting the application.
> Designing and Implementing Application Components:
First, determine your application architecture, including which components are local objects and which components are remotely accessible. This step includes:
Defining the remote interfaces. A remote interface specifies the methods that can be invoked
remotely by a client. Clients program to remote interfaces, not to the implementation classes of those interfaces. The design of such interfaces includes the determination of the types of objects that will be used as the parameters and return values for these methods. If any of these interfaces or classes do not yet exist, you need to define them as well.
Implementing the remote objects. Remote objects must implement one or more remote interfaces. The remote object class may include implementations of other interfaces and methods that are available only locally. If any local classes are to be used for parameters or return values of any of these methods, they must be implemented as well.
Implementing the clients. Clients that use remote objects can be implemented at any time after the remote interfaces are defined, including after the remote objects have been deployed.
> Compiling Sources:
As with any Java program, you use the javac compiler to compile the source files. The source files contain the declarations of the remote interfaces, their implementations, any other server classes, and the client classes.
> Making Classes Network Accessible:
In this step, you make certain class definitions network accessible, such as the definitions for the remote interfaces and their associated types, and the definitions for classes that need to be downloaded to the clients or servers. Classes definitions are typically made network accessible through a web server.
> Starting the Application:
Starting the application includes running the RMI remote object registry, the server, and the
client.
> Building the four required classes:
An interface for the remote object which is used by both the client and the server
The RMI client which will look up the object on the remote server, cast it to the
type of the interface from Step 1, then use it like a local object.As long as there is a "live" reference to the remote object, an open network connection is maintained. The connection will be automatically closed when the remote object is garbage collected on the client.
The object implementation which implements the interface of Step a, and will be used by the server
The RMI server which will create an instance of the object from Step c and register it with a particular URL.
> Compiling and running the system:
Compile client and server.by which the remote object interface and implementation is compiled automatically.
Generate the client stub and the server skeleton,by using the rmic compiler on the remote object implementation. For this the client system will need the client class, the interface. class, and the client stub class.If the client is an applet, these three classes must be available from the applet's home machine . The server system will need the server class, the remote object interface and implementation, and the server skeleton class.
Start the RMI registry . This only needs to be done once, not for each remote object. The current version of RMI requires this registry to be running on the same system as server.
Start the server . This step must be on the same machine as the registry of step c.
Start the client. This step can be done on an arbitrary machine.
CHAPTER 4 TABLES
Table 4.1 USER TABLE
FIELD DATATYPE CONSTRAINTS
Username Varchar
Password Varchar Primary Key
This table stores the details of the users ie the username and the password which is used to identify each of the clients.
Table 4.2 RESOURCE TABLE
FIELD DATATYPE CONSTRAINTS
System IP Varchar Primary Key
Resource Varchar
Path Varchar
This table stores the details of those resources that each authorized client could submit to the server.
CHAPTER 5
CHAPTER 6
CONCLUSION
Cross platform is a novel concept which is being used widely in many areas like Local Area Network, Wireless networking etc. As more computers are added to the network which supports different platforms cross platform tools become increasingly useful. These tools need to be shared to utilize them thoroughly. Thus cross platform software that enables the users of a network to share cross platform tools tends to be of great use. This is where we think the relevance of our project lies. Also the resources which are placed in sharable drives can be accessed in much lesser time if they too are registered.In the years to come Local Area Network is likely to support faster data rates, hence the Local Area Networks would serve numerous functionalities. Therefore the tools and soft wares employed would also have added capabilities. Also with the systems connected in the network supporting varied platforms to perform specialized tasks, interaction between the systems becomes a major issue. The tools and soft wares then need to be highly adaptable catering to the different cross platform tasks. The operating systems will be designed incorporating this aspect. So the software we have developed would be find importance in the future and may in turn pave way to develop much more complex cross platform tools.
RESUME
By our project we have accomplished the task of sharing cross platform tools in a Local Area Network. All clients with authorized permission which is provided by the system administrator can log on .Each of the clients in the network have to register with the server by providing the necessary details of the respective resources. The server keeps track of the resources in the network and updates the details of the resources when the respective clients attempts to do so. Each of the registered clients can view the other clients and their corresponding resources in the network
When a client invokes a particular resource in a network, the server with the help of the System Internet Protocol Address (IP) identifies the client which possesses the invoked resource .Depending on the fact whether the invoked resource is a software or a hardware and in the case of software resource taking into consideration the file extension , the request is processed.
As a future enhancement of our project includes auto detecting the cross platform tools saved in the system. The software then registers the cross platform tools with the server Internet Protocol Address of the server which is provided by the system administrator .Changes regarding the details of the resources is made by the server on request from the client. If a client wishes not to share a resource, the resource details can be deleted from the database that resides at the server.
REFERENCES
1. Herbert Schildt (2005) 'Java: The Complete Reference,J2SE 5 Edition'
2. sun.com
3. mysql.com
4. wikipedia.com
5. linux.org