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 5. Guidelines 106Context An application is composed of many services that are developedby different teams.Forces(a) Many services provide similar functionality.(b) Functionality of each service is different.(c) High cohesion of services has to be kept.Solution The pattern divides service inventory into logical layers containingservices with similar functionality. Each layer contains one specificand abstract concern. The pattern enforces usage of at least two layers-onecontains basic service, the other contains composed services.Result Context The application is divided into several (at least two)service layers that support maintainability and further development of thisapplication.2. Name Canonical ProtocolProblem Service can be provided by different vendors. The vendors canuse different languages and communication protocols. However the differencein language is not so important, the differences in communicationprotocols are. Different communication protocols limit number of potentialconsumers and introduce the need of protocol bridging.Context An application is composed of services that are delivered bydifferent vendors.Forces(a) Services need to communicate with each other(b) A main way of communication needs to be established(c) A way of communication cannot limit functionality of servicesSolution Application of the pattern enforces usage of one communicationprotocol as a main mean of communication. Pattern application eliminatesbridging services in the system what improves performance and maintainability.In order to increase benefits associated with the pattern, architectsshould consider usage of widely supported and vendor independent communicationprotocols like SOAP
Chapter 5. Guidelines 107Result Context The system has one main way of communication. Eachservice of the system provide interface for this way of communication.3. Name Canonical SchemaProblem Many services perform operation on the same data that aremodeled differently by different vendors or teams. Those differences increasedevelopment efforts and make design more complex. Additionally,the transformation between different models introduces performance drop.ContextApplication uses communication protocolsForces(a) Schema of the data may change over time.(b) The schema is used in many services from different inventories.(c) Schema needs to be easily extended.Solution The pattern standardizes data model for information within theinventory. The motivation behind the pattern is to avoid translation betweendifferent definitions of the same data and eliminate data definitionredundancy across the systemResult Contextand maintainable.System has a centralized schema that easily accessible4. Name Policy CentralisationProblem Services may require to process individual polices. Policies mayrefer to security, transaction requirements and Quality-of-Services. Replicationof policies across inventories brings redundancy and problems withsynchronization of changes to the policies.ContextThe system is composed of services that need to process policies.Forces(a) Number of services using policies is not fixed(b) The policies change over time
- 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
- Page 85 and 86: Chapter 4. Service Oriented Archite
- Page 87 and 88: Chapter 4. Service Oriented Archite
- Page 89 and 90: Chapter 4. Service Oriented Archite
- Page 91 and 92: Chapter 4. Service Oriented Archite
- Page 93 and 94: Chapter 4. Service Oriented Archite
- Page 95 and 96: Chapter 4. Service Oriented Archite
- Page 97 and 98: Chapter 4. Service Oriented Archite
- Page 99 and 100: Chapter 4. Service Oriented Archite
- Page 101 and 102: Chapter 4. Service Oriented Archite
- Page 103 and 104: Chapter 4. Service Oriented Archite
- Page 105 and 106: Chapter 4. Service Oriented Archite
- Page 107 and 108: Chapter 4. Service Oriented Archite
- Page 109 and 110: Chapter 4. Service Oriented Archite
- Page 111 and 112: Chapter 4. Service Oriented Archite
- Page 113 and 114: Chapter 5. Guidelines 1035.1 Patter
- Page 115: Chapter 5. Guidelines 105Descriptio
- 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
Chapter 5. Guidelines 107Result Context The system has one main way <strong>of</strong> communication. Eachservice <strong>of</strong> the system provide interface for this way <strong>of</strong> communication.3. Name Canonical SchemaProblem Many services perform operation on the same data that aremodeled differently by different vendors or teams. Those differences increasedevelopment efforts and make design more complex. Additionally,the transformation between different models introduces performance drop.ContextApplication uses communication pro<strong>to</strong>colsForces(a) Schema <strong>of</strong> the data may change over time.(b) The schema is used in many services from different inven<strong>to</strong>ries.(c) Schema needs <strong>to</strong> be easily extended.Solution The pattern standardizes data model for information within theinven<strong>to</strong>ry. The motivation behind the pattern is <strong>to</strong> avoid translation betweendifferent definitions <strong>of</strong> the same data and eliminate data definitionredundancy across the systemResult Contextand maintainable.System has a centralized schema that easily accessible4. Name Policy CentralisationProblem <strong>Service</strong>s may require <strong>to</strong> process individual polices. Policies mayrefer <strong>to</strong> security, transaction requirements and Quality-<strong>of</strong>-<strong>Service</strong>s. Replication<strong>of</strong> policies across inven<strong>to</strong>ries brings redundancy and problems withsynchronization <strong>of</strong> changes <strong>to</strong> the policies.ContextThe system is composed <strong>of</strong> services that need <strong>to</strong> process policies.Forces(a) Number <strong>of</strong> services using policies is not fixed(b) The policies change over time