Migration of a Chosen Architectural Pattern to Service Oriented ...
Migration of a Chosen Architectural Pattern to Service Oriented ... Migration of a Chosen Architectural Pattern to Service Oriented ...
Chapter 2. Related Work 24Advantages1. Identifies relations between services2. The technique is systematic3. Execution of the technique can be performed semi automatic4. Provides a lot of information about the migrated systemDrawbacks1. The technique does not consider properties of architecture of migrated system2. Requires documentation - the documentation of an old system may be missingor not maintained2.2 Other approachesThe approaches described in the previous section present complex and generictechniques meant to migrate a legacy system to SOA. Their description did notgo into details because the techniques need complex tailoring for each particularmigration. The next group of techniques migrates systems toward SOA emphasisingarchitecture of the migrated system. This section presents three differentapproaches utilising benefits brought by architectural patterns. The first approachis a try of standardisation of migration. In fact, the approach does notrefer only to migration but also to other activities changing the application. Thefact that this is a try of standardisation makes this technique worth to describe.The next example presents modification of architectural pattern (PCBMER) inorder to adjust it to SOA. The last approach presents how to create SOA basedon Peer–to–Peer architectural pattern2.2.1 Architectural–Driven ModernisationArchitectural Driven Modernisation is [58] “the process of understanding andevolving existing software assets for the purpose of software improvement; modifications;interoperability; re–factoring; restructuring; reuse; porting; migration;translation into another language; and enterprise application integration.” Theprocess describes modernisation of an architecture on three levels of abstraction[79]:1. Technical Architecture Modernisation –includes migration between bothplatform and language or just platform or language. The migration may becaused by technology obsolesce, lack of further modernisation and maintenancepossibilities or other technological factors.
Chapter 2. Related Work 252. Application and Data Architecture Modernisation –is modernisation on ahigher level of abstraction that includes changes to architecture of the systemand may require changes in structure of the stored data. The modernisationincludes also Technical Architecture Modernisation. The modernisationmay be needed, because the application due to incremental changesmay become monolithic and impossible to maintain block of code.3. Business Architecture Modernisation –is the most complex and the mostrisky type of modernisation. The risk is strengthening by lack of any standardisationin the domain of migration of legacy assets. The complexity isa result of the scope of the modernisation process. The result includes bothpreviously described modernisations.Analysis of the modernisation processes within the context of Service OrientedArchitecture allows making an assumption that the final version of the standardwill align to migration towards SOA due to mapping between SOA structure andmodernisation scope. While modernisation on a technology level correspondsintroduction of SOA infrastructure into the application, modernisation on applicationand data architecture matches changes required during identification andspecification of services.Substandards – However Architecture–Driven Modernisation is presented asone standard, in fact it is a set of sub–standards that include different aspects ofmodernisation. There are following standards [64]:1. ADM: Knowledge Discovery Meta–Model (KDM) –establishes an initialmeta–model that describes the structure of the system and data model,but does not describe the system below procedural level.Status ow work: Adopted in 20062. ADM: Abstract Syntax Tree Meta–Model (ASTM) –starts where KDM finishes,namely ASTM describes the system below procedural level what guaranteesa full representation of the system.Status ow work: Rolled out in 20093. ADM: Pattern Recognition –tires to identify structural aspects of the systemby recognising both pattern and anti–patterns in order to define requirementsand opportunities for refactoring and transformation of the system.Status ow work: Work started in 20094. ADM: Structured Metrics Package (SMM) –uses KDM in order to derive aset of various metrics describing different attributes of the system. Metriccoverage includes technical, functional and architectural aspects of the system.Status ow work: Rolled out in 2009
- 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 and 32: Chapter 2. Related Work 21Advantage
- Page 33: Chapter 2. Related Work 23between a
- 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 43 and 44: Chapter 3. Architectural Patterns 3
- Page 45 and 46: Chapter 3. Architectural Patterns 3
- Page 47 and 48: Chapter 3. Architectural Patterns 3
- Page 49 and 50: Chapter 3. Architectural Patterns 3
- Page 51 and 52: Chapter 3. Architectural Patterns 4
- Page 53 and 54: Chapter 3. Architectural Patterns 4
- Page 55 and 56: Chapter 3. Architectural Patterns 4
- Page 57 and 58: Chapter 3. Architectural Patterns 4
- Page 59 and 60: Chapter 3. Architectural Patterns 4
- Page 61 and 62: Chapter 3. Architectural Patterns 5
- Page 63 and 64: Chapter 3. Architectural Patterns 5
- Page 65 and 66: Chapter 3. Architectural Patterns 5
- Page 67 and 68: Chapter 3. Architectural Patterns 5
- Page 69 and 70: Chapter 3. Architectural Patterns 5
- Page 71 and 72: Chapter 3. Architectural Patterns 6
- Page 73 and 74: Chapter 3. Architectural Patterns 6
- Page 75 and 76: Chapter 3. Architectural Patterns 6
- Page 77 and 78: Chapter 3. Architectural Patterns 6
- Page 79 and 80: Chapter 3. Architectural Patterns 6
- Page 81 and 82: Chapter 3. Architectural Patterns 7
- Page 83 and 84: Chapter 3. Architectural Patterns 7
Chapter 2. Related Work 252. Application and Data Architecture Modernisation –is modernisation on ahigher level <strong>of</strong> abstraction that includes changes <strong>to</strong> architecture <strong>of</strong> the systemand may require changes in structure <strong>of</strong> the s<strong>to</strong>red data. The modernisationincludes also Technical Architecture Modernisation. The modernisationmay be needed, because the application due <strong>to</strong> incremental changesmay become monolithic and impossible <strong>to</strong> maintain block <strong>of</strong> code.3. Business Architecture Modernisation –is the most complex and the mostrisky type <strong>of</strong> modernisation. The risk is strengthening by lack <strong>of</strong> any standardisationin the domain <strong>of</strong> migration <strong>of</strong> legacy assets. The complexity isa result <strong>of</strong> the scope <strong>of</strong> the modernisation process. The result includes bothpreviously described modernisations.Analysis <strong>of</strong> the modernisation processes within the context <strong>of</strong> <strong>Service</strong> <strong>Oriented</strong>Architecture allows making an assumption that the final version <strong>of</strong> the standardwill align <strong>to</strong> migration <strong>to</strong>wards SOA due <strong>to</strong> mapping between SOA structure andmodernisation scope. While modernisation on a technology level correspondsintroduction <strong>of</strong> SOA infrastructure in<strong>to</strong> the application, modernisation on applicationand data architecture matches changes required during identification andspecification <strong>of</strong> services.Substandards – However Architecture–Driven Modernisation is presented asone standard, in fact it is a set <strong>of</strong> sub–standards that include different aspects <strong>of</strong>modernisation. There are following standards [64]:1. ADM: Knowledge Discovery Meta–Model (KDM) –establishes an initialmeta–model that describes the structure <strong>of</strong> the system and data model,but does not describe the system below procedural level.Status ow work: Adopted in 20062. ADM: Abstract Syntax Tree Meta–Model (ASTM) –starts where KDM finishes,namely ASTM describes the system below procedural level what guaranteesa full representation <strong>of</strong> the system.Status ow work: Rolled out in 20093. ADM: <strong>Pattern</strong> Recognition –tires <strong>to</strong> identify structural aspects <strong>of</strong> the systemby recognising both pattern and anti–patterns in order <strong>to</strong> define requirementsand opportunities for refac<strong>to</strong>ring and transformation <strong>of</strong> the system.Status ow work: Work started in 20094. ADM: Structured Metrics Package (SMM) –uses KDM in order <strong>to</strong> derive aset <strong>of</strong> various metrics describing different attributes <strong>of</strong> the system. Metriccoverage includes technical, functional and architectural aspects <strong>of</strong> the system.Status ow work: Rolled out in 2009
Change language