Frequently Asked Questions
| Welcome > | ||||||||||
| Services > | ||||||||||
| Jumping Beans® Framework > | ||||||||||
|
||||||||||
| Evaluation Software > | ||||||||||
| Partners > | ||||||||||
| Press > | ||||||||||
| About Us > |
General
What is Jumping Beans®?Jumping Beans® is a framework developed by Jumping Beans®, Inc. with which a developer may create jumping applications.
What is a jumping application?
A jumping application is just like an ordinary application, except that while it is running it can pick itself up and physically move to another computer on the network, and then resume execution.
Can a computer receive a jumping application even if the jumping application has never been installed on it?
Yes.
Once the jumping application has jumped to a new host, can that host then disconnect from the network?
Yes. Jumping Beans® does not require a connection in order to keep the jumping application running.
Must the receiving computer have some software loaded and running in order to receive the jumping applications?
Yes. The 143Kb Jumping Beans® daemon resides and runs on the receiving computer to facilitate receipt of the jumping applications and to enforce security after the jumping application arrives.
Can Jumping Beans® mobilize an existing application?
Yes. Jumping Beans®, Inc. has done this with several third-party applications.
Can Jumping Beans® move applications between different operating systems?
Yes, if it is a Java application. If it is not a Java application, the application developer should assess the appropriateness of the application for the target platform.
Security
What makes Jumping Beans® secure?Jumping Beans® has four layers of security:
-
Traditional Distributed Security: Jumping Beans® employs all of the standard security
techniques used in traditional distributed computing systems, such as digital signatures, encryption, passwords, audit logs,
ACLs, non-repudiation, replay prevention, etc. As part of this layer, Jumping Beans® has
patent-pending technology which gives it intelligence about when to issue a password challenge. With this technology, if a
PDA or laptop computer is lost or stolen, and the loss or theft is not detected, the system is still protected.
-
Multi-Jump Security: Each jumping application is trusted no more than the least trusted host it has visited in its
past. The system administrator can easily assign a level of trust to each host. This is a very fine-grained level of
trust.
-
Trusted Source: Jumping Beans® ensures the code executed by a jumping application
comes from a known trusted source, even if the jumping application was launched by an untrusted host, or if the jumping
application has visited an untrusted host. Jumping Beans®, Inc. has applied for patent
protection on this technology.
- Monitoring and Intervention: Through the Management and Security Console, the system administrator can track the activity in the entire Jumping Beans® system to help detect unwanted activity. In addition, the system administrator can control jumping applications to help prevent or stop unwanted activity.
The enabling feature of Jumping Beans® is its unique star architecture. In this architecture, each participating host communicates with only the Management and Security Console. This implies that each jumping application must pass through the Management and Security Console on each jump. This in turn allows the Management and Security Console to perform extensive security checks on each jumping application on every jump.
Couldn't a jumping application attack the Management and Security Console and thereby weaken the whole security system?
No. While on the Management and Security Console, the jumping application is treated as a BLOB. Jumping applications are never deserialized on the Management and Security Console.
If there is a rogue jumping application on the network, how will I know?
Three different ways:
-
Graphical Tracking: Using the monitoring and intervention capabilities of the Management and Security Console, it
is easy to discover what jumping applications are on the network and centrally control them.
-
Audit Logs: Each jumping application includes an indelible audit log. After each jump, that log is copied to the
Management and Security Console so that a hostile host cannot alter it, and so that a hostile jumping app cannot alter it.
- Callbacks: When a jumping application arrives on a host, Jumping Beans® uses callbacks to notify the resident host software of this event before the jumping application is allowed to execute. When Jumping Beans® makes a callback to the resident host software, the resident host software is given an opportunity to reject the jumping application or perform other security checks. This way, the resident host software can be aware of what jumping applications are present at all times, and can make its own security decisions.
Can a developer customize the security?
Yes. Jumping Beans® does not allow the developer to modify the existing security behavior, but a developer can add additional capabilities by inheriting from the Jumping Beans® security manager. All of the methods in the Jumping Beans® security manager are declared as final so that a developer cannot alter them and an administrator can be assured that the security system is properly implemented. However, a developer can extend the class and add additional security methods and rules.
Is the security difficult to manage?
No. Through the Management and Security Console, Jumping Beans® provides central security management so that an administrator at the console can edit Access Control Lists from a central location. Jumping Beans®' unique inheritance of client groups makes it very easy for the systems administrator to configure and manage many client groups.
Does Jumping Beans® protect the jumping software from attacks by the host?
Yes, to a degree. Jumping Beans®' advanced security will ensure that the code is restored to its correct state on each jump.
However, while the jumping application is executing on the host, there is no way to protect it from the host. Obviously, Jumping Beans® cannot protect the jumping application from physical events such as a hard drive crash. In fact, there is no way any software can force the host hardware to perform in any particular way.
Does Jumping Beans® use encryption to protect a jumping application?
Yes, to an extent. For editions of Jumping Beans® that support encryption, jumping applications are protected by encryption while in transit.
However, the jumping applications are not encrypted while they are on a host computer. At first glance, an encryption scheme might seem to be a good way to protect a jumping application from a hostile host. It would seem that the jumping application could be encrypted so that only the jumping application can access itself. However, in order to use the encrypted data either the resident host software or the jumping application would have to have a key, and a good hacker could get that key with little effort.
Can a jumping application encrypt data with a public key, and not decrypt it until it arrives at a safe host?
Yes. With this arrangement, the encrypted data would be unavailable to the jumping application until it reaches the safe host, which would have the private key. This is provided with the Java Cryptography Engine (JCE) in Java 1.2 and later.
Can Jumping Beans® get through firewalls in a secure way?
Yes. A gateway is available to facilitate communications between different Management and Security Consoles. For clients which are behind a firewall, the client can be configured to use polling, so that the connections always originate from the client, and so are allowed through the firewall. At this time, there is no gateway to facilitate communication between the clients and the Management and Security Console.
Jumping Beans® Design
How does Jumping Beans® provide centralized management?From the Management and Security Console, a system administrator can revoke, kill, and track jumping applications, and can configure the Jumping Beans® system.
Why does Jumping Beans® have a star architecture?
Two reasons: Security and central management.
On each jump, a jumping application must pass through the Management and Security Console. This allows the Management and Security Console to perform extensive security checks on each jumping application, on each jump.
The Management and Security Console also provides a point of centralized management. From the console, an administrator can monitor and configure the agencies and the jumping applications. There is no central location in a peer-to-peer arrangement.
What does the Jumping Beans® Management and Security Console do?
See the previous question.
Is a Jumping Beans® client actually a server?
This depends on how you define 'server'. If you define a 'server' as software which accepts and responds to requests coming through the network, then yes, the client is a 'server'. If you define a 'server' as the central software in a distributed system, then no, the client is not a 'server'.
Does Jumping Beans® support communication between jumping applications?
Yes. With Version 2.0 and later, the developer can make natural Java method calls to jumping applications, just like an ORB. Under the covers, Jumping Beans® will forward the method calls to the jumping application, whether it is in the local JVM or on a remote machine.
Jumping Beans® will even sort out contention if a jumping application is in transit when a method call is made to it. The method call will be delayed until the jumping application reaches its target. Similarly, if a jumping application is asked to dispatch to its next host, the dispatch will be delayed until all active method calls to it are finished.
Requirements
What are the requirements to make an application mobile?-
The application must be serializable. The developer may use the standard Java serialization mechanisms to implement
this.
This is not an absolute requirement. In the labs at Jumping Beans®, Inc. have successfully retro-actively mobilized many non-serializable programs by building a serializable wrapper around the non-serializable software.
-
The application must store and retrieve resources in a location-independent fashion. This is described in detail at the
Sun web site.
This is not strictly necessary, because resources can be retrieved by techniques which are application specific, but must be aware that the host environment can change. Additionally, resources can be retrieved in a mobility-aware fashion by techniques which are specific to Jumping Beans®.
-
The jumping application must be thread safe. Jumping Beans® is inherently
multi-threaded.
-
If the jumping application requires access to Jumping Beans® services, it must implement
MobileApp, which is a Java interface defined by Jumping Beans®, Inc.. This is
optional.
What are the requirements of the host computers?
-
It must have the Jumping Beans® client software (the "daemon") loaded. The Jumping
Beans® daemon must be registered with the Management and Security Console, and it must be running.
(Jumping Beans®' persistence allows a host to shut down and restart without difficulty, but Jumping
Beans® and the jumping applications cannot run unless its daemon is running.)
-
The 143 KB Jumping Beans® daemon will run on Personal Java or JRE Version 1.2 or later.
The Jumping Beans® daemon will run on a minimal implementation of Personal Java®, except that it requires these packages:- java.security
- java.util.zip
-
The computers hosting jumping applications must have a TCP-IP connection to the Management and Security Console. Jumping
Beans® is not particular about what type of TCP-IP connection is used; it can be fast or
slow.
-
The Management and Security Console requires J2SE Version 1.4.2 or later.
All features are included, and none are left out. Systems requiring a fast datastore can substitute a different persistence implementation which might result in a larger footprint.
I am using 802.11b with WEP on my LAN, but my field clients do not have any VPN. Can I mix clients that support encryption with clients that do not support encryption?
Yes. To do this, you must be using a Management and Security Console that supports encryption. Clients that do not have encrypted communications can interact with a Management and Security Console that supports encrypted communications.
How big is the full-featured client?
143 Kb.
Miscellaneous
Is Jumping Beans® a mobile agent framework?No. Jumping Beans® is focused strictly on mobility and security. However, Jumping Beans® would be an excellent framework on which to build a mobile agent system; an agent developer can focus on the application requirements, and not worry about the details of mobility and security.
Can a Jumping Beans® jumping application dispatch to a remote domain?
Yes. This is a new feature as of Version 2.0.
What is a 'Replaceable Persistence Subsystem'?
The core Jumping Beans® API has a persistence system which is defined entirely by Java interfaces. Any implementation of these interfaces can act as a persistence system for Jumping Beans®. A developer can provide a custom implementation of these Java interfaces, and thereby replace Jumping Bean's persistence system.
Different implementations of these interfaces are bundled with the Jumping Beans® API, so that a developer can use any of them. An ultra tight footprint implementation is bundled with the Jumping Beans® developer's kit.
If two different hosts implement different persistent subsystems, can they exchange jumping applications?
Yes. For transport, Jumping Beans® breaks down the jumping application into a canonical form, so that hosts can exchange jumping applications regardless of what persistence is being used.
How does Jumping Beans® handle distributed garbage collection?
The star architecture of Jumping Beans® eliminates the need for distributed garbage collection. Jumping Beans® uses natural Java life cycle mechanisms.