A Service-Oriented Product Lines Implementation Approach: SOPLE-IM
Introduction
Software reuse is a key factor for companies which intend to increase software productivity and improve quality,
as well as reduce the development cost and time to market. Thus, instead of develop everything from scratch,
it is better to reuse some assets that are common among the applications.
Currently, with the growth of software complexity and size,
the software maintenance and comprehension become a hard task. In addition,
flexibility is another important factor that affects reuse, since today, large enterprise
application packages are prevalent, leading to problems whenever a new system is introduced
or business needs requires changes in existing systems.
In this context, Software Product Lines (SPL) and Service-Orientation (SO) could be applied to meet these challenges.
In the context of software reuse, SPL explores commonality and variability among related products, while SO
is a way of developing service-based applications, which has in its roots the Service-Oriented Architecture (SOA).
SOA is a model with the support of designing, developing, deploying, and managing systems in which
services provide reusable business functionality. Furthermore, applications or other service consumers
are built using functionalities from available services, and, the SOA infrastructure enables the discovery,
composition, and invocation of services. The development of software product lines using software architectures and implementation supports
systematic planned reuse, high software flexibility and contract-based communication on the use of a
common, managed set of core assets for rapidly developing customized products for specific customers.
On the other hand, a SOA implementation exposes standard interfaces to make services available for
authorized service consumers to use in a variety of ways.
However, reasoning about how to combine both SPL and SOA concepts within variability implementation and
technological concerns become a challenging task. As a consequence, the challenges consist the implementation
activities that become more complex, since it is important to understand the variability mechanisms for
realizing variabilities in different levels of granularity at runtime (e.g.,components, services,
service-orchestrations), and feature types (e.g., alternative, optional, and OR-feature).
Consequently, it becomes more critical when these aspects are addressed
in a technology-specific way. For example, the need of mapping these aspects within the interaction and
life cycle of services, making the assembly of a product easier to perform. Therefore, when it comes
down to code there are some specific aspects that must be dealt by a method or process.
In this sense, the use of an appropriate approach is essential to make decisions on several
SOA quality attributes (well-defined interfaces, loose coupling, composability, among others)
and variability implementation concerns as aforementioned. Without it, these issues can hardly be mastered.