Package gnu.cajo.utils


package gnu.cajo.utils
A set of common utilities used by either proxy, or server items. As a general rule, do not compile all of the utility classes blindly; rather jar any classes resulting from the compilation of the proxy or server applications. As a rule, a proxy hosting VM is not required to have these classes in its classpath; therefore, the ones used from this package by a proxy application must be included in the proxy's codebase jar file.

Fundamentally, there are two entities; clients and servers. A server is a Virtual Machine which, at a minimum, exports one item, meaning a remotely invokable object implementing the Invoke interface. A server can also provide proxies; i.e. mobile item interfaces, to the server's local item objects (exported or not), which run inside the client's runtime. A client is a VM that makes use of a server's items and proxies, but need not export any of its own. The architecture readily supports the possibility of hybrid client/server VMs. Each VM can export as many items as it wants.

Items can transparently connect to other items across, logical, virtual or physical separation. This package seeks to establish the following roles between items:

An item is a control element of a system, it performs three major tasks:

  • control system resources
  • monitor system operation
  • log system transactions
A proxy is a optional, item-specific, interface, designed to separate and manage the following functions:
  • user input validation and feedback
  • item output formatting and presentation
  • localization and internationalization
Any item instance can invoke a transpparently local/remote method invocation on another. The invocation may or may not carry inbound data, and may or may not result in a synchronous response of data. A remote method invocation may also initiate an asynchronous operation in the receiver, resulting in a subsequent callback invocation from the receiver back to the client, at a later time.

When the items are remote; the overall network structure looks something like this:


 --------------         --------------
|  Server VM   |       |  Client VM   |
|  ----------  | TCP   |  ----------  |
| | Item     | | links | | Proxy    | |
| |----------| |       | |----------| |
| | http     | |invalid input: '<'------| | codebase | |
| | callback | |invalid input: '<'------| | notify   | |
| | notify   | |------>| | callback | |
|  ----------  |       |  ----------  |
 --------------         --------------

Note: Each outgoing TCP link consumes a corresponding anonymous return link, so the following port consumption realities for a server VM must be considered:
  • Each item consumes 2 inbound ports permanently (http / callback)
  • Each item consumes 1 outbound short-term port per client (codebase)
  • Each item consumes 1 outbound session-term port per client (callback)
Therefore, it must be understood that since each connecting client will consume 2 dynamically allocated TCP ports, therefore no more than ~64k simultaneous clients could be served by one IP address; that is, assuming the host had no other servers. Therefore, for very high usage hosts, multiple physical machines, multiple network interfaces, or a multi-homed host, would become necessary.
  • Classes
    Class
    Description
    An optional base class for server objects.
    A standard abstract base class for proxy objects.
    The standard mechanism to send proxies, and other complex objects to remote VMs.
    These routines are used for server object construction.
     
    This class is used to instrument an object for invocation logging purposes.
    This class can listen for UDP multicasts over the network, as well as to send out UDP announcements.
    This class is used to avoid having to load proxies into the VM runtime of the proxy server.
    This class is used to transfer its internal proxy object as a zipped marshalled object (zedmob).