Service design pattern

From ControlTier

Jump to: navigation, search

Contents

Intent

Problem

We want to control the runtime state of application services, but each service must be controlled through proprietary or operating specific interfaces, and often must be invoked differently depending on application environment context.

Discussion

While the Deployment type provides a standard interface and properties to manage the life cycle of a software configuration, it does not assume the software has runtime state. For example, imagine that following the installation and configuration of a Deployment, a file must be executed to start a long running process to handle requests. One would need to know how to check if the process was already running to avoid starting multiple processes which may cause undesirable conflicts. Likewise, if one had to shut down the service, one might need to consider what to do if the normal stop operation fails.

When one considers the common details and requirements for services they can be organized into different categories:

stop and check status of the service.

Because service implementations vary widely and do not present a consistent management interface, the administrator must often possess either intimate knowledge of the application code or operating system features to control a service's runtime state.

problem

Compounding the need to have a consistent approach to starting and stopping a wide variety of services, the administrator must also adjust for environmental differences; varying command line options or running commands in different directories.

A preferred option would be to define an abstraction that builds on the Deployment type which already includes support for coordinating the installation and configuration of a software component but to add to that, standard strategies for managing the runtime state of a service.

Using this model, a generic logical skeleton for starting up and shutting down a service can be embodied yet the details for interfacing with the underlying service executables and or operating system can be provided by classes derived from the generic abstraction.

solution

This approach is particularly useful because it separates the variant and invariant behavior, minimizing the amount of code to be written.

Structure

The Service type inherits the capabilities and relationships from Deployment incorporating startup and shutdown logic to the deployment update sequence.

structure

The essential service properties are:

Properties
NameDescription
startup-rankA value specifying a level relative to other services.

Example

The Service type defines an object that provides methods to manage the runtime state and deployment of a software service.

The diagram below describes the startup of an Apache web server managed via the Service abstraction. One can begin integrating the Service's procedural interfaces using the provided apachectl command. For example, startService can be defined as apachectl start and stopService as apachectl stop. But one might find themselves in the situation where they are unable to use the standard apachectl command due to the way Apache was installed or must be invoked. In these cases, the Service runtime state management commands can be defined to meet the specific needs yet the administrator can still rely on the standard management interfaces: Stop, Start and Status

example

Check List

  1. Identify the procedures for starting and stopping the application service
  2. Define the assertServiceIsUp, assertServiceIsDown, startService and stopService commands using the identified procedures.

Rules of Thumb

Commands

Service Commands Reference

assertServiceIsDown

Confirm the service process is down.

This command is invoked by #Stop, and is configured via the service-isdown-script attribute.

assertServiceIsUp

Confirm the service process is running.

This command is invoked by #Start and #Status, and should be configured via the service-isup-script attribute.

Prepare

Prepare the service for the update.

This workflow executes the Install command inherited from Deployment.

Restart

Restart the service process.

Runs the workflow:

  1. Stop
  2. Start

Start

Start the service process.

Runs the workflow:

  1. assertServiceIsUp

startService

Start the service process.

This command is invoked by #Start and should configured via the service-start-script attribute.

Status

Get the status of the service.

Runs the workflow:

  1. assertServiceIsUp

Stop

Stop the service process.

Runs the workflow:

  1. assertServiceIsDown

stopService

Stop the service process.

This command is invoked by #Stop and should be configured via the service-stop-script attribute.

Related Types

Supertype:

Links

Personal tools
Namespaces
Variants
Actions
Navigation
Communication
Development
Toolbox
Print/export