Domain-Specific Languages for Service-Oriented Architectures: An Explorative Study [chapter]

Ernst Oberortner, Uwe Zdun, Schahram Dustdar
2008 Lecture Notes in Computer Science  
Domain-specific languages (DSLs) are an important software development approach for many service-oriented architectures (SOAs). They promise to model the various SOA concerns in a suitable way for the various technical and non-technical stakeholders of a SOA. However, so far the research on SOA DSLs concentrates on novel technical contributions, and not much evidence or counter-evidence for the claims associated to SOA DSLs has been provided. In this paper, we present a qualitative, explorative
more » ... study that provides an initial analysis of a number of such claims through a series of three prototyping experiments in which each experiment has developed, analyzed, and compared a set of DSLs for process-driven SOAs. Our result is to provide initial evidence for a number of popular claims about SOA DSLs which follow the model-driven software development (MDSD) approach, as well as a list of design trade-offs to be considered in the design decisions that must be made when developing a SOA DSL. Service-oriented Architectures (SOA) use platform-independent interfaces, or services, for performing business processes [7] . A SOA, in which services realize individual process steps or tasks, is called a process-driven SOA [27] . Process-driven SOAs deal with multiple concerns, such as orchestration of business processes, information in processes, collaboration between processes and services, data, transactions, humancomputer interaction, service deployment, and many more. Hence, many domains need to be considered. Furthermore, a SOA has different stakeholders, including various domain experts and technical experts [25] . Using Domain-Specific Languages (DSL) for SOAs, based on Model-driven Software Development (MDSD) [19, 8] , enables technical experts and domain experts to work at higher levels of abstraction compared to using technical interfaces, executable process models, or service interface descriptions, such as programming APIs, Business Process Execution Language (BPEL) code, or interfaces described in the Web Service Description Language (WSDL). Furthermore, MDSD can be used for separating concerns. Hence, the multiple concerns of process-driven SOAs can be modeled independently through MDSD. This paper presents an explorative study in which we developed a number of MDSD-based DSL prototypes, as well as a model-driven infrastructure to generate a running process-driven SOA from the models expressed in the DSLs. We present three experiments, in which we have focused on finding design decisions and/or trade-offs for developing model-driven DSLs. DSLs for domain experts (from now on called high-level DSL) and DSLs for technical experts (from now on called low-level DSL) were designed and developed. Two of our experiments deal with model-driven DSLs developed for process-driven SOAs, and the third one focuses on extending SOAs with Web user interfaces (UI), i.e., non-process-driven SOA concerns. An in-depth study of specific claims about model-driven DSLs for SOAs was conducted. The claims target on (1) a systematic development approach for model-driven DSLs for SOAs, (2) the multiple concerns of SOAs, (3) the different levels of abstraction presented to the different stakeholders, and (4) on providing facilities for extensions. An analysis of the claims was made for each experiment in order to collect evidences and counter-evidences for claims about model-driven DSLs for SOAs. Hence, our results aim to help in making design decisions and considering the relevant design trade-offs, when engineering a model-driven DSL for SOAs. This paper is organized as follows: Section 2 gives some background information on MDSD. Next, Section 3 describes our research method and discusses in detail the previously mentioned claims. Section 4 provides a description of our research experiments. The observations and results of the experiments are discussed in Section 5. Section 6 compares to related work. Finally, Section 7 concludes the paper.
doi:10.1007/978-3-540-89897-9_14 fatcat:ik65eyj7crgmzclusujz2wohk4