Service Oriented Solution Modeling and Variation Propagation Analysis based on Architectural Building Blocks

Transcription

1 Carnegie Mellon Universiy From he SelecedWorks of Jia Zhang Ocober, 203 Service Oriened Soluion Modeling and Variaion Propagaion Analysis based on Archiecural uilding locks Liang-Jie Zhang Jia Zhang Available a: hps://works.bepress.com/jia_zhang/95/

2 Service Oriened Soluion Modeling and Variaion Propagaion Analysis based on Archiecural uilding locks ASTRACT: Liang-Jie Zhang, Jia Zhang 2 Kingdee Inernaional Sofware Group CO., Ld, China 2 Carnegie Mellon Universiy Silicon Valley, USA zhanglj@ieee.org; jia.zhang@sv.cmu.edu In spie of he widely recognized benefis of applying Service Oriened Archiecure (SOA) o design enerprise-scale sofware sysems, is acual applicaion pracice is no always a success. One major reason is he lack of a sysemaic engineering process and ool suppored by reusable archiecural arifacs. Toward his ulimae goal, his paper proposes a new mehod of archiecural building blocks (A)-based SOA soluion design and i is applicable o any layered or iered infrasrucure. We presen he modeling of soluion-level archiecural arifacs and heir relaionships, whose formalizaion enables even-based variaion noificaion and propagaion analysis. The goal is o provide archiecure-level suppor for configuraion and reconfiguraion of archiecural arifacs based on indusry pracices. Our mehod also suppors soluion-level projec variaion managemen for he process of updaing and mainaining archiecural arifacs. We repor a prooype ool ha we have developed and describe how we exend he Unified Modeling Language (UML) mechanism o implemen he sysem and enable soluion-level enforcemen as an example. The prooype has been applied in real projecs as an SOA soluion modeling ool. KEY WORDS: Soluion Modeling, Archiecure overview diagram, CASE, evoluionary prooyping INTRODUCTION Service Oriened Archiecure (SOA) has been widely acknowledged as a powerful model ha opens a new cos-effecive way of engineering sofware sysems, by dynamically inegraing and composing exising componens ino new business processes (Zhang, Zhang e al. 2007). usiness applicaions designed and developed using he SOA echnology are called SOA soluions or services soluions. However, he acual applicaion pracice of SOA is no always successful. To dae, mos of SOA pracices are conduced in an ad hoc manner and mainly based upon soluion archiecs personal experiences. This is obviously neiher pracical nor efficien. Among ohers, one major reason is he lack of a sysemaic engineering mehodology and an inegraed design ool. Unified Modeling Language (UML) mechanism (Arlow and Neusad 2005), including Raional Unified Process (RUP) and Raional ools, has been exensively used o help sofware engineers design and develop enerprise-scale applicaion sysems in a uniform way. However, UML ools were designed for building generic sofware sysems. Thus, hey do no provide normaive guidance and sysem-level suppor for building SOA soluions. From indusry pracice, layered archiecural models have been widely adoped by SOA praciioners o build SOA soluions. A ypical example is IM s Service-Oriened Soluion Sack

3 (S3), which defines a concepual view of a service-oriened archiecure in he soluioning conex (Arsanjani, Zhang e al. 2007). As shown in Figure, nine layers are idenified, organized ino a wo-dimensional archiecure wih five horizonal layers and four verical layers. The horizonal dimension (Operaional Sysem layer, Services Componen layer, Service layer, usiness Process layer, and Soluion Consumer layer) implemens funcional requiremens, and he verical dimension (Inegraion layer, Daa Archiecure layer, Qualiy of Service (QoS) layer, and Governance layer) provides sysem-suppor faciliies and enablemen. Fig.. SOA Soluion Sack model. However, S3 alone is oo coarse grained o be advisory for enerprise-level SOA soluion design and developmen. I only provides high-level guidance for developers o design an SOA soluion, i.e., in nine layers. To provide a uniform mechanism for building configurable and reusable SOA soluions on op of S3, we inroduced a concep of Archiecural uilding lock (A) as he fundamenal uni of an SOA soluion (Zhang, Zhang e al. 2008). An A is a concepual componen ha encapsulaes inernal saes and funcions and can be configured, exended, and insaniaed. Each layer in S3 is comprised of muliple As, which collaborae o carry ou all expeced aciviies. ased on indusry experience, we recommended a collecion of fine-grained A emplaes for each of he nine layers in S3 (Zhang, Zhang e al. 2008, Zhang and Zhang 2009, Zhang and Zhang 2009, Zhang and Zhang 2009). Considering he adapive feaure of business scenarios, each projec may have o configure and cusomize A emplaes o ap o proprieary requiremens and consrains. Some As, however, bear some iner-relaionships beween hem. If an A is changed, relaed As should be changed as well. Take our emplae for he Soluion Consumer layer shown in Figure 2 as an example. A predefined : relaionship exiss beween he Consumer A and he Presenaion View A. If a projec configures a Consumer A insance, a Presenaion View A insance should be creaed accordingly. Therefore, our goal is o build a ooling environmen supporing SOA soluion-based modeling and design. This paper focuses on supporing soluion-level design. Our main conribuions are hree-fold. Firs, we exend he exising UML ools, by inroducing a buil-in A-based modeling approach, o faciliae in designing SOA soluions. The raionale is ha, S3 and A emplaes form a space of archiecural arifacs. The modeling environmen can guide sofware archiecs in building a qualified SOA soluion based on predefined schemes and rules. Second, we leverage he power of formal mehods (Traore and Aredo 2004) o model soluion-level archiecural arifacs and heir relaionships, which formalizaion enables our ool o conduc rule-based verificaion of an SOA soluion design and conduc variaion propagaion analysis when changes are made during design ime. Noe ha variaion here refers o differen configuraion and cusomizaion from archiecural arifac emplae library during design ime. Third, we repor our experience and lessons learn from indusry pracice. The prooype sysem is being applied in real projecs as an SOA soluion modeling ool. 2

4 I should be noed ha he soluion-level design in he paper refers o meadaa-level design of archiecural building blocks; and he presened modeling approach is applicable o any layered or iered archiecure. Meanwhile, noe he differences beween several words used hroughou he paper, componen, archiecural arifac, and archiecural building block. A componen refers o a comprising par of he srucure of an SOA soluion wih relaively clearly defined srucural boundary. For example, a layer in S3 can be viewed as a componen. An archiecural building block refers o a reusable elemen in an SOA soluion archiecure. An archiecural arifac is a more generic erm referring o eiher a componen or a building block a archiecural level. The remainder of his paper is organized as follows. We will firs discuss relaed work. Using an A emplae for he Soluion Consumer layer as an example, we will inroduce modeling noaions, variaion propagaion modeling, and soluion modeling. Then we will explain our implemenaion of A modeling by exending he UML modeling echnique, and will inroduce our prooype sysem and explain how i validaes a cusomized SOA soluion. Aferwards, we will depic an overview of our modeling process. Finally, we will conclude he paper and share some fuure research direcions in he area. RELATED WORK Our work is a coninuous effor based on S3 and S3-based A emplaes. S3 (Arsanjani, Zhang e al. 2007) lacks a way o define elemens and deails inernal of any layer, and i does no provide normaive guidance on how o build prooypes of SOA soluions. In addiion, since he models say a very high level and remain coarse grain, soluion archiecs have o design sysem archiecure for each SOA projec from scrach based upon personal experiences. This ad hoc approach no only wases valuable human resources, bu also usually resuls in schedule delays. Our A emplaes (Zhang, Zhang e al. 2008) provide a comprehensive se of archiecural building blocks for he Soluion Consumer layer in he S3 model based on our pracice. The emplaes can be used as a saring poin for sofware archiecs o quickly configure and design a prooype for a specific SOA soluion. However, alhough he emplaes require some relaionships beween comprising archiecural arifacs, hese relaionships are implici and require significan learning curves and personal experiences. Therefore, his projec aims o build an engineering ooling environmen o guide sofware archiecs in consrucing an appropriae SOA soluion. More imporanly, his paper aims o esablish a foundaion and formalizaion for he modeling environmen o enable soluion-level auomaic verificaion of archiecural arifacs. Some researchers have sudied variaion analysis in Web services developmen (Jiang, Ruokonen e al. 2005, Kim and Doh 2008, Ruokonen, Räisänen e al. 2008). Variaion is well known as variabiliy managemen in he generic sofware developmen process (Jazayeri, Ran e al. 2000). Svahnberg e al. define sofware variabiliy as he abiliy of a sofware sysem o be efficienly exended, changed, cusomized or configured for use in a paricular conex (Svahnberg, Gurp e al. 2005). Gao e al. (Gao, Zhang e al. 203) propose a fuzzy and uiliy heory based mehod for collaboraive produc design. They adop an agen-based mechanism o coordinae design-ime variaion propagaion. Sofware variabiliy is usually classified ino differen caegories, from differen perspecives such as variaion poins, variaion realizaion echniques, and feaure variaions. A variaion poin refers o a design decision ha is consciously lef open for sofware engineers o decide based on some specific siuaions. Jiang e al. (Jiang, Ruokonen e al. 2005) highligh he imporance of reusing archiecure oward developing Web services. They idenify a se of variaion poins from hree resources: WSDL 3

5 documens, service endpoins, and business logics. Using UML o model wo paerns (inerface and implemenaion), hey build a prooype ool o help configure variaion poins in WSDL documens and service endpoins. However, heir modeling says a simple applicaion examples. The relaionships beween variaion poins are no examined. In conras o heir work focusing on parameer-level variaion poins in WSDL documens and service endpoins, our work focuses on building an engineering ool o help manage variaions a he SOA soluion level. Kim and Doh (Kim and Doh 2008) idenify hree iers (presenaion ier, service ier, and applicaion ier) in a Web service design and use UML o model variaion poins in each ier and heir relaionships. However, heir modeling currenly says a a rudimenary sage and has no been used in any pracice. In addiion, in conras wih heir hree-ier model saying a a very high level, our modeling is based on indusry pracice-based S3 model (as shown in Figure ) ha offers a proved guidance for large-scale SOA soluion modeling and design. Ruokonen e al. (Ruokonen, Räisänen e al. 2008) idenify a caegory of variaion needs and ypes relevan for SOA-based sysems, based on wo dimensions: sysem conceps and developmen process. In each of he perspecives of process, subprocess, service, and service inerface, variaion issues are discussed and a simple ecard service is used o as an example. However, heir variaion definiions say a a high level; hus, hey do no provide normaive guidance for sofware archiecs. Mezini and Osermann (Mezini and Osermann 2004) propose a feaure-oriened and aspecoriened modularizaion approach o manage variabiliy in he conex of sysem families. In conras o heir work focusing on building a language describing low-level feaures for variabiliy, our work focuses on modeling variaions a soluion-level archiecural arifacs. Some researchers leverage service usage hisory o guide SOA soluion design. Zhang e al. (Zhang, Ding e al. 20) use he pas query and invocaion hisories o calculae he user similariy and propose a collaboraive filering algorihm o rank service candidaes. Our earlier work (Zhang, Tan e al. 20) model service usage hisory in a service social nework, and leverage social neworking heory and echniques o suppor conex-aware service recommendaion. These echniques can be leveraged in our ooling environmen o faciliae SOA soluion modeling and proacive recommendaion. Model-driven developmen (MDD) approaches have been widely used in all phases of he lifecycle of sofware engineering pracices o increase sofware design and developmen produciviy reduce ime-o-marke in a sysemaic manner (Sendall and Kozaczynski 2003, Schmid 2006, Escalona and Aragón 2008). Represenaive examples include OMG s MDA (OMG 2003), Domain Specific Modeling (DSM) (Karsai, Szipanovis e al. 2003), and Sofware Facories (Greenfield and Shor 2004) from Microsof. Differen from hose componen-based modeling approaches focusing on building prooypes from exising models and paerns, our mehod uses variaion analysis of soluion archiecure design as a driving force o idenify archiecural arifacs and heir relaionships. Zhang and Møller-Pedersen (Zhang and Møller- Pedersen 203) sudy how o inegrae differen developmen ools in a collaboraive environmen. They propose a mehod o combine various modeling languages regarding specifying ool inegraion, and esablish ool chains in order o provide ools as a service. OMG s Service Oriened Archiecure Modeling Language (SOAML) aims o guide users in describing desired service characerisics (Gebhar, aumgarner e al. 200). Meanwhile, Masson e al. (Masson, Lundell e al. 2008) have poined ou ha radiional MDD canno auomae enforcemen of he archiecure on deailed design due o is inabiliy o model 4

6 archiecural design rules. They also emphasize he imporance of formally modeling archiecural design rules. Our repored work in his paper forms a foundaion o model archiecural arifacs and relaionships, as well as layered verificaion rules. Compared wih he repored works focusing on modeling and building single Web services, we concenrae on building a formalized model as a foundaion for esablishing an engineering mehod for SOA soluion design. We aim o enable and faciliae in designing and developing enerprise-scale SOA soluions ha may involve many exising service componens, business processes, and oher arifacs such as rules. A TEMPLATE EXAMPLE To ease our discussion, Figure 2 shows he recommended A configuraion for he Soluion Consumer layer of S3. Eigh As are idenified: A consumer A represens an exernal user of he Soluion Consumer layer. A presenaion (view) A is responsible for communicaing o and from exernal consumers. A presenaion conroller A is he coordinaor for all oher As in he Soluion Consumer layer. A consumer profile A is responsible for geing cusomerspecific informaion o be used by he presenaion conroller for navigaion and conen presenaion purposes. An access conrol A provides access o auhenicaion/auhorizaion capabiliies o be used by he presenaion conroller o allow/preven wha conen can be presened o he consumer. A forma ransformaion A is responsible for ranslaion of Query conen forma required by he Inegraion layer and o conver conen reurned from he Inegraion layer o a consumer response forma. A configuraion rule A is responsible for hosing rules ha define how he As can be configured based on consumer reques scenarios. A cache A is responsible for emporarily soring consumer ineracion-relaed daa o enhance sysem performance. For deailed A definiion and configuraion please refer o our previous repor (Zhang, Zhang e al. 2008). Fig. 2. Soluion Consumer layer As. FOUNDATIONS FOR A MODELING A Modeling To faciliae our formalizaion, Table I summarizes he fundamenal noaions and heir semanic meanings, which will be discussed in deail in he following secions and used hroughou he 5

7 paper. A Type and Insance Definiion. An Archiecural uilding lock (A) is an auonomous componen in S3 ha encapsulaes inernal saes and funcions and can be configured and exended. An A ype refers o every A we idenified represening a ypical fine-grained building class in an SOA soluion. An A insance refers o a building block in a specific SOA soluion implemening an A ype. An A componen refers o eiher an A ype or an A insance. Each A may be insaniaed ino several objecs in a specific SOA soluion. TALE NOTATIONS OF A MODELING Noaions Semanic Meanings X a layer in S3 X A ype se in layer X X A insance se in layer X X A A A ype A a layer X A a an insance of A ype A (i.e., wih sereoype A ) X # of insances of A n m X Y A A q A p a, b q p Ρ R A, A A, q a, b p X A A A ype A and A ype has a m:n mapping relaionship an insance of A ype A and an insance of A ype has a p:q mapping relaionship a p:q mapping relaionship beween eiher a pair of A ypes or a pair of A insances complian relaionship beween A insances wih ha beween corresponding A ypes (boh mapping and propagaion) q proocol beween a pair of A insances ( p for mapping and R for propagaion) n proocol beween a pair of A ypes ( m for mapping and R UML relaionship in UML 2.0) RUML X Y n AA, A m S an SOA soluion A a b a variaion publisher/subscriber relaionship exiss from R b ype publisher/subscriber relaionship A a Complian proocol beween a pair of A insances wih heir corresponding A ypes, A o A Mapping Relaionships Definiion 2. A mapping relaionship refers o he cardinaliy beween wo A componens, if here is relaionship beween hem. A mapping relaionship can be represened by a pair of ses m:n, each falling ino one of he hree possibiliies: (Cheng, Sun e al.), {0..*}, or {..*}. 6

8 n n 0..*..* m m null,,,, 0..*,... (R) The cardinaliy definiions can be used o deec and verify componen-level variaions. For he same reason, we define a null relaionship o imply ha no relaionship exiss beween wo A componens. Definiion 3. A complian mapping relaionship requires ha he mapping relaionship beween a pair of A insances be eiher he same as or sronger han he one defined beween heir corresponding A ypes: q p A n X Y a, b m AA, A n q n p m null null q p (R2) m Definiion 3 requires ha a cardinaliy relaionship defined beween a pair of A insances be a subse of he one defined in he corresponding pair of A ypes. For example, if he relaionship 0..* beween a pair of A ypes is defined as, he relaionship beween heir A insances..* 0..* can only be one of he following possibiliies: (,, ). Variaion Propagaion Modeling In his secion, we discuss how we model variaion propagaion requiremens beween wo A componens. Propagaion Relaionship To mainain loose coupling beween As in an SOA soluion, we applied he publisher/subscriber design paern (uschmann, Meunier e al. 996) o manage variaion propagaion and synchronize cooperaing As. y noifying all of is subscribers abou changes, a publisher enables single-direcional change propagaion. Each pair of variaion publisher/subscriber relaionship can be visually represened as a single-direcional relaionship, by employing a direced arrow poining from he variaion publisher o he variaion subscriber. Such a relaionship can be denoed by an operaor. Definiion 4. For each idenified single-direcional relaionship beween a pair of A insances, he A insance ha is independen from he oher one is assigned as a variaion publisher; he A insance ha depends on he oher one is assigned as a variaion subscriber. Their A A relaionship can be represened by: a b, where: a and b denoe wo A insances, wih he former denoing he variaion publisher in he relaionship and he laer denoing he variaion subscriber. The propagaion relaionships beween each pair of As can be normalized as one or wo single-direcional relaionships (a bi-laeral relaionship can be broken ino wo single-laeral relaionships). Such a relaionship implies a logical arrow poining from one acive A o he oher passive A. The acive A here means ha i is independen on changes from he passive A; and is changes have o be refleced o or be reaced by he passive A. The publisher/subscriber paern is applied o each such single-direcional relaionship, by assigning he role of publisher o he acive A and he role of subscriber o he passive A. We hus 7

9 define a pair of variaion publisher and variaion subscriber o each single-direcional relaionship. When variaion happens a he variaion publisher, i is propagaed o he corresponding variaion subscriber hrough noificaion. Such a variaion publisher/subscriber relaionship is enabled by he variaion subscriber regisering iself a he variaion publisher. An A may inerac wih muliple As; herefore, i may be involved in muliple singledirecional relaionships. In each such relaionship, i may ac as eiher a variaion publisher or a variaion subscriber. Meanwhile, for a pair of As having bi-direcional relaionships, each A acs as boh a variaion publisher and a variaion subscriber for each oher. As we discussed, A ypes are mean for meamodel and A insances are mean for SOA soluion modeling. Here we will discuss propagaion beween A ypes firs. Propagaion beween A Types Propagaion relaionships beween A ypes are no as imporan as ha beween A insances. One imporan reason is ha A ypes are for meamodel only; hey need o be embodied in acual models and may need o be flexible o be overwrien in accordance wih acual condiions. However, properly designed propagaion relaionships defined beween A ypes can be of use for wo purposes. Firs, since meamodel is ypically mainained by he highes-level archiecs, he defined relaionships can be used as guidance for acual model design. Second, defined relaionships can be used o validae and verify acual propagaion relaionships beween A insances. Meanwhile, propagaion relaionships can be overwrien a A insances from A ypes wihin cerain degrees if necessary. For example, a wo-dimensional associaion relaionship can be srenghened ino one-dimensional direced associaion. Since we are only ineresed in propagaion relaionships defined for A insances, he propagaion relaionships defined for A ypes are more casual and do no have o be enforced. Thus, we summarize our consideraions of propagaion relaionships beween A ypes and A insances in Figure 3. Fig. 3. Propagaion relaionship specificaion model. As shown in Figure 3, meamodels are ypically mainained by lead archiecs and models are consruced by individual SOA archiecs. Our sraegy is ha meamodels can uilize normal UML 2.0 relaionships. The caegorized propagaion relaionships summarized in Table 2 can be recommended bu do no have o be enforced. On he oher hand, models should be allowed o use he propagaion relaionships in Table 2. While archiecs could sill ry o use UML 2.0 relaionships, some reformaion work will be performed underlying (e.g., break a wodimensional associaion ino wo one-dimensional associaions), and incompaible relaionships (e.g., package impor) will be warned and enforced o be removed from a valid model. TALE 2. A-LEVEL VARIATION MANAGEMENT. Ca Covered UML Descripions Variaion managemen 8

10 relaionships direced associaion, dependency, usage 2 aggregaion, composiion 3 implemens, Cusomized dependency relaionship Whole/par relaionship Absracion/implemenaion relaionship realizaion 4 generalizaion Super-/sub-class relaionship Regisraion a he depended A (publisher) Regisraion a he whole A (publisher) Regisraion a he absracion A (publisher) Regisraion a he sub-class A (publisher) Definiion 5. A complian propagaion relaionship refers o he propagaion relaionship defined beween a pair of A insances mus be complian wih ha defined beween he corresponding pair of A ypes. The requiremen can be represened as R3: A R a, b A X Y R a, b R A UML A, A (R3) The implicaion of R3 is wo-fold. Firs, he propagaion relaionship defined beween a pair of A ypes should be among hose idenified in Table 2. Second, he publisher/subscriber relaionship beween a pair of A insances should be assigned using he sraegies summarized in Table 2. As menioned earlier, in his paper, we considered simplified publisher/subscriber relaionship. Thus, R3 can be simplified ino R4: R A a, b A X Y R a, b RUML A A (R4) SOA Soluion Definiion In his secion, we discuss how o model an SOA soluion based on A propagaion modeling. Propagaion Pah I is common ha various kinds of A-relaed variaions could happen a runime. For example, a new A insance is creaed, a mehod of an exising A insance is modified, an A insance broadcass a message, and so on. When a variaion occurs, i needs o be propagaed o relaed A insances, and in urn be propagaed o subsequenly corresponding A insances. In shor, a variaion should be propagaed o all direcly or indirecly relaed A insances. We formally define a propagaion pah and propagaion se as follows. Definiion 6. A propagaion se depics an ordered se of all eiher direcly or indirecly impaced A insances in an SOA soluion when a variaion happens a one conained A insance. A propagaion se can be denoed by a direced graph represened by a 4-uple G P a P, P, a, PSe, where P represens a se of nodes each represening an A insance; PA represens a se of direced arcs; a represens he saring poin of A insance; and PSe represens a se ha including all propagaion pahs saring from a. Each arc links beween wo nodes if here is a propagaion relaionship beween he wo A insances. Such an arc sars from he propagaion publisher poining o he propagaion subscriber. A propagaion pah of he 9

11 A insance a depics a subse of is propagaion se, saring from a and canno furher propagae. A propagaion pah of an A insance a can be denoed by a direced graph: pah N, A, a, where: N a, N, N2,..., Nn, A R a, N, R N, N2, R N2, N3,... R Nn, Nn, N PN, A PA Definiion 5 implies ha: PA A A a N b N R a b, (R5) and PSe { P, P2,..., Pk }, Pi { a, N, N 2,..., N n}, i, k, N j PN, j [, n], a N, N N 2,..., N n N n A propagaion pah depics a possible farhes propagaion pahway saring from an A insance. A propagaion poins ou a message passing pah beween involved A insances a runime. Definiion 7. A propagaion loop in a propagaion se indicaes an included circular propagaion pah. Saring from one included A insance, a propagaion loop will end wih he saring A insance. I can be denoed by a direced graph L, LA, k, where: L L, L LA R 2,..., Ll, L, L, R L, L,... R L, L 2 where L PN, LA PA, k L 2 3 l, Raionale. We consider a propagaion loop in he conex of a propagaion se insead of a dependency graph. For example, a secion of dependency graph, which conains a propagaion loop bu may never have any variaion occurred, should no be par of our consideraion. Generally, here should exis no circles in a propagaion se. If exising, a loop should be broken o avoid infinie message passing; or a specific excepion handling mechanism should be esablished o realize manual inerrupion (usually by a sofware archiec). Le us consider a simple loop. If a change is required for a business goal, i will be propagaed o he implanaion services, which will in urn be propagaed o he realizaion service componens. However, some echnology change may be desired a a service componen, e.g., change from.net o Java. Such a change has o be propagaed back o he corresponding service and in urn may cause some change a he business goal. Such a loop is needed; and afer a decision is made by coordinaion agens, he propagaion circle will end. A Proocol Puing ogeher mapping relaionship and propagaion relaionship, we can define proocols beween A ypes and A insances. Definiion 8. One proocol beween a pair of A ypes conains wo elemens: a mapping relaionship (as defined in Definiion ) and a propagaion relaionship referring o a UML 2.0 0

12 relaionship ha defines he correlaion beween wo A ypes. Such a proocol can be represened as follows: R UML n m A X A, Y A, where: X Y n A A and A denoe wo A ypes; M m denoes ha he cardinaliy beween he wo A n X Y ypes is M m AA, A ; here is a correlaion relaionship beween he wo A ypes ha can be represened by a UML 2.0-defined relaionship R UML. Definiion 9. One proocol beween a pair of A insances conains wo elemens: a mapping relaionship (as defined in Definiion ) and a propagaion relaionship referring o a publisher/subscriber relaionship ha defines he direcion of variaion propagaion. Such a proocol can be represened as follows: a, b R A q p A a and b, where: denoe wo A insances; q A A insances is M a b p q M p denoes ha he cardinaliy beween he wo, ; here is a publisher/subscriber relaionship beween he A A wo insances a b, where a is he publisher and b is he subscriber; and he publisher/subscriber ype R beween he wo A insances is of ype R (In his paper since we only consider one ype of generic publisher/subscriber relaionship, i can be simplified as R ). Definiion 0. A complian A proocol refers o he proocol defined beween a pair of A insances mus be complian wih ha defined beween he corresponding pair of A ypes in wo aspecs: one is heir mapping relaionship mus be complian; he oher one is heir propagaion relaionship mus be complian. RUML X Y R A n AA, A q a, b p m (R6) n R R UML Definiion of an SOA Soluion q p m Wih he preparaion of hese noaions, we are ready o define he noaion of an SOA soluion. Definiion. An SOA soluion S is defined as a uple as follows: S,, where: represens he meamodel of he soluion, which is in urn a uple:, P, where: represens nine layers of A ypes: 9 X i, P represens he relaionships i beween he defined A ypes: p P RUML X Y ( A ) ( ) P n AA, A M m represens he acual model of he soluion, which is in urn a uple:, P,

13 where: X i i, P represens he relaionships beween he defined A insances: X Y p P a b R X Y P n a, b M m IMPLEMENTING SOA SOLUTION MODELING ased on he presened formal A modeling, we now discuss how we leveraged he modeldriven approach o exend UML o implemen A-based SOA soluion modeling as an example. UML has become a widely acceped indusry sandard for sofware sysem modeling (Arlow and Neusad 2005). The major echnical challenge we encounered is how o implemen our formal A represenaion using UML modeling. Paricularly, we had o ackle wo issues: how o model variaion propagaion beween A insances and how o model A-based SOA soluions. Propagaion beween A Insances UML provides a comprehensive se of relaionship ypes o model relaionships beween eniies (e.g., class, inerface, componen, and package) [9]. In his paper, we are only ineresed in he relaionship ypes ha may lead o variaion propagaion hrough A insances. For example, consider a Presenaion Conroller A ha uses an Access Conrol A. If an access conrol mehod name in he Access Conrol A is changed, he Presenaion Conroller A should be informed o make consequen changes. We examined all relaionship ses defined in UML 2.0. Some relaionship ypes will no cause componen-level variaion propagaion (e.g., subsiuion), or have equivalens (e.g., absracion), or are irrelevan o he semanics of A insances hus will no appear beween A insances (e.g., insaniaion, binding, package impor, elemen impor, and associaion class). A A level, hese relaionships will no be allowed so we remove hem from our consideraion. Afer his process, we obain a se of 0 relaionships: associaion, link, direced associaion, aggregaion, composiion, generalizaion, implemens, realizaion, dependency, and usage. Among he remaining se, some relaionship ypes are one-direcional (direced associaion, aggregaion, composiion, generalizaion, implemens, realizaion, dependency, and usage) while ohers are bi-direcional (associaion and link). ecause we inend o analyze variaion propagaion, direcion is imporan here. Therefore, for each bi-direcional relaionship, we break hem ino wo single-direcional ones. In more deail, an associaion relaionship will be broken ino wo direced associaion relaionships; a link will also be broken ino wo. ecause from he componen-level relaionship perspecive, he wo relaionships associaion and link ac as he same, wihou losing generaliy, one link relaionship will be broken ino wo direced associaion relaionships. Meanwhile, from he consideraion of componen-level variaion propagaion, some relaionships will cause he same or similar acion. For example, an aggregaion and a composiion relaionship boh represen a whole-par relaionship, and a change in a par (e.g., adding a new par or removing an exising par) needs o be propagaed o he whole componen. For anoher example, 2

14 an implemens and a realizaion relaionship boh imply ha one componen represens an absrac of he oher one. Thus, we organize he sudied relaionships ino four caegories as shown in Table 2. The deailed definiion for each discussed UML relaionship can be found from UML 2.0 specificaion (Arlow and Neusad 2005) and will be followed in our sudy. The major reason why we caegorize he relaionships beween As is for enabling variaion propagaion analysis and managemen, which is also he crierion of how we caegorize he relaionships. Caegory represens cusomized dependency relaionship beween wo As, which covers hree ypes of UML relaionships: direced associaion, dependency, and usage. Caegory 2 represens whole/par relaionship beween wo As, which covers wo ypes of UML relaionships: aggregaion and composiion. Caegory 3 represens absracion/implemenaion relaionship beween wo As, which covers wo ypes of UML relaionships: implemens and realizaion. Caegory 4 represens super-/sub-class relaionship beween wo As, which covers he UML relaionship generalizaion. As shown in Table 2, each caegory implies a proprieary variaion managemen approach. Table 2 provides he guidance on how o apply he publisher/subscriber paern and assign variaion publisher/subscriber roles o each ype of A relaionship. The sraegy is ha he A ha will be noified for variaion propagaion will be assigned as a variaion subscriber; and he oher A iniiaing a variaion will be assigned as a variaion publisher. For Caegory, each covered UML relaionship implies a dependency relaionship beween he wo As. Therefore, he depended A is assigned as he variaion publisher and he dependen A is assigned as he variaion subscriber; he dependen A regisers iself a he depended A. For Caegory 2, he A as a par is assigned as he variaion subscriber and he A as he whole is assigned as he variaion publisher; he par A regisers iself a he whole A. For Caegory 3, he A as he absracion is assigned as he variaion publisher and he A as he implemenaion is assigned as he variaion subscriber; he implemenaion A regisers iself a he absracion A. For Caegory 4, he A as he sub-class is assigned as he variaion publisher and he A as he super-class is assigned as he variaion subscriber; he super-class A regisers iself a he subclass A. Six levels of variaions should be propagaed: daa eniy, message, business primiive, business consruc, business proocol, and business process (Zhang, Zhang e al. 2007). All of hese variaions can be propagaed hrough he same publisher/subscriber approach. However, i is useful o differeniae beween levels of variaions hrough propagaion, so ha proper acion can be conduced effecively and efficienly. For example, if a variaion happened a a variaion publisher is a an operaion level, is variaion subscriber may only updae is corresponding operaion invocaion. If he propagaion only informs a variaion occurrence wihou variaion level, hough, he variaion subscriber may no be able o ake righ acion promply. This simple example illusraes he necessiy and imporance of differeniaing variaion levels. To address his need, our soluion is o exend he original publisher/subscriber paern by associaing variaion level informaion. In more deail, when a publisher/subscriber relaionship is se up beween wo A insances, one of he six levels of variaion will be bound o he publisher/subscriber relaionship. To simplify he sudied domain, wihou losing generaliy, in his paper we only consider he original defaul publisher/subscriber forma. In oher words, when any level of variaion happens a a variaion publisher, is corresponding variaion subscribers will be informed in he same way. Sudying variaion propagaion a various levels in deail will be our fuure research. 3

15 A-ased SOA Soluion Modeling In his secion, we inroduce how we exend UML o model As associaed wih variaions in an SOA soluion. Saring from UML 2.0, meamodels specify he absrac synax and semanics of UML modeling conceps. On op of meamodel, profiles and consrains provide mechanisms o exend he exising UML meamodel o model specific applicaions. In more deail, he UML meamodel defines he basic sereoypes (i.e., daa ypes) ha users can uilize o build UML models. Examples of basic sereoypes are class, package, and associaion. A user-defined meamodel defines newly added sereoypes and heir relaionships. A profile carries sereoypes and consrains can be applied by users o creae insances of sereoypes in UML models. In oher words, a user-defined profile defines applicaion-specific building blocks ha users can use o build specific UML models. In his research, we exend he UML meamodel o model A-based SOA soluions. Each A is modeled as a UML sereoype; sereoypes represening all As defined in one layer are grouped in one package as a profile. The raionale is ha, every building block in an SOA soluion is an insance of an idenified A. In ye anoher words, an A can be considered as a class wih specific definiions ha can be insaniaed ino final building blocks. As S3 illusraes, a ypical SOA soluion can be organized ino a nine-layer srucure. The final code srucure can consequenly be organized ino nine packages. Noe ha hese nine packages only represen he op-level sofware srucure; more packages can be idenified if needed. Therefore, we esablish a mapping beween SOA soluions wih UML models, by mapping an S3 layer o a UML package and mapping an A o a UML sereoype. Thus, an SOA soluion can be modeled using exended UML. Figure 4 shows a segmen of a class diagram of he Operaional Sysem layer of a paricular ravel booking sysem. As shown in Figure 4, wo componens Car Reservaion Applicaion and Hoel Reservaion Applicaion each represen an inerface deriving from a LegacyApplicaion A sereoype; a componen JVM (Java Virual Machine) represens an inerface deriving from a RunimeEnvironmen A sereoype, a componen Operaional Sysem Conroller represens an insance deriving from a OperaionalSysemConroller A sereoype. Fig. 4. A segmen of class diagram. 4

16 Meamodel-Cenered Adapive Modeling According o our exensions o UML o model SOA soluions using As, we creaed hree kinds of arifacs: meamodel, profile, and palee. For each layer of he S3 model, we firs creaed a meamodel represening all idenified As as sereoypes as he concepual model of he layer, hen we creaed a package of profiles represening each A as a sereoype, and hen we creaed a palee conaining all As as building blocks for users o use o creae UML models. We found ha here are inheren relaionships among he hree conceps: meamodel, profile, and palee. As a maer of fac, all of he hree conceps define sereoypes ha can be used by users o build UML models. A palee is a ypical way for a UML modeling ool o prepare a se of available sereoypes for users o pick from and draw UML diagrams. A profile carries defined sereoypes for users o apply o models. A meamodel is he source o formally define sereoypes. Due o he inrinsic relaionships among he hree conceps, if we creae hem separaely as wha we originally did, whenever we make changes o any As, we have o apply he same changes o all hree ypes. This approach of manual consisency conrol is no only inefficien bu also error-prone. Our soluion is o uilize he inheren relaionships among he hree conceps and use he meamodel as he basis o realize auomaic synchronizaion among hem. The deails of he idea can be summarized as in he pseudo code shown below. We firs consruc he meamodel for each layer. Then for each meamodel, we idenify he sereoypes and creae a corresponding profile conaining all As as sereoypes. Aferwards we creae a corresponding palee comprising all As as building blocks. Any UML modeling environmen ypically already conains a buil-in palee represening basic building blocks in hierarchies for UML modeling, such as class, associaion, class diagram, and so on. To differeniae beween our SOA soluionoriened palee and embedded-in palee, we organize palee in model libraries insead. Algorihm : Meamodel-cenered SOA soluion model managemen. If no exised, creae all hree caegories of elemens.. For each of he nine layers of he S3 model, Creae a meamodel wih all idenified As;.2. For each of he nine meamodel,.2.. Creae a profile;.2.2. Ierae hrough all sereoypes (As) in he meamodel, Creae a sereoype in he profile;.3. For each of he nine meamodel,.3.. Creae a model library;.3.2. Ierae hrough all sereoypes (As) in he meamodel, Creae a building block in he model library; 2. If already exised bu a change is required, 2. make changes o he corresponding meamodel; 2.2 re-generae he corresponding profile elemens only; 2.3 re-generae he corresponding model library elemens only. Whenever changes are required, we will modify he corresponding meamodels. Aferwards, by re-generaing corresponding profile elemens and model library elemens, all hree ypes of model elemens can be synchronized. I should be noed ha inelligence is necessary here o ensure ha 5

17 only involved profile elemens and model library elemens be re-generaed, so ha oher elemens wih cusomized code (e.g., wih user-added derived sereoypes) can say unouched. Example of UML Exensions for Soluion Consumer layer We will use he Soluion Consumer layer as an example o illusrae how we use meamodel o simplify and auomae sereoype managemen, by using meamodels as he base o enable auomaic generaion of profiles and palees. As a prerequisie for our mehod, we creae a S3 base profile serving all nine layers in he S3 model. The cenral sereoype in he S3 base profile is he sereoype A. ased on he S3 base profile, as shown in Figure 5, we creae a meamodel o define he eigh ypes of As and heir relaionships for he Services Consumer layer as defined in Figure 3. As shown in Figure 5, he meamodel is creaed as a class diagram conaining a se of eigh classes, each represening an idenified A. Each class is marked as an insance of he sereoype A. A profile will be auomaically generaed for he Soluion Consumer layer. Each A depiced in Figure 5 becomes a UML sereoype. The profile of he Soluion Consumer layer hus comprises eigh sereoypes. Each sereoype derives from basic UML 2.0 sereoype class. Each layer in S3 model possesses a proprieary profile. Noe ha such a sereoype generaed will only allow a creaion of is insance exending from UML sereoype class. If we expec o creae an insance of he generaed sereoype exending oher UML sereoypes, such as inerface, we will have o manually add a corresponding super sereoype in he profile. This implicaion comes from he fac ha a meamodel is ypically creaed as a UML class diagram comprising only classes, which is he ypical way o represen daa ypes (i.e., sereoypes). Thus, his limiaion is in general olerable. Fig. 5. Services Consumer layer meamodel. As shown in Figure 6 on he lef panel, a model library will be auomaically creaed for he Services Consumer layer. Each A depiced in Figure 5 becomes a building block in Figure 6. Noe ha a his momen, he profiles creaed before have been applied. Each of he building blocks in he Services Consumer layer has already been marked as represening he corresponding sereoype. For he building block of consumer highlighed in Figure 6 on he lef panel, he sereoype Consumer has already been applied. Meanwhile, each generaed building block is marked wih he signal $ and is delimied wih a pair of brackes, which implies ha when a user creaes an insance of he building block, he/she should change he name of he insance o 6

18 specific name. Moreover, Figure 6 shows ha he each layer in S3 model possesses a proprieary model library. Usages of Meamodel for Generaing Soluion Paerns The indusry pracice we use no only leads o he idenificaion of As, bu also depics he relaionships beween he As. As shown in Figure 5, since a meamodel is a class diagram, hese relaionships can be represened in he meamodel using sandard UML relaionship elemens. For example, here is a one-o-many relaionship beween a Presenaion Conroller sereoype and a Presenaion sereoype. These relaionships can help o build SOA soluions using insances of As (i.e., sereoypes). Figure 6 shows an example srucure of a Services Consumer layer of an SOA soluion. As shown in Figure 6, each of he A idenified has an insance; hese A insances are inerconneced according o he relaionships defined in Figure 5. Meanwhile, based on indusry pracice, our meamodels also implicaes a design paern of he corresponding layers in he S3 model. For example, as shown in Figure 6, by insaniaing every sereoype in he meamodel in Figure 5 and mapping he relaionships beween sereoypes o heir insances, we can obain a modeling emplae of he Services Consumer layer. Similar o ha a design modeling emplae represening a reusable soluion o a repeaable scenario, his paern represens a saring poin o build a cusomized Services Consumer layer for a specific SOA soluion. Therefore, we propose anoher novel way o uilize our meamodels, by auomaically generaing a modeling emplae for each layer in he S3 model. The main concep of he algorihm is similar o he one inroduced in earlier secion. The difference is ha, his ime in addiion o ieraing hrough each idenified A in a meamodel, we will also cach all relaionships. For every A caugh, a class insance will be creaed as an insance of he sereoype; for every relaionship 7

19 caugh beween wo sereoypes, a relaionship will be creaed beween he corresponding wo class insances. SOA SOLUTION VALIDATION Afer we inroduce he basic modeling aspecs of an SOA soluion, in his secion, we discuss how o validae a cusomized SOA model, hrough layered archiecural rule ses. Hierarchical Rule Ses We organize archiecural rules in a hree-level hierarchy: () op-level rules, (2) layer-level rules, and (3) A-level rules. A se of op-level rules is esablished a global S3 model-wide for any SOA soluion. These rules are o be enforced wih he highes prioriy over any oher rules. For example, each A ype can only belong o one layer. Each layer can define a specific se of rules as layer-level rules, which have o be enforced wih he second highes prioriy. For example, he Soluion Consumer layer may allow only one insance of Presenaion Conroller A. A-level rules refer o he relaionships defined beween A ypes ha have o be enforced on corresponding A insances. For example, assume a one-o-many dependency relaionship is defined beween A ype A and. If an insance of A ype is creaed, i should be regisered in he insance of A ype A. Sysem-level Rules The global rule se conains six defaul rules as defined in Definiion 2. Definiion 2. The sysem-level rule se for an SOA soluion following six rules: X X AA X AA X. X A A X Y A A a 2. a A 3. X null X 4. X X 5. X A 0 R 6. RUML n m UML n m A Y A A X a X A X a Y X Y X R A A A,, A, a, b A X A, Y A Y A q p R q p a A, b S, by defaul conains he Rule denoes ha each A ype A X A belongs o and only belongs o one specific layer X. Rule 2 denoes ha each insance of A ype A belongs o and only belongs o one layer X o which he A ype A belongs. Rule 3 denoes ha for a paricular SOA soluion, one layer may conain no As, meaning ha he layer is no necessary for he soluion. Rule 4 denoes ha if a 8

20 specific layer does no exis in he meamodel, he layer does no exis in he acual SOA model. Rule 5 denoes ha one A ype A may or may no have insances in a specific SOA soluion, and one A ype A may have more han one insance in a specific SOA soluion. Rule 6 denoes ha a proocol beween a pair of A insances in a specific SOA soluion is required o be complian wih ha defined beween he corresponding A ypes in he corresponding meamodel of he SOA soluion. Specially, rule 6 also implies ha: () if here is no cardinaliy relaionship beween a pair of A ypes, here should be no cardinaliy relaionship beween he corresponding pair of A insances; (2) if here is cardinaliy relaion beween a pair of A ypes, heir corresponding A insances have o be conneced wih he same or sronger cardinaliy relaionships; and (3) if here is propagaion relaion beween a pair of A ypes, heir corresponding A insances have o use he way summarized in Table 2 for assigning publisher and subscriber roles. In general, he op-level rules are implicily defined and canno be modified hroughou he modeling of any SOA soluion. Layer-level Rules Each layer in he S3 model can carry a specific se of rules as layer-level rules. Taking he Soluion Consumer layer as an example, is layer-level rule se possesses one rule R7: Consumer Pr esenaion _ Conroller presenaion _ conroller (R7) iff Consumer _ Layer Consumer _ Layer presenaion _ conroller R7 denoes ha if he Soluion Consumer layer model is no empy, hen here has o be one and only one insance of Presenaion Conroller A exiss. This rule can be enforced by seing he mulipliciy of he Presenaion Conroller A ype o be. Each layer may carry some predefined layer-level rules. Typically, hese layer-level rules can be modified by chief archiecs a he ime of consrucion of a meamodel for a specific SOA soluion. For example, a comprehensive applicaion may allow muliple insances of Presenaion Conroller A exis in is Soluion Consumer layer. This rule can be represened as R8 and can be se up by seing he mulipliciy of he Presenaion Conroller A ype o be..*. Consumer Pr esenaion _ Conroller presenaion _ conroller iff Consumer _ Layer Consumer _ Layer presenaion _ conroller Meanwhile, applicaion-specific layer-level rules can be added if necessary. For example, one paricular PDA-oriened applicaion may require ha a leas one pair of (PDA_Consumer, PDA_Presenaion) insances are creaed for he A ype pair (Consumer, Presenaion), meaning ha he soluion has o suppor PDA users by providing corresponding PDA-specific inerface presenaion generaion mechanisms. The rule can be represened as follows: Pr esenaion _ Layer (R8) Pr esenaion _ Layer Consumer (R9) A-level Rules 9

21 A-level rules define he muual connecions beween A ypes ha need o be enforced on corresponding A insances. As defined in earlier secion, he connecion relaionship in our concern includes cardinaliy relaionship and propagaion relaionship. Such relaionships can be deduced and ransformed ino rules o regulae he consrucion of SOA models using A insances. For example, a chief archiec may define ha here is a one-o-zero_o_many dependency relaionship beween a Presenaion Conroller A ype and an Access Conroller A ype in he Soluion Consumer layer, which can be represened as follows: Consumer _ Layer R Pr esenaion _ ConrollerA, Dependency 0..* Consumer _ Layer (R0) Access _ ConrollerA The above rule can be deduced ino he following se of rules comprising hree rules regarding relaed A insances: Consumer _ Layer presenaion _ conroller, R () 0..* access conroller A, Consumer Layer Consumer_ Layer presenaion _ conroller, R (2)..* access conroller A, Consumer Layer Consumer _ Layer presenaion _ conroller, R (3) access conroller A, Consumer Layer The deduced rules indicae accepable relaionships regarding corresponding A insances in an SOA model. In oher words, if an SOA model conains a pair of A insances Presenaion Conroller and Access Conroller, heir relaionship has o be one of he above hree possibiliies o be considered as a valid relaionship. Using he same mehod, each defined relaionship beween a pair of conained A ypes in a meamodel can be represened as an A-level rule; each such rule can be deduced ino a se of rules for a corresponding pair of A insances. Accumulaing hem all, for each meamodel for an S3 layer, we can obain a knowledge base conaining a se of relaionship rules for accepable relaionships for he S3 layer. Noe ha he publisher/subscriber relaionship is an implemenaion-oriened sraegy considering variaion adapaions. An SOA archiec also uses common semanic-rich relaionships (e.g., UML 2.0-defined relaionship ypes) o define he relaionships beween A insances when creaing an SOA soluion. To enable validaion and verificaion of a user-creaed model, our sraegy is o ranslae he relaionship beween each pair of A insances ino a publisher/subscriber relaionship, using he algorihms defined in Table 2 for each ype of UML 2.0 relaionship. For example, if here is a one-o-zero_o_many dependency relaionship defined beween a Presenaion Conroller A insance and an Access Conroller A insance in he Soluion Consumer layer, i can be ransformed ino he following relaionship: R 0..* Consumer _ Layer presenaion _ conroller, A Consumer Layer, _ access _ conroller 20