The Service-Definition Metamodel is one of the core composition structures of RobMoSys.

A Service allows interaction (i.e. regular exchange of information) between software components. A Service consists of service-properties (defined in an external metamodel) and a communication-pattern-usage. The communication-pattern-usage selects a certain Communication Pattern with a pattern-specific selection of according number of communicated data-structures (i.e.Communication Objects).

The service-definition is used as a base meta-model for component-definition and for service-architecture. The relation between these three service-related meta-models form a service triangle (see the example of a Service Triangle).

A service can be graphically represented as a port of a component (just like in UML). However, depending on the current role-specific view with an according level of abstraction, a service “port” can reveal additional details that are not visible (i.e. hidden/encapsulated) for another role. The more detailed view enrolls additional internal structures of the port and the port itself might appear as a block for that role (see figure below). This is a useful pattern to provide different levels of abstraction, each adequate for the according developer role (with certain responsibilities and concerns).

This pattern can be applied recursively, where the ports of the currently more detailed view can again contain additional internal structures (not visible for the current role). For instance, a the “external” port of a service (see orange block on the right in the figure below) provides sufficiently detailed and stable communication semantics between interacting components (defined through a selected Communication Pattern). Second, the “internal” port of a service provides a clear API towards implementation within a component (also defined as part of the Communication Pattern). Third, the “bottom” port of a service provides a generic middleware abstraction layer that allows using any general purpose communication middleware without affecting the communication semantics (see Communication Objects).

References:

• Christian Schlegel. “Navigation and Execution for Mobile Robots in Dynamic Environments: An Integrated Approach”. Dissertation. University of Ulm, 2004.PDF
• Christian Schlegel and Alex Lotz, “ACE/SmartSoft - Technical Details and Internals”, in Technical Report 2010/01, Hochschule Ulm, Germany, ISSN 1868-3452, 2010. PDF

See next:

• Component-Definition Metamodel

See also:

• Communication-Pattern Metamodel
• Communication-Object Metamodel
• Service Triangle
• Service Design View