Browse Prior Art Database

Method for agentless remote execution of Java applications

IP.com Disclosure Number: IPCOM000225219D
Publication Date: 2013-Jan-31
Document File: 5 page(s) / 64K

Publishing Venue

The IP.com Prior Art Database

Abstract

Method for agentless remote execution of Java applications that allows them to be executed remotely in the same way that they would be locally

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 32% of the total text.

Page 01 of 5

Method for agentless remote execution of Java applications

Java Runtime Environment (JRE) allows execution of a Java application within a Java Virtual Machine (JVM). In order to execute the application, the binary code of the application must be available to the JVM through a file system and it means that the binary code must be stored locally or must be available through a mounted file system. The user that starts the Java application must be able to execute the Java Application Launcher ("java [-options] class" command) on the machine where the JRE has been installed.

The problem occurs if the user wants to run a Java application remotely on any remote computer:


1) a valid JRE (version and vendor) must be installed on the remote computer


2) binary code of the application must exist on the remote computer,


3) all classes and libraries required by the Java application must exist on the remote computer.

The above steps can be carried out manually but they are time-consuming, require some additional technical knowledge from the user, and are not easy for automation if the application is intended to run on many different, heterogenous remote operating systems. For example, the problem appears when a developer wants to test his or her Java application on different OS platforms.

This article proposes a method for agentless remote execution of Java applications that allows them to be executed remotely in the same way that they would locally. Currently there is no method that would resolve the problem. A couple of solutions resolve the problem partially:


1) Microsoft Sysinternals' psexec tool allows to automatically copy and execute any Windows binary on a remote Windows system. The tool has some limitations:
- it does not take into account any dependencies of the binary. If the dependent libraries are not found on the remote Windows, the application will fail.
- it covers only Windows system
- it does not ensure a JRE on the remote computer.


2) scp, ssh - they are tools that can be used for secure file transfer and remote execution of commands. They have the same limitations as RXA but allow connecting only to remote computers with a running SSH Server. They do not support Windows systems without installed external software such as CygWIN, Tectia SSH Server, or MKS Toolkit.


3) Java Remote Method Invocation (RMI) is a mechanism that allows the invocation of a method on an object that exists in another JVM. It is rather a Java API than a stand alone tool. It also requires a JRE and remote Java object to exist on the remote computer.

The solution is less related to the idea than psexec, RXA, or scp/ssh but it allows to dynamically load dependent classes and libraries form a remote location when needed. It also requires developing RMI aware Java applications.

Currently in order to resolve the problem covered by the method, a couple of usually manual or semi-automatic steps would have to be done using different mechanisms and tools. The method...