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

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 im- plementation. 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 bet- ter 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 architec- tural patterns. Necessity and what’s possible, because of the existing systems, takes overhand and limits the selection of architectural pat- terns 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 ar- chitectural pattern may not be worth the effort. Instead the developers should focus more on what is possible in the system environment. Referat

En jämförelse av Arkitektoniska mönster

Detta arbete ger en inblick i hur arkitektoniska strategier väljs från ar- betslivs perspektivet. Med alla arkitektoniska strategier som finns kan det vara svårt att avgöra vilken strategi man ska välja. Även om en arki- tektonisk 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 stra- tegier 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 arkitek- toniska strategier och viktiga faktorer. Genom att studera ett projekt om system integration så gavs det en tydlig bild av hur valet av en ar- kitektonisk 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 arkitekto- niska 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ö. Contents

I Introduction 1

1 Thesis 3 1.1 Background ...... 3 1.2 Goals ...... 3 1.3 Problem statement ...... 4 1.4 Scope ...... 4 1.5 Case: Prototype project ...... 4 1.6 Thesis contents ...... 5 1.7 Target audience ...... 5

II Theory 7

2 The viewpoint of patterns 9 2.1 Architectural pattern ...... 9 2.2 Design pattern ...... 10 2.3 Benefits with patterns ...... 10 2.4 Methodology to compare Architectural Patterns ...... 10 2.5 Further reading ...... 11

3 Important areas 13 3.1 Separation of Concerns ...... 13 3.2 Loose coupling ...... 14 3.3 Modularity ...... 14 3.3.1 Five criteria ...... 15 3.3.2 Five rules ...... 17 3.4 High availability ...... 18 3.4.1 Issues which may interfere with high availability ...... 18

4 Two architectural patterns described 21 4.1 Service-Oriented Architecture (SOA) ...... 21 4.1.1 Description ...... 21 4.1.2 Service ...... 21 4.1.3 Connection ...... 22 4.1.4 Strengths ...... 22 4.1.5 Weaknesses ...... 23 4.2 Event-Driven Architecture (EDA) ...... 23 4.2.1 Description ...... 23 4.2.2 Components in EDA ...... 24 4.2.3 Strengths ...... 25 4.2.4 Weaknesses ...... 25

IIICase study 27

5 Introduction 29 5.1 Project description ...... 29 5.2 Goal ...... 29 5.3 Scope ...... 30 5.4 Assets ...... 30 5.5 Project plan ...... 31 5.6 Selection of prototype ...... 32 5.7 Midway Project evaluation ...... 32 5.8 Final Project evaluation ...... 32 5.9 Reaching a conclusion ...... 33

6 Pre-study 35 6.1 Available assets ...... 35 6.2 Adobe Prelude ...... 35 6.3 Vidispine MAM ...... 36 6.4 Conclusion ...... 36

7 Prototype design phase 39 7.1 Approach ...... 39 7.2 Prototype designs ...... 39 7.3 Selection of prototype ...... 45

8 Prototype implementation & evaluation phase 49 8.1 Implementation phase startup ...... 49 8.2 Midway evaluation ...... 49 8.3 Final project Evaluation ...... 50

9 Project Conclusions 55

IV Results 57

10 Discussions 59 11 Final Conclusions 61 11.1 Project ...... 61 11.2 Architectural patterns ...... 61 11.3 Method ...... 62

Bibliography 63

Appendices 64

A Project documentation 65

Part I

Introduction

1

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 com- puter 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 dif- ferent 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.

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

4 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 conclu- sions 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.

5

Part II

Theory

7

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.

9 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 develop- ers. 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 pat- terns. 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 dif- ferent attributes. Attributes are often connected to each other and by changing the architecture to improve an attribute it may come with downsides to other at- tributes.

10 2.5. FURTHER READING

An iteration is made of four phases.

1. Scenario & Requirement Gathering – In this phase we collect different sce- narios, 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.

11 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 ar- chitecture patterns are a concept and therefore most of them are independent of platform and of programming language.

12 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

13 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

14 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 com- ponents 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?".

15 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 com- mon 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 dur- ing 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

16 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 in- formation 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 conti- nuity 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 ac- cessible, 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 crite- ria. This rule shares some ideals of the Small Interfaces rule, by not having everything public we will also make the module interfaces smaller.

17 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

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

19

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 de- sign and development is focused on abstracting the functionality into interoper- able 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 tech- nology 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].

21 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 imple- mented 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.

22 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 func- tionalities 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 im- plementation since the service may be reused instead.

• Independent services/functionalities offers possibilities for parallel develop- ment.

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 format- ted 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

23 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

24 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 process- ing 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?

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

26 Part III

Case study

27

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

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

29 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 mark- ers. 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.

30 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 proto- type 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.

31 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 lim- ited 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?

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

33

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

35 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

36 6.4. CONCLUSION

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

37

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 exten- sion. Since our implementation required communication with Prelude we had to implement an extension. Vidispine is using the Service Oriented Architecture, com- munication 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 pro- gramming 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 weak- nesses.

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

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

41 CHAPTER 7. PROTOTYPE DESIGN PHASE

Design 2

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

42 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 exten- sion. 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 es- timate the usage and if necessary allocate more bandwidth or even setup several application servers.

43 CHAPTER 7. PROTOTYPE DESIGN PHASE

Design 3

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

44 7.3. SELECTION OF PROTOTYPE

Strengthes

• Single deployment

• Easy to maintain

• Easy to test

• Modularity gives reusable code and Separation of Concerns

• Cost efficient

For a customer a simple deployment is desirable. This architecture design only requires the two systems and the extension to work. With modularity comes main- tainability, easier testing with smaller modules, reusable code and a Separation of Concerns. All these factors make it a cost efficient solution.

Weaknesses

• Does not use Service Oriented Architecture fully

• Does not let any other software/components use its business logic

This architecture design does not offer the usage of its business logic to other ap- plications on the same level as the design with the application server. This design encapsulates the business logic. Only applications with a similar environment to the module can reuse the implementation. The application server however could have an independent entry point(platform independent API). The only way to re-use the business logic is if the business logic module is viable for the other implementation (factors such as programming language becomes important factors).

7.3 Selection of prototype

The implementation was going to be a prototype, a proof of concept. The time limit was one month. Since the communication with Prelude was asynchronous and Prelude already implemented EDA we believed that adapting to it would be more beneficial then not adapting. The implementation was going to use a GUI(Graphical User Interface) and it was going to perform actions from user interaction. This did fit very well with an implementation of EDA. SOA was not a requirement and there were no immediate benefits of using SOA. Neither design 1 or 3 were using SOA.

It would be beneficial to produce reusable code through modularity because we were not sure when we would reuse the code. The modules could be used either to realize the prototype or to use the module in other implementations.

45 CHAPTER 7. PROTOTYPE DESIGN PHASE

To simplify testing even though it was a prototype, designs with as much Sepa- ration of Concerns as possible would be more beneficial. By making testing faster and easier, the focus could be placed upon development instead of testing. Testing is an important part of programming and even if was a prototype we would perform a lot of tests to make sure the integration between the systems worked correctly.

Cost efficiency and difficulty of deployment are important factors when consid- ering implementation outside the theoretical world. Therefore an application server would have made the deployment stage one level more difficult for a user than nec- essary. Also the cost of maintaining the application server needed to be included. It was decided to not use any kind of implementation with an application server since there was not any absolute need of an application server and it made the implementation more cost efficient and easier to deploy. Design 2 was therefore not implemented after receiving directions of the project owner.

Since design 1 and 3 were both realizable we decided to base our selection by discussing the designs with the criteria in section 5.6 as basis.

• How well could the architecture patterns be used? Both designs could utilize EDA to its fullest. When an event occurs in either the GUI or in Prelude the event gets relayed into the processing and afterwards a specific event could be sent to the Vidispine MAM for postprocessing actions.

• How well was the “Separation of Concerns” and modularity in the prototype design? Design 1 was a monolithic approach. It did not separate any logic at all. Design 3 was using Separation of Concerns, perhaps not as much as possible but to a certain degree. Design 3 was preferred considering this criterion.

• What was the difficulty level to deploy the implementation? Design 2 with its implementation of SOA with an application server would be the most difficult implementation to deploy. Design 1 and 3 would have the same deployment procedure. Their differences would more likely to be on the inside of the extensions.

• How well could the modules be reused? Design 3 had mainly four modules, the GUI, the business logic, the com- munication module to Prelude and the communication module to Vidispine MAM. All these modules could potentially be reused if the interfaces between the modules were clearly defined. Design 1 would only have a single module with all the functionality embedded. The re-usage of the code in Design 1 was therefore non-existent. The prototype would exist specifically for this implementation. Design 3 would be better on this criterion then Design 1.

46 7.3. SELECTION OF PROTOTYPE

Considering all the strengths, weaknesses and the requirements, we decided to implement the design “The single deployment with modularity”(Design 3) because it offered modularity and its benefits included an easy deployment and no need for having an application server. Since this was going to be a prototype implementation we did not find the necessity to offer the business logic as a service because there was at that time no application which would like to be able to use the business logic. The code in the prototype could be re-used to some extent and we believed it would be better practice than implementing a monolithic design.

47

Chapter 8

Prototype implementation & evaluation phase

8.1 Implementation phase startup

We obtained more details about how communication to Prelude was done from an extension. The extension had to access the event dispatcher from the Flex library to communicate with Prelude. In the pre-study phase we mentioned that the event messages had the structure of xml but there were no xml-schemas defining how the events would look like. We had still not received any schemas but instead received more detailed descriptions of the events through the Prelude API documentation. This did not change the implementation design but clarified that a design where the communication with Prelude would be abstracted to an application server was no longer possible since the communication to Prelude required communication to be done from a Prelude instance, and the extension was going to be launched and hosted by the Prelude instance. The communication with Vidispine MAM could still be abstracted to the application server though. The goal with the implementation was to use modularity and Separation of Concerns as much as possible since we wanted to gain the benefits such as re-usability and easier testing.

8.2 Midway evaluation

There were no concerns regarding the prototype architecture design. There had been no changes regarding the Vidispine MAM. We had decided to set the scope of the extension to be able to create, read, update and delete (CRUD) markers (time specific metadata) and other metadata to a specific clip. The main reason was because of the late arrival of the Prelude API documentation and because of a few major tasks being not documented in the API documentation. Solving these tasks took longer than expected because we didn’t think some configuration had to be done before being able to perform some actions. Instead we thought we had implemented code incorrectly. After deciding to ask the developer at Adobe for

49 CHAPTER 8. PROTOTYPE IMPLEMENTATION & EVALUATION PHASE solutions it still took a while to get an answer due to time differences due to the contact living in another timezone (Europe, America) and some questions had to be sent to other developers (in Asia). All these issued could be avoided with a well-documented API. We decided to skip creating interfaces between the modules and instead let it be tightly coupled. The interfaces could be implemented at a later stage.

8.3 Final project Evaluation

The project ended well. A prototype implementation was successfully implemented during the given time. The original scope had to be adjusted due to missing docu- mentation which led to longer time being spent on specific parts of implementation than intended. EDA was implemented without any major problems. The only issue which existed was how the message body was supposed to be structured. Since no kind of validation could be made prior to sending the message to the systems, they had to be tested through "trial and error". Reflecting back on the criteria in section 5.8:

• Depending on project requirements, where there any requirements which lim- ited the number of possible architectural patterns which could be applied? Due to a request by the project owner, the application server design wasn’t a valid choice. The project was an integration project between two different systems. Due to one of them already implementing EDA, the implementation itself had a functional GUI and the communication being asynchronous it became evident that the implementation needed to support EDA and therefore EDA was implemented. The project time limit was not enough to implement SOA and there was also no need of the benefits of the patterns. There was not enough time to be able research other architectural patterns which might have been a better fit. Instead the focus was on starting an implementation as soon as possible to be able to fit the tight time schedule.

• How well were the architecture patterns used? SOA was not used at all since there was no need to implement it. EDA was successfully implemented and fitted well with the needs of the implementation. The communication was in many ways asynchronous and event driven which was a good match for an implementation of EDA. There was not enough time in the project to research other architectural patterns which would have had a positive impact on the implementation.

• How well modularized was the prototype? We implemented the extension through four modules, the GUI, the business logic and the two communication modules for Prelude and Vidispine MAM.

50 8.3. FINAL PROJECT EVALUATION

The communication modules could probably be abstracted into three mod- ules. One which would do the communication, one which interprets the mes- sages and one which sends the interpreted message to the business logic. The business logic module could probably also be better modularized into a data model, business logic for GUI and a processing module. But the functionality which we implemented was very limited and we didn’t feel the necessity to implement so many modules since we believe it would take longer time to define the separation than being worth the benefits.

• How well could the modules be reused? Since we did not define the interfaces between the modules it created a tight coupling with the data model we implemented. Parts of the code could be re-used while a large amount was very specific for Vidispine MAM and Pre- lude. We would estimate 25-50% of the code to be re-usable. If all the communication between the modules would be done through interfaces then the re-usability of the modules would rise substantially.

• How well was the "Separation of Concerns" in the prototype? With the four modules with their own specific task the "Separation of Con- cerns" was decent but we believed improvements could be made by abstracting the modules into smaller modules. The modules would be as mentioned ear- lier in How well modularized is the prototype?. The main question here was on which level the "Separation of Concerns" should be placed. If we tried to separate as much functionality as possible into different modules, the develop- ment process could turn into a process of defining the communication between the modules and deciding the abstraction. Due to the project time limit we did not spend as much time as we would like on the design which could had improvements on the "Separation of Concerns" aspect but the implementation turned out to be good enough to easily explain the task of each module.

• How well could the system be maintained? With "Separation of Concerns" and by having the extension panel made by several modules it becomes easier to maintain. Improvements which could have been done would include unit testing for each module and adding inter- faces between the modules instead of the tight coupling which exists at the moment. If a change needs to be implemented it might be that more than just the module needs to be changed. If we had more time and if it would be prioritized, we would definitely add interfaces to the modules and thereafter add unit tests to get code coverage of the logic which was performed. We had written comments in the code but we believed if we could we would try to make the code simplified but still performing the task. Perhaps a TDD (Test Driven Development) approach would have been a good idea to minimize the code.

51 CHAPTER 8. PROTOTYPE IMPLEMENTATION & EVALUATION PHASE

• How difficult was the prototype to apply? The prototype design was not difficult to apply. The only real issue was the time frame. Due to receiving the API documentation late and since the doc- umentation was not as thorough as we could hope, we had to do a lot of "trial and error" and make assumptions about functionality. These assump- tions could sometimes be wrong, which required additional development time. With a fixed deadline the scope of the project had to be lowered.

• How much planning was needed to start the implementation? The task given was to make an integration between two systems. We es- tablished early that one of the systems (Prelude) used EDA and the other one (Vidispine MAM) used a RESTful webservice as API. A requirement was also that the prototype was going to have a GUI. With a pre-study result which didn’t show any major limitations we could start the implementation. Even though there wasn’t any documentation of one of the systems, there was proper documentation of the interface of the RESTful webservice. By implementing a prototype design which was using "Separation of Concerns" it became possible to perform development within the areas which we had knowledge about. By mocking(simulating) the Prelude module we could start the development without any major limitations.

• Time consumption? Total time consumption in reading documentation, development and testing was estimated to be 200-250h. The time consumption for this level of proto- type would be substantially lowered with a more thorough API documentation of the Prelude API. The pre-study took longer than expected due to the ne- cessity of being very thorough when missing an API documentation. Also because of the contact being in another timezone it was sometimes difficult to hold real-time conversations so most conversation was dealt with through mails.

• How much time was spent together with seniors to discuss about different difficulties? The discussions with seniors were mainly about requirements and the goal of the project. Due to receiving necessary information quite late into the process, some functionalities had to be put aside to be able to keep to the time plan. Also requirements on the prototype were raised from the discussion with seniors. One example is the requirement of making the project easy to deploy. This lowered the possibilities for the application server prototype and after further discussions a decision to not use an application server was made. The total amount of time spent discussing with seniors were about 25-50h.

• What major problems occurred?

52 8.3. FINAL PROJECT EVALUATION

A lot of discussion was about the missing API documentation from Adobe which had a negative impact on the project. The development time was lower then expected due to not receiving the API documentation in time. Due to weak documentation a lot of functionality had to be tested before it could be used.

• Is it difficult to deploy the implementation to a customer? With an implementation which is pretty much stand-alone it becomes quite easy to deploy the implementation. If the implementation would require an application server it would need to be configured and maintained. The im- plementation only required the minimum configurations and we believed if it would be packaged in an installer the installation could either be centrally distributed and installed or installed by a person with minor computer knowl- edge.

53

Chapter 9

Project Conclusions

The project result was satisfactory. From obstacles such as very little API docu- mentation and a project time limit of one month, the result was better than what was expected. In the midway evaluation, we had to change the scope of the project but the goal was achieved. The project requirements changed the possible architecture designs which could be applied. By using Vidispine MAM (SOA) and Prelude(EDA) we had to ad- just the architecture designs to fit those systems. Since easy deployment was a requirement we had to choose designs which did not have any application servers. These limitations didn’t make it possible to apply the architecture patterns to their fullest. A design which would according to theory be superior to other designs, due to utilizing architecture patterns, does not have to be the design which gets im- plemented. It does not mean that the design would be better performing or easier to implement. We have learned that there is a big difference between the theoret- ical world and the working world. Our first thought was that theory would decide how the architecture design would look like, but instead the project specification had limitations and requirements which changed the whole scope. The main goal with the implementation was to modularize as much as possible. This direction was chosen because we wanted to be able to reuse the code and if needed, since the project was prone to change, change different modules without affecting the whole implementation. We successfully made the implementation modularized enough to make testing easy. This was achieved by having “Separation of Concerns” as much as possible to separate different tasks. If we would like to change the database, only a single class in our implementation had to be switched out. All this contributes to make it easier to maintain the implementation. Even though it was a prototype im- plementation it wouldn’t be difficult to maintain. If anything needs to be extended or new functionality needs to be implemented it wouldn’t be a hard task since the implementation was modularized and the “Separation of Concerns” are clear. The prototype implementation didn’t go as good as we hoped to. Without an API-documentation which covers all the basic areas, an implementation will be delayed by so many pit stops which have to be solved before continuing on. We

55 CHAPTER 9. PROJECT CONCLUSIONS

Figure 9.1. Actual implementation tried to work on different areas and changed our focus when we couldn’t continue to work on a specific area. But when the distribution of time amongst Vidispine MAM and Prelude got too unbalanced we had to ask ourself, could this be avoided? We estimated our time used on testing undocumented API would be 10-25% which could be reduced with a well written API-documentation and examples. Even though we had access to a developer at Adobe who could answer our questions it still took time due to time differences in Europe(us) and America(the resource). The time needed before starting the implementation was mostly put on the Pre-study. By clarifying what we were going to work with and after some discussion with the seniors at Mediasmiths, a much clearer picture could be made about what would be implemented. The pre-study and the discussion with seniors took about 10 days of research. We extended the second implementation phase by one week due to getting the API-documentation for Prelude a little bit into the first implementation phase. No other major obstacles occurred during the implementation phase. It’s not a difficult task to deploy the implementation but due to architecture decisions some configurations needs to be set manually. The prototype implementation was a proof of concept. Therefore it should by no means be used commercially.

56 Part IV

Results

57

Chapter 10

Discussions

The results of the case study were a little surprising. Coming from the academic world we hadn’t really thought that much about the new but ordinary factors, in working life, which may have a decisive role. We can now understand why others haven’t tried to compare architectural pattern a larger scale. The application which implements most architecture patterns or the most efficient architecture patterns for the given task might not always be the one which will be implemented. Sadly no method for comparing architectural patterns could be created. We didn’t gain any more knowledge about how a comparison of architectural pattern is performed nor gain any directions towards guidelines in how a comparison would have been done. Perhaps in a work application there are too many factors which must be satisfied which render a possible method useless. Even though if we had a method which could compare architectural patterns there is still a possibility that there may be factors which force us to make different decision. The developer may have to sacrifice flexibility and functionality to be able to finish a product because the deadline in a real world application may be the most crucial factor. A missed deadline might mean unexpected costs which may jeopardize the project or even the development team or in worst case even the company. Due to factors such as requirements and time it might not be possible to find an architectural pattern which is a better fit than an architectural pattern which the developer knows. With a new pattern the developer needs to spend time on the architectural pattern. The developer needs to find knowledge about the pattern, read up, fully understand its application and how it works as well as understand how it may be implemented in the current context. This results in even more time consumption on research than actual progress forward. Since the number of architectural patterns is huge it might be hard to find the specific architectural patterns which improve the result. It might only be time consumption which results in nothing. We believe that in many cases delivering a system which performs the specified action A good enough is better than delivering a system which performs the specified actions A and B while being late when action A was the project requirement. B

59 CHAPTER 10. DISCUSSIONS might have been an extra feature which was planned to be added but a feature which can be removed and is not critical. Architectural patterns are very specific and clarify when a pattern should be used, its purpose and which prerequisites are needed to be fulfilled. Even though it may seem to be a good idea to always implement them, it might not be so. Implementation may prolong the development time and if the benefits of the applied architecture pattern are not used then why should the pattern be implemented in the first place? In this project, time was a very important factor. Since we didn’t receive the API documentations in an early stage it stalled the development a little since we could only make assumptions of how to work with the system. This had an impact on our project plan which resulted in down prioritizing finding a better architectural pattern/prototype design to apply and instead use our current knowledge to be able to deliver in time. The academic world actually has more freedom within this area than working life. Maybe it is not the best way to tackle the issue of "Which is the best fitting architectural pattern" with finding a method to be able to compare the architectural patterns. It’s too specific and the difference between architectural patterns is so vast as well as the related factors. We would like more case studies to be able to draw general conclusions. But we believe that there are many factors which influence the development of software and some of these factors have a larger impact than others. Some factors are critical and some are not, but there are always some factors which change the selection of architectural patterns.

60 Chapter 11

Final Conclusions

11.1 Project

The case study given by Mediasmiths was a system integration project. The conclu- sions made from this project may be very specific. More data need to be gathered to be able to achieve a more certain conclusion. An integration project has limitations, since we have to adapt to the systems which are going to be integrated, e.g. how we communicate with the other systems, what functionality needs to be integrated etc. Factors outside the academic world have a major impact. There are factors which disregard the technical details: time and money, are factors which are non- negotiable: project result requirements and more. Time has had a large impact on the project. With a fixed deadline, we didn’t have as much time as we wanted to for being able to research, learn and be ready to apply the architectural patterns. Instead we had to narrow the scope and timebox tasks to be able to receive results. We have to be able to adopt to changes when developing in a project. A sudden change, like gaining additional information about a system, opens new possibilities. But due to already having started the project we had less time. Decisions needed to be made and we had to sacrifice a more versatile solution to avoid being late with the project delivery. This project showed the importance of a thorough pre-study and proper documentation of the systems which were going to be integrated. It is understandable when a developer uses his existing knowledge when design- ing a prototype instead of putting time into finding an architectural pattern which may improve the design. The time cost would be too high and it could risk the project. A prototype project aims to be able to show that it is feasible to carry out.

11.2 Architectural patterns

Architectural patterns are very specific. They are meant to be put into use in a certain context and they require certain requirements to be fulfilled before they should be applied. It is hard to compare different architectural patterns since they

61 CHAPTER 11. FINAL CONCLUSIONS may cover different areas. Since the architectural patterns may cover different areas they can sometimes be implemented together to gain both of their advantages and disadvantages. It takes a substantial amount of time to search for an architectural pattern, understand it and gain enough knowledge to be able to apply it. When applying an architectural pattern we must consider if we need its benefits versus the extra difficulty of implementation. The project time plan needs to be taken to account.

11.3 Method

No method could be established by our project. Factors such as environment and time were too strong, and there was no choice between architectural patterns or time to research for an architectural pattern to be implemented. No conclusions from case study experience could be drawn which would help towards creating guidelines in a comparison of architectural patterns since there was never a discussion about different patterns, more of a forced selection.

62 Bibliography

[1] Rick Kazman, Mark Klein, Mario Barbacci, Tom Longstaff, Howard Lipson, and Jeromy Carriere. The architecture tradeoff analysis method. Technical report, Carnegie Mellon Software engineering Institute, 1998. [2] Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Pat- terns: Elements of Reusable Object-Oriented Software. Addison-Wesley Pro- fessional, 2nd edition edition, 1995. [3] Eric Freeman, Elisabeth Freeman, Kathy Sierra, and Bert Bates. Head First Design Patterns. O’Reilly Media, 1st edition edition, 2004. [4] Gregor Hohpe and Bobby Woolf. Enterprise Integration Patterns. Addison- Wesley Professional, 1st edition edition, 2003. [5] J. D. Meier, David Hill, et al. Microsoft Application Architecture Guide. Mi- crosoft Corporation, 2nd edition edition, 2009. [6] Walter L Hürsch and Cristina Videira Lopes. Separation of concerns. Technical report, College of Computer Science, Northeastern University, 1995. [7] Artur Trosin. Separation of concern vs single responsibility principle ( soc vs srp ). Technical report, 2009. [8] Robert C Martin and Micah Martin. Agile Principles, Patterns, and Practices in C#. Prentice Hall, 1st edition edition, 2006. [9] Michael Jones. Loose coupling is good - tight coupling is the devil. The Software Devotional, 2009. [10] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 2nd edition edition, 2000. [11] Evan Marcus. The myth of the nines. www.searchstorage.techtarget.com, 2012. [12] Rongshu Yi and B Eng. High availability and software architecture. Master thesis, McMaster University, 2007. [13] Thomasl Erl. SOA Principles of Service Design. Prentice Hall, 1st edition edition, 2007.

63 BIBLIOGRAPHY

[14] Raghu R Kodali. An introduction to soa. Technical report, 2005.

[15] Douglas K Barry. Service-oriented architecture (soa) definition. Technical report, 2005.

[16] David Sprott and Lawrence Wilkes. Understanding service-oriented architec- ture. Architecture Journal, 2004.

64 Appendix A

Project documentation

The following document is the system integration project description given by Me- diasmiths.

65 APPENDIX A. PROJECT DOCUMENTATION

Background Prelude is the working name of an upcoming product from Adobe which among other things can be used as a cataloging solution.

It gives the user the ability to review media in a variety of formats (codec, wrapper, operational pattern, bit rate etc) and also the ability to add comments (metadata) to the media as a whole or specific sections of the media (aka sub­items). Additionally, there are plug­ins to Prelude for speech­to­text for instance which automatically create sub­items with the text associated with the time in the media where a word was spoken.

This functionality can be used in different ways. It can for instance be used for pre­processing (QC or shot selection) before moving the content into Premier (craft editing solution) or to generate a log of the content to send to a 3rd party. We however see a different use for Prelude. We want to use it as a cataloging solution for an enterprise media asset management system (MAM).

About MAM An enterprise MAM system can in the "worst" case hold hundreds of thousands of hours of media content and in such an environment it becomes crucial to provide users with good search facilities. The indexing and search components are key but without good and descriptive metadata there will not be anything to search for.

Integration task We want to integrate Prelude with the Vidispine MAM system for two main use cases.

1) Content acquisition and acquisition logging

A digital file (high resolution) would be opened in the Prelude application. Metadata is entered for the whole asset as well as timecode (frame count) specific metadata sets. Once all cataloging metadata has been entered, the media will be transferred into the Vidispine MAM system and the metadata will be transferred as well. Alternatively, create a placeholder item in Vidispine straight away and create metadata sets in Vidispine as they are created in Prelude.

2) Logging of existing content

66 From within Prelude, search the Vidispine MAM system for an asset. Load the media (preferably proxy) from the MAM into Prelude. Any metadata (general or timecode/frame count specific) stored in Vidispine is to be loaded from Vidispine to Prelude. Ideally, listen to notifications/register to get updates about changes to the metadata of the item so Prelude can be continuously updated if metadata sets are created/updated/removed for the item in another session. Enter timecode (frame count) specific metadata sets. Metadata sets should be transferred to Vidispine as they are created. When finished, remove any locally stored/cached media (proxy or high resolution).

Prototype functional requirements

Function Description/comment Importance 1­5

Ability to insert media into 5 Vidispine

Ability to insert (whole) 5 asset metadata for media into Vidispine

Ability to render and also 5 create, update, delete asset metadata in Prelude

Ability to insert timecode 5 specific metadata into Vidispine

Ability to render and also 5 create, update, delete timecode specific metadata (sub­item) in Prelude media timeline

Ability to differentiate 4 between different types of sub­items in communication with Vidispine

Ability to differentiate 4 between different types of sub­items when rendering on Prelude timeline

67 APPENDIX A. PROJECT DOCUMENTATION

Investigate if it is possible E.g. sub­items of certain types may not overlap, 5 to enforce rules in Prelude sub­items of type X must be contained within in terms of how different sub­item of type Y. sub­items affect each other.

Error handling on E.g. lost connection to Vidispine, don’t leave 2 acquisition orphaned data in Visipine or media on local workstation, recover work­in­progress data in case of application crash

Ability to search Vidispine for assets

Ability to present search result in Prelude

Ability to load selected Obtain video and keep Vidispine identifier for search result into Prelude video. Obtain asset metadata and sub­item information and display in Prelude.

Instruct Vidispine to create 2 proxy for acquired media

Instruct Vidispine to create 2 keyframes for acquired media

Ability to listen to 4 notifications from Vidispine about updates to the currently loaded asset including sub­items

Ability to display (modify 4 currently rendered) result of notifications from Vidispine abotu currently loaded asset including sub­items

68 www.kth.se

Powered by TCPDF (www.tcpdf.org)