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 4. Service Oriented Architecture 90pattern), design of a single component (typical design pattern) or maybe designof a process (process pattern)(see section 3.1.1). The distinction grows in importancewhen architectural knowledge is taken into consideration. ArchitecturalKnowledge is meant to describe an architecture and rationale behind decisionmade during architecture designing [9]. The decisions do not refer only to rationaleof fine-grained components but also to a “big picture” – system architecture.Architecture requires more detailed studies, due to a large-scale impact on system.This subsection describes SOA architectural patterns in following manner..1. SOA patterns– presents a problem with SOA architectural patterns andpresents results of pattern investigation.2. The target architecture – presents the target architecture that is a result ofcombination of patterns found in section 4.6.14.6.1 SOA patternsThe book “SOA –Design Patterns” [32] is the largest and the most completesource of pattern in SOA domain[54]. Patterns presented in the book belong todesign patterns, but their descriptions question this adherence. The problem risesfrom definition of pattern and design pattern used by T.Erl in this book.According to T.Erl pattern [32]“provides a proven solution to a common problemindividually documented in a consistent format and usually as part of a largercollection” what corresponds to the definition of pattern presented in section 3.1.1.Design pattern is defined as follows [32]: “Patterns in the IT world that revolvearound the design of automated systems are referred to as design patterns.”.Thisdefinition can be also applied to other types of patterns. All the pattern describedin section 3.1.1 “revolve” around design of automated system, not only designpatterns.SOA patterns are described also in“Patterns: Service–Oriented Architectureand Web Services”[30] but they refer to Enterprise Application Integration. Integrationis out scope of this thesis.Selection of architectural patternsThe target architecture will be build on architectural patterns. Usage of the book“SOA –Design Patterns” [32] as a source of architectural patterns requires furtherstudies.Analysis of patterns presented by T. Erl (see [32]) results in division of presentedpattern into four categories. The categories are following
Chapter 4. Service Oriented Architecture 911. Architectural Patterns – describe general solution for a whole architecture ora part of architecture. Those patterns refer to structure and communicationwithin the system.2. Design Patterns – provide solution for a fine-grained problems that has alocal impact on the architecture3. Process patterns – describe patterns for processes that should be applied inorder to gain particular outcome.4. SOA Concepts – describe issues that already are part of Service OrientedArchitecture5. Technical Issues – describe both Design and Architectural patterns whichare build-in exiting frameworks and supported by external technologies.Table 4.1 presents summary of pattern assigned to particular categories.Pattern TypeAmountArchitectural 14Design 28Process 12Technology issue 9SOA concept 10Total 73Table 4.1: Summary of pattern typesExamples of pattern that were not classified as architectural (see table 4.2 forsummary):1. Canonical Expression –assumes up-front analysis in order to standardisenaming conventions, which is later applied to service contracts. A goodexample of Canonical Expression is CRUD.Motivation: Canonical Expression was classified as a Process pattern, becauseit defines a process – analysis.2. Service Encapsulation –defines a service as a containing logic entity. Thelogic can be encapsulated in a new service as well as become a part of anexisting service.Motivation: Encapsulation of logic in a service is a basic concept ofSOA,therefore there is nothing what could be considered as a pattern. SeeService Definition 4.2.1
- 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
- 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: 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 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
Chapter 4. <strong>Service</strong> <strong>Oriented</strong> Architecture 90pattern), design <strong>of</strong> a single component (typical design pattern) or maybe design<strong>of</strong> a process (process pattern)(see section 3.1.1). The distinction grows in importancewhen architectural knowledge is taken in<strong>to</strong> consideration. <strong>Architectural</strong>Knowledge is meant <strong>to</strong> describe an architecture and rationale behind decisionmade during architecture designing [9]. The decisions do not refer only <strong>to</strong> rationale<strong>of</strong> fine-grained components but also <strong>to</strong> a “big picture” – system architecture.Architecture requires more detailed studies, due <strong>to</strong> a large-scale impact on system.This subsection describes SOA architectural patterns in following manner..1. SOA patterns– presents a problem with SOA architectural patterns andpresents results <strong>of</strong> pattern investigation.2. The target architecture – presents the target architecture that is a result <strong>of</strong>combination <strong>of</strong> patterns found in section 4.6.14.6.1 SOA patternsThe book “SOA –Design <strong>Pattern</strong>s” [32] is the largest and the most completesource <strong>of</strong> pattern in SOA domain[54]. <strong>Pattern</strong>s presented in the book belong <strong>to</strong>design patterns, but their descriptions question this adherence. The problem risesfrom definition <strong>of</strong> pattern and design pattern used by T.Erl in this book.According <strong>to</strong> T.Erl pattern [32]“provides a proven solution <strong>to</strong> a common problemindividually documented in a consistent format and usually as part <strong>of</strong> a largercollection” what corresponds <strong>to</strong> the definition <strong>of</strong> pattern presented in section 3.1.1.Design pattern is defined as follows [32]: “<strong>Pattern</strong>s in the IT world that revolvearound the design <strong>of</strong> au<strong>to</strong>mated systems are referred <strong>to</strong> as design patterns.”.Thisdefinition can be also applied <strong>to</strong> other types <strong>of</strong> patterns. All the pattern describedin section 3.1.1 “revolve” around design <strong>of</strong> au<strong>to</strong>mated system, not only designpatterns.SOA patterns are described also in“<strong>Pattern</strong>s: <strong>Service</strong>–<strong>Oriented</strong> Architectureand Web <strong>Service</strong>s”[30] but they refer <strong>to</strong> Enterprise Application Integration. Integrationis out scope <strong>of</strong> this thesis.Selection <strong>of</strong> architectural patternsThe target architecture will be build on architectural patterns. Usage <strong>of</strong> the book“SOA –Design <strong>Pattern</strong>s” [32] as a source <strong>of</strong> architectural patterns requires furtherstudies.Analysis <strong>of</strong> patterns presented by T. Erl (see [32]) results in division <strong>of</strong> presentedpattern in<strong>to</strong> four categories. The categories are following