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

More documents

Recommendations

Info

Chapter 4. Service Oriented Architecture 923. Multi–Channel Endpoint –is a Service Inventory Endpoint variation thatallows consuming services using different channels. The channel can be forinstance a PC or a mobile phone with an access to Internet.Motivation: the pattern does not provide anything what may stronglyaffect architecture. The problem can be also solved by creation of a set ofsingle channel service. This is a matter of a design.4. Version Information – the pattern advices introduction of a service versionto service contracts.Motivation: The solution is:“Use version annotation”. Annotation is anXML element therefore this is a technical issuePattern NameCanonical ExpressionService EncapsulationMulti–Channel EndpointVersion informationTypeProcessSOADesignOthersTable 4.2: Examples of rejected SOA patternsDescription of SOA architectural patternsThis subsection presents briefly description of identified architectural pattern inSOA. Description of each architectural is followed by “Rationale”. Rationale motivatesselection of the pattern as an architectural. Additionally two patterns wereclassified as duplicates. Canonical Schema appears to be Schema Centralizationand Rules Centralisation is in fact Validation Abstraction.1. Service Layers –Services delivered by different teams may contain inconsistenciesand redundant functionalities. The pattern divides service inventoryinto logical layers containing services with similar functionality. Each layercontains one specific and abstract concern. The pattern enforces usage ofat least two layers-one contains basic service, the other contains composedservices.Rationale: The pattern corresponds to Layers architectural pattern.2. Canonical Protocol –Service can be provided by different vendors. Thevendors can use different languages and communication protocols. Howeverthe difference in language is not so important, the differences in communicationprotocols are. Different communication protocols limit number ofpotential consumers and introduce the need of protocol bridging. Applicationof the pattern enforces usage of one communication protocol as a main
Chapter 4. Service Oriented Architecture 93mean of communication. Pattern application eliminates bridging servicesin the system what improves performance and maintainability. In order toincrease benefits associated with the pattern, architects should consider usageof widely supported and vendor independent communication protocolslike SOAP.Rationale:Enforcing usage of one specific protocol by every single servicein an inventory has a large impact on communication within the system.3. Canonical Schema –Many services perform operation on the same data thatare modeled differently by different vendors or teams. Those differencesincrease development efforts and make design more complex. Additionally,the transformation between different models introduces performance drop.The pattern standardizes data model for information within the inventory.The motivation behind the pattern is to avoid translation between differentdefinitions of the same data and eliminate data definition redundancy acrossthe system.Rationale:Forces services to use predefined schemas. Service cannot defineown ’implementation’. The pattern influences every service in the system.4. Utility Abstraction –Services, even those that do not provide redundantfunctionality may perform some common operation. Those operations areredundant. The redundancy requires additional effort for testing and maintenance.Utility Abstraction defines one layer containing common utilityservices. The layer contains mainly services without business concern, thereforein opposite to business-based services, utility services are developedmainly by architects and developers what raises problems related to contentof such service. Teams need good communication in order to avoidredundant services.Rationale:Enriches structure of Service Layers, what also changes flow ofmessages in the system.5. Entity Abstraction –Many business processes uses the same business entities.It is very likely that the functionality is implemented several times indifferent services. This raises problems with maintenance and testability.Entity Abstraction introduces another layer into layered structure. Thelayer contains services performing operation on business entities.Rationale: See Utility Abstraction rationale.6. Process Abstraction –Grouping of business process services together withnon-business process services makes harder maintenance of both types ofthe services. It is harder to change processes and maintain functionality
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 and 34:
Chapter 2. Related Work 23between a
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 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52: Chapter 3. Architectural Patterns 4
Page 85 and 86: Chapter 4. Service Oriented Archite
Page 101: Chapter 4. Service Oriented Archite
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 ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?