All objects in a distributed system need some notion of location. In SST, object spaces fill this role. All objects live within an object space. At their simplest an object space corresponds to a running Smalltalk image. The space itself has a name and all objects within it have an identifier that is unique within the space. These together form a unique object identifier. Object spaces use these identifiers to manage object identity between multiple running images.

Quite often distributed systems consist of a number of mostly distinct subsystems working together. In Smalltalk, it is often convenient to have these subsystems share the same running image. With one object space per image, the objects from one subsystem are managed together with those from another. This can cause problems if they share the infrastructure which makes distributed computing possible. Imagine, for example, one subsystem deciding that it has to restart its transport just as another was trying to send a message!

The solution is to have application-specific sets of infrastructure (object spaces, invocation handlers, and so on). In SST, application contexts provide a separate operating environment for distinct applications in the same image. Each context manages a single local object space and a list of perhaps many representations of remote spaces. It also manages all of the local communications mechanisms available to the application. Therefore, applications use contexts to manage and keep separate the SST resources they use. While not strictly controlled, communication between application contexts is not permitted.

Object spaces are known to each other by their accessible URLs. That is, the URLs identify the location of invocation handlers to which messages can be transmitted for processing. A URL is a combination of an invocation scheme configuration name, a transport name, and a transport-specific address.

The invocation scheme configuration name identifies an agreed upon high-level protocol which will be used to send and handle requests. The name identifies, for example, the type of marshaler used, the way requests are dispatched, and the like. The name is commonly application-specific.

The transport used is identified by a unique name (for example, tcp) which matches a known transport configuration. This configuration specifies both the mechanism and the wire-format of exchanged messages.

The form of a URL's address portion depends entirely on the requirements of the transport specified. The general form of a URL is: scheme:/transport/address. The ping-pong examples mentioned in this guide use schemes such as pingPongRef and tcp transports with standard host:port IP addresses. So a full URL looks like:

Further sections provide more detail on these concepts but this is sufficient to allow you to set up SST and run the examples.