Migration of a Chosen Architectural Pattern to Service Oriented ...

More documents

Recommendations

Info

Chapter 2. Related Work 22Service Identification –Service Identification underlines all the processes associatedwith migration toward Service Oriented Architecture. In context of thepresented approach, the identification is based on analysis of documentation, especiallyrequirement documentation. The identification consists of two steps [84]:1. Sub domain identification –includes analysis of selected sub–domains inorder to define boundaries of the whole legacy system.2. Further analysis –carries the burden from strict analysis to modelling, especiallyon modelling of the whole system as UML diagram that is afterwardstransferred to third party software. The diagrams are expressed in XML[84]. The model serves as an input for identification of potentially reusablecomponents that latterly may be provided as services. Those services arecalled logical services and they are spanned between concept of service itselfand the technical realisation separated from legacy code.Legacy System Understanding –The second process is intended to estimatepotential migration chances and model the system. According to ZhuopengZhang[84],a system is suitable to migrate toward SOA when the system containsreusable business functionality that in comparison to the whole system is reasonablymaintainable. Moreover, the functionality should bring additional valueafter exposing it as a service. Having estimation done, a model of the systemshould be elaborated. Elaboration of the model is based on a re–engineeringprocess and analysis of existing documentation including technical documentation,graphs, interfaces and other existing models. Approach description includesdifferent treatment of procedural software and object–oriented (OO) software.Re–engineering of procedural–application in opposite to OO applications involvesusage of additional tools in order to obtain candidate classes and intermediateobject–oriented model. In turn, Intermediate Model incorporates UML representation,event driving programming models and object oriented programminglanguage [84]. Object–Oriented approach tries to define system on different levelsof abstraction by creation of UML class diagram and control flow graph.Agglomerative Clustering Analysis – Agglomerative Clustering requiresa set of data for reorganization purpose. This set of data in case of migrationinvolves functions, procedures and classes that are further clustered accordingto feature similarity. The similarity is a key concept in legacy systemrestructuring[84]. The technique defines features that are used to measure thesimilarity and determinate whether two entities belong to the same cluster. Afeature reflects found identifiers–name. A name can identify any non local entityor a property of the entity including property, name or method name [84].Then, the algorithm is executed (see [84] for more information about thealgorithm).The algorithm produces a dendrogram that describes dependencies
Chapter 2. Related Work 23between all the provided data. In order to allocate services, architects have toset cutting points manually and divide the diagram into sub–trees. The sub–treebecome services. During service selection, architects have to take into considerationother information retrieved during previous steps as well as the amount ofdependencies in order to receive coarse grained and loosely coupled services (see4.3.1).Service Packaging and Integration This is the last step of presented Gray–Boxtechnique. The step accomplishes the process of migration from legacy system towardsService–Oriented Architecture. The last step is composed from a sequenceof three sub–steps [84]:1. Refinement –the services obtained as a result of all the previous steps areloosely coupled, but they still contain some dependencies. Refinement increasesindependence of those services and improve their quality by removalof all the “dead” code and unrelated interactions of interfaces. During thisprocess also an interface for service communication is established [84].2. Component integration and packaging –component integration takes previouslyrefined services and connects them with a “glue code” that serves asan adapter in order to transform ingoing and outgoing invocation. Additionally,some differences between domain and retrieved model may appear.The differences should be filled up with new services.3. Interface design –this step is meant to create interfaces[84],but in fact theoutput is a contract that specifies exact input and output for each operationof the service. Also an interface –a representation of the contract–is created.Application of clustering seems to be very promising solution because it base onvery basic human activity–classification [4]. Generally, clustering is meant to reorganizegroups of entities by taking into consideration their similarity and basedon that divide them into more homogenous groups[4]. The similarity can vary asa domain of analysis and can be understood as for instance similarity of propertieswhich is measured with metrics. Method applied in this approach bases onan improved agglomerative hierarchical clustering [4],This technique emphasizesfunctional aspects [4]that are essential in SOA. The technique is presented as aset of processes and an algorithm.2.1.5 Advantages and drawback of Taxonomy AnalysisTaxonomy Analysis analyses code of the migrated application in order to identifyservices and relationships between them.
Page 1 and 2: Master ThesisSoftware EngineeringTh
Page 3 and 4: AbstractContext: Several examples o
Page 5 and 6: List of Figures1.1 Research methodo
Page 7 and 8: List of Tables3.1 Summary of archit
Page 9 and 10: 3.3.1 Definition of Pattern Languag
Page 11 and 12: Chapter 1Introduction1.1 Background
Page 13 and 14: Chapter 1. Introduction 3technique
Page 15 and 16: Chapter 1. Introduction 5was notice
Page 17 and 18: Chapter 1. Introduction 7do not pro
Page 19 and 20: Chapter 1. Introduction 9Chapter 4
Page 21 and 22: Chapter 2. Related Work 11This chap
Page 23 and 24: Chapter 2. Related Work 13(b) Chara
Page 25 and 26: Chapter 2. Related Work 15Figure 2.
Page 27 and 28: Chapter 2. Related Work 17Drawbacks
Page 29 and 30: Chapter 2. Related Work 19Figure 2.
Page 31: Chapter 2. Related Work 21Advantage
Page 35 and 36: Chapter 2. Related Work 252. Applic
Page 37 and 38: Chapter 2. Related Work 274. Mediat
Page 39 and 40: Chapter 2. Related Work 292.3 Summa
Page 41 and 42: Chapter 3. Architectural Patterns 3
Page 83 and 84:
Chapter 3. Architectural Patterns 7
Page 85 and 86:
Chapter 4. Service Oriented Archite
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Chapter 5. Guidelines 1035.1 Patter
Page 115 and 116:
Chapter 5. Guidelines 105Descriptio
Page 117 and 118:
Chapter 5. Guidelines 107Result Con
Page 119 and 120:
Chapter 5. Guidelines 109ContextAn
Page 121 and 122:
Chapter 5. Guidelines 111Result Con
Page 123 and 124:
Chapter 5. Guidelines 113System’s
Page 125 and 126:
Chapter 5. Guidelines 115ViewSchema
Page 127 and 128:
Chapter 5. Guidelines 117ViewViewCo
Page 129 and 130:
Chapter 5. Guidelines 119ViewViewCo
Page 131 and 132:
Chapter 5. Guidelines 121ViewViewPr
Page 133 and 134:
Chapter 5. Guidelines 123FrontendFr
Page 135 and 136:
Chapter 5. Guidelines 125complicati
Page 137 and 138:
Chapter 5. Guidelines 127Concluding
Page 139 and 140:
Chapter 5. Guidelines 129UsecasesTh
Page 141 and 142:
Chapter 5. Guidelines 131puter (ext
Page 143 and 144:
Chapter 5. Guidelines 133Group 3 ma
Page 145 and 146:
Chapter 5. Guidelines 135Output: Du
Page 147 and 148:
Chapter 5. Guidelines 137generation
Page 149 and 150:
Chapter 5. Guidelines 139(a) Fronte
Page 151 and 152:
Chapter 5. Guidelines 141Figure 5.1
Page 153 and 154:
Chapter 5. Guidelines 143Figure 5.1
Page 155 and 156:
Chapter 5. Guidelines 145FrontendSc
Page 157 and 158:
Chapter 6. Conclusion 147There are
Page 159 and 160:
Chapter 6. Conclusion 149RQ.6 How t
Page 161 and 162:
References[1] http://www.soa-manife
Page 163 and 164:
References 153[22] Frank Buschmann,
Page 165 and 166:
References 155[46] Dirk Krafzig, Ka
Page 167 and 168:
References 157[67] Xiaohong Qiu. Bu
show all

Migration of a Chosen Architectural Pattern to Service Oriented ...

Create successful ePaper yourself

Delete template?

Save as template?