Variability Modeling for Service Oriented Product Line Architectures 최경석

Content 2 Introduction Using SPL Concepts to model SOA variability Multiple view service variability model Multiple view service variability model relationships Feature to service architecture mapping Service variability meta-model Feature oriented service application derivation Conclusions

Introduction 3 SOA is the flexible building of IT solutions that can react to changing business requirements quickly and economically  In SOA, service providers are usually decoupled from service requesters, thus requesters and providers can change independently of each other  Service providers offer their services  Service requesters search and discover these services based on their business needs Existing SOA variability approaches do not address certain types of variability pertinent to SOA in a unified and platform-independent manner  In this paper, we introduce a multiple-view variability modeling approach  That addresses the variability considerations of SOA based on our SOA variability meta- modeling framework We follow a platform independent approach in which we combine SPL variability modeling concepts with SOA concepts  as represented in the newly released OMG standard SoaML

Using SPL Concepts to model SOA variability (1/2) 4 This section analyzes how SPL concepts can be used to model SOA variability  SOA variability modeling can benefit from SPL variability modeling techniques  The main goal of SPL is the reuse-driven development of SPL member applications by using reusable assets from all phases of the development life cycle  This goal is similar to the goal of SOA where flexible application development is a common theme  Service oriented systems can be modeled as service families SOA and SPL differ in the following ways:  In SPL, components are designed and implemented a priori and usually owned by the same developing organization, whereas in SOA, services are usually developed by external providers who are unaware of their clients

Using SPL Concepts to model SOA variability (2/2) 5 Existing research do not provide a treatment of multiple variability concerns in SOA in a unified framework  These papers mainly treats SOA variability issues in a platform specific way by focusing on Web Services Multiple view modeling approach for service oriented software product lines in which the unifying view is the feature model  Kruchten introduced the 4+1 view model of software architecture in which the use case view is the unifying view

Multiple view service variability model (1/5) 6 Each view of the multiple view model is depicted by a UML diagram that is extended by using stereotypes, which are a standard UML extension mechanism  each modeling element is depicted using two stereotypes, one to represent a SOA concept and the other to represent a SPL commonality/variability concept. Multiple view model  Service Contract View  Business Process View  Service Interface View  Feature Modeling View

Multiple view service variability model (2/5) 7 Service Contract View  This view models service contracts and service participants Service contracts are prescribed by collaborating organizations in order to govern and regulate their interactions Service contracts may include service interfaces, polices, and service level agreements

Multiple view service variability model (3/5) 8 Business Process View  This view models the workflow of business processes Participants may define internal business processes to conduct their business  A business process workflow is composed of a sequencing of activities use a UML Activity diagram for each business process assign it the stereotype >

Multiple view service variability model (4/5) 9 Service Interface View  This view models service interfaces Services expose their capabilities through service interfaces only Service interfaces describe the operations provided by services to service clients  To model service interfaces, we use SoaML’s ServiceInterface element which models the service interface concept in SOA ServiceInterface specifies provided and required interfaces by Participants. This element extends the UML Class element ServiceInterface categorized as kernel, optional, or variant

Multiple view service variability model (5/5) 10 Feature Modeling View  Multiple-view service variability modeling is difficult to get a complete picture of the variability in the service architecture because it is dispersed among the multiple views It is necessary to have one view that focuses entirely on variability and defines dependencies in this variability  Feature models are used to express and manage similarities and differences among different family members in a SPL Features are analyzed and categorized as common, optional, or alternative

Multiple view service variability model relationships (1/2) 11 The inter-view relationships among the elements of the service model described in the previous section  It enables us to analyze what happens in one view if a change happens in another view An SOA SPL has one or more ServiceContract elements  Ex) An E-Commerce SPL has Purchasing, Credit Checking, Inventory Ordering, and Sales Tax ServiceContract elements A ServiceContract element is associated with two or more Participant elements  a ServiceContract element defines the rules for participating entities in the SOA system Ex) The Purchasing ServiceContract is associated with the Buyer and Seller Participants.

Multiple view service variability model relationships (2/2) 12 A ServiceContract element contains one or more ServiceInterface elements  Ex) The Purchasing ServiceContract contains the Ordering Service ServiceInterface which is part of the Service Interface View Participant elements provide or require ServiceInterface elements  Participating entities only interact through interfaces to minimize coupling  Ex) The Tax Agency Participant provides the SalesTax ServiceInterface, while the Seller Participant requires the SalesTax ServiceInterface Participant elements define their own internal business processes Service activities require ServiceInterfaces  Ex) the Calculate Tax Activity requires a SalesTax ServiceInterface

Feature to service architecture mapping (1/2) 13 This section establish a mapping between features in the feature model and the relevant service modeling views in the service model Feature to ServiceContract View Mapping  A Feature is associated with one or more ServiceContract elements Ex) when feature Credit Rating is selected, the Credit Checking ServiceContract will be activated and enforced  A Feature is associated with one or more Participants Ex) when the Electronic Goods optional feature is selected, the ElectronicSupplier Participant participates in the InventoryOrdering ServiceContract

Feature to service architecture mapping (2/2) 14 Feature to BusinessProcess View Mapping  A Feature is associated with one or more Activities in the Participant’s BusinessProcess Ex) when the Discount optional feature is selected (Fig.a), the Calculate Discount Activity is added to the Order Fulfillment BusinessProcess (Fig.c) Feature to Service Interface View Mapping  A Feature is associated with one or more ServiceInterfaces Ex) if the Credit Rating optional feature is selected (Fig.a), the Seller Participant has to provide a new interface that can interact with a credit rating agency

Service variability meta-model 15

Feature oriented service application derivation (1/2) 16 Basic E-COMMERCE application  The table shows how each feature, in the feature model, is supported by SOA elements from the different views.

Feature oriented service application derivation (2/2) 17

Conclusions 18 We have introduced a multiple-view modeling approach that addresses service oriented variability concerns in a unified manner This approach has several benefits:  Facilitates variability modeling of service families in a platform independent way  The use of established SPL feature modeling to manage variability in SOA  It allows service providers and consumers to change independently of each other, since all variability is performed at the service contract or service interface level only Future Research  We will add an Interaction View to our model in order to model the coordination of service invocations  We are augmenting our meta-model with consistency rules (using OCL) to ensure the consistency within each view and among the multiple views  we are working on a tool prototype that automates the mapping of features in feature models to service elements in SOA environments  we plan to apply the concepts of our approach to SOA runtime dynamic adaptation

Proposal 19 Future Research 진행에 따른 뷰 개선안  SOA 환경에서 피쳐 모델을 서비스 요소로 매핑을 자동화하는 경우에 발생할 수 있는 문제점을 찾고 이를 바탕으로 기존의 뷰들을 개선할 수 있는 방안을 연구  런타임 시에 동적으로 적응하는 경우에 발생할 수 있는 문제점을 찾고 이를 바탕으로 기존의 뷰들를 개선할 수 있는 방안을 연구

20 Q & A