A comparison of Architectural Patterns: A study of a real world application

(1)

Degree project in Computer Science Second cycle

A comparison of Architectural Patterns

Hwoh Hei James Hau

(2)

A comparison of Architectural Patterns

A study of a real world application

HWOH HEI JAMES HAU

Master’s Thesis at NADA Supervisor: Karl Meinke Examiner: Jens Lagergren

TRITA xxx yyyy-nn

(3)

(4)

Abstract

This work gives an insight into how architectural patterns are chosen from the working life perspective. With all of the existing architectural patterns it can be hard to decide which pattern to choose. Even though an architectural pattern describes in which circumstances it should be applied, it doesn’t necessary result in it being applied when the oppor- tunity occurs. This can be due to factors which are much more clearly apparent in the working life such as time, capital and difficulty of implementation.

In this Master Thesis, a description selection of important areas in architectural patterns are given and two patterns, Service Oriented Architecture (SOA) and Event-Driven Architecture (EDA) will also be described in minor versions. This will help the reader to get a better understanding of architectural patterns and important factors. By studying a software integration project it gave a clear view of how the choice of an architectural pattern was decided in working life. Factors such as time limited the prototype design and its implementation of the architectural patterns. Even more factors limited the choice of architectural patterns. Necessity and what’s possible, because of the existing systems, takes overhand and limits the selection of architectural patterns heavily.

With every project being very specific, and with working life factors such as time and capital, it became evident that focus was on deliver- ing a system which fulfills the requirements rather than implementing the "best" possible application. We found it more important to focus on when an architectural pattern should be implemented weighing the benefits against the disadvantages. It becomes clear that comparing architectural pattern may not be worth the effort. Instead the developers should focus more on what is possible in the system environment.

(5)

Referat

En jämförelse av Arkitektoniska mönster

Detta arbete ger en inblick i hur arkitektoniska strategier väljs från arbetslivs perspektivet. Med alla arkitektoniska strategier som finns kan det vara svårt att avgöra vilken strategi man ska välja. Även om en arkitektonisk strategi beskriver under vilka omständigheter de bör tillämpas behöver det inte betyda att strategin tillämpas när ögonblicket uppstår.

Detta kan bero på faktorer som är mycket mer tydligt i arbetslivet såsom tid, kapital och svårigheten att implementera strategin.

Beskrivningen om ett urval av viktiga områden i arkitektoniska strategier ges och två strategier, Tjänst Orienterad Strategi(SOA) och Hän- delsestyrd Strategi (EDA) kommer också att beskrivas i lägre detalj.

Detta kommer att hjälpa läsaren att få en bättre förståelse av arkitektoniska strategier och viktiga faktorer. Genom att studera ett projekt om system integration så gavs det en tydlig bild av hur valet av en arkitektonisk strategi görs i arbetslivet. Det var inte endast faktorer som tid som begränsade prototype designen och valet av de arkitektoniska strategierna, det var flera faktorer som påverkade valet av arkitektoniska strategier. Nödvändighet och vad som var möjligt på grund av de befintliga systemen, visade sig vara stora faktorer vilket begränsade valet av arkitektoniska strategier kraftigt.

Varje projekt är väldigt specifikt och med arbetslivs faktorer som tid och kapital blev det uppenbart att fokus låg på att leverera ett system som uppfyllde kraven i stället för att implementera det “bästa”

möjliga systemet. Jag fann det viktigare att diskutera med fokus på när en arkitektonisk strategi bör genomföras när man väger fördelarna mot nackdelarna. Det blev tydligt att jämföra arkitektoniska strategier kan potentiellt inte vara värt den ansträngning som krävs. Istället bör systemutvecklare fokusera mer på vad som är möjligt i systemets miljö.

(6)

Introduction

(11)

(12)

Chapter 1

Thesis

In this chapter we will describe the purpose and content of this Master Thesis.

This is the final work for a Master of Computer Science at the Royal Institute of Technology in Stockholm (KTH), Sweden.

1.1 Background

Architectural patterns are an important part of software development and the knowledge of different patterns has become more and more popular amongst computer scientists and system developers. Architectural patterns offer solutions to the developers in well-known problems such as how to abstract their task, organize functionalities and how different modules such as the user interface(UI) and the data storage should interact with each other. But nowadays there are so many different patterns and new patterns are still being designed, it is impossible to know all the different architectural patterns and there is no method of deciding which pattern to apply to a given situation when several patterns could be applied. It is very common that the software developers themselves decide which architectural pattern to use and it sometimes comes down to preference and experience of the pattern instead of how well the architectural pattern actually fits with their current task.

1.2 Goals

The goal of this master thesis is to be able to provide a method to differentiate between different architecture patterns and to help the developer in the choice of which pattern fits the given task best. The goal is to be able to decide how to compare different architectural patterns in working life. There will be a case study given by Mediasmiths where we will evaluate how the decision of software design is made and which requirements may interfere with the selection of software design.

Based on the experience of a real case study we will try to create a method. The case study given by Mediasmiths will be a software development case.

(13)

CHAPTER 1. THESIS

1.3 Problem statement

• What do we have to consider when deciding which architectural pattern we can and should use in working life when developing software?

• How can we decide which architectural pattern is the most suitable one for our software design?

• Can we develop a method to help developers with the decisions of which architectural patterns to apply in a working life context?

1.4 Scope

This Master thesis will not cover all architectural patterns, since there are too many patterns. Instead a small selection of patterns will be made. The goal is to make the method as general as possible. The method which will be created will not be the definitive answer to the problem statement but give an example of how an evaluation can be made and also have guidelines in the decision making.

The method should be considered an heuristic method. The focus is placed in the context of working life and not in the academic world, where a lot of factors, which have a huge role in working life, are not applicable. The focus on programming language and development environment will be as small as possible. The thesis will only view the problem from an Object-Oriented Programming view.

1.5 Case: Prototype project

Since the selection of architectural pattern is so vast, the thesis will introduce only a few architectural patterns. These patterns will be discussed in terms of complexity in implementation, strengths and weaknesses. A case study will be presented and design prototypes will be made. These prototypes will also be discussed in the context of how well they fit with this specific case. This specific case will be a real case study provided by Mediasmiths. A requirement specification of the case study will be given as well. A small project of the case study will be made where we will make an implementation of the prototype and evaluate if the selection of the prototype design was good considering the circumstances of the project. If not, another prototype design will be chosen and/or the prototype will be adjusted.

After the project has reached its end we will make a summary of how well the prototype design fit the project. From this experience we hope to be able to find specific factors which need thorough consideration when an architectural pattern is selected. With the experience of the case study we hope to be able to create a method to compare and decide the best fitting architectural pattern for a given task in the working life.

(14)

1.6. THESIS CONTENTS

1.6 Thesis contents

The outline of the thesis is organized as follows: Part II, the Theory, will describe some important factors in software architecture and give an definition of what Ser- vice Oriented Architecture and Event Driven Architecture patterns are. In Part III , the Prototype Project, the project will be described from requirement to design and implementation. Finally there will be an evaluation of the project results. Part IV will present results from the prototype project and if we can make any conclusions from the results which may give the answer to the goals. We conclude with a discussion about the project results.

1.7 Target audience

This thesis is written for aspiring software developers and individuals who have an interest in software architecture. This thesis will help developers with an academic background to prepare for the working life. With this thesis they will hopefully get more prepared for how the real world looks like and come to understand that the academic world is very much different than the real world. Knowledge in software development is not required but will help to fully understand this thesis.

(15)

(16)

Part II

Theory

(17)

(18)

Chapter 2

The viewpoint of patterns

There are several opinions of what the definition is for an architectural pattern and a design pattern. We will in this chapter offer the thesis viewpoint of the definition of patterns. A brief description of patterns will give a better understanding to the reader and will make it easier to understand in which context the patterns are used in.

2.1 Architectural pattern

An architectural pattern is a high level design of how elements or components are interconnected. It may show predefined sub-system, their responsibilities and their relationships amongst each other. An architectural pattern is a way to abstract the elements and components so the system becomes easier to understand, modulate and describe. It does not show how each element or component is designed itself, just how it may be used and for what purpose. It’s similar to a class in Object- Oriented Programing with a public interface while the private interface is not shown for the outside world.

“An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used. A pattern can be thought of a set of constraints on an architecture- on the element types and their pattern of interaction and these constraints define a set or family of architectures that satisfy them.”

Frank Buschmann The architectural pattern offers a solution to a specific problem in a specific context. There are many architectural patterns used as a solution for the same problem but they may vary in their benefits and weaknesses like cost, security, high-availability and performance.

(19)

CHAPTER 2. THE VIEWPOINT OF PATTERNS

2.2 Design pattern

An architectural pattern and a design pattern are both solutions to re-occurring problems. The difference is that a design pattern is a much more detailed view of an element. While the architectural pattern describes the top view, a design pattern shows the classes and interfaces needed to create the element. Design patterns are becoming more and more important in software development since they are proven solutions and save research and testing time which means we can focus on new development instead.

2.3 Benefits with patterns

A pattern needs to be flexible enough to be able to be applied to several similar, but still different, problems. At the same time it must be specified clear enough so the pattern is not misused in a context where it does not contribute to the solution of the problem.

A pattern describes three main parts:

1. Context - In which environment does the problem occur.

2. Problem - Description of the existing problem which exists in the context.

3. Solution - The solution with its advantages and disadvantages to the problem in the given context.

Patterns are tried solutions to problems which may reoccur. Patterns describe the problem in such a way that we know what the requirements are, the benefits and the weaknesses.

Patterns make it more efficient to communicate between designers and developers. By telling a software professional which patterns are to be used or used in a system, the person can picture the high-level design of the system.

2.4 Methodology to compare Architectural Patterns

We have not succeeded in finding any methodology for comparing architectural patterns. However Kazman[1] describes a method for understanding the tradeoffs when dealing with architecture of software systems. We will describe this method briefly.

The Architecture Tradeoff Analysis Method works by evaluating different attributes and how they affect other attributes when altering the architecture of the software system in anyway. By doing several iterations where each iteration is split up into four main phases we understand how different requirements and changes affect different attributes. Attributes are often connected to each other and by changing the architecture to improve an attribute it may come with downsides to other attributes.

(20)

2.5. FURTHER READING

An iteration is made of four phases.

1. Scenario & Requirement Gathering – In this phase we collect different scenarios, requirements and constraints for the software. These can be gathered from different analyses, from the stakeholders and more.

2. Architectural Views & Scenario Realization – By describing the architectural view and understand how it will react to different input we can theoretically do trials. Several architectural views can be created or altered in this phase.

In this phase we perform the different scenarios with each of the architectures and document the results.

3. Model Building & Analyzes – By performing performance analyses we can see if the architectural views of the software fulfill the requirements set in phase 1. By having the analyses early in the design processes we can quickly apply changes and compare the different architectural views. This also increases the chance of discovering potential dangers and areas to be aware of. If we would estimate the system availability we can get an average result by creating and solving a Markov model. A Markov model can be described as a model used to predict a future status by its current status without knowing old statuses.

4. Tradeoffs – The final phase tries to summarize which attributes were affected in the architectural views and how those changes affected other attributes.

With this information we can decide which tradeoffs to perform by having theoretical weight behind the decisions. If all requirements and constraints are not satisfied we can perform another iteration.

2.5 Further reading

Perhaps the most famous book about design patterns is “Design Patterns: Elements of Reusable Object-Oriented Software”[2] by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. The book describes common software design problems and had (and still has) a large influence of design patterns when it was released in 1994 .The design problems and patterns are described in detail and by examples.

The authors are sometimes called “The Gang of Four” and the book is sometimes called “The GoF book” because of its long title.

Another book is “Head First Design Patterns”[3] by Eric Freeman & Elisabeth Freeman and more. It’s a great book about design patterns with examples based around Java and the book is written for people with junior or senior skills in software development which makes it easy to read and understand.

A book about different architecture patterns is “Enterprise Integration Patterns”[4]

by Gregor Hohpe and Bobby Woolf. It’s written from the experience of enterprise software architectures and one of the main issues in system integration is messaging.

(21)

CHAPTER 2. THE VIEWPOINT OF PATTERNS Therefore they have made one of the main focuses of the book to be about how to build the architecture around the messaging process.

“Microsoft Application Architecture Guide 2nd edition”[5] by the Microsoft Pat- terns & Practices Team briefly describes several of the most common architecture patterns. It’s not a very detailed book but it’s a quick reference if we want to look up an architecture pattern. Note that the book has Microsoft products in mind (Windows) as well as their Object Oriented languages (C#) in focus but the architecture patterns are a concept and therefore most of them are independent of platform and of programming language.

(22)

Chapter 3

Important areas

In this chapter we will present basic knowledge about some important factors in software development. These are factors which we may consider when designing the architecture of a system. These factors are some of the factors that we will consider when we evaluate the case study.

3.1 Separation of Concerns

Separation of Concerns is when we separate functionality instead of cluttering it together. There are several ways to achieve Separation of Concerns and modularity is one of them. By separating features into different modules it becomes easier to find and change a specific feature. Abstracting into different layers is also a common way to show Separation of Concerns. A concern might be a specific feature or behavior in a program [6]. Designing these systems gives the possibility to work on an individual feature and makes it easier to exchange each module. Service-Oriented Architecture is a way to separate concerns by having services. Some benefits from Separation of Concerns are [7]:

• Allows people to work on individual concerns.

• Allows re-usability.

• Makes software more maintainable and easier to test and debug.

• Makes it more simple to create, update or delete software features easier.

• Makes the architecture more viewable with a clearer separation.

Examples of Separation of Concerns are html and css as well as the MVC design pattern. Separation of Concerns has some similarity to the Single Responsibility Principle[7] but they are not the same. The goal, to separate code into different parts is the same but these approaches do it in different ways. The Single Re- sponsibility Principle works with objects having the responsibility for a work task

(23)

CHAPTER 3. IMPORTANT AREAS while Separation of Concerns can be modules with several classes taking care of a task. The Single Responsibility Principle defines responsibility to be “a reason for change”. If there might be more than one reason to change a class then it has more than one responsibility and should be abstracted[8].

3.2 Loose coupling

Coupling is the dependency level between two different modules. If we have two modules, A and B, and A is coupled to B, this will have consequences. To be coupled means that if a change happens to B this will force a change on A, similar to dependency. In systems where agility is very important we don’t want modules to be tightly coupled, we want loose coupling. This means that the modules should have a dependency level that is minimal to zero.

A module should know as little as possible about the other modules. By having little knowledge about other modules the module won’t be able to form as many dependencies and the module will be less tightly coupled. If a module implements business logic which is very specific to another module we might build an unnec- essary dependency. The main issue with applying loose coupling is that it’s more difficult to program, we have to do more work and our thought process needs to be more abstract. In the short run, code which is tightly coupled is produced faster, problems and bugs are solved more quickly and it gives a clear concept of what’s being programmed [9]. In the long run if our system has become something much larger than expected, this may have major impact on the system when a minor change occurs. If we have several modules tightly coupled like a chain this will be similar to a ripple effect, just because we changed a property we suddenly have to change several classes. Small changes suddenly grow out of proportion.

What we need to consider is what we should loosely couple and what we should tightly couple. Using loose coupling on everything we program is not the goal of loose coupling. The goal is more to reduce the work when changing modules or interfaces. Say we have an application with a data layer using a database. When we want to switch the database and if the layer is correctly loosely coupled we will only have to work on the data layer and not on any other layers. This doesn’t remove all the work but makes it a lot smaller, easier to test and debug.

3.3 Modularity

During software development we often notice that business models change quickly which requires the software to be flexible so it can support changes and also be expandable to be able to cope with the growth of a software. We may have stumbled upon times when we noticed that we are implementing functionality and code which we might have implemented before. Why not reuse the code if it has good enough interfaces? When we are trying to find an error in existing software, wouldn’t it be

(24)

3.3. MODULARITY

good to know about where to look even though we haven’t developed the application from the beginning?

Modular programming is a method to design our software into separate components called modules. A module may use Separation of Concerns to be able to distinguish itself from other modules. It’s hard to pin-point exactly what a module is in software engineering. It could be a server, an application or even a class. We have read a number of papers, had discussions and we believe the word "module" is often used without really comprehending what it involves. Then we stumbled upon a description of modularity by Bertrand Meyer[10] who lists 5 criteria and 5 rules which cover the most important parts of a modular design method and which helps us evaluate the modularity level of a software architecture. We will here reference Bertrand Meyer and give a short description about the criteria and rules.

3.3.1 Five criteria

• Modular Decomposability – "A software construction method satisfies Mod- ular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex sub-problems, connected by a simple struc- ture, and independent enough to allow further work to proceed separately on each item"

This allows the problem to be split into minor problems which may be worked on separately. The benefits of working in parallel to solve a subproblem, which contributes to a much complexer problem, is that the main problem might be solved faster. This also requires the subproblem dependencies to be as few as possible. If the dependencies are too many it will halt its progress because it has to wait for problems which it depends on to be solved or to reach a certain point where it may continue. These dependencies need to be known as well otherwise we might end up with a solution to a subproblem which doesn’t fulfill the requirements of the main problem.

• Modular Composability – "A software construction method satisfies Modular Composability if it favors the production of software elements which may then be freely combined with each other to produce new systems, possibly in an en- vironment quite different from the one in which they were initially developed"

To be able to reuse the subsystems it must be possible to be able to rebuild other systems. This doesn’t mean a design is not modular if the modules don’t work in every other environment, but the module should be independent enough to be used in another context. We usually want to fulfill this criteria as much as possible because we will very likely have to reuse the module again, perhaps in a new environment than the environment which it was created in.

How often has a software developer not scratched his head and asked himself

"Haven’t we done this before?".

(25)

CHAPTER 3. IMPORTANT AREAS

• Modular Understandability - "A software construction method satisfies Mod- ular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others"

When maintaining software there is a need to identify where the fault is. By having well defined modules the process of finding the problem is a lot easier.

By giving a clear understanding to a module, without having to read the code itself, there will be less misunderstandings when interpreting what the module does. Descriptions also help with paving the way for an analysis, making it easier to create a software design with the module integrated and also what’s necessary to implemented the module.

It’s always a good idea to keep a description inside the module. This reduces the chance of having a document with a description which is out of sync with the module. This will steadily remind the developer that the documentation needs to be kept up-to-date.

• Modular Continuity – "A software construction method satisfies Modular Con- tinuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small num- ber of modules"

With all the evolving techniques and business models the requirement to make software possible to expand is very important. Ad hoc solutions are quite common and with designs allowing extensions to be connected into the solution it becomes more expandable. This raises requirement of the software design, since flexibility might be a comprehensive task to implement. Nowadays we are supposed to be able to configure anything, from our custom fit car to our functionality in our mobile phones.

When implementing a system, it’s not uncommon to get change requests during development which need to be implemented. By having a system made from modules and being directly able to change a module instead of changing the whole system, the process takes less time. These are just a few examples why it’s important to not make modules dependent on other modules so we don’t have to remake the design of all their dependencies.

• Modular Protection – "A software construction method satisfies Modular Pro- tection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighboring modules"

If an error can occur, it will occur(Murphy’s law). It’s important to keep the error within the module and not spreading it to other modules. If an error is spread from a module this may create undefined behavior which makes it hard to track down its source. This criteria is not about how to solve the error but how the error is spread. In many object oriented languages ,such as C++

and Java, there is support for exception handling. The weakness here is that

(26)

3.3. MODULARITY

exception handling is often optional, where an error may halt the instance or even continue without any data validation.

3.3.2 Five rules

• Direct Mapping - By having a direct mapping between the implementation and the designed software model it makes it much easier to understand. It makes it easier to localize where changes needs to occur (The Continuity criteria) as well as making it easier to analyze the model. By having a better understanding, given by direct mapping, it will also make it easier to decompose the software into separate modules which may be used for later composition.

• Few Interfaces - A module should communicate with as few other modules as possible. The requirement to change several modules when changes need to be implemented becomes less and the occurrence of an error will be spread to as few modules as possible. By having as few dependencies as possible it also helps the composability criteria, since it makes it easier to fit into different designs when less modules are required. This also assists in the continuity and protection criteria.

• Small Interfaces - By having small interfaces we will exchange as little information as possible. It’s easier to change small modules than large ones.

With small interfaces which only send necessary information we also lower the chance of propagating errors to other modules. This assists in the continuity and protection criteria.

• Explicit Interfaces - When two different modules communicate with each other their communication should be clearly defined and their dependencies should be visible. This assists in decomposability and composability by showing which modules are coupled, and if we want to compose a new system design, we will know which modules need to be used because of dependencies. This rule supports the continuity criteria by showing which modules need to be changed and the understandability criteria by defining which modules need to be understood because of their dependencies.

• Information Hiding - By not having all the module properties public or accessible, it creates better protection for the module. We generally don’t want a user to be able to access all parts because they might be fundamental for the module[10]. The rule is necessary because if a secret property changes, it should not affect the public interfaces. This assists the continuity criteria. This rule shares some ideals of the Small Interfaces rule, by not having everything public we will also make the module interfaces smaller.

(27)

CHAPTER 3. IMPORTANT AREAS

3.4 High availability

Availability is an important factor in system design. It’s the time which a system is functional and working, but this doesn’t have to mean that a system should always be available. Sometimes we want a system to only be available during a short period of time or specific events like the Olympic games.

Availability is usually measured by a percentage of availability over a time period.

We might have heard about hosts of different kinds of services tell us about their 99.99% availability. When discussing the high availability we usually talk about

"the nines"[11] shown in the table.

Nines Percentage Downtime in a year

1 90% 36.5 days

2 99% 3.65 days

3 99.9% 8.75 hours

4 99.99% 52 minutes

5 99.999% 5 minutes

6 99.9999% 31 seconds

Figure 3.1. Table of high availability rates

A system architect always has to design a system to be available when it’s critical for it to be available for usage. When we can’t pinpoint these times we favor a generally high availability percentage. With the Table 3.1 we get a quick overview.

3.4.1 Issues which may interfere with high availability

Below we will list some of the issues which may interfere with high availability[5][12]

Single point of failure

When all data passes through a certain module and the module becomes unavailable at a time, the whole system might not function correctly. This may be avoided by mirroring the module and reroute the work flow through the duplicate to avoid total unavailability. Another example is network load balancing for not locking out certain modules when large amounts of data are being sent or having an emergency route which the data may travel on. This emergency route (backup system) should be a totally separate process to minimize the chances of them both being unavailable at the same time.

Protection

Systems are sometimes the target of attacks such as Denial of Service (DoS) attacks.

This specific attack overloads the system and by doing so prevents the usage of

(28)

3.4. HIGH AVAILABILITY

that system. If the system also has a single point of failure it becomes easier to sabotage a system. This attack might use the weakness in a system with a slow processing time, to make the system look like it has been halted, or a bug in the network configuration. To prevent DoS attacks it’s important to detect the attack patterns and malicious behavior and stop them before they continue for too long. A common reason why systems crash is because of low data validation. By sending unexpected data into the system an unexpected behavior might be the result. Enforcing comprehensive data validation may be a large task to do but it is an important task if we want to minimize the risk.

Excessive use of resources

Resources which are held too early and for too long may cause resource starvation.

This may cause an unexpected behavior if not treated correctly, or the service request will be rejected. A common example is databases and access to the same data. When two requests on the data source are performed at the same time it may cause one request to be rejected while the other one proceeds. Deadlocks, where two asynchronous requests are waiting for each other to finish before any of them can proceed are a common issue.

Bugs or faults

Probably the most common cause of a system malfunctioning is by bugs or faults.

When an error occurs and it’s not handled correctly it may cause dire consequences.

In the worst case it may cause the whole system to become unavailable and in the best case it may not cause any damage at all. By designing correct exception handling the system can catch these bugs and faults for reporting to the system developers who might fix the issues with an update of the system.

Frequent updates

Depending on the system design, frequent updates may force the whole system to become offline. By having a design which allows run-time upgrades the whole system doesn’t have to become offline and may still function with perhaps only a small delay on request execution. Developing a system with the possibility to perform run-time upgrades may be difficult to develop, but the availability issue can be solved in many other ways. For example a server upgrade might be performed in batches instead of taking down all servers at the same time so there will always be some servers available.

(29)

(30)

Chapter 4

Two architectural patterns described

In this chapter the reader is given a detailed description of two architectural patterns which are used throughout this thesis. By giving these descriptions the reader will hopefully understand the context of their usage better.

4.1 Service-Oriented Architecture (SOA)

4.1.1 Description

Service-Oriented Architecture (SOA) is an architectural pattern where the design and development is focused on abstracting the functionality into interoperable services[5][13][14]. SOA is based upon a set/collection of services, which each offer their own unique functionality. With SOA comes certain strengths such as re-usability but also weaknesses such as extended development time for certain functionalities. SOA does not mean "a bunch of services" but the pattern also in- cludes the policies, practices and the frameworks by which the services are provided as well as the communication to and between them.

SOA became popular with the usage of web services[15]. Web services are the set of protocols which services can be published, discovered and used in a technology neutral standard form. SOAP, REST, CORBA and Java RMI are other implementations with the SOA pattern.

4.1.2 Service

The main building blocks in SOA are the services and their communication. A service implements a reusable functionality and has a clear description of what its functionality is, how to use the service and where to access it. Services are loosely coupled, simplified for the service consumer and allow changes to a single service without having an impact on any other services. Here is a representation of a selection of principles [13].

(31)

CHAPTER 4. TWO ARCHITECTURAL PATTERNS DESCRIBED

Service principles

• Loose coupling - Self-contained

– Does not depend on the context of other services – Does not depend on the status of other services

• Reusable - The service should be able to be integrated into other systems

• Abstracted - Hides the internal implementation from the outside

• Relevant and modularized -Has a defined functionality

• Published - Publishes functionality, does not describe its implementation

• Formal - Presents a simple exposed interface. It has a formal contract between itself and the consumer which places obligations on the provider and consumer

• Interoperability - With well defined interfaces the services can interact with each other without encountering issues because of their implementation or access

• Independent - The services should be independently – Developed

– Deployed – Maintained

4.1.3 Connection

Communication is done in a heterogeneous environment, with little or no knowledge of the consumer. As long as the service consumer fulfills the formal contract it will receive the data as described.

Services need to be interoperable[16]. This means that they need to be implemented in such a way that the services have a common and reliable way to exchange messages between each other. The services don’t need to know how they are in- dividually implemented, they only need to know how to use each other. This can lead to errors in communication but when a collection of services are interoperable it means that they can interact without encountering these issues. This is very similar to loose-coupling but loose-coupling does not guarantee there won’t be any issues due to communication breakdown.

4.1.4 Strengths

• A consumer should only need to know what the service does, where it is and how to use it. There is no need to know anything about the implementation of the service.

(32)

4.2. EVENT-DRIVEN ARCHITECTURE (EDA)

• It becomes easy to add new services to the provider while not changing any of the existing services.

• Today with fast changing business logic, SOA fits nicely. With separate functionalities in services it’s very quick to apply changes to the business logic in specific areas.

• The pattern allows evolution without changing existing implementations.

• It offers scalability because we can add new functionality without changing the existing implementation.

• Reuse and reconfiguration instead of Build and redesign.

• A service provides with specific functionality. This avoids duplication of implementation since the service may be reused instead.

• Independent services/functionalities offers possibilities for parallel development.

4.1.5 Weaknesses

• Is there really a need to turn functionality into services? It might be tempting to turn all functionality into different services but is the added time and the difficulty worth it or are the services even necessary?

• There might be a delay between services which might affect the performance between services.

• Separation needs managing.

• When testing the service, we have to be careful if we are both implementing the service as well as being one of the consumers. We might test the service with information which we have knowledge of due to knowing its underlying implementation.

• Overhead when wanting a certain functionality. Suddenly it has to be made through a communication protocol and the message might have to be formatted in a certain way.

4.2 Event-Driven Architecture (EDA)

4.2.1 Description

Event-Driven Architecture (EDA) is an architectural pattern which focuses on the communication between components through processing events. The pattern also describes event production, the detection of an event and the reactions to an event.

An event signals that something specific has occurred and that the corresponding

(33)

CHAPTER 4. TWO ARCHITECTURAL PATTERNS DESCRIBED action to this event should be triggered. Sometimes the action might trigger a work flow, sometimes a transformation and sometimes the event might also result in no action being taken at all. This pattern promotes an asynchronous, loosely coupled and flexible implementation. The system performs the work first after the event has been received which makes it asynchronous. All the event subscribers have different implementations and shouldn’t have any kind of dependencies between each other which makes the subscribers loosely coupled and the system also becomes very flexible to changes. An event-driven system usually consists of one or many event producers, some sort of messaging queue and the event consumers who react accordingly to an event.

The communication in SOA can be done with an EDA. A service consumer reacts to an event which has been sent out by a service provider. This makes the services very loose coupled. The source of the event only knows that the event occurred. It does not know anything of the subscribers, neither their existence or their implementations.

4.2.2 Components in EDA Event

An event refers to an action which has occurred either inside or outside our business logic. An event refers to the specification (definition of the type of event) and each occurrence (the current instance of the event) For the event to be meaningful for downstream subscribers, the event specification should be described in business terms for easier understanding of what has occurred.

An event contains a header and the body. Many Object-Oriented Programing languages implement the event with event type, event name, event timestamp, event occurrence and event creator. The event body should contain enough information so that any subscriber handling the event shouldn’t have to retrieve any additional information from the system the event originated from.

Event generator

The event generator is the source of the event. The source may be a button click, a service or anything else which is a change to the existing environment. It creates the event and sends it to the event channel. The event generator does not know of anything past the event channel. Since there may be several different event generators it may be required to transform the event in a specific format so it may be transported correctly by the event channel and thereafter handled correctly by the event processing engine.

Event channel

The event channel transports the standard formatted event produced by the event generator to the event processing engine. It may also transport the event between

(34)

4.2. EVENT-DRIVEN ARCHITECTURE (EDA)

event processing engines and event subscribers.

Event processing engine

The event processing engine receives the event and takes different actions. It may start a work flow, call a service or notify a human of the event. It may also publish the event to downstream event-driven activity.

Downstream Event-driven Activity

The downstream event-driven activities receive the event since they subscribe to the event. They subscribe to the event by telling the corresponding event processing engine that they would like to receive the event in case the processing engine publishes the event. The subscribers of the event may be other automated services or non automated services. The automated services then perform an action such as start a work flow, publish the event to a dashboard or even store the event. A system developer might receive the event and take the necessary actions.

4.2.3 Strengths

• Events are messages which can be serialized and can thereafter be processed at a later stage.

• The possibility to send an event to several different subscribers with each subscriber possible triggering different workflows. This allows expandability while not modifying the existing code (Open Closed principle).

• The source of the event does not need to know how the event handling is implemented or anything about the event subscribers. It only needs to make sure to populate the event with sufficient data and broadcast it correctly.

• The system becomes expandable since only an additional subscriber needs to be added.

• Easier to maintain when each subscriber which processes the event triggers their work independently from each other. This makes it easier to maintain the system due to most business logic being performed in the event processing engine or in the downstream activities.

4.2.4 Weaknesses

• Can become difficult to develop due to complexity level of the pattern.

• It can be hard to get a clear overview of what the system really does since we might not be sure which subscribers there are.

• Is the extra overhead of the event necessary?

(35)

CHAPTER 4. TWO ARCHITECTURAL PATTERNS DESCRIBED

• Does the system really need the benefits of EDA? Architecture patterns are always situational.

• It is hard to track the event along the multiple subscribers. Therefore EDA is mostly used for asynchronous flows since the system may publish the event and thereafter forget it (Fire-and-forget).

(36)

Part III

Case study

(37)

(38)

Chapter 5

Introduction

This prototype project was a minor project set in an industrial context. By having the constraints of working life and experiencing them first hand we hoped to be able to make some conclusions and gain insights info how architectural patterns are used in working life context. The conclusions drawn from this experience are empirical and not in any way definite conclusions.

5.1 Project description

This project was a research project with a minor implementation part. What was of interest in this project were the possibilities and limitations of the integration between Vidispine MAM(Media Asset Management system) by Vidispine and Pre- lude(Metadata logging software) by Adobe System Incorporated as well as their own limitations. The implementation part was to make a proof of concept/prototype of a possible integration between the two systems. This integration was a Prelude Extension. The extension was written in Actionscript which is an Object Oriented language with the aid of the Flex library. Mediasmiths was the project owner.

For full details about the project please view the project description given by Me- diasmiths¹.

5.2 Goal

The goal of this project was to gain experience of how to implement an architecture design in working life. By documenting factors, limitations and conflicts of interest regarding architecture design and architectural patterns we wanted to see issues which would possibly occur in other types of projects. By applying theory and designing architecture design prototypes we hoped to gain a better understanding on what limits architectural patterns and if there was a way to differentiate between

1Appendix A

(39)

CHAPTER 5. INTRODUCTION different architectural patterns and designs. A very interesting phase in this project was the Prototype design phase (chapter 7). In this chapter we will explain and justify why we selected a certain design for implementation.

5.3 Scope

In this master thesis the focus was on the usage of architectural patterns and when they are eligible in this working life project. Therefore we will not mention details which did not concern or impact the usage of architectural patterns. The limitations of the programming language, platforms and such will not be mentioned either, unless they had a large impact on the results.

5.4 Assets

The following assets were assumed to be fully available during the project:

• Vidispine MAM v3.0.5

• Metadata logging software: Adobe Prelude build 1.0.0586

• Implementation language is Actionscript 3.0 with Flex v3.5.0.12683 library Adobe Prelude was hosted on Mac OS X 10.6. Vidispine 3.0.5 was hosted on Ubuntu 10.04 LTS. Adobe contributed with a SDK and API documentation for Adobe Prelude. Vidispine had their own API documentation for the Vidispine MAM. Adobe had an integration engineer available for development questions and Mediasmiths supported with a project leader and an architecture designer.

Adobe Prelude CS6

Adobe Prelude CS6 (hereby referenced as Prelude) is a tool made for ingesting, logging and adding metadata to media assets. The greatest feature which Prelude has to offer is its minimalistic GUI and adding time specific metadata called markers. Markers are metadata with a time span which give possibilities to offer more detailed views of search options and much more. Instead of getting a whole clip as a search result the user may now get a time span where the search criteria hap- pened. Example "Goal" when searched inside a football clip could result in several time spans where goals occurred. Integrations with Prelude are made through an extension to Prelude.

Vidispine Media Asset Management v3.0.5

Vidispine is a Media Asset Management (M.A.M) platform. It is a media content repository with a RESTful-web service API. They offer the functionally of advanced search capabilities, customized metadata storage and much more.

(40)

5.5. PROJECT PLAN

“An architectural pattern is a description of element and relation types together with a set of constraints on how they may be used. A pattern can be thought of a set of constraints on an architecture- on the element types and their pattern of interaction and these constraints define a set or family of architectures that satisfy them.”

Vidispine

Actionscript 3.0 & Flex 3.5

Actionscript is an Object-Oriented Programming language developed by Macrome- dia Inc. The Actionscript runs on the Actionscript Virtual Machine (AVM). The language is made for the Adobe Flash Player and Adobe AIR environments. Flex is an open source framework which extends Actionscript and helps the developer to build towards the web as well as desktop applications.

5.5 Project plan

This project had several phases over a set amount of time. The project time limit was set to three months. The main phases were:

• Pre-study phase - To be able to try to determine what kind of limitations there were with the assets (mainly Prelude and Vidispine), a pre-study was performed. The pre-study also gave a more clear definition of how Prelude and Vidispine communicate with other systems.

• Prototype design phase - Several prototype implementation designs were made which suited the given scope. This led to discussions about which prototype design we would finally begin to implement in the implementation phase.

• Prototype implementation & evaluation phase - A prototype design was selected and it was implemented. If the implementation design would show negative signs or other effects which would impact the project negatively, a change to the prototype design or scope of the project would be possible to add at the midway project evaluation. Thereafter the implementation phase continued. The phase also contained evaluations. The project evaluation resulted in two reports. An evaluation report was handed over to Mediasmiths as well as the implementations source code. The other evaluation report was mainly a discussion about the implementation based on the new experience and theory. A set of questions was discussed. Further detail will be explained below.

(41)

CHAPTER 5. INTRODUCTION

5.6 Selection of prototype

The patterns that have been selected for this Master Thesis are Service-Oriented Architecture and Event-Driven Architecture.

The selection of prototype design was made from these criteria:

• How well could the architecture patterns be used?

• How well was the “Separation of Concerns” and modularity in the prototype design?

• What was the difficulty level to deploy the implementation?

• How well could the modules be reused?

A short discussion about each prototype implementation was made and finally a decision of which prototype implementation was selected to be implemented.

5.7 Midway Project evaluation

During an implementation of a project, due to a vast variety of circumstances, the project might have to be re-evaluated and assessed again. In this case it could be necessary due to new information about the different integration parts that could change the picture or the choice of prototype design.

The Midway Project evaluation considered if there were any circumstances where a change to the prototype design or limiting the scope was beneficial based on:

• If the currently owned information created possibilities or limitations.

• If the prototype implementation phase was according to schedule.

• If there were any discoveries that showed there were limitations due to the selection of prototype implementation design.

5.8 Final Project evaluation

These questions were discussed with the newly gained view of the experience. The viewpoint of the theory was also discussed.

• Depending on project requirements, where there any requirements which limited the number of possible architectural patterns which could be applied?

• How well were the architecture patterns used?

• How well modularized was the prototype?

• How well could the modules be reused?

(42)

5.9. REACHING A CONCLUSION

• How well was the "Separation of Concerns" in the prototype?

• How well could the system be maintained?

• How difficult was the prototype to apply?

• How much planning was needed to start the implementation?

• Time consumption?

• How much time was spent together with seniors to discuss about different difficulties?

• What major problems occurred?

• Was it difficult to deploy the implementation to a customer?

5.9 Reaching a conclusion

By evaluating the project experience we wanted to be able to give our current suggestions and/or answers to the thesis problem statements. Any specific events that could have changed the project outcome was discussed as well as how they could impact the project differentially if they would have been foreseen.

(43)

(44)

Chapter 6

Pre-study

Before starting the project a pre-study was done. This pre-study tried to reveal issues, possible risks which could cause damage and other possible conditions. In this case the project had many assets which were completely new to the developer and therefore needed to be overviewed.

6.1 Available assets

The materials which described the systems were:

Adobe Prelude:

1. A set of SDK samples provided by Adobe (Adobe Prelude extensions).

2. Possibility to have email conversations with an Adobe developer.

Vidispine MAM:

1. Access to a wiki-homepage, describing the Vidispine MAM, by Vidispine.

2. The API-documentation as pdf-document by Vidispine.

3. Access to developer forums hosted by Vidispine.

6.2 Adobe Prelude

Integrating with Prelude is usually done through an extension. This extension uses the Flex library which involves Actionscript. All programmatic communication with Prelude is done through the extension. Prelude does not expose any kind of data but instead allows an extension to listen to specific events which triggers on user actions(EDA). These events have bodies of the format of XML. To reply or trigger events in Prelude we had to dispatch our own events with a specific event name and event body (format is also XML). The SDK samples given by

(45)

CHAPTER 6. PRE-STUDY Adobe for Prelude are minimalistic. Note that developing towards Prelude has recently begun and therefore the examples might be in the earliest stages. The samples mostly show that things happen through events with a message body such as XML, by showing printouts, but not much else. Due to the lack of any kind of documentation we have to make assumptions on what kind of actions trigger which event, and assume that the body has the format of XML and is constantly returning the same structure. One requirement is that the extension needs to use the Flex 3.5 library since Adobe Prelude uses this library. Since no XML schemas or API- documentation have been given, uncertainty on how to communicate with Prelude exists. One sample demonstrates communication with Prelude. Due to all these circumstances the possibilities and limitations of communication with Prelude need to be re-reviewed at a later stage. This presents a major risk that some functionality may not be possible at all.

6.3 Vidispine MAM

Vidispine MAM API is a RESTFUL-web service. REST stands for Representational state transfers, which has several benefits. One is that each entity has their own URI(Uniform Resource Identifier). The main difference between SOAP and REST is that REST is more lightweight with less headers, less XML and will therefore use lower bandwidth. RESTFUL-web services uses the http protocol and the headers POST, PUT, DELETE and GET to be able to add, change, delete or get data. Flex 3.5 has full support of SOAP services by consuming the wsdl(web service description language). A wsdl describes how to use the web service. RESTFUL-web services has a counterpart named wadl(web application description language) but Flex 3.5 does not have any support for wadl(Flex 4.0 has full support). Both the wsdl and wadl are meant for promoting the reuse of the web services by describing the web-services with their own format. Vidispine MAM is well documented with their up-to-date wiki page about the API. They have a clear and consistent layout of each possible action which can be performed by Vidispine MAM and the wiki offers examples for nearly every task. The Vidispine MAM is configurable and its data model is quite adaptable due to using a generic data model.

6.4 Conclusion

Prelude uses events to expose and communicate (EDA). There is no API call to fetch the current data from Prelude into our own extension. To communicate with Prelude we had to use specific events as well. At this time we had not been given an API-documentation or an overview of the XML documents (XML schemas or anything similar), which were used to communicate with Prelude.

Vidispine MAM uses the RESTFUL-web service and it’s well documented with clear description on what the message should look like and what the message bodies (XML) should contain. Vidispine MAM is a great example of Service Oriented

(46)

6.4. CONCLUSION

Architecture (SOA). All the business logic which is specific to Vidispine MAM is wrapped within the RESTFUL-web service.

(47)

(48)

Chapter 7

Prototype design phase

7.1 Approach

The information that we had at this given time gave us the following knowledge.

Prelude is implemented with an Event Driven Architecture. It communicates only through events. Prelude can only be communicated with through an extension. Since our implementation required communication with Prelude we had to implement an extension. Vidispine is using the Service Oriented Architecture, communication is made through the RESTFUL web-service API. The Prelude extension uses Actionscript 3.0 and Flex 3.5. There were no known limitations of the programming language or the library which we had found that could interfere with an implementation. Actionscript has all the necessaries to support an Event Driven Architecture(see 4.2). The extension did not need to expose any kind of service.

The implementation should be as simple as possible for a user to deploy and to get the system running.

7.2 Prototype designs

We presented three architecture designs with their descriptions, strengths and weaknesses.

(49)

CHAPTER 7. PROTOTYPE DESIGN PHASE Design 1

Figure 7.1. The monolithic design

Monolithic design Description

A monolithic approach. All the different layers, presentation, business logic and the data-layer communication are embedded in the same component(the extension).

For small programs a monolithic approach is acceptable since it’s only meant to do a specific task. This is considered bad coding since we want modularity and its benefits such as re-usability.

Strengths

• Independent

• Single deployment

• Starts and completes the task within itself

The prototype would always start and end a task in itself. It wouldn’t be dependent on any other modules and could potentially have a lower execution time when no transport delay needs to be accounted.

(50)

7.2. PROTOTYPE DESIGNS

Weaknesses

• Difficult to maintain

• Difficult to test

• The code might be specific for this task and may therefore not be reused

• One large single component

• Cost inefficient

Without any kind of modularity all these factors will impact the prototype.

(51)

Figure 7.2. The Application Server with Business logic

Application Server with Business logic Description

A Service Oriented Architecture approach. All the business logic would be abstracted to the application server. By having this approach all the business logic would be reusable for future implementations which may be on different platforms or environments. As long as it could communicate with the application service the business logic would be accessible. It required a defined messaging protocol between the extension and the application server. The extension would have communication modules and the GUI-module. The application server would handle all business logic. The application server would as well have it’s own communication modules and the business logic.

(52)

7.2. PROTOTYPE DESIGNS

Strengthes

• Easy to maintain

• Easy to test

• Modularity gives reusable code and Separation of Concerns

• Service Oriented Architecture with the application server

• Greater visibility of the business abilities with the exposed application server

• Cost efficient

With modularity and a Service Oriented Architecture, the code becomes easier to maintain. With smaller modules it would be easier to perform test on them. Mod- ularity gives code re-usability as well since the tasks are abstracted into their own modules. These strengths would make the implementation cost effective. The most cost effective part would be when we only expose the application server to the extension. This would give us the ability to swap databases which the application server would be using without any changes to the extension. And if the application server was going to become outdated we could swap it as well. Business logic could be added to the application server and we wouldn’t have to update the old extensions because they would not be affected or even aware of the changes.

Weaknesses

• Deployment

• Requirement of the application server being available

• More code needs to be implemented for a prototype implementation

• With only one deployment of the application server we may experience latency issues

• Requires a clear definition of the messaging protocol and its structure

When setting up this implementation an extra step of setting up the application server would be needed. This could be undesirable when the client for the project only wanted a single deployment. This also required the application server to be available and to be able to handle the workload it would get. With several clients potentially connected to the same application server it would be important to estimate the usage and if necessary allocate more bandwidth or even setup several application servers.

(53)

Figure 7.3. The single deployment with modularity

Single deployment with modularity Description

This architecture design used modularity to achieve Separation of Concerns. With- out an application server, Service Oriented Architecture would not be used fully but it would still use the Service Oriented Architecture where the Vidispine module and the Prelude module could be considered to be different services. The re-usability of the code would be high since we could change the Vidispine module for another MAM module. The Prelude module would also be possible to be exchanged for another module which would offer similar functionality as Prelude, perhaps a Premiere module. Premiere Pro is a video editing software made by Adobe System Incorpo- rated.

The Vidispine module would have similar implementation as the Prelude module.

Each module would have two minor modules. A communication module which would accept requests from the business logic to send requests to external services. These services would reply to the communication module. However the other minor module would be an interpretation module and would receive the reply give by the service through the communication module. The interpretation module would interpret the reply and callback to the business logic to take the appropriate action.

A comparison of Architectural Patterns: A study of a real world application

A comparison of Architectural Patterns

Hwoh Hei James Hau

A comparison of Architectural Patterns

Abstract

Referat

En jämförelse av Arkitektoniska mönster

Contents

Part I

Introduction

Chapter 1

Thesis

1.1 Background

1.2 Goals

1.3 Problem statement

1.4 Scope

1.5 Case: Prototype project

1.6 Thesis contents

1.7 Target audience

Part II

Theory

Chapter 2

The viewpoint of patterns

2.1 Architectural pattern

2.2 Design pattern

2.3 Benefits with patterns

2.4 Methodology to compare Architectural Patterns

2.5 Further reading

Chapter 3

Important areas

3.1 Separation of Concerns

3.2 Loose coupling

3.3 Modularity

3.4 High availability

Chapter 4

Two architectural patterns described

4.1 Service-Oriented Architecture (SOA)

4.2 Event-Driven Architecture (EDA)

Part III

Case study

Chapter 5

Introduction

5.1 Project description

5.2 Goal

5.3 Scope

5.4 Assets

5.5 Project plan

5.6 Selection of prototype

5.7 Midway Project evaluation

5.8 Final Project evaluation

5.9 Reaching a conclusion

Chapter 6

Pre-study

6.1 Available assets

6.2 Adobe Prelude

6.3 Vidispine MAM

6.4 Conclusion

Chapter 7

Prototype design phase

7.1 Approach

7.2 Prototype designs