SST is a large and complex framework. There is no simple recipe for success with SST, but here are some guidelines that may be helpful.

As with learning any framework of similar scope and flexibility, it is essential to have a clearly defined goal at the outset. Don't start building your mission critical distributed application as soon as you have loaded SST into your Smalltalk image. Select an archetype use-case of interest, and define a simple scenario. Define and implement a simple sample application.

To make quick progress and avoid becoming ensnarled in a web of unnecessary complexity, proceed in phases of increasing breadth and complexity. Build skeletal exploratory prototypes.

On a project with several developers, there can usefully be different areas of specialization. In particular, someone must play the role of SST Developer - the SST expert - while others will play the role of SST User.

The SST developer must have a broad awareness of SST components and features, and a deep knowledge of those which are selected as appropriate for the problem at hand. The SST Developer will likely build a certain amount of application-specific (or organization-specific) framework and tooling to expedite and simplify the use of SST by SST Users, enabling SST Users to focus on functional rather than architectural issues.

This section continues with an overview of remote object messaging in the Smalltalk-Smalltalk use case, for the remote procedure call computing model. (The infrastructure component interactions are similar, though generally more complex, when using the remote object invocation computing model.) This overview identifies and describes the key elements of the SST remote messaging infrastructure, and should be a valuable introduction to anyone unfamiliar with SST.

Readers interested in further detail on Smalltalk-Smalltalk with SST should proceed, after reading this section, to the following topics.

The key elements of an SST infrastructure include:

The figure below illustrates the roles of these components in a remote message send.

In the figure, a message is being sent from the upper system to an object in the lower system. The client application asks an invocation handler to invoke the desired request at the intended connection endpoint (#invoke:at:). The handler delegates to its dispatcher to employ the configured concurrency policy, delegates to its marshaler for conversion of the request object graph into a series of bytes to be sent to the remote image, and delegates to its transport for employing the native transport protocol to send the marshaled request to the remote endpoint and receieve a reply.

A similar algorithm is followed on the receiving side. A process started by the invocation handler makes use of its transport to read incoming bytes using the native transport protocol. The invocation handler then delegates to its marshaler for conversion of the sent bytes to a Smalltalk request, delegates to its dispatcher to employ the configured request handling concurrency policy, resolves the intended receiver of the request in its object space, and dispatches the request to this intended recipient object within the handler's running image.

The interactions for sending a reply are similar, but with the direction of the arrows reversed.

As it appears, the invocation handler is the core of the framework. It ties the SST mechanism together, and coordinates the activities of the marshaler, transport, and dispatcher components. Alternate behaviors are obtained by plugging different component configurations and strategies into a particular realization of the framework. For example, specifying an "immediate" dispatcher will cause incoming requests to be serialized on one Smaltalk process, whereas specifying a "pooled" dispatcher will enable incoming requests to be processed concurrently on individual dedicated processes.

The alternate SST infrastructure behaviors are typically orthogonal to the behavior of other components, and so can be mixed and matched freely. For example, the TCP transport can be used with both remote procedure call and remote object invocation computing models; with immediate dispatching or pooled dispatching.

Alternate behaviors are selected and customized through registered configuration objects. SST provides examples and defaults for these configurations, and in fact, most users are not likely to choose to customize the default component configuration.

SST's high degree of flexibility and configurability makes it quite powerful. Customizing the default configurations, however, is only recommended for advanced SST developers.