Stubs and Skeletons

What are stubs and skeletons? At times, it is easy to confuse what is intended when a software engineer refers to stubs and skeletons. If you have been confused in the past, you are not alone. The meaning of these terms differ depending on the context. Stubs and skeletons are primarily used in two contexts, 1. a software pattern and  2. distributed computing

Let’s start with the software pattern.

1. As a Software Pattern: Stubs and Skeletons

A stub is a simple implementation of a piece of functionality that is used in place of the real implementation. This is very useful when the real implementation is highly complex or when the real implementation is dependent on non-trivial resources e.g. a database. Stubs are highly effective when used in conjunction with testing. A stub can made to simulate the behavior of a complex system e.g. we can stub out simple in-memory database in place of the real relational database. These type of stub objects are often referred to as mock objects. Stubs can also be used to provide a temporary simple implementation for complex code to be written later.

As a software pattern, a skeleton can be thought of as a stub with no implementation. A skeleton is simple a piece of source code containing variables, constructors, methods, etc; all of which are empty! Skeletons are typically highly annotated. They provide an empty implementation describing how a specific piece of software is intended to be used. A programmer will use the skeleton as a blueprint for the his implementation..

2. Distributed Computing: Stubs and Skeletons:

In distributed computing, a stub refers to a client side representation of a server side object or resource.  The stub will contain logic to establish a stable communication channel with the server. The communication logic is never exposed to the via the stub. A stub, thus provides a simple means for client-side programmers to interact with the server side resource. In many cases, a stub may support a variety of communication protocols e.g. HTTP, TCP, SOAP, etc. These implementation details are never exposed through the stub, thus client-side programmers can simply change the communication protocol, simply by switching the stub‘s implementation. All existing code, that had interacted with the stub will not require any code change.

Typically, a stub is responsible for marhsaling client side data. This is the process converting the client side resource into a format that can be transmitted to the server via the desired communication channel.

In distributed computing, a skeleton is a server side representation of the server resource. It essentially wraps the server resource. It receives the communication from the stub, then invokes the appropriate operation on the ‘real’ server resource. Typically, a skeleton is responsible for unmarhsaling the stub’s request, invoking operations on the server side object appropriately, then marshaling a response back to the stub.

Thank you!