The BackOnline Server is a fairly light-weight process in itself; however, as the number of clients accessing it increases, the system administrator might wish to reallocate system resources in one of various ways mentioned below in order to achieve maximum performance.
Note, the BackOnline Server can be configured to use any available port on the system, hence multiple BackOnline Server processes can be started on the same machine, each using a different configuration.
This configuration is one of the simplest ones, as a single machine is used to provide several services (web server, BackOnline Server, FTP, etc.).
This configuration uses a separate machine for web services and another for the BackOnline Server. In this configuration, the user initially connects to a web page which causes the applet to get downloaded via the web server. The applet then downloads it's configuration file (default: backonline.ini) which contains the name of the host the BackOnline Server is running on, and the port it is listening to on that host.
This configuration is similar to
configuration 2, except it routes different users to different
BackOnline Server either based on the user name/type or by the
load on the system (perhaps, for load balancing purposes).
Routing can be dynamically done by pointing to different applet
configuration files in the <APPLET> tag as shown here (note
the <APPLET> tag HTML can be dynamically generated via CGI
scripts):
<APPLET CODE=com.freeback.backonline.app.class width=650 height=500> <PARAM NAME=ConfigFile VALUE=backonline.ini> </APPLET>
The BackOnline Server uses an open architecture which allows any client application to use it for managing "streamed" objects. However, the server does require the client application to communicate with it using a certain protocol. To faciliate this communication, the BackOnline software comes with a Client Side API which can be used by custom Java applets and applications to store their application's data on the server.
Underneath the covers, the BackOnline Server is actually part of another product marketed by FreeBack, Incorporated known as UPstream. In fact, the BackOnline Server is actually the UPstream Server.
The UPstream framework provides a client side API to communicate with the UPstream server. Additionally, the UPstream server can also be extended to use data sources other the file system (default). For example, an application's data can be stored in a Relational Database System or an Object Database by easily "plugging in" custom server components as described below.
The following is a list of classes available for working in the UPstream framework:
The com.freeback.upstream.client.Request class is the main class for communicating with the UPstream server, the remaining classes are supporting or utility classes. For example, the com.freeback.upstream.client.ObjectPanel and ObjectDialog classes provide functionalities similar to the java.awt.FileDialog class. Click here to view TryUpstream.java, a sample program which uses most of the methods provided in the Request class.
To use the client side API, you must install the com.freeback.upstream.client and com.freeback.upstream.common Java packages in the appropriate location; these packages can be extracted from the backonline.jar file -- located in the backonline/client directory -- using the JDK JAR or a ZIP compatible utility (e.g. WinZip).
The UPstream Server can be extended via "pluggable" data classes which provide a custom implementation for storing and managing the data sent by UPstream Clients. For example, the data can be stored in a relational database instead of the file system.
To "plug-in" a custom data class, the user must create a Java class which implements all the methods specified in the com.freeback.upstream.server.DataInterface Java "interface". This Java class must be placed in a directory where it can be found and loaded by the server.
To cause the server to use the custom DataInterface* class, the setServerDataInterface method can be called in the com.freeback.upstream.client.Request class to set the class name. Optionally, the DataInterfaceClassName parameter can be specified in the server's configuration file to use a given class by default.
Copyright © Visual Patterns, Inc. All rights reserved.