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 78(b) Logic Centric Services– correspond to algorithms and business ruleslibraries in monolithic systems.The definitions clearly show that there are two types of basic services butin practice, it is very hard to create pure Data Centric Service or pure LogicCentric Service.3. Intermediary Service [46] [31] – are stateless mediators that serve as bridgesbetween services. They may be categorized into Gatways, Adapters, Facadesand functionality adding services. Because they connect very specificservices, reusability of Intermediary services is much lower than reusabilityof Basic Services.4. Public Enterprise Service [46] – Enterprise level public services are veryrare entities. They make available their functionality outside a company inopposite to other types of services. They have to be loosely coupled andwell described on business level. Those issues raise security problems, whichmay occur and generate more problems than services within a company.5. Process Centric Service [31] – encapsulates and executes a part of processlogicof a company. This type of service is the most complex. ProcessCentric Service is less reusable and does not contribute too much to functionalinfrastructure of SOA due to its complexity and narrowed usage [46].Nevertheless, its process control is essential for the organization [34]. Inspite of its complex structure and lowered reusability, Process Centric Servicebring some benefits, which are especially important in applications thathave to guarantee simultaneous access for many users. Those benefits are:(a) Process encapsulation [46] [31][59] [13]– Process Centric Service hidesand encapsulates hermetically structure of the process. This supportsdesigning of architecture may be expressed as a set of Process CentricServices implementing processes. Encapsulation improves testabilityof the system and allows different teams to work on different parts ofthe system simultaneously.(b) Load balancing simplification [46]– clear separation of processes supportsparallel executing what is very important for applications thatare characterised by short response time.(c) Support for multi-channel application [46] –multi-channel applicationsare [86] applications enabling users to access them by using a variety ofdevices like personal computer, mobile phones or any other device thatcan connect to the web. Each of these devices is called ’a channel’.In fact, multi-channel application is a set of interfaces for the same
Chapter 4. Service Oriented Architecture 79logic. Application of SOA to multi-channel application simplifies reuseof logic of application by encapsulation of process logic in ProcessCentric Services.(d) Separation of process logic [46] [31] [59] –process logic separation is aprecondition for efficient process management.Architects that consider usage of Process Centric Services have to carefullyseparate process from process control activities. Clear separation simplifiesmaintenance and reorganization, which due to possible changes of businessprocess may appear more frequent.From all of the service types mentioned before, only Basic Service is a mandatorypart of SOA. All the remaining Services are meant to help during developmentand maintenance [46].The relationship between SOA and its elements is described in figure 4.14.2.4 Structure of a serviceA service is not a simple entity. It is composed of following elements [46]:Service contract – may be described as a ’technical interface’ which providestechnical constrains, requirements and any other information that is meant tobe public [31]. A contract may consist also from a set of technical documentsdescribing properties of the service. Those documents can be definition of servicedescribed with Web Service Definition Language (WSDL), XML Schema definitionor Web Service (WS) policy. The purpose [46] of documents like WSDLdefinition is to provide technology independence by describing further level of abstraction.The most general goal of a contract is to set boundaries of the service[59].Implementation — is a realisation of the contract. The realization is providedby business logic and appropriate data.Interface —exposes functionality of service to clients connected via network.An interface consists of two parts. The first is a description, which is also a partof a service contract. The second is a physical representation in the shape of aservice stub that is a part of service’s client.
- 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
- Page 85 and 86: Chapter 4. Service Oriented Archite
- Page 87: 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 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
Chapter 4. <strong>Service</strong> <strong>Oriented</strong> Architecture 79logic. Application <strong>of</strong> SOA <strong>to</strong> multi-channel application simplifies reuse<strong>of</strong> logic <strong>of</strong> application by encapsulation <strong>of</strong> process logic in ProcessCentric <strong>Service</strong>s.(d) Separation <strong>of</strong> process logic [46] [31] [59] –process logic separation is aprecondition for efficient process management.Architects that consider usage <strong>of</strong> Process Centric <strong>Service</strong>s have <strong>to</strong> carefullyseparate process from process control activities. Clear separation simplifiesmaintenance and reorganization, which due <strong>to</strong> possible changes <strong>of</strong> businessprocess may appear more frequent.From all <strong>of</strong> the service types mentioned before, only Basic <strong>Service</strong> is a manda<strong>to</strong>rypart <strong>of</strong> SOA. All the remaining <strong>Service</strong>s are meant <strong>to</strong> help during developmentand maintenance [46].The relationship between SOA and its elements is described in figure 4.14.2.4 Structure <strong>of</strong> a serviceA service is not a simple entity. It is composed <strong>of</strong> following elements [46]:<strong>Service</strong> contract – may be described as a ’technical interface’ which providestechnical constrains, requirements and any other information that is meant <strong>to</strong>be public [31]. A contract may consist also from a set <strong>of</strong> technical documentsdescribing properties <strong>of</strong> the service. Those documents can be definition <strong>of</strong> servicedescribed with Web <strong>Service</strong> Definition Language (WSDL), XML Schema definitionor Web <strong>Service</strong> (WS) policy. The purpose [46] <strong>of</strong> documents like WSDLdefinition is <strong>to</strong> provide technology independence by describing further level <strong>of</strong> abstraction.The most general goal <strong>of</strong> a contract is <strong>to</strong> set boundaries <strong>of</strong> the service[59].Implementation — is a realisation <strong>of</strong> the contract. The realization is providedby business logic and appropriate data.Interface —exposes functionality <strong>of</strong> service <strong>to</strong> clients connected via network.An interface consists <strong>of</strong> two parts. The first is a description, which is also a part<strong>of</strong> a service contract. The second is a physical representation in the shape <strong>of</strong> aservice stub that is a part <strong>of</strong> service’s client.
Change language