Mspl4soa

View project on GitHub

Introduction

The MSPL4SOA is a tool that combines the Multiple Sofware Product Line (MSPL) with the Service Oriented Architecture (SOA) paradigms. The goal of the tool is to design an MSPL that includes two dependent SPLs, named SPLSP and SPLSC, for respectively the Service Providers (SPs) and Service Consumers (SCs). These SPLs are used to generate valid and consistent SPs and SCs. The MSPL4SOA tool (see Figure 1) is mainly based on the Java EE technologies and the FAMILIAR tool (https://github.com/FAMILIAR-project/familiar-documentation). FAMILIAR is a recent tool which implements many composition (e.g., the merge by intersection) and decomposition (e.g., the slice operator) operators that can be applied to edit FMs. Our tool is composed of two generators allowing to generate customized, valid and consistent SPs and SCs, namely: `spgenerator` and `scgenerator`.

tool_site
Figure 1: Snapshots of our tool MSPL4SOA

The Feature Models of the Service Provider and Service Consumer

We propose to integrate in our tool practical FMSP and FMSC to handle the variability of SPLSP and SPLSC. These two FMs are respectively illustrated in the following figures.

fm_sp
Figure 2: Feature model FMSP
fm_sc
Figure 3: Feature model FMSC

Requirements

We provide here a pre-configured Eclipse version (http://www.jboss.org/products/devstudio/overview/) named JbdevStudio9.0 (996 Mo) that includes all the required technologies and configurations for our tool, such:

The `spgenerator` can be downloaded from here (175 Mo) and the `scgenerator` can be downloaded from here (159 Mo). In order to configure your Maven with our tool, please download the settings.xml file and copy it in the root of your m2 dir.

Getting started

We provide in the following two videos that explain how our aproach and tool work. The first video is a presentation that presents the proposed software product line for service oriented architecture. The second video presents the functionalities of the SP generator. The third video discusses the functionalities of the SC generator

Service provider generator

The SP generator, named `spgenerator`, is an implementation of the FMSC and thus responsible to generate customized SPs which are based on the Switchyard 2 ESB. The Switchyard 2 is a recent free software ESB developed by the Redhat company. It adopts in its implementation the Service Component Architecture (SCA) that provides a technology-neutral assembly capability allowing the composition of services which are developed using different technologies, such as: JMS (HornetQ), SOAP, REST and Apache Camel. These technologies have been integrated, on demand, in the generated SPs. The SCA also separates the development of the services from that of the communication technologies. The generated SPs can be deployed and executed in the server JBoss Enterprise Application Platform (EAP). We also integrate the FAMILIAR tool (https://github.com/FAMILIAR-project/familiar-documentation) in the SP generator to implement our update operator and to perform some other operations to edit FMs.

Service consumer generator

The SC generator, named `scgenerator`, consists of an implementation of the SPLSC that allows to generate customized SCs as standalone Java programs that invoke the capabilities offered by a generated SP. For this purpose, two main steps are required by the developer. In the first step, the SC developer gives to the SC generator as an input the host name of the SP (e.g., http://localhost:8080/sp_manager). The SC generator will then download, from this SP, the files fm_sc_update.fml. This file will be used to configure the SC generator by generating files like input and output classes of the SP capabilities. In the second step, the SC developer derives one or many am_sc_update.fml (i.e., AMSCupdate) from fm_sc_update.fml. Each AMSCupdate regroups the required features to invoke a certain capability. Afterwards, the SC generator will use the Apache Velocity tool to transform the fm_sc_update.fml, defined with the FAMILIAR language, to the source code of the required SC. For each fm_sc_update.fml, the generator generates a source code based on our Java API, that we propose in the following Figure.

SCGenerator scGenerator = new SCGenerator("./files/sp_manager/fm_sc_update.fml");
try {
	scGenerator.setAmFilePath("./files/sp_manager/am/am_sc_update.fml");
	scGenerator.start(); 
	// If the response handler feature in your am_sc_update.fml is asynchronous, then, the code here is executed in parallel with the capability invocation.
	scGenerator.stop(); 
} catch (SCGeneratorException e) { 
}
T result = (T) scGenerator.getResponse(); 
String state = scGenerator.getState();

The API is composed of, but not limited to, seven principle instructions that are required to execute an am_sc_update.fml. The first instruction (line 1) creates an instance of the class SCGenerator which takes as input the path of the file fm_sc_update.fml. The second instruction (line 3) sets the path of the file am_sc_update.fml. The third instruction (line 4) executes the am_sc_update.fml, i.e., it maps the features of am_sc_update.fml with the artifacts of SC. The fourth instruction (line 6) allows to stop the execution of am_sc_update.fml and release the resources (e.g., closing the MOM connections). The SC developer can integrate some source codes between the third and fourth instructions (line 5). This code will be executed in parallel with the capability invocation only if the feature Response handler presented in the am_sc_update.fml is asynchronous (see Figure 3). The fifth instruction (line 7) permits to handle the exceptions thrown in case of error in the execution of am_sc_update.fml (e.g., problem in the SP or am_sc_update.fml is not consistent with fm_sc_update.fml). The sixth and seventh instructions (lines 9 and 10) retrieve respectively the response and the state data (if any) of the capability. The letter T in line 11 will be replaced, by the SC generator, with the type of the response object.

Many advantages can be identified when using our API. It permits to use the same few lines of code to execute a given am_sc_update.fml independently of its features (e.g., SOAP, REST and MOM) and hides their implementation complexities. Hence, the SC developer does not require to work directly with the low level APIs of these features. Our API is designed to map the features of am_sc_update.fml with the artifacts of SC at runtime. This can be useful, as an instance, to reconfigure the SC at runtime in order to adapt to the SP changes.

Authors and Contributors