Architecture Guide

Copyright: 2010 University of Southampton, IT Innovation Centre

Introduction

Ting is a Service Oriented Architecture (SOA). There are three layers to the architecture:

  • The functional layer
  • The governance layer
  • The modelling layer

The functional layer

The basic object here is a functional service, which exposes a number of methods (or "operations") to its clients. An example of a service is an object that takes a stock symbol as an input and returns the current price of its shares. A client might be a desktop widget that uses the service to display the current value of a stock.

The governance layer

The clients and services in the functional layer are capable of operating by themselves. In this case, a human must be involved in deploying the service, offering it to clients, monitoring it, charging for it, and so on.

These tasks can be automated through the use of governance components. A physical server is set up by a system administrator and configured, and the governance components are permitted and requested to manage it. The governance components will:

  • Collect monitoring data from the service (for example, the service may report response times, the number of times it has been used, the number of failures, etc).
  • Monitor whether the server is up or down.
  • Offer the use of the service to potential customers, allowing them to agree an SLA (Service Level Agreement).
  • Deploy a new service instance on the server each time an SLA is agreed and give the customer access to it.
  • Monitor the customer's use of the service against the terms of the SLA.
  • Take actions automatically, according to a policy it is given, such as suspending the service if it is overused.

After agreeing the SLA and deploying the service instance, the governance layer operates asynchronously, observing the service and taking actions in response. If the governance components are shut down, the functional services continue to work autonomously until they are restored.

The governance layer also looks at the resources an organisation has available (i.e. resources which it is managing) and at commitments the organisation has to its customers through the SLAs that have been agreed. It may take actions in response to imbalances, such as withdrawing offers of SLAs when it doesn't have the resources to provide them.

The modelling layer

The modelling layer performs more sophisticated analysis of the origanisation's resources and relationships to detect more subtle problems. For example, if several functional services fail, analysis at this level might suggest a common cause (e.g. all the services that failed share a single network switch). Modelling can also detect potential failures (for example, that both the main functional service and the backup depend in turn on a third component), and thus cannot deliver the reliability required.

Details

A basic functional service

This UML class diagram shows a very simple service with a single operation (echo). Clients use the service to echo messages.

arch/client-server.png

The client and service objects may be running on different machines. If so, the implementation must preserve the key object-oriented semantics: EchoClient's reference to EchoService is necessary and sufficient for it to be able to invoke the service's methods.

A manageable service

To make a service manageable we typically add four features to it:

  • A factory for creating new service instances, so that we can give a different instance to each customer.
  • Monitoring and reporting features so see how it is being used and how it is performing.
  • Management properties, allowing the service to be suspended or reconfigured.
  • Access control, allowing us to delegate some of our access to the service.

Strictly speaking, all of these features are optional:

  • A server may only be able to host a limited number of services, and that limit may be 1.
  • Even if a service reports no statistics itself, the governance components can monitor whether it is up or down.
  • A service without management properties can be managed manually by a human.
  • If a service has no management properties, it is possible to use it without access control either.

A more typical service looks like this (note: not all methods are shown):

arch/manageable.png

Notice that the client no longer has a reference directly to the service. Instead, we use the AccessControl feature to create an Authorisation which proxies calls to some subset of the methods. The Authorisation also implements the AccessControl interface, allowing the client to extend the delegation chain with more proxies. See the Security page for more details about this.

Exactly which methods are made available to the client is determined by the service's policy. It is common to allow the client access to some monitoring data, for example.

Finally, note that the factory may itself implement the management interfaces too.

The Resource Manager

The system above can be managed manually by the service administrator, or it can be registered with the governance components. To do this, a reference to the factory is given to the ResourceManager.

arch/resourcemanager.png

The resource manager represents each factory using a Resource object. It associates a policy and a capacity with each one.

The capacity is a model of what the resource is capable of providing (for example, the number of service instances it can support, or the total number of requests per day it can handle). It is like a mini-SLA between the factory and the governance components, and is written in the same language.

The policy says how to manage the resource. For example, it may say that if the average response time drops below 1 second then an alert should be sent.

The SLA Service

The SLA service is used to make offers to customers. Each offer takes the form of an SLATemplate. Someone in the client's organisation who is responsible for procurement will look at the terms and agree an SLA with the provider.

Although an SLA is legally a document, we use the term here to refer to an object hosted within the SLA service. When an SLA is agreed, the ResourceManager is used to find a factory capable of creating a service instance that can meet the terms of the SLA and this factory is used to create a new service instance.

arch/slaservice.png

The procurement actor uses the SLA to get (an authorisation proxy to) the service instance, and places both in the client organisation's registry. Client applications, such as the EchoClient can then discover and use the service. They find it by matching on the terms of the SLA.

The SLA object monitors the service to ensure that it is meeting the terms that were offered, and to decide how much to charge the customer for their use of it. The SLA object uses the template's policy to take management actions, such as suspending the service if the client over-uses it.

The Service Manager

The SLAService knows what commitments it has made to customers. The ResourceManager knows what capacity it has available. The ServiceManager compares the organisation's commitments and capacity to ensure that it can meet its obligations.

arch/servicemanager.png

The ServiceManager also looks at (aggregated) usage reports. It will:

  • Compare the commitments made to customers with the actual usage.
  • Compare the capacity available according to the resource manager with the capacity actually used.

Note

The Service Manager does not yet look at usage reports.

Workflows

Some service instances require the use of other services. That is, they act both as services and as clients. To avoid hard-coding the address of the services it needs, the service will typically use a registry to locate its dependencies at run-time. For example, the EchoService may want to add a time-stamp to the messages it echos:

arch/workflow.png

If the service indicates its requirements in the metadata it provides to the ResourceManager then the ResourceManager can ensure that a suitable service instance is available in the Registry:

arch/workflow-rm.png

Note

Currently, the ResourceManager always creates and registers one instance of every service it manages in the Registry. It should only register services needed by others.

External resources

You may have noticed that both service factories and SLAs provide a way of obtaining service instances, described by a set of terms. Indeed, an SLA can be registered with the ResourceManager in a similar way:

arch/external.png

Note

Design question: should we be registering SLAs or SLA templates?

Metadata and Ontologies

Each service needs to provide information describing itself, stating:

  • What the service does.
  • What metrics the service monitors and reports.
  • What other services this one depends on.
  • What management properties are available.
  • What roles are available for delegation.