Setting up an application using object invocation also must create and install the relevant configurations, and create an application context. As discussed above, application contexts manage all the resources related to a particular user application. They also provide a separation between object spaces.

Consider the SstPingPongByReference example. To bootstrap the application, code similar to Pong's code shown below must be run in each participating image. Setup code can be done as an explicit application boot step or automatically during image startup.

This method lazily creates an application context and then adds two object spaces (#ping and #pong). When adding a space, you must supply a logical name for the image running the space and a set of URLs (or URL strings) describing how that space can be accessed. Each of these URLs represents an invocation handler as in the previous example.

After adding the spaces, the application context is initialized using setupFor:using: and specifying which space is the local space as well as the kind of object space (its configuration) to use locally. Note that more spaces can be added dynamically but as a minimum the local space must be specified before doing setupFor:using:. Finally, the context is started, which performs any final setup and starts all local invocation handlers.

There are some differences from the SstPingPongByValue worth noting. First, there is no need to explicitly export the example class. All Smalltalk globals are implictly exported. The bootstrap method below shows how to create a reference to a remote global (in this case, the example class) using the sstGlobalIn:context: API. Then an implicitly remote message is sent to the remote example class to create and cross-link the example objects. Note that the argument ping is automatically exported when it is passed to a remote space.

Since implicit remote messaging can be used, ping and pong messages can be sent directly to the remote example objects. For example: