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 ...

12.07.2015 Views

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

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!