2.2.3
Model Serialisation
The principle of graphical representation lies at the core of UML. However, to be able to store and exchange UML models, a machine-readable serialisation format is required. UML 2 models are serialised in XMI according to the rules specified by the MOF 2.0 XMI Mapping Specification (see [OMG07]). In prac- tise, however, different tools implement different versions of this specification, or define their own format altogether.
With the introduction of the Eclipse Model Development Tools project (MDT) [Ecl10c], this field has seen some consolidation. The MDT project de- fines the complete UML2 meta-model based on the Eclipse Modelling Frame- work (EMF); many tools are now based on this model and thus use the same serialisation format. The UML2-EMF-XMI format of Eclipse can be written and read by the Eclipse UML2 tools, read and written by the Rational Software Architect [IBM09] modelling tool by IBM, and exported by many other tools, for example by MagicDraw [NoM10].
Figure 2.7: A UML Model and its Serialisation
An example of a serialisation of an UML2 activity diagram to EMF2-XMI is shown in figure 2.7. All tools presented in this thesis are based on this format. It is important to note that the UML2-EMF-XMI format does not include any layouting information, such that manual layouts (which are quite common) are lost during serialisation and deserialisation.
2.3
SoaML
One of the contributions of this thesis is adding the ability to model service- oriented systems with UML by extending and adapting UML elements to the SOA view. Although the focus of the extensions in this thesis is on the be- havioural part, behaviour can only be defined in the context of a system struc- ture. Thus, a way of modelling the static part of a SOA system in UML is required as well.
A first step into this direction has already been taken with the UML profile
SoaML [OMG09b], which is a draft OMG standard for describing the static
aspects of service-oriented systems in UML. Although SoaML is currently in beta status, the concepts are considered valid and stable enough to be included in this thesis. Nevertheless, the final version of SoaML might differ from the concepts presented here.
Structural service modelling in SoaML employs the basic UML mechanisms for modelling composite structures as introduced in the last section. SoaML adds several stereotypes to the elements present in composite structures, and defines several constraints on these elements. In the following, the SoaML con- cepts relevant for this thesis are presented.
2.3.1
Participants
In SoaML, the basic unit for implementing service functionality is aparticipant. A participant can represent people, organisations, or system components, and may offer or require any number of services. SoaML introduces the stereotype
Participant, which is used to tag UML components to indicate that the
component takes part in a SOA. A participant may be both a consumer and a provider of services, depending on the ports associated with the participant.
A SoaML participant may include UML ports, which are interaction points where services are provided or requested. Each of the ports of a participant is tagged with eitherServiceor Request. In the former case, the partic- ipant offers a service through this port, while in the second case, a service is requested on this port.
The behaviour of the provided services of a participant may be implemented by different means. The SoaML specification lists three possible ways of pro- viding such behaviour:
A first option is to implement eachprovided operation separately, i.e. by using an owned behaviour of the corresponding method. The behaviour may be realised by an interaction, activity, state machine, protocol state machine, or opaque behaviour.
A second action is through the means ofevent handling. Using this con- cept, a participant is active in the sense that it already contains running behaviour and is thus able to react to incoming events using actions such as AcceptCallAction.
The third options is delegation: A participant may also delegate incom- ing requests to inner parts in the composite structure. This allows for wrapping existing implementations, or for further decomposition.
The UML4SOA profile introduced in chapter 3 takes the second approach by providing workflows which are able to react to incoming events from the ports of the owning participant.
2.3. SOAML 33 SoaML defines another concept, theMessageType, which is relevant to this thesis. A message type is an extension of the UML meta-classesDataType andClass, and is used to represent information exchanged between participant requests and services. Message types may not contain operations or behaviours: The intention is to only allow data to be transported between services. Data can be represented through attributes and associations to other message types. SoaML requires that all input and output parameters of operations defined in the provided and required interfaces of service and request ports must be typed with either simple types or message types.
2.3.2
Services and Requests
Ports of SoaML participants tagged with Service or Request may be typed with a simple UML interface (in which case, no protocol is assigned to the port), or with aServiceInterface, which is another concept defined by SoaML. AServiceInterface, which is an extension of an UML class, specifies the responsibilities of both the participant to which the corresponding port is attached, and the communication partner which is connected to the port.
For service interfaces used as types of Service ports, the semantics is as expected from the UML: Interfaces implemented by the service interface are provided by the participant; thus, the behaviour of the participant must implement them and provide the corresponding functionality. Interfaces used
by the service interface arerequiredby the participant, thus, the communication partner must implement them and provide the corresponding functionality.
When usingRequest ports, this situation is inverse: Implemented op- erations of the service interface are requested by the participant, and must be implemented by the partner. To avoid having to create two service interfaces due to this problem, SoaML introduces the notion ofconjugation. In aRequest port, the provided and required interfaces of a port type are inverted, which means that the port uses the port type instead of implementing it.
Note that when using service interfaces, provided and required interfaces are not specified on the port but on the port type, and are derived in the port. Furthermore, the behavioural protocol observed at the port is also attached to the service interface. This will become important in chapter 3 with the definition of service protocols.
2.3.3
SoaML Meta-Model
The meta-model for the four new SoaML concepts introduced above — partici- pants, service ports, request ports, and service interfaces, is shown in figure 2.8. The figure shows how the Service and Request stereotypes are derived from the Port meta-class, and redefines the type of Port with the ServiceInterfacestereotype. The latter is an extension of the UML meta-
Figure 2.8: SoaML Meta-Model (Excerpt)
class Class. Furthermore, on the bottom, the stereotype Participant is shown as an extension of Component, and theDataType stereotype as an extension of bothClass andDataType.
2.3.4
Case Study
SoaML has been used to model the static part of the eUniversity case study introduced in chapter 1. The architecture makes use of all of the SoaML stereo- types introduced above and is shown in figure 2.9. Note that the port types are associated with the ports with a usage link stereotyped withtype; this is a convenience notation used to clarify the relationship between a port and its service interface and is not a UML or SoaML concept. The figure shows only one participant —ThesisManagement— which has twoServiceports and three Request ports. The service interfaces of theService ports both implement and use operations, while the service interfaces of the Request ports are simpler and only implement operations.
The types referenced in the composite structure are all message types, and are shown in figure 2.10.
2.3. SOAML 35
Figure 2.10: eUniversity Case Study: Data Types