12.07.2015 Views

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

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 3. <strong>Architectural</strong> <strong>Pattern</strong>s 37Both presented definitions present architectural pattern as a pattern appliedon level <strong>of</strong> architecture. In turn definition <strong>of</strong> Design <strong>Pattern</strong> given in [35] saysthat:“Design <strong>Pattern</strong> describes a commonly–recurring structure <strong>of</strong> communicatingcomponents that solve a general design problem in a particularcontext.”Other definition [22] says that:“Design patterns are medium–scale patterns. They are smaller inscale than architectural patterns, but are at a higher level than the programminglanguage–specific idioms. The application <strong>of</strong> a design patternhas no effect on the fundamental structure <strong>of</strong> a s<strong>of</strong>tware system,but may have a strong influence on the architecture <strong>of</strong> a subsystem.”<strong>Architectural</strong> patterns are the patterns that have an impact on architecture <strong>of</strong>the whole system while design patterns may have an impact only on subsystems.Even having the definitions, classification <strong>of</strong> a specified pattern <strong>to</strong> a particularcategory is not so obvious. In some specific circumstances a design pattern canbe implemented as an architectural pattern. This can happen when a systemis very specialized and subordinated <strong>to</strong> a specific task that imposes solutionslike design patterns. In this case, elements <strong>of</strong> a design pattern can grow <strong>to</strong> thesize <strong>of</strong> subsystems and determinate architecture. In order <strong>to</strong> provide a betterexplanation <strong>of</strong> this concept, an example imaginary system (“DataProvider”) willbe considered.The “DataProvider” system provides information about individuals <strong>to</strong> requestingand authorized institutions. Information provided by the system canbe general like personal data or detailed like pictures and fingerprints. Database<strong>of</strong> the system contains thousands <strong>of</strong> records and it is distributed over the country.One <strong>of</strong> the most important aspects <strong>of</strong> the system is availability <strong>of</strong> the system andits resources. The system is queried twenty-four hours, seven days a week. Thesystem will be designed as a distributed application. The system has <strong>to</strong> be stableand has <strong>to</strong> have high availability. The description <strong>of</strong> requirements <strong>of</strong> the systemmatches one <strong>of</strong> the design patterns, namely lazy acquisition design pattern. Lazyacquisition design pattern [45] has two very important properties what makes ituseful <strong>to</strong> apply here:1. Availability – all downloadable data are available, but the data is not acquiredin advance. This approach saves resources <strong>of</strong> the system what isespecially important when the system has <strong>to</strong> process a lot <strong>of</strong> data (especiallymultimedia).2. Stability – all resources are acquired only when needed so the system doesnot have <strong>to</strong> overuse memory and other resources. Overview <strong>of</strong> the designpattern is presented on the figure 3.3

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

Saved successfully!

Ooh no, something went wrong!