This post describes important issues related to service-oriented analysis and design that were identified with a systematic review on the area and also present our future work related to combining service-oriented architecture and software product line. This research is being performed at Cin/UFPE.
The aim of the systematic review was to analyze the existing service-oriented analysis and design approaches with the objective of understand and summarize evidences about analysis and design discipline, identify activities, key points, drawbacks and gaps.
After analyze the existing approaches, we could identify some gaps such as a lack of architecture documentation and concerns with reusability and other quality attributes. We also detected common activities such as service identification from business process and legacy applications, create a service inventory blueprint, service and components specification and realization strategy selection such as wrapper or develop a new service from scratch.
With the systematic review on service-oriented analysis and design approaches concluded and the problems identified on the existing service-oriented approach, together with a systematic review on domain design approaches, a software product line design process, David Parnas’ ideas and based on Attribute Driven Development, our mission is to develop an approach for service-oriented product line.
Service-oriented architecture and software product line share a common goal, both concepts focus on reusability which brings productivity gains, decreased development costs, reduce time to market, higher reliability, and competitive advantage [Soa and Spl conference].
SOA and SPL also need a well defined process to be adopted and reduce its risks as stated by Thomas Erl and Klaus Pohl. This is the main motivation for our research that intends to develop a unified process for service-oriented architecture and software product line.
However, some questions remain interesting for discursion: How to combine service-oriented architecture and software product line? How can components be substituted by services in software product line context? How to consider different organizations with its own business processes to develop a service-oriented architecture as a product regarding variability?
4 comments:
Flavio, in your study, could you identify any method (comprising guidelines, for instance) for SOA and PL development that has already been applied and experimented in an academic (or industrial) context?! If yes, how is your point of view on its (or their) effectiveness?!
Ivan, we have not found any approach regarding service-oriented architecture and product line in our systematic review. We have not considered the SPL terms in our search strings. However, we found an approach that considers service match and variability. There are other papers at http://www.sei.cmu.edu/productlines/SOAPL2008/ that provide information about service variability. I already read them, but they are not approaches and they have not been experimented in academy or industry.
Flavio, how is your feeling about in combine SOA with SPL? It will be better change components by services in SPL or try to create an SPL for a SOA? Until the moments I think it is easier to think in use services in SPL rather than use components in this mix of approaches on software development
Hernan, I think that's a good combination and depend on the quality attributes you are looking for, it is better to use SPL with services or SOA with principles of SPL such as variability.
Post a Comment