OCSelot
- A Lightweight Java Middleware
receives requests from clients and executes them by invoking methods on subjects and subject classes and by creating subjects on behalf of client-side proxies.
Servers in the OCSelot system are instances of class OCSServer.
To create a server instance, the class method OCSServer.createInstance() is used.
Just as clients, instances of OCSServer are kept in their class and can be accessed using their name at any time. There may be several server instances in a process.
There can be servers working in remote mode, using the network, and servers working in local mode, where they are referenced directly by clients and passed in data without network.
To create and start a remote server, call something like
OCSServer server=OCSServer.createInstance(23229,"server"); server.start();
See the API documentation for details.
You can also start the server from the command-line, and typically this will be what you do.
The power of the OCSelot class proxy, namely to generate its subject on its own, and the option to install subjects on the server using OCSServerUserInterface allows to start servers quite empty and unspecified.
It can be left entirely to the clients to determine what particular use to put servers to. (But see below for how to set restrictions on the server.)
The command-line allows to fully parameterize the server. See the API or simply run
java -cp ocs.jar tw.net.ocs.OCSServer
for all the details.
To create a server to be directly linked to a client, call
OCSServer server=OCSServer.createInstance(Server.LOCAL,"server");
and pass it to an OCSClient instance when that is created:
OCSClient.createInstance(server,"client",true);
Note that you don't need to start() a local server.
As with the client, the OCSServer class comes up equipped with a local instance. The local server instance is named "LOCAL" and referenced by its client counterpart.
Local servers are convenient in that they allow you to design and code local and remote versions of a program practically identically.
With a local server, you can still use proxies as you would in remote mode. The sole difference in the code will be the way clients and servers are instantiated.
Most of the time, when using class proxies to create subjects, the subjects are quietly created and hosted by the server and do require little attention.
The server provides methods to maintain subjects directly, however. You can add and remove subjects, check for subjects' existence, and retrieve information about them.
See the API for details.
OCSServer provides a number of ways to restrict access and operations. You can set these restriction through OCSServer methods and through options specified at the command line.
First of all, you can make sure that only a limited circle of clients is able to access the server, by specifying (patterns of) IP addresses of clients which should be allowed or forbidden to connect with the server.
Allowing and forbidding IPs can be combined to give you powerful, yet simple means to open the server for just the right clients. See the API for a description of how it works.
Also, you can require client authentication through passwords. You can set passwords for normal use of the server and, separately from that, for access to admin functions.
The server can be set to work in encrypting mode using the DES / DESede (TripleDES) algorithm. Simply specify an encryption key to make the server expect and return encrypted data.
By default, a server running in encrypting mode does not accept clients which send unencrypted requests. You can, however, configure the server in such a way that it allows both encrypting and non-encrypting clients. See the API for how that's done.
And you can specify the classes which the server should be allowed to host as subjects.
Since subjects can be installed on a server by purely using client-side methods, without any such class contraints set, the server can be put to virtually arbitrary uses.
You can call methods on a server instance from its associated OCSClient, using the interfaces OCSServerUserInterface and OCSServerAdminInterface, which declare user and administration methods of OCSServer, respectively.
Class OCSClient has methods that return objects which implement these interfaces and allow to invoke their methods on the associated server.
You may call both normal user and administrative functions, including the methods for subject maintenance. Using this feature, you can place a subject on the server from the client side without creating a class proxy.
Short digression for the technically minded: the objects returned by OCSClient.getServerUserProxy() and OCSClient.getServerAdminProxy() are ordinary interface proxies associated with the server, which for this purpose hosts itself as a subject ... a nice example of self reference, don't you think?
A server running at the command-line can be stopped by sending it a signal with Ctrl-C.
From inside a program, use method pleaseStop(), which can be called from the client using the OCSServerAdminInterface.
In addition, class OCSServer, just as OCSClient, allows to stop a remote server with a command-line call.
As always, please see the API for details.