A Service-Oriented Product Lines Implementation
Approach
R4ll Case Study: An Assessment on Technologies to Implement Core Assets in Service-Oriented Product Lines
The dynamicity of service-oriented applications implies on the services life cycle control,
since many of them are independent and need to be discovered at runtime throughout the network.
In this way, a service technology may be important to manage the services life
cycle and to map the SOA concepts down to the level of SPL practices.
Thus, the technology used for implementation should be analyzed as well as it can require additional
technological-specific concerns that may cause different measurable benefits, e.g., complexity,
modularity and understandability. For example, when services candidates handle specific variants
(depending on the feature type) it may affect how the service consumer will support
each variant, and must prepare the change according to the system requirements.
In order to understand and mitigate these issues, our research provides a quantitative case study
for comparing three technologies (OSGi, Apache Tuscany and JAX-WS) with the support of
variability mechanisms (Binding variants within services, Parameters and Strategy Pattern)
to implement core assets in a service-oriented product lines project. The case study presented was based on an initial development of a SPL in the domain of libraries,
herein named the Rental for All Software Factory (R4ll), which will be evolved in the future.
The R4ll was developed as part of a post graduate course at the Federal University of Pernambuco, Brazil.
The SPL project development involved all life cycle phases ranging from scoping to testing concerns.
For validation purposes, the architecture reference and the feature model of R4ll were analyzed and adapted
in order to support SOA concepts. The feature model was defined for capturing commonalities and variabilities
of the domain, which resulted in fifty-nine features, and sixteen variabilities could be identified as can
bee seen in the following Figure.
R4ll Overview
THe R4ll aims to develop of core assets to enable a rapid derivation of products. The project followed certain steps of the RIPLE (RiSE Product Line Engineering) process: RIPLE-RE as responsible for Requirements Engineering, RIPLE-DE responsible for the design of the product line, and finally the RIPLE-EM responsible for change management, embracing both engineering field, such as application. The implementation step was performed for this study purpose. Furthermore, it receives as inputs the artifacts generated by the RIPLE-RE and the RIPLE-DE, such as the domain features description, domain feature model and the architecture specification. The next pages will present the most important work products (artifacts) generated for this case study. In addition, as the goal of the case study was to compare the technologies aforementioned, we provide in the link below the entire code produced for each technology using the variability mechanisms to manage the variabilities considered.
| Previous | Next |