Capabilities & Requirements Architectural Pattern

This is the third pattern in an architectural pattern set. The first (Information Models) can be found here, the second (Policy) can be found here .


Provide a mechanism to reconcile the capabilities of a service with the requirements of a client. This in turn means that there must a mechanism to describe the capabilities of a service and the requirements of a client.


In any given environment there will be a population of entities that provide a similar but not identical service. For example different routers in a network may have different limits on the number of VPs they can provide. Some may be running different versions of an O/S with subtly different characteristics. Not all routers are made by Cisco(!). Different versions of a service may expose additional interfaces or use slightly different information models.

In the worst case clients would be hard-coded to expect specific variants. A slightly better solution is to summarize the capabilities of a service using a version number – in this case the actual capabilities are implicit in the version number. However this has the following problems:

  • A client has to be coded to understand the full set of version numbers that it may encounter in a service now or in the future.
  • Some features of a service may change in incompatible ways whilst others don't.
  • A client would not be able to communicate with a new service that happened to provide the capabilities that it required.


An explicit description of the capabilities of a service provides a more manageable and adaptable mechanism for a client to resolve its requirements of a service.

Similarly an explicit description of the requirements of a client allows either party, or even a third-party, to handle the reconciliation of capabilities with requirements.

The descriptions of the capabilities and requirements need not be provided directly by either party. One or both sets of definitions may be handled by a proxy or mediator. In fact in many cases this is extremely likely to be the case as there will be many systems and services that do not have an explicit capabilities and requirements interface.

Capabilities and requirements are defined in profiles. Typically a client or service profile defines:

Attributes These define a characteristic of the capability or requirement.
Capabilities These are collections of attributes that define a single distinct capability.
Requirements These are collections of attributes that define a single distinct requirement.
Reconciliation Policy This defines how a set of capabilities and requirements is reconciled to provide an acceptable match. For example if
Vocabulary This specifies the capability data model that this profile is using. It defines the set of allowable attributes, capabilities, requirements, policies and any rules that they have to follow. For example you may have a vocabulary for defining router capabilities, another for defining service capabilities another for defining end-user SLA requirements.

Vocabularies are defined using a vocabulary definition language that must allow the definition of the following:

  • Attribute types
  • Attribute values
  • Attribute value constraints
  • Composition rules
  • Extension points
  • Protocol
  • Extensibility

Preferably a standard representation should be used to encode every vocabulary.

The following actors are present:

Client The entity making a request
Service The entity fulfilling the request
CRProvider The entity providing the service Capabilities and the client Requirements
Reconciliation PDP The entity reconciling the capabilities with the requirements (a Policy Decision Point)

Their interaction is illustrated in the following diagram:

Note that the diagram shows logical entities, not physical entities. Thus in some scenarios the requirements are passed with the invocation, the capabilities and the reconciliation are provided by the service.


Network access involves the interaction of a large number of components all with differing capabilities and requirements. For example:

  1. An end-user has a set of capabilities and requirements that are determined by their SLA with their service provider.
  2. A content provider has a set of capabilities that they can offer users of their content and a set of requirements of the network.
  3. Network devices have a set of capabilities that can be used to shape traffic.

A requirement defines the constraints on the capabilities of other entities. For example a VOD service may require 10MB/s bandwidth.

So one possible use-case of this is that when a user chooses to access content a self-configuring network could reconcile all of the various capabilities of the entities involved with the requirements of the media stream being accessed..

Known Uses

  • UDDI
  • SIP
  • SASL
  • HTTP1.1 (Accept header)
  • RDF
  • JSR188
  • W3C CC/PP
  • Computational Grids (OGSA, Globus etc.).
  • Parlay

One Response to “Capabilities & Requirements Architectural Pattern”

  1. ATC Says:

    Hi, It seems you missed the example in the Reconciliation policies section in the Profiles table. I know this is an old entry, but it’s a good reference for arc.

Leave a Reply

Judge’s Random Ramblings