Server Smalltalk Guide : Java RMI support : Programming with RMI support : Configuring and starting RMI support
Configuring and starting RMI support
SstApplicationContext provides some methods for manipulating RMI-related objects.
rmiRepository
Answers the RMI typing repository associated with the receiver.
rmiNaming
Answers the RMI Naming service associated with the receiver.
createRmiNamingServiceAt: url
Creates, starts, and answers a context which runs an RMI naming service at the endpoint specified by @url. It is assumed that @url is local to the receiver. If a context/space related to @url already exists, that context is returned (unchanged).
createRmiContextNamed: contextName
Creates and sets up an instance of the receiver for RMI-based communications at 'rmi://'. The new context is called @contextName and contains a local space whose name is the printString of the endpoint started at 'rmi://'.
createRmiContextNamed: contextName at: location
Creates and sets up an instance of the receiver for RMI-based communications at @location. The new context is called @contextName and contains a local space whose name is the printString of @location (or @location itself if it is a string). This space has one handler whose endpoint is at @location.
shutDownRmiNamingServiceAt: location
Shuts down any RMI naming service running at @location.
rmiNaming returns a naming service object which responds to the standard Java naming (java.rmi.Naming) protocols. Creating a naming service (actually a class method) runs a Java-style naming service in your Smalltalk image. This service then is accessible to all hosts running RMI (those running Java or SST's RMI Support).
You can use any available RMI Naming service when using the SST RMI support facilities.
Setting up an RMI-enabled application context is very much the same as setting up normal SST contexts. In fact, for RMI it is generally not necessary to define the remote spaces with which you interact. This is done automatically whenever a new space is detected. The major differences are highlighted by the following example code:
self context
addSpace: #ping on: 'Ping' at: #('rmi://foo.com:2345');
setupFor: #ping using: SstSpaceConfiguration rmiProxyConfiguration;
rmiStartUpWith: self typeRepository
The code specifies a Java type repository and defines a space configuration which uses RMI remote references (rmiProxyConfiguration). This type repository must contain definitions for all the Java types you plan on using in your application. As discussed in Java type information, you can dynamically extend the repository if required.
When setting up an RMI-enabled context, keep in mind the following:
RMI-enabled application contexts must be started using rmiStartUpWith: as opposed to startUp. The repository provided can be nil, however.
Do not mix standard SST, IIOP, or RMI-based invocation handlers in the same application context. Doing so will have unknown but generally subtle and hard to debug side-effects.
There can be at most one handler per RMI-enabled application context.
The URL specified for the local space contains the host and port at which the RMI-enabled objects will appear to be living to other RMI-based systems.
Typically SST does not contain predefined invocation configurations as it is nearly impossible to predict what users will want. In the case of RMI however, there is a reasonably well-defined behavior which satisfies most users. Accordingly, SST provides a standard RMI invocation scheme, named rmi, as well as a transport named rmi. The declaration of these is in the SstRmiSupport class.
SST's RMI support also includes a new kind of URL which supports the format: 'rmi://host:port/<information>'. This is typically used in conjunction with the Naming service, where <information> is the name on which to operate.
Last modified date: 01/29/2015