Product Lines for Service Oriented Applications - PL for SOA

L. K ov acs, R.Pugliese, and F . T iezzi (Eds.): W orkshop on Automated Specification and V erification of W eb Systems (WWV 2011) EPTCS 61, 2011, pp. 34–48, doi:10.4204 / EPTCS.61.3 c  M.H. ter Beek, S. Gnesi & M.N. Njima This work is licensed under the Creativ e Commons Attribution License. Pr oduct Lines f or Service Oriented A pplications - PL f or SO A Maurice H. ter Beek Stefania Gnesi Istituto di Scienza e T ecnologie dell’Informazione, ISTI–CNR Pisa, Italy { maurice.terbeek,stefania.gnesi } @isti.cnr.it Mercy N. Njima IMT Institute for Advanced Studies Lucca Lucca, Italy mercy.njima@imtlucca.it PL for SO A proposes, formally , a software engineering methodology , de velopment techniques and support tools for the provision of service product lines. W e propose rigorous modeling techniques for the specification and verification of formal notations and languages for service computing with inclinations of variability . Through these cutting-edge technologies, increased lev els of flexibility and adaptivity can be achie ved. This will in v olve dev eloping semantics of v ariability over behavioural models of services. Such tools will assist organizations to plan, optimize and control the quality of software service provision, both at design and at run time by making it possible to develop flexible and cost-e ff ecti ve software systems that support high levels of reuse. W e tackle this challenge from two le vels. W e use feature modeling from product line engineering and, from a services point of view , the orchestration language Orc. W e introduce the Smart Grid as the service product line to apply the techniques to. 1 Intr oduction Business en vironments command innov ation, increasingly shorter time-to-market and e ffi ciency . Product line technology , is increasingly finding its way to the softw are sector , allowing companies to sustain gro wth and achiev e market success [13]. Service-Oriented Architecture (SOA) has emerged as a standard-based computing model for de- signing, building and deploying flexible distrib uted software applications. SO A emphasizes extremely loosely-coupled design approaches where disparate systems with di ff erent computing platforms can col- laborate and e v olve without major changes to their core architectures. Services are designed as self- contained modules that can be advertized, disco vered, composed and ne gotiated on demand. Software Product Lines (SPL) are families of softw are systems that share common functionality , but each member also has v ariable functionality . The main goal of SPL is the agile and speedy dev elopment of member systems by taking adv antage of reusable assets from all phases of the dev elopment life cycle. This goal is similar to SO A ’ s goals [1]. Despite the wide academic and industrial activities related to SOA, no systematic end-to-end method- ology exists to analyze and design service-oriented applications. On the other hand, SPL is an established field with considerable methodological support. It is then clear that combining SO A and SPL is a po w- erful way to b uild complex e v olving systems. The combination of SPL and SO A dev elopment practices is a new dev elopment paradigm that can help provide the answers to the need for agility , versatility and economy . SO A and SPL approaches to software dev elopment share a common goal. The y both encourage an organization to reuse existing assets and capabilities rather than repeatedly redev eloping them for new systems. These approaches enable org anizations to capitalize on reuse to achiev e desired benefits such as productivity gains, decreased de velopment costs, improv ed time to market, higher reliability and competiti ve advantage. Their distinct goals may be stated as follo ws [14, 26, 27]: M.H. ter Beek, S. Gnesi & M.N. Njima 35 SO A T o enable the assembly , orchestration and maintenance of enterprise solutions to quickly react to changing business requirements. SPL T o systematically capture and e xploit commonality among a set of related systems while managing v ariations for specific customers or market segments. The goal of our research is to formally answer the question, ‘Ho w can the use of product line practices support service-oriented applications?’ SOA and SPL hav e their di ff erences and similarities and we are exploiting the similarities in order to naturally formalize SPL [20] and service-oriented applications [34]. This work is part of a longer-term research e ff ort to dev elop a PL for SO A formalisms. The paper introduces a first step towards this goal. W e have found an e xisting formalism for modeling variability in product lines that can be combined with a SO A calculus and thus create a PL for SO A formalism. Modeling variability in product families has been the subject of extensi v e study in the literature on SPL, especially that concerning feature modeling [12, 15, 23]. V ariability modeling addresses ho w to de- fine which features or components of a system are optional, alternativ e, mandatory , required or excluded; formal methods are then developed to show that a product belongs to a family , or to deriv e instead a prod- uct from a family , by means of a proper selection of the features or components. V ariability management is the ke y aspect that di ff erentiates SPL engineering from ‘con ventional’ softw are engineering. Labelled T ransition Systems (L TSs) hav e been used successfully to reason about system behaviour . Modal Transition Systems (MTSs) are an extension of L TSs that distinguish between mandatory , possible and unknown behaviour . MTSs have been studied for some time as a means for formally describing partial kno wledge of the intended behaviour of softw are systems [3]. MTSs hav e been proposed as a formal model for product families [19, 28], allowing one to embed in a single model the behaviour of a family of products that share the basic structure of states and transitions, transitions which can moreover be seen as mandatory or possible for the products of the family . In [16], the MTS concept was pushed to a more general form, allowing more precise modeling of the di ff erent kinds of v ariability that can typically be found in the definition of a product family . In [8], a temporal logic for modeling variability in product families was proposed by taking adv antage of the way in which deontic logic formalises concepts like violation, obligation, permission and prohi- bition, using MTSs as the underlying semantic model. In [9, 11], a model checker is presented based on a formal framework consisting of v a CTL (a v ariability and action-based branching-time temporal logic) with its natural interpretation structure (MTSs). Product deriv ation is defined inside the framew ork and logical formulae are used as v ariability constraints as well as behavioural properties to be verified for families and products alike. A first attempt to apply this tool to the analysis of variability in behavioural descriptions of families of services is presented in [10]. From a service orientation point of view , we believ e that Cook and Misra’ s Orc [33] will highlight the SPL aspects necessary to meet our goals. An operational semantics of Orc based on L TSs appears in [35]. Thus, it appears from a first glance that we can extend the L TS semantics of Orc to a semantics ov er MTSs and merge the di ff erent scopes of SOA and SPL creating a PL for SO A formalism. The formal definition of such a semantics is left for future work. The paper is structured as follo ws. In Section 2, we revie w some related work and some product line basics from a feature modeling perspective and present the orchestration language Orc and its usefulness. Section 3 combines ideas from product line engineering and the service-oriented concurrency calculus of Orc. Section 4 highlights the case study ov er which the tools are applied. W e conclude in Section 5 with some remarks on future work. 36 PL for SOA 2 Related W ork and Preliminaries V arious authors have contrib uted to the study of combining SOA and SPL practices and most are still in the preliminary stages of defining what SPL for SO A means: [1] presents a method to design service- oriented applications based on SPL principles by applying variability analysis techniques to W eb Ser- vices to design customized service-based applications. In [4, 36] the authors study the common problems relating to SOA and SPL approaches and propose ways of reconciling the two, while [5] demonstrates how model-driv en engineering can help with in- jecting a set of required commonalities and variability of a software product from a high-lev el business process design to the lower lev els of service use. T o realize the method and acti vities in volv ed, a supply chain management application is used. G ¨ unther et al. [21] propose a di ff erentiated dev elopment process for SPLs implementing a SO A. They use an extensi ve example of a web store to sho w ho w parts of this process can be solved technically with already de veloped methods for feature modeling and management using W eb Services. An approach to service identification methods is proposed in [22] to bridge the feature models of product lines and the business process models in service orientation and enables functions to be expressed as services. 2.1 Product Line Modeling As a first step we hav e used feature diagrams to model product lines. Feature diagrams are a family of popular modeling languages used for engineering requirements in SPL represented as the nodes of a tree, with the product family being the root and ha ving the follo wing features [23]: • optional features, may be present in a product only if their parent is present; • mandatory features, are present in a product if and only if their parent is present; • alternative features, are a set of features among which one and only one is present in a product if their parent is present. When additional constraints are added to a feature diagram, this results in a feature model. Constraints come in se veral fla vours and we consider the follo wing constraints: • r equir es is a unidirectional relation between two features indicating that the presence of one feature requires the presence of the other; • excludes is a bidirectional relation between two features indicating that the presence of either feature is incompatible with the presence of the other . 2.2 Service-Oriented Modeling Orc has prov ed to be a high-lev el language that makes the notoriously di ffi cult task of building distributed systems easier . It coordinates interactions among basic subsystems, called sites, by use of a small number of combinators. It allows integration of components and assumes that structured concurrent programs should be de veloped much lik e structured sequential programs, by decomposing a problem and combin- ing the solutions with the combinators. Orc permits structuring programs in a hierarchical manner , while permitting interactions among sub- systems in a controlled way [24]. The basis for its design is to allo w integration of components and is founded on the premise of combination. Thus, combinators are a very important part of the theory . M.H. ter Beek, S. Gnesi & M.N. Njima 37 An Orc program consists of a goal expression (either primiti v e or a combination of two expressions) and a set of definitions. The goal expression is ev aluated in order to run the program. The definitions are used in the goal and in other definitions. A component is generally called a service; Orc adopts the more neutral term site which is the most primiti ve Orc expression. It represents an external program and is said to publish a v alue when a value is returned in response to a call. Gi ven the formalism we are working on, we will not dwell on the Orc programming language but concentrate on the Orc calculus. 2.3 The Orc Calculus W e present the calculus informally in this paper . The Orc calculus is based on the e xecution of expres- sions. Expressions are built up recursi vely using Orc’ s concurrent combinators [25]. When executed, an Orc expression calls services and may publish values. Di ff erent ex ecutions of the same expression may hav e completely di ff erent behaviour; they may call di ff erent services, recei ve di ff erent responses from the same service and publish di ff erent values. Orc expressions use sites to refer to external services. A site may be implemented on the client’ s machine or on a remote machine. A site may provide any service; it could run sequential code, transform data, communicate with a W eb Service or be a proxy for interaction with a human user . A site call is defined as A ( x ), where A is a site name and x is a list of actual inputs. The following table lists the fundamental sites of Orc. if ( b ): Returns a v alue if b is true, and otherwise does not respond. Rtimer ( t ): Returns a value after exactly t , t > 0, time units. Signal (): Returns a v alue immediately . Same as if ( true ). 0: Blocks fore ver . Same as if ( false ). Though the Orc calculus itself contains no sites, for our purposes we consider another fundamental site which is essential to writing useful computations. The site let is the identity site; when passed one argument, it publishes that ar gument, and when passed multiple ar guments it publishes them as a tuple. Orc has four combinators to compose expressions: the parallel combinator | , the sequential combina- tor > x > , the asymmetric parallel combinator < x < , and the otherwise combinator ;. When composing expressions, the > x > combinator has the highest precedence, followed by | , then < x < and finally ; has the lo west precedence [25]. 1. The independent parallel combinator , ( A | B ), allows independent concurrent execution of A and B . The sites called by A and B indi vidually are called by ( A | B ) and the v alues published by A and B are published by ( A | B ). 2. The sequential combinator , ( A > x > B ), initiates a ne w instance of B for every value published by A whose value is bound to name x in that instance of B . The values published by ( A > x > B ) are all instances of those published by B . If x is not used in B , this combinator is abbreviated by ( A  B ). 3. The asymmetric parallel combinator , ( A < x < B ), ev aluates A and B independently , b ut the site calls in A that depend on x are suspended until x is bound to a value; the first value from B is bound to x , e v aluation of B is then terminated and suspended calls in A are resumed; the v alues published by A are those published by ( A < x < B ). If x is not used in B , this combinator is abbre viated by ( A  B ). 38 PL for SOA 4. The otherwise combinator , ( A ; B ), e xecutes A and if it completes and has not published any values, then e xecutes B . If A did publish one or more values, then B is ignored. The publications of ( A ; B ) are thus those of A if A publishes, or those of B otherwise [24]. 2.4 Modal T ransition Systems MTSs are now an accepted formal model for defining behavioural aspects of product families [3, 8 – 11, 16, 19, 28]. An MTS is an L TS with a distinction between may and must transitions, seen as optional or mandatory features for a family’ s products. For a gi v en product family , an MTS can model • its underlying behaviour , shared among all products, and • its variation points , di ff erentiating between products. An MTS cannot model advanced variability constraints regarding alternative features nor those regard- ing the r equir es and excludes inter-feature relations [8]. Such advanced variability constraints can be formalized by means of an associated set of logical formulae expressed in the variability and action- based branching-time temporal logic v a CTL (interpreted ov er MTSs) [9]. W e no w formally define MTSs and — to begin with — their underlying L TSs. Definition 2.1. An LTS is a quadruple ( Q , A , q , δ ) , with set Q of states, set A of actions, initial state q ∈ Q, and transition r elation δ ⊆ Q × A × Q. One may also write q a − → q 0 for ( q , a , q 0 ) ∈ δ .  In an MTS, transitions are defined to be possible ( may ) or mandatory ( must ). Definition 2.2. An MTS is a quintuple ( Q , A , q , δ  , δ ^ ) such that the quadruple ( Q , A , q , δ  ∪ δ ^ ) is an LTS, called its underlying LTS. An MTS has two tr ansition r elations: δ ^ ⊆ Q × A × Q is the may tr ansition r elation, e xpr essing possible tr ansitions, while δ  ⊆ Q × A × Q is the must transition r elation, e xpr essing mandatory transitions. By definition, δ  ⊆ δ ^ . One may also write q a − →  q 0 for ( q , a , q 0 ) ∈ δ  and q a − → ^ q 0 for ( q , a , q 0 ) ∈ δ ^ .  The inclusion δ  ⊆ δ ^ formalises that mandatory transitions must also be possible. Reasoning on the existence of transitions is thus like reasoning with a 3-v alued logic with the truth values true , false , and unknown : mandatory transitions ( δ  ) are true , possible b ut not mandatory transitions ( δ ^ \ δ  ) are unknown , and impossible transitions (( q , a , q 0 ) < δ  ∪ δ ^ ) are false . T o model feature model representations of product families as MTSs one thus needs a ‘translation’ from features to actions (not necessarily a one-to-one mapping) and the introduction of a behavioural relation (temporal ordering) among them. A family’ s products are then considered to di ff er w .r .t. the actions they are able to perform in any giv en state of the MTS. This means that the MTS of a product family has to accommodate all the possibilities desired for each deriv able product, predicating on the choices that make a product belong to that family . Figure 3 below is an example of an MTS: dashed arcs are used for the may transitions that are not must transitions ( δ ^ \ δ  ) and solid ones for must transitions ( δ  ). Gi ven an MTS description of a product family , an L TS describing a product is obtained by preserving at least all must transitions and turning some of the may transitions (that are not must transitions) into must transitions as well as removing all of the remaining may transitions. Definition 2.3. Let F = ( Q , A , q , δ  , δ ^ ) be an MTS specifying a pr oduct family . A set of products speci- fied as a set of LTSs { P i = ( Q i , A , q , δ i ) | i > 0 } is derived by considering each transition r elation δ i to be δ  ∪ R, with R ⊆ δ ^ , defined over a set of states Q i ⊆ Q, so that q ∈ Q i , and every q ∈ Q i is reac hable fr om q via transitions fr om δ i . M.H. ter Beek, S. Gnesi & M.N. Njima 39 Mor e precisely , we say that P i is a product of F , denoted by P i ` F , if and only if q i ` q, wher e q i ` q holds, for some q i ∈ Q i and q ∈ Q, if and only if: • whenever q a − →  q 0 , for some q 0 ∈ Q, then ∃ q 0 i ∈ Q i : q i a − → i q 0 i and q 0 i ` q 0 , and • whenever q i a − → i q 0 i , for some q 0 i ∈ Q i , then ∃ q 0 ∈ Q : q a − → ^ q 0 and q 0 i ` q 0 .  The products deriv ed in this way obviously might not satisfy the aforementioned advanced variability constraints that MTSs cannot model. Howe ver , as said before, v a CTL can be used to express those con- straints and [10] contains an algorithm to deri ve from an MTS all products that are valid w .r .t. constraints expressed in v a CTL. 3 Service-Oriented Pr oduct Line In order to model a service product line, we merge the feature modeling and Orc approaches. W e show here that the Orc calculus can be viewed from product line / feature modeling perspectiv e and, hence, the resulting calculus can su ffi ciently specify service-oriented product lines. W e believ e that the Orc com- binators can be gi ven a semantics over MTSs that would result in an almost one-to-one correspondence with the features and inter-feature relations of product f amilies: • The independent parallel combinator , ( A | B ), can be used to specify mandatory features. This is because there is no direct communication or interaction between these two computations and they are instantiated independently and in parallel. • The sequential combinator, ( A > x > B ), can be used to specify required features. This follo ws from the fact that B is never instantiated unless A publishes a value which is bound to x and utilized as input in B . Thus, B requires published values from A . • The asymmetric parallel combinator , ( A < x < B ), can specify optional features. Since both A and B are instantiated in parallel and those computations of A that require a v alue from B are suspended, this combinator may ignore the published v alue from B in order to incorporate optionality . • The otherwise combinator , ( A ; B ), can be used to specify e xcluding features especially when there is a preferred outcome or priority . It follo ws because the computation of either A or B means that the other cannot be instantiated or has already failed. W e do not see how to directly cater for the alternative features from the combinators. Ho wev er , we foresee the use of Orc’ s powerful composition of the combinators to reason about them. W e then intend to look at an alternativ e feature as a choice between two computations from which we let only one proceed. This is the essence of mutual exclusion. W e consider a product in which we choose feature M if A happens, while otherwise we choose N (i.e. if B happens). W e represent A and B as sites and M and N as expressions and use site fla g to record which of A and B responds first. if ( flag )  M | if ( ¬ flag )  N  flag ∈ ( A  let ( true )) | ( B  let ( false )) In the future, we plan to e xtend the L TS semantics of Orc to a semantics over MTSs to merge the di ff erent scopes of SO A and SPL and create a PL for SO A formalism. 40 PL for SOA 4 Case Study The ener gy utilities industry may be one of the last great technological frontiers, due to the fact that it has experienced little inno v ation ov er its lifespan and it is quickly approaching the end of its design life. Ho wev er , the utility industry is about to embark on a re v olutionary journe y: the Smart Grid. Utilities and information technology companies will be surrounding the electric grid with a digital grid that will provide consumers and b usinesses with many v alue propositions [17]. One of the key components to this ‘smart’ electric grid is the upgrade to a two-way communica- tions technology . This technology , partially fueled by governments supporting the modernization of the electric grid, requires one of the lar gest IT ‘upgrades’ that we will see in decades, and pro vides ne w prod- uct, service and market opportunities for utilities, generators, power traders and information technology companies [2]. W e hav e a long way to go to turn this antiquated grid into a Smart Grid. Howe ver , using SO As which lead to decreasing the time to market we may be able to have a fast response to the market needs. The applications will entail a fast time-to-market response, correctness, reusability , maintainability , testability and e volv ability — besides lo w cost. Furthermore, like the Internet it will require a standard layered and distributed architecture in order to deli ver electricity o ver a two-way protocol from supplier to consumer utilizing independent components that must cooperate. SPLs and SO As can pro vide several of these requirements due to the inherent flexibility in composing more sophisticated comple x systems. Suppose that your utility company has de veloped an intelligent electrical power system that leverages increased use of communications and information technology in the generation, delivery and consump- tion of electrical energy . Y our company provides a choice among a family of products with di ff erent price tags and di ff erent functionalities. The basic architecture provides three products: 1. Inte gration of r enewables , o ff ering storage capacity , vehicle to grid and electric vehicles. 2. Demand r esponse , o ff ering e ffi cient markets, load shifting and incorporating all end users. 3. Grid monitoring management , o ff ering smart meters, self-healing capability and integrated com- munications. The coordination component uses predefined external services (one for each business sector) to retrieve a list of alternati ves, say for storage, load shifting or billing through the smart meters. The basic product can be enhanced in two ways: 1. Adding the possibility to choose what company to source your electricity and in case you hav e generation capacity , choosing whom you will sell your excess power to, from a set of utilities in order to retrie ve the best quotes through more than one service. 2. Adding the possibility for the user to make a reserv ation for the supply of extra electricity . This is accomplished by means of an added component that requests an external forecasting service to predict what sources of electricity generation are av ailable and ho w much demand e xists. These enhancements can be combined to obtain four di ff erent products of the family . A greater le vel of flexibility in the service may be added by incorporating dynamic roles. As the grid becomes more intelligent and more complex, the tools to operate it become increasingly important. Hence the need for interoperability (SO A), fle xibility and v ariability (SPL). Our interest in undertaking this case study lies in specifying electricity pro vision as a service and the Smart Grid as a service product line. M.H. ter Beek, S. Gnesi & M.N. Njima 41 4.1 The Smart Grid as a Product Line The generic Smart Grid will be modeled as a family of products with basic components for basic products and specialized properties for some of the products, such as: • storage; • renew ables, varying with weather , time, season and other intermittent e ff ects; • load shifting, the practice of managing electricity supply and demand so that peak energy use is shifted to o ff -peak periods; • vehicle to grid (V2G), establishing a viable transparent b usiness model, guaranteeing the av ailabil- ity and controllability of electric vehicles (EV) and V2G capacity as well as accurate forecasting of rene wable ener gy supply and demand. Load shifting and V2G can reduce the energy storage capacity required to maintain po wer quality . From the Smart Grid family in Figure 1 we can develop up to four di ff erent products, all the while utilizing the basic architecture. Similarly , giv en an MTS model of the Smart Grid family , we can use Definition 2.3 to deri ve products. SMART GRID GRID MONITORING MANAGEMENT DEMAND RESPONSE INTEGRATION OF RENEWABLES SELF HEALING SMART METERS INTEGRATED COMMUNICATIONS LOAD SHIFTING EFFICIENT MARKETS INCORPORATES CUSTOMER ELECTRIC VEHICLES STORAGE VEHICLE TO GRID Optional Alternative Requires Mandatory Figure 1: Feature model for the Smart Grid family One of the most obvious ones is a product without the integration of renewables, sho wn in Figure 2, which represents most of the e xisting electricity grids today and in which all the features are mandatory . This product contains a Demand Response component, referring to dynamic demand mechanisms to manage customer consumption of electricity in response to supply and the programs to achie v e that goal. From the utility company point of vie w , there is a virtual po wer plant where the supply of electricity is managed. In place are technologies that allow the utility to talk to devices inside the customer premise. They include such things as load control devices, smart thermostats and home energy consoles for sens- ing, so as to provide information to consumers and operators so that the y better understand consumption patterns and make informed decisions for more e ff ecti ve use of ener gy [30]. These are essential to allo w customers to reduce or shift their power use during peak demand periods. Demand response solutions play a k ey role in se v eral areas: pricing, emergency response, grid reliability , infrastructure planning and design, operations and deferral. 42 PL for SOA GRID MONITORING MANAGEMENT RESPONSE SELF HEALING SMART METERS INTEGRATED COMMUNICATIONS LOAD SHIFTING EFFICIENT MARKETS INCORPORATES CUSTOMER Mandatory DEMAND SMART GRID Figure 2: Feature model for a product without integration of rene w ables The part of the MTS model of the Smart Grid family which is relev ant for this component is shown in Figure 3. Virtual Power Plant High Supply Low Supply Aggregator Market Quantity Price Day ahead Realtime Buy Sell Equilibrium Load Shift Agreement Figure 3: MTS for the demand response function M.H. ter Beek, S. Gnesi & M.N. Njima 43 Thus, the three branches stemming out of the aggregator perform the follo wing functions: 1. O ff er flexible tari ff s including critical peak pricing and real-time pricing. 2. T wo-way communications allo w for pricing information to be transmitted to customers based on price changes each day and at timed intervals, determined by software at the enterprise level to allo w real time or day ahead management. 3. Exception pricing as well as price changes associated with system emergenc y conditions and quan- tity av ailable to enable the customer to either b uy or sell depending on their capacity . From this we can break down behaviour as shown in Figure 4, highlighting the behaviour of the system when supply of electricity is high, represented as: DRH : = { High Supply , Agreement , Sell , Equilibrium } This means that when the utility has excess supply of electricity , it will take advantage of existing agree- ments with their customers to sell and allo w the system to get back to a state of equilibrium. Virtual Power Plant Aggregator Market Equilibrium High Supply Sell Day ahead Pricing Load Shift Agreement Figure 4: A beha vioural description of demand response when supply is high 4.2 Encoding the Product Line in Or c The product demand response is realized in terms of service orchestration using the combinators as follo ws. From Figure 3, we model the two branches on the right. W e need to spawn two independent threads at a point in the computation in this case depending on whether we are load shifting or ex ecuting an existing agreement and resume the computation after both threads at the equilibrium point. Therefore, 44 PL for SOA we call sites ( r eal time | day ahead ) and ( sell | b uy ) in parallel and compose using the asymmetric parallel combinator . The call then publishes the values as a tuple after the y both complete their ex ecutions. DR : = let ( u , v ) < Load shi f t < ( r eal time | d ay ahead ) < Agr eement < ( sell | buy ) The v alues published by this expression are the v alues contained in site let , which acts as a container for the first result published and releases both when the second v alue is receiv ed. In the same way we can model the fact that these two features are alternati v es. This means that once we instantiate the computation Load shift we are not in a position to execute Agr eement and vice versa. W e therefore ha ve ( if ( f )  L s ) | ( if ( ¬ f ))  A  f ∈ (( r eal time | day ahead )  let ( true )) | (( buy | sell )  let ( false )) in which, due to restrictions in space, we ha ve used the following abbreviations: f for fla g (our container for the computation published first), L s for Load shift and A for Agr eement . As a start, we call L s and A in parallel by utilizing the independent parallel combinator and await for values published by either ( r eal time | day ahead ) or ( sell | buy ) to determine which of the computations is ex ecuted. The v alue published first by the asymmetric parallel combinator is held. The site if returns the value held in A if A is true, and otherwise does not respond and thus, completes the alternati ve service reasoning. Why Orc? The dynamic nature of this illustration highlights the dynamic nature of the various com- ponents and services of the Smart Grid, which is the main reason why we opted to work on the Orc calculus. Dynamic service, market management and pricing are basic building blocks of a Smart Grid system while Orc allows for the dynamic combination of services and the dynamic reconfiguration of software systems. The idea of in v oking a published service instead of dev eloping an isolated function leads a re volution of application dev elopment [29]. Thus, electricity business jobs can be arranged by orchestrating the services which can provide computation resources or functional support. 4.3 Semantics The semantics is operational, asynchronous, and based on L TSs [24]. W e show what this means for our case study . W e have ? k , which denotes an instance of a site call that has not yet returned a value, where k is a unique handle that identifies the call instance. The transition relation A a − → A , states that expression A may transition with event a to expression A . There are four kinds of ev ents, which we call base e vents: a , b ∈ BaseEvent :: = ! v | τ | M k ( v ) | k ? v A publication event, ! v , publishes a v alue v from an expression. As is traditional, τ denotes an internal e vent. The remaining two events, the site call ev ent M k ( v ) and the response ev ent k ? v , are discussed belo w . A site call M ( v ), in which v is a v alue, transitions to ? k with ev ent M k ( v ). The handle k connects a site call to a site return — a fresh handle is created for each call to identify that call instance. The resulting expression, ? k , represents a process that is blocked waiting for the response from the call. A site call occurs only when its parameters are values; in M ( x ), in which x is a v ariable, the call is blocked until x is defined. The composition rules are straightforward, except in some cases in which subexpressions publish v alues. M.H. ter Beek, S. Gnesi & M.N. Njima 45 Consider the independent parallel combinator ( A | B ). When A publishes a v alue ( A ! v − → A ), it creates a new instance of the right-hand side, [ v / x ] . B , the expression in which all free occurrences of x in B are replaced by v . The publication ! v is hidden, and the entire expression performs a τ action. Note that A and all instances of B are ex ecuted in parallel. Since the semantics is asynchronous, there is no guarantee that the values published by the first instance will precede the values of later instances. Instead, the v alues produced by all instances of B are interleav ed arbitrarily . Asymmetric parallel composition, ( A < x < B ), is similar to parallel composition, except when B publishes a value v . In this case, B terminates and x is bound to v in A . One subtlety of these rules is that A may contain both active and blocked subprocesses — any site call that uses x is blocked until B publishes. W e no w check one of our expressions: DR : = let ( u , v ) < Load shift < ( r eal time | day ahead ) < Agr eement < ( sell | buy ) An execution of DR is as follows: the first step ( sell | buy ) publishes sell or b uy , which is bound to Agr eement : [ sell / Agr eement ] . ( sell | buy ) or [ buy / Agr eement ] . ( sell | buy ) The same strategy is employed for the next step and we hav e an ev ent τ due to the site let as it receiv es one v alue before the other . 5 Conclusion and Futur e work Correct modeling of service product lines appears to be important — if not vital — in order for them to provide the same le v el of accurac y and support as their earlier counterparts, service-oriented applications and SPLs. W e hav e seen that Orc, being a language for orchestration at a moderately abstract level, provides important support for this. W e hav e proposed that services can be modeled in a new way by incorporating v ariability notions from SPLs. It is perhaps unexpected how direct the resulting reasoning is to v ariability in product family descriptions using feature modeling. This is due to the extent to which Orc captures the sequences of publications. W e ha ve not fully formalized service product lines, but the techniques and tools identified and the relationships established amongst them are a firm foundation for this. W e plan to extend Orc in order to support the abstract layer provided by the MTSs and to allow verification by means of the v a CTL logic. Feature models will remain our low-le v el representation of our service product lines. T o fully formalize and verify service product lines, we require that Orc has the capability to integrate the tools. W e also intend to extend the L TS-based semantics of Orc to an MTS-based semantics in order to utilize the v a CTL logic for verification. Acknowledgments W e thank the referees and participants of WWV 2011 for their useful comments before, during and after the workshop, which ha ve considerably impro ved this paper . 46 PL for SOA Refer ences [1] M. Abu-Matar (2007): T owar d a service-oriented analysis and design methodology for software pr oduct lines . http://www.ibm.com/developerworks/webservices/library/ar- soaspl/index.html . [2] R. Aldrich & G. Mellinge (2008): Cisco Ener gy Manag ement: A Case Study in Implementing En- er gy as a Service . http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps10195/ CiscoEMSWhitePaper.pdf . [3] A. Antonik, M. Huth, K.G. Larsen, U. Nyman & A. W aso wski (2008): 20 Years of modal and mixed specifi- cations . Bulletin of the EA TCS 95, pp. 94–129. [4] S. Apel, C. Kaestner & C. Lengauer (2008): Resear ch c hallenges in the tension between featur es and services . In: Proceedings 2nd International W orkshop on Systems Development in SOA Environments (SDSOA ’08) , A CM Press, pp. 53–58, doi:10.1145 / 1370916.1370930. [5] M. Asadi, B. Mohabbati, N. Kaviani, D. Ga ˇ sevi ´ c, M. Bo ˇ skovi ´ c & M. Hatala (2009): Model-driven de- velopment of families of Service-Oriented Ar chitectur es . In S. Apel, W .R. Cook, K. Czarnecki, C. K ¨ astner , N. Loughran & O. Nierstrasz, editors: Proceedings 1st International W orkshop on Feature-Oriented Software Dev elopment (FOSD’09) , ACM Press, pp. 95–102, doi:10.1145 / 1629716.1629735. [6] P . Asirelli, M. H. ter Beek, S. Gnesi & A. Fantechi (2009): Deontic Logics for Modeling Behavioural V ari- ability . In D. Bena vides, A. Metzger & U.W . Eisenecker , editors: Proceedings of the 3rd International W ork- shop on V ariability Modelling of Software-Intensi v e Systems (V aMoS’09) , ICB Research Report 29, Uni- versit ¨ at Duisbur g-Essen, pp. 71–76. http://www.vamos- workshop.net/proceedings/VaMoS_2009_ Proceedings.pdf . [7] P . Asirelli, M. H ter Beek, S. Gnesi & A. Fantechi (2010): A Deontic Logical F ramework for Modelling Pr oduct F amilies . In D. Bena vides, D.S. Batory & P . Gr ¨ unbacher , editors: Proceedings of the 4th In- ternational W orkshop on V ariability Modelling of Software-Intensiv e Systems (V aMoS’10) , ICB Research Report 37, Univ ersit ¨ at Duisburg-Essen, pp. 37–44. http://www.vamos- workshop.net/proceedings/ VaMoS_2010_Proceedings.pdf . [8] P . Asirelli, M.H. ter Beek, A. Fantechi & S. Gnesi (2010): A Logical F ramework to Deal with V ariability . In D. M ´ ery & S. Merz, editors: Proceedings of the 8th International Conference on Integrated Formal Methods (IFM’10) , Lecture Notes in Computer Science 6396, Springer-V erlag, pp. 43–58, doi:10.1007 / 978-3-642- 16265-7 5. [9] P . Asirelli, M.H. ter Beek, A. Fantechi & S. Gnesi (2011): A Model-Checking T ool for F amilies of Services . In R. Bruni & J. Dingel, editors: Proceedings 13th International Conference on F ormal Methods for Open Object-Based Distributed Systems and 31st International Conference on Formal T echniques for Networked and Distributed Systems (FMOODS / FOR TE’11) , Lecture Notes in Computer Science 6722, Springer-V erlag, pp. 44–58, doi:10.1007 / 978-3-642-21461-5 3. [10] P . Asirelli, M.H. ter Beek, A. Fantechi & S. Gnesi (2011): F ormal Description of V ariability in Pr oduct F amilies . In: Proceedings 15th International Software Product Line Conference (SPLC’11) , IEEE Computer Society Press. T o appear . [11] P . Asirelli, M.H. ter Beek, A. Fantechi, S. Gnesi & F . Mazzanti (2011): Design and V alidation of V ariability in Pr oduct Lines . In: Proceedings ICSE 2011 2nd International W orkshop on Product LinE Approaches in Software Engineering (PLEASE’11) , A CM Press, pp. 25–30, doi:10.1145 / 1985484.1985492. [12] D.S. Batory (2005): F eature models, gr ammars, and pr opositional formulas . In J. Obbink & K. Pohl, editors: Proceedings International Software Product Line Conference (SPLC’05) , Lecture Notes in Computer Science 3714, Springer-V erlag, pp. 7–20, doi:10.1007 / 11554844 3. [13] O. Bubak & H. Gomaa (2008): Applying softwar e pr oduct line concepts in service orienta- tion . International Journal of Intelligent Information and Database Systems 2(4), pp. 383–396, doi:10.1504 / IJIIDS.2008.021444. M.H. ter Beek, S. Gnesi & M.N. Njima 47 [14] S.G. Cohen & R.W . Krut, editors (2008): Pr oceedings 1st W orkshop on Service-Oriented Arc hitectur es and Softwar e Pr oduct Lines: What is the Connection? (SO APL ’07) . T echnical Report CMU / SEI-2008-SR-006, Carnegie Mellon Uni versity . http://www.sei.cmu.edu/reports/08sr006.pdf . [15] K. Czarnecki & U. Eisenecker (2000): Generative Pr ogramming: Methods, T ools, and Applications . Addison-W esley . [16] A. Fantechi & S. Gnesi (2008): F ormal Modeling for Pr oduct F amilies Engineering . In: Proceedings 12th International Software Product Line Conference (SPLC’08) , IEEE Computer Society Press, pp. 193–202, doi:10.1109 / SPLC.2008.45. [17] C. Feisst, D. Schlesinger & W . Frye (2008): Smart Grid: The Role of Electricity Infrastructur e in Reduc- ing Gr eenhouse Gas Emissions . http://www.cisco.com/web/about/ac79/docs/wp/Utility_Smart_ Grid_WP_REV1031_FINAL.pdf . [18] D. Fischbein, V .A. Braberman & S. Uchitel (2009): A Sound Observational Semantics for Modal T r ansition Systems . In M. Leucker & C. Morgan, editors: Proceedings 6th International Colloquium on Theoretical Aspects of Computing (ICT A C’09) , Lecture Notes in Computer Science 5684, Springer-V erlag, pp. 215– 230, doi:10.1007 / 978-3-642-03466-4 14. [19] D. Fischbein, S. Uchitel & V .A. Braberman (2006): A foundation for behavioural conformance in soft- war e pr oduct line arc hitectur es . In R.M. Hierons & H. Muccini, editors: Proceedings ISST A 2006 W ork- shop on Role of Software Architecture for T esting and Analysis (R OSA TEA ’06) , A CM Press, pp. 39–48, doi:10.1145 / 1147249.1147254. [20] A. Gruler , M. Leucker & K.D. Scheidemann (2008): Modeling and Model Checking Softwar e Pr oduct Lines . In G. Barthe & F .S. de Boer , editors: Proceedings 10th International Conference on Formal Methods for Open Object-Based Distributed Systems (FMOODS’08) , Lecture Notes in Computer Science 5051, Springer- V erlag, pp. 113–131, doi:10.1007 / 978-3-540-68863-1 8. [21] S. G ¨ unther & T . Berger (2008): Service-Oriented Pr oduct Lines: T owar ds a Development Pr ocess and F ea- tur e Manag ement Model for W eb Services . In: [26] , pp. 131–136. [22] D. Kang & D. Baik (2010): Bridging Softwar e Pr oduct Lines and Service-Oriented Ar chitectur es for Service Identification Using BPM and FM . In T . Matsuo, N. Ishii & R. Lee, editors: Proceedings 9th International Conference on Computer and Information Science (ICIS’10) , IEEE Computer Society Press, pp. 755–759, doi:10.1109 / ICIS.2010.33. [23] K.C. Kang, S.G. Cohen, J.A. Hess, W .E. Nov ak & A.S. Peterson (1990): F eatur e-Oriented Domain Analysis (FOD A) F easibility Study . T echnical Report SEI-90-TR-21, Carne gie Mellon University . http://www.sei. cmu.edu/reports/90tr021.pdf . [24] D. Kitchin, W .R. Cook & J. Misra (2006): A Language for T ask Orc hestration and Its Semantic Pr op- erties . In C. Baier & H. Hermanns, editors: Proceedings 17th International Conference on Concur - rency Theory (CONCUR’06) , Lecture Notes in Computer Science 4137, Springer -V erlag, pp. 477–491, doi:10.1007 / 11817949 32. [25] D. Kitchin, A. Quark, W .R. Cook & J. Misra (2009): The Or c Pr o gramming Languag e . In D. Lee, A. Lopes & A. Poetzsch-He ff ter , editors: Proceedings 11th International Conference on Formal Methods for Open Object-Based Distributed Systems and 29th International Conference on Formal T echniques for Networked and Distributed Systems (FMOODS / FOR TE’09) , Lecture Notes in Computer Science 5522, Springer-V erlag, pp. 1–25, doi:10.1007 / 978-3-642-02138-1 1. [26] R.W . Krut & S.G. Cohen, editors (2008): Pr oceedings 2nd W orkshop on Service-Oriented Ar chitectur es and Softwar e Pr oduct Lines: Putting Both T ogether (SO APL ’08) . Lero Centre, Uni versity of Limerick, doi:10.1109 / SPLC.2008.71. [27] R.W . Krut & S.G. Cohen, editors (2009): Pr oceedings 3r d W orkshop on Service-Oriented Arc hitectur es and Softwar e Pr oduct Lines: Enhancing V ariation (SO APL ’09) . ACM Press, doi:10.1145 / 1753235.1753279. 48 PL for SOA [28] K.G. Larsen, U. Nyman & A. W asowski (2007): Modal I / O Automata for Interface and Pr oduct Line Theo- ries . In R. De Nicola, editor: Proceedings 16th European Symposium on Programming (ESOP’07) , Lecture Notes in Computer Science 4421, Springer-V erlag, pp. 64–79, doi:10.1007 / 978-3-540-71316-6 6. [29] Q. Li, H. Zhu & J. He (2010): A Denotational Semantical Model for Orc Language . In A. Cav alcanti, D. Deharbe, M.-C. Gaudel & J. W oodcock, editors: Proceedings 7th International Colloquium on Theoretical Aspects of Computing (ICT A C’10) , Lecture Notes in Computer Science 6255, Springer-V erlag, pp. 106–120, doi:10.1007 / 978-3-642-14808-8 8. [30] E.M. Lightner & S.E. Wider gren (2010): An Orderly T ransition to a T r ansformed Electricity System . IEEE T ransactions on Smart Grid 1(1), pp. 3–10, doi:10.1109 / TSG.2010.2045013. [31] F . Mazzanti: FMC v5.0b . http://fmt.isti.cnr.it/fmc . [32] J. Misra & W .R. Cook (2007): Computation Or chestration: A Basis for W ide-area Computing . Software and Systems Modeling 6(1), pp. 83–110, doi:10.1007 / s10270-006-0012-1. [33] Orc Pr ogramming Langua ge . http://orc.csres.utexas.edu/ . [34] M. Papazoglou, P . Tra verso, S. Dustdar & F . Leymann (2007): Service-oriented computing: State of the art and r esear c h challenges . IEEE Computer 40(11), pp. 38–45, doi:10.1109 / MC.2007.400. [35] I. W ehrman, D. Kitchin, W .R. Cook & J. Misra (2008): A timed semantics of Or c . Theoretical Computer Science 402, pp. 234–248, doi:10.1016 / j.tcs.2008.04.037. [36] C. W ienands (2006): Studying the Common Pr oblems with Service-Oriented Ar chitectur e and Softwar e Pr od- uct Lines . Presented at 4th Service-Oriented Architecture (SOA) & W eb Services Conference.