Ports are interaction points of components. A component may execute operation calls via a port when it requires a service. When a component provides a service, a operation of a port is called when the service is invoked. In SW Designer, this abstraction is also used for data oriented ports, as calls are flexible and well handled by the underlying programming language. For instance, data consumption via polling might correspond to the call of an "getData" operation (component calls, required interface), consumption via push the call of an pushData operation (environment calls, provided interface).
From the user view point, the provision or use of a specific interface is an implementation aspect. Therefore, these two interfaces or not specified, but they are calculated or derived from two other port properties: its type and its <a href="portKind.html">kind</a>. For instance, a "PullConsumer" port kind could be used in conjunction with a data type and would define the "getData" operation above.
A port kind characterizes a port. Simple examples of port kinds are (1) the UseInterface and
ProvideInterface kinds which describe client/server ports and (2) PushPublisher which describe a data
publisher port for a given data type. In the first case, the port is typed with the interface that is
provided or required, in the second case, the port is typed with datatype.
</br>
Although it does not formally define its semantics, each port kind should be associated with a
description of the intention behind it. A port kind is always associated with a mapping rule
that describes which interface a port provides and/or requires when in function
of its type (and/or additional information, e.g. coming from a MARTE stereotype).
On the model level, a port kind is first a stereotyped class. In SW Designer, the associated mapping rule is defined defined by means of Java code. but this is mainly an implementation issue. Examples can be found in the plug-in org.eclipse.papyrus.designer.components.transformation.stdmappingRules.