Concept: Participant (SoaML)
The type of a provider and/or consumer of services. In the business domain a participant can be a person,
organization, or system. In the systems domain a participant can be a system, application, or component.
Relationships
Main Description

Usage:  "Participant" stereotypes UML Class, Component

A Participant represents some (possibly concrete) party or component that provides and/or consumes services. Participants can represent people, organizations, or systems that provide and/or use services. A Participant is a service provider if it offers a service. A Participant is a service consumer if it uses a service.  A Participant can both provide or consume any number of services. Service consumer and provider are roles Participants play.  A Participant can play the role of provider in some services and consumer in others.  Because most consumers and providers have both services and requests, Participant is used to model both.

Participants have ServicePoint and RequestPoint ports that are the interaction points where services are offered or consumed, respectively.

A Participant can have CollaborationUses that indicate what ServiceContracts and ServicesArchitectures it fulfills.  The parts of a Participant, its services and requests as well as other properties, can be bound to the roles they play in these services architectures. A concrete Participant can realize any number of "specification" Participants (see UML2.x specification keyword and specification components). The full scope of a SOA is realized when the relationship between Participants is described using a services architecture. A services architecture shows how Participants work together for a purpose, providing and using services.

Semantics

A Participant is an Agent, Person, Organization, Organizational Unit, or Component that provides and/or consumes services through its Service and Request points. It represents a component that (if not a specification or abstract) can be instantiated in some execution environment or organization and connected to other participants through ServiceChannels in order to provide its services. Participants might be organizations or individuals (at the business level) or system components or agents (at the I.T. level). A Participant implements each of its provided service operations. UML2 provides three possible ways a Participant can implement a service operation:

  1. Method: A provided service operation might be the specification of an ownedBehavior of the Participant. The ownedBehavior is the method of the operation. When the operation is invoked by some other participant through a ServiceChannel connecting its Request to this Participant's Service, the method is invoked and runs in order to provide the service.  Any Behavior, including Interaction, Activity, StateMachine, ProtocolStateMachine, or OpaqueBehavior, can be used as the method of an Operation.
  2. Event Handling: A Participant might have already-running ownedBehaviors. These behaviors can have forked threads of control and can contain AcceptEventActions or AcceptCallActions. An AcceptEventAction enables the Participant to respond to a triggered SignalEvent. An AcceptCallAction enables the Participant to respond to a CallEvent. These actions enable Participants to control when they are willing to respond to an event or service request. Contrast with the method approach for implementing a service operation, where the consumer determines when the method will be invoked.
  3. Delegation: A Participant can delegate a service to a service provided by one of its parts, or to a user. A part of a Participant can also delegate a Request to a Request of the containing Participant. This allows Participants to be composed of other Participants or components, and control what Services and Requests are exposed. Delegation is the pattern often used for legacy wrapping in services implementations.

SoaML does not constrain how a Particular participant implements its service operations. A single Participant can mix delegation, method behaviors, and accept event actions to implement its services. A Participant might also use different kinds of behavior to implement operations of the same service or interface provided through a service. Different concrete Participants can realize or subclass the responsibilities of an abstract participant.

More Information