• No results found

specifications for Java, C++, BPEL, and PHP. As such, SCA does not include its own means of specifying service behaviour.

There are alsoplatform-dependent approaches to the specification of service behaviour. The first language which comes to mind is the Business Process Execution Language (BPEL) [OAS07], which is specific to the domain of Web Services as it is fundamentally based on WSDL. BPEL itself is not a graphical language; however, most BPEL modellers introduce proprietary graphical mod- elling elements to aid customers in the specification of BPEL processes, whose syntax is in fact defined in XML.

Another platform-specific language for service modelling is the jBPM Process Definition Language (JPDL) [JBo10]. jBPM is a business process management suite based on process descriptions which can directly be executed by a virtual machine. JPDL is a process language which allows the specification of busi- ness processes using the Java language; similar to activity diagrams, it takes a graph-based approach to the specification of control flows. JPDL programs are deployed on the JBoss jBMN server to execute.

UML4SOA differs from the above approaches by providing a platform-in- dependent, graphical modelling approach based on the Unified Modeling Lan- guage. Regarding SCA, UML4SOA models may be in fact be used with a num- ber of target languages including Java and BPEL to contribute components to systems based on the SCA.

3.6

Summary

This chapter has introduced the UML4SOA profile, a lightweight extension of the UML for modelling the behaviour and the protocols provided and required of participants in service-oriented architectures.

In section 3.1, we have discussed the need for an extension for service be- havioural modelling in the UML due to insufficient representation of key service concepts such as communicating actions, long-running transactions, and self- descriptions in activities and protocol state machines.

Section 3.2 has then introduced the UML4SOA meta-model and, subse- quently, the profile. According to the main aim of the definition of the UML4- SOA profile — minimalism and conciseness — we have defined additions to the UML for both activities and PrSMs, while reusing existing UML constructs such as structured activities, actions, and control structures such as fork or decision nodes.

This section has also discussed a lightweight data manipulation language for guards, actions, and pins in UML4SOA, which enables the modeller to stay on the same level of abstraction as in the rest of UML4SOA. Finally, in order to accommodate different usage scenarios of UML4SOA, the two dialects UML4- SOA/Open and UML4SOA/Strict have been introduced. The former focuses on maximum expressiveness and integration with existing UML constructs, while the latter adds a set of constraints for ensuring unambiguous models ready for

code generation and analysis.

Section 3.3 has shown a practical example of how to model with UML4SOA in the form of diagrams for the eUniversity case study introduced in chapter 1. More examples can be found in [EGK+10].

We have discussed tool support for modelling UML4SOA in different UML modelling tools in section 3.4. Finally, section 3.5 has discussed related work.

Chapter 4

The Service Meta-Model

The MDD4SOA approach to model-driven development of service-oriented ar- chitectures consists of three main components — modelling, analysis, and code generation. Before discussing analysis and code generation in the next two chapters, we take a step back to address the underlying structure of these three components: A meta-model for services.

The previous chapter has already introduced UML4SOA, a profile for spec- ifying SOA behaviour based on the UML. Together with parts of the UML and the SoaML profile referenced in chapter 2, UML4SOA defines a syntax for mod- elling SOA systems. This chapter refines this field with the introduction of the Service Meta-Model (SMM). The SMM is a generic, language- and platform- independent meta-model for describing the static, dynamic, and data handling aspects of a SOA system. It relates to the three main components of MDD4SOA as follows:

ˆ Taken together with the restrictions discussed in UML4SOA/Strict, the UML, SoaML, and UML4SOA form the concrete syntax for the SMM.

ˆ A semantics and corresponding formal analysis methods for the behavioural parts of the SMM allow evaluation of UML4SOA models, which will be discussed in chapter 5.

ˆ Model transformations based on the SMM enable code generation of UML- 4SOA models; in particular, we discuss transformations to actual exe- cutable code in Java and BPEL (chapter 6).

This chapter is structured as follows. First, we show how the individual parts presented in this thesis fit together based on the SMM (section 4.1). Sec- ond, we introduce the Service Meta-Model (SMM), detailing its design ideas (section 4.2). Finally, we conclude in section 4.3.

Published results: Results presented in this chapter are based on publications [MSK08a] and [MSK08b].

4.1

Overview

The three main contributions areas of MDD4SOA — modelling, analysis, and code generation — share a common idea of a service-oriented system. This chapter defines this common idea with the Service Meta-Model (SMM).

Before we introduce the SMM, it is important to understand how the SMM relates to UML4SOA, the formal semantics and analyses, and the transforma- tions to code. This is shown in figure 4.1.

Static Part Data

S e r v i c e M e t a - M o d e l ( S M M )

Web Services

Graphical Notation

SoaML/UML4SOA

Behaviour

MIO-based formal semantics

Java

Figure 4.1: Overview: The SMM and Related Artefacts

The figure shows the Service Meta-Model (SMM) in the middle, consisting of three parts — a static part (left) which describes the static structure of a SOA system, a data part (right) which contains constructs for assignments, variable declarations, and operations, and finally (middle) the behavioural part.

The SMM in general does not have any notation, graphical or otherwise. This part is played by the UML and the SoaML and UML4SOA profiles, which are displayed on top of the SMM. The SoaML profile has been introduced in chapter 2 and is used as the concrete syntax for modelling the static part of the SMM. The UML4SOA profile has been introduced in chapter 3 and is used as the concrete syntax for the behavioural and data parts of the SMM.

We have introduced two variants of UML4SOA: UML4SOA/Open, which is intended for maximum expressiveness and free modelling of SOA systems mainly

4.2. THE SERVICE META-MODEL 113