Since server applications vary widely in terms of requirements and architecture, it is impossible to design and build one environment which satisfies all users. As such, SST has been designed as a highly configurable toolkit or framework of components which are commonly needed when building distributed and server applications. As a developer, constructing new configurations of these components to specialize SST for the particular requirements of distributed application designs is a requirement.

These components fall in the following rough categories: Communications, Marshaling, Method Invocation and Remote Objects. The Communications components provide a transport-independent mechanism for the transfer of data from one machine to another. Marshaling describes the format of the transferred data and allows objects to be converted to bytes and vice versa. The Method Invocation classes provide functionality similar to remote procedure calls (RPC) and allow the specification of various message dispatch policies. SST's Remote Object Model supports references to remote objects. SST also provides a number of tools or tool extensions to assist in composing, monitoring and debugging programs using these components.

The basic execution model of SST involves invocation handlers, dispatchers, marshalers, and transports. These components are linked together in a manner that is depicted in the figure in Getting started with SST.

On detecting an attempt to send a message to a remote machine, the system asks an invocation handler to invoke the desired method on the desired machine. The handler asks its associated dispatcher for the best way to send the message. Having determined this the handler passes the message to its marshaler which converts the objects into a series of bytes. The handler then uses its transport to send the bytes to the machine hosting the object which is the receiver of the Smalltalk message.

A similar algorithm is followed on the receiving side. When the receiving system detects the arrival of an incoming message it passes the received bytes to an invocation handler for processing. The handler has its marshaler convert the bytes to objects (a Smalltalk message object). It then asks its dispatcher for the best way of handling the message. Having made all the correct preparations, the received message is sent to the intended receiver within the handler's running image and a result obtained.

The procedure for handling the return of the result is very similar to that of the original send. The only difference is that the dispatchers on either end may use somewhat different ways of handling the outgoing and incoming reply.

Each of the components involved in the handling of messages is implemented as a set of concrete Smalltalk classes. SST adopts a flexible configure-and-compose model in which you compose instances of these classes which are configured to satisfy a particular application's distributed/server computing needs. An aim is to minimize the amount of unneeded functionality in particular situations. Rather than providing one monolithic distributed/server class library, SST is broken into a number of discrete chunks which are loaded and used only as needed.

For example, if you decide that you will only be requiring message passing by value you do not need to load the infrastructure for remote references. If at some point you find that you do need remote references, the relevant components can be loaded and used with a minimum of disruption.

SST provides a number of commonly-used pre-configured components such as pass-by-reference/value marshalers, logical process invocation handlers, various transports, and object spaces which support transparent remote references. As a developer, you can start with these as a base and make incremental modifications to customize the distributed architectures you wish to create, rather than starting from scratch.