Work Product (Artifact): Service Component
This artifact is intended for use in describing the realization of a service specification. A service component may provide the realization for one or more services by the realization of multiple service specifications. The set of model elements on the inside of the component represent the concrete realization of the structural, behavioral, and policy contract described by these service specifications.

Service Components are key to the development of a service-oriented solution as they provide the implementation of the services identified within the Artifact: Service Model.

The following people use the service component:

  • Implementers of the services, to describe the model elements that provide the behavioral implementation of the service.

The Service Component shall provide a complete encapsulation of its behavior and only expose those capabilities defined by the Service Specification. Where the Service Specification also includes behavioral specifications in the form of protocol state machines, interactions, or activities, the Service Component shall ensure the implementation complies with this behavior.

Container Artifact
RolesResponsible: Modified By:
Input ToMandatory: Optional:
  • None
  • None
Output From
Main Description

The Service Component is the primary realization artifact for services defined during Service Specification. In describing the realization of Subsystems during such specification activities patterns are used that facilitate the provision of both functional and non-functional requirements (example patterns are described in Guideline: Service Component Patterns).

The choice of implementation technologies for Service Components is not prescribed by this work product description; however the emerging Service Component Architecture (SCA) [1] , and related Service Data Objects (SDO) [2], standards are intended specifically to play this role and have already described bindings for different platforms and implementation technologies. The SCA specifications are also the subject of an open source reference implementation [3].


  1. Service Component Architecture Specifications
  2. Service Data Objects
  3. Apache Tuscany project
Representation OptionsUML Representation:

UML 2.0 Component, stereotyped as <<Service Component>>. Note that UML 2.0 does provide a stereotype, within the "Intermediate" profile, called <<service>>, however this is simply defined as a "A stateless, functional component (computes a value)" which does not convey the meaning implied by this model element.

Service Components represent the realization of Services identified in the Service Model and described by the Service Specification; however as the granularity of a service tends to be quite large a Service Component may be further decomposed into components or coarse-grained Design Classes within its implementation. It is likely therefore that different specific forms of service are required for this implementation. In particular during the Task: Document Service Realization Decisions patterns are identified that use the following additional stereotypes in addition to the use of standard component, classes and elements of the RUP Design Model:



UML Representation


icon facade stereotype on Class or Component. Used to denote the component acting as the facade for the implementation of the service; in general there is one facade component for each realized Service Specification.
icon mediator stereotype on Class or Component. Used in situations where there may be one or more implementations for a given service operation, the mediator is called by the facade to identify and call the correct implementation component.
icon data access stereotype on Class or Component. Used to denote a data access component, this component is responsible for the access and management of persistent data for the service implementation.

More Information