Near Term Stellation Architecture

This short paper is written as a follow-on to the proposals of Jim Wright regarding the separation of components within Stellation and the content of the interfaces between these components. This paper is presented at a higher level than Jim’s proposals and attempts to cover the full architecture of Stellation both as a standalone system and as integrated into the Eclipse IDE.

Architectural Overview

The diagram below shows a proposed component structure for Stellation. The structure is quite close to the existing Stellation structure except that it identifies separate components that are merged together in the current implementation.

Stellation Components

The following sections describe each of the Stellation components in the diagram and each of the interfaces between the components.

Stellation Client Manager

This component is the heart of the Stellation system. It provides access from the outside world to Stellation. It provides the conduit between a Stellation repository and a Stellation workspace. The primary interface into the client manager is IScmProject. The client manager communicates with the repository via the Stellation server and with the workspace via an interface to be defined. Essentially the client manager can be considered the controller in a MVC architecture where the client applications supply the views and the Stellation workspace provides the model. The client manager will communicate with the Stellation Server using the IScmAccessPoint interface.

Stellation Repository Manager

This component provides the implementation of the Eclipse team management facilities using a Stellation repository. It accesses the Stellation client manager via the IScmProject interface. It must completely insulate Eclipse from Stellation and vice-versa. This component is actually made up of a number of plug-ins as defined in the Eclipse Platform Plug-in Developer Guide.

Stellation Command Line Utility

Extracting the command line processing capabilities from the current workspace code will create this component. It will use the IScmProject interface to access the Stellation Client. It will have essentially the same functionality as the current command line utility with the following additions:

• Accept multiple commands as individual lines from stdin.
• Accept multiple commands as individual lines from a named file.

Options will persist until overridden or until all commands have been processed.

Stellation Workspace

This component manages the internal representation of a Stellation workspace. This representation is expressed in terms of the same objects i.e. the artifact objects that are used in the Stellation server and repository. It should specifically NOT tie itself to a particular implementation of a persistent workspace such as a file system. It should also allow the implementation of a variety of persistent Stellation workspaces. This component will contain the logic required to implement the workspace

Persistent Stellation Workspace

All persistent workspaces will be accessed through an interface that is yet to be defined. I believe that, at a minimum, the following workspace implementations will be required.

• A standalone workspace based on the current Stellation implementation. I would expect this workspace to be used primarily when Stellation is being used in stand-alone environments, or possibly with IDE’s other than Eclipse.
• It should be possible to use the Eclipse workspace as the Stellation workspace. In this case, Stellation workspace operations should be delegated to the Eclipse workspace. This option only makes sense if the user is using Stellation integrated with Eclipse.
• It should be possible to provide an Envy-like workspace implementation using a local Stellation repository. Having the repository local and private to the developer should go a long way to eliminating the operational problems encountered with network based implementations. Open source databases such as MySql and Firebird remove the financial obstacle to such an approach. Database replication added to the inherent transaction capabilities provided by databases provides a more reliable workspace environment. The ability to use conventional or Eclipse based workspaces in addition gives the flexibility to handle all situations.
  
  If this option is implemented it should be possible to make this an optional Eclipse workspace as well since Eclipse already allows for custom workspace implementations.

Stellation Server

The Stellation Server is implemented as a daemon process under Unix or as a Windows service under Windows. This implies that the current ability to run the client and server within a single process will be dropped. It handles the logic required to implement the Stellation command processing needed to handle the preparation of project metadata and content for storage in the repository. The server should be implemented without containing specific knowledge of any repository or even of repository type. If this is done, it will be easy in the future to provide alternate repository implementations using other technologies such as object-oriented databases, or even radically different repository technologies in the future. The work that Rodolfo Raya, Mark and Jonathan did on generalizing SQL table definitions provides a starting point for this effort.

Stellation Repository

This component will contain the repository specific logic required to store Stellation objects in a repository. It will be accessed only from a Stellation server through an interface that is not yet fully defined.

Stellation Interfaces

IScmProject

See Jim Wright’s description of this interface for details in the “Overview” and “Issues” issues documents in the org.eclipse.Stellation.scm.model/doc directory. This interface is the primary interface to Stellation from the outside world.