A comparison of Architectural Patterns

A study of a real world application

HWOH HEI JAMES HAU

Master’s Thesis at NADASupervisor: Karl Meinke

Examiner: Jens Lagergren

TRITA xxx yyyy-nn

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

In this Master Thesis, a description selection of important areasin architectural patterns are given and two patterns, Service OrientedArchitecture (SOA) and Event-Driven Architecture (EDA) will also bedescribed in minor versions. This will help the reader to get a bet-ter understanding of architectural patterns and important factors. Bystudying a software integration project it gave a clear view of how thechoice of an architectural pattern was decided in working life. Factorssuch as time limited the prototype design and its implementation of thearchitectural patterns. Even more factors limited the choice of architec-tural patterns. Necessity and what’s possible, because of the existingsystems, takes overhand and limits the selection of architectural pat-terns heavily.

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

ReferatEn 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 kandet 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ämpasbehö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åsomtid, 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 projektom 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 somtid som begränsade prototype designen och valet av de arkitektoniskastrategierna, det var flera faktorer som påverkade valet av arkitekto-niska strategier. Nödvändighet och vad som var möjligt på grund avde befintliga systemen, visade sig vara stora faktorer vilket begränsadevalet av arkitektoniska strategier kraftigt.

Varje projekt är väldigt specifikt och med arbetslivs faktorer somtid och kapital blev det uppenbart att fokus låg på att leverera ettsystem 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ördelarnamot nackdelarna. Det blev tydligt att jämföra arkitektoniska strategierkan potentiellt inte vara värt den ansträngning som krävs. Istället börsystemutvecklare fokusera mer på vad som är möjligt i systemets miljö.

Contents

I Introduction 1

1 Thesis 31.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Case: Prototype project . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Thesis contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.7 Target audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

II Theory 7

2 The viewpoint of patterns 92.1 Architectural pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Design pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Benefits with patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Methodology to compare Architectural Patterns . . . . . . . . . . . . 102.5 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Important areas 133.1 Separation of Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 Loose coupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 Five criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 Five rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.4 High availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4.1 Issues which may interfere with high availability . . . . . . . 18

4 Two architectural patterns described 214.1 Service-Oriented Architecture (SOA) . . . . . . . . . . . . . . . . . . 21

4.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.2 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.3 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.1.4 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.5 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Event-Driven Architecture (EDA) . . . . . . . . . . . . . . . . . . . 234.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.2 Components in EDA . . . . . . . . . . . . . . . . . . . . . . . 244.2.3 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2.4 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

IIICase study 27

5 Introduction 295.1 Project description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.4 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.5 Project plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.6 Selection of prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 325.7 Midway Project evaluation . . . . . . . . . . . . . . . . . . . . . . . 325.8 Final Project evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 325.9 Reaching a conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6 Pre-study 356.1 Available assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.2 Adobe Prelude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356.3 Vidispine MAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

7 Prototype design phase 397.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2 Prototype designs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.3 Selection of prototype . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8 Prototype implementation & evaluation phase 498.1 Implementation phase startup . . . . . . . . . . . . . . . . . . . . . . 498.2 Midway evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498.3 Final project Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . 50

9 Project Conclusions 55

IV Results 57

10 Discussions 59

11 Final Conclusions 6111.1 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6111.2 Architectural patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 6111.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 ofTechnology in Stockholm (KTH), Sweden.

1.1 BackgroundArchitectural patterns are an important part of software development and theknowledge of different patterns has become more and more popular amongst com-puter scientists and system developers. Architectural patterns offer solutions tothe developers in well-known problems such as how to abstract their task, organizefunctionalities and how different modules such as the user interface(UI) and thedata 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 knowall the different architectural patterns and there is no method of deciding whichpattern to apply to a given situation when several patterns could be applied. Itis very common that the software developers themselves decide which architecturalpattern to use and it sometimes comes down to preference and experience of thepattern instead of how well the architectural pattern actually fits with their currenttask.

1.2 GoalsThe goal of this master thesis is to be able to provide a method to differentiatebetween different architecture patterns and to help the developer in the choice ofwhich pattern fits the given task best. The goal is to be able to decide how tocompare different architectural patterns in working life. There will be a case studygiven by Mediasmiths where we will evaluate how the decision of software design ismade 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. Thecase 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 wecan and should use in working life when developing software?

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

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

1.4 Scope

This Master thesis will not cover all architectural patterns, since there are toomany patterns. Instead a small selection of patterns will be made. The goal isto make the method as general as possible. The method which will be createdwill not be the definitive answer to the problem statement but give an example ofhow 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 thecontext of working life and not in the academic world, where a lot of factors, whichhave a huge role in working life, are not applicable. The focus on programminglanguage and development environment will be as small as possible. The thesis willonly 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 afew architectural patterns. These patterns will be discussed in terms of complexityin implementation, strengths and weaknesses. A case study will be presented anddesign prototypes will be made. These prototypes will also be discussed in thecontext of how well they fit with this specific case. This specific case will be areal case study provided by Mediasmiths. A requirement specification of the casestudy will be given as well. A small project of the case study will be made wherewe will make an implementation of the prototype and evaluate if the selection ofthe prototype design was good considering the circumstances of the project. Ifnot, 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 theprototype design fit the project. From this experience we hope to be able to findspecific factors which need thorough consideration when an architectural patternis selected. With the experience of the case study we hope to be able to create amethod to compare and decide the best fitting architectural pattern for a given taskin the working life.

4

1.6. THESIS CONTENTS

1.6 Thesis contentsThe outline of the thesis is organized as follows: Part II, the Theory, will describesome 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 designand implementation. Finally there will be an evaluation of the project results. PartIV 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 adiscussion about the project results.

1.7 Target audienceThis thesis is written for aspiring software developers and individuals who have aninterest in software architecture. This thesis will help developers with an academicbackground to prepare for the working life. With this thesis they will hopefully getmore prepared for how the real world looks like and come to understand that theacademic world is very much different than the real world. Knowledge in softwaredevelopment 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 anda design pattern. We will in this chapter offer the thesis viewpoint of the definitionof patterns. A brief description of patterns will give a better understanding to thereader and will make it easier to understand in which context the patterns are usedin.

2.1 Architectural pattern

An architectural pattern is a high level design of how elements or components areinterconnected. It may show predefined sub-system, their responsibilities and theirrelationships amongst each other. An architectural pattern is a way to abstract theelements and components so the system becomes easier to understand, modulateand 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 shownfor the outside world.

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

Frank Buschmann

The architectural pattern offers a solution to a specific problem in a specificcontext. There are many architectural patterns used as a solution for the sameproblem 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 patternAn architectural pattern and a design pattern are both solutions to re-occurringproblems. The difference is that a design pattern is a much more detailed view ofan element. While the architectural pattern describes the top view, a design patternshows the classes and interfaces needed to create the element. Design patterns arebecoming more and more important in software development since they are provensolutions and save research and testing time which means we can focus on newdevelopment instead.

2.3 Benefits with patternsA 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 sothe pattern is not misused in a context where it does not contribute to the solutionof 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 problemin the given context.

Patterns are tried solutions to problems which may reoccur. Patterns describethe problem in such a way that we know what the requirements are, the benefitsand 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 asystem, the person can picture the high-level design of the system.

2.4 Methodology to compare Architectural PatternsWe have not succeeded in finding any methodology for comparing architectural pat-terns. However Kazman[1] describes a method for understanding the tradeoffs whendealing with architecture of software systems. We will describe this method briefly.

The Architecture Tradeoff Analysis Method works by evaluating different attributesand how they affect other attributes when altering the architecture of the softwaresystem in anyway. By doing several iterations where each iteration is split up intofour main phases we understand how different requirements and changes affect dif-ferent attributes. Attributes are often connected to each other and by changingthe 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 gatheredfrom different analyses, from the stakeholders and more.

2. Architectural Views & Scenario Realization – By describing the architecturalview and understand how it will react to different input we can theoreticallydo trials. Several architectural views can be created or altered in this phase.In this phase we perform the different scenarios with each of the architecturesand document the results.

3. Model Building & Analyzes – By performing performance analyses we can seeif the architectural views of the software fulfill the requirements set in phase1. By having the analyses early in the design processes we can quickly applychanges and compare the different architectural views. This also increases thechance of discovering potential dangers and areas to be aware of. If we wouldestimate the system availability we can get an average result by creating andsolving a Markov model. A Markov model can be described as a model usedto predict a future status by its current status without knowing old statuses.

4. Tradeoffs – The final phase tries to summarize which attributes were affectedin the architectural views and how those changes affected other attributes.With this information we can decide which tradeoffs to perform by havingtheoretical weight behind the decisions. If all requirements and constraintsare not satisfied we can perform another iteration.

2.5 Further readingPerhaps the most famous book about design patterns is “Design Patterns: Elementsof Reusable Object-Oriented Software”[2] by Erich Gamma, Richard Helm, RalphJohnson and John Vlissides. The book describes common software design problemsand had (and still has) a large influence of design patterns when it was released in1994 .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 sometimescalled “The GoF book” because of its long title.

Another book is “Head First Design Patterns”[3] by Eric Freeman & ElisabethFreeman and more. It’s a great book about design patterns with examples basedaround Java and the book is written for people with junior or senior skills in softwaredevelopment 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 enterprisesoftware 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 tobuild 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 architecturepatterns. It’s not a very detailed book but it’s a quick reference if we want to lookup 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 ofplatform and of programming language.

12

Chapter 3

Important areas

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

3.1 Separation of ConcernsSeparation of Concerns is when we separate functionality instead of cluttering ittogether. There are several ways to achieve Separation of Concerns and modularityis one of them. By separating features into different modules it becomes easier tofind and change a specific feature. Abstracting into different layers is also a commonway to show Separation of Concerns. A concern might be a specific feature orbehavior in a program [6]. Designing these systems gives the possibility to work onan individual feature and makes it easier to exchange each module. Service-OrientedArchitecture is a way to separate concerns by having services. Some benefits fromSeparation 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 designpattern. Separation of Concerns has some similarity to the Single ResponsibilityPrinciple[7] but they are not the same. The goal, to separate code into differentparts 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 atask. The Single Responsibility Principle defines responsibility to be “a reason forchange”. If there might be more than one reason to change a class then it has morethan one responsibility and should be abstracted[8].

3.2 Loose coupling

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

A module should know as little as possible about the other modules. By havinglittle knowledge about other modules the module won’t be able to form as manydependencies and the module will be less tightly coupled. If a module implementsbusiness 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 moredifficult to program, we have to do more work and our thought process needs to bemore 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’sbeing programmed [9]. In the long run if our system has become something muchlarger than expected, this may have major impact on the system when a minorchange occurs. If we have several modules tightly coupled like a chain this will besimilar to a ripple effect, just because we changed a property we suddenly have tochange several classes. Small changes suddenly grow out of proportion.

What we need to consider is what we should loosely couple and what we shouldtightly couple. Using loose coupling on everything we program is not the goal ofloose coupling. The goal is more to reduce the work when changing modules orinterfaces. Say we have an application with a data layer using a database. Whenwe want to switch the database and if the layer is correctly loosely coupled we willonly have to work on the data layer and not on any other layers. This doesn’tremove 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 quicklywhich requires the software to be flexible so it can support changes and also beexpandable to be able to cope with the growth of a software. We may have stumbledupon times when we noticed that we are implementing functionality and code whichwe might have implemented before. Why not reuse the code if it has good enoughinterfaces? 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 applicationfrom 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 todistinguish itself from other modules. It’s hard to pin-point exactly what a moduleis in software engineering. It could be a server, an application or even a class. Wehave read a number of papers, had discussions and we believe the word "module" isoften used without really comprehending what it involves. Then we stumbled upona description of modularity by Bertrand Meyer[10] who lists 5 criteria and 5 ruleswhich cover the most important parts of a modular design method and which helpsus evaluate the modularity level of a software architecture. We will here referenceBertrand 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 probleminto a small number of less complex sub-problems, connected by a simple struc-ture, and independent enough to allow further work to proceed separately oneach item"

This allows the problem to be split into minor problems which may be workedon separately. The benefits of working in parallel to solve a subproblem, whichcontributes to a much complexer problem, is that the main problem might besolved faster. This also requires the subproblem dependencies to be as few aspossible. If the dependencies are too many it will halt its progress because ithas to wait for problems which it depends on to be solved or to reach a certainpoint where it may continue. These dependencies need to be known as wellotherwise we might end up with a solution to a subproblem which doesn’tfulfill the requirements of the main problem.

• Modular Composability – "A software construction method satisfies ModularComposability if it favors the production of software elements which may thenbe 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 rebuildother systems. This doesn’t mean a design is not modular if the modulesdon’t work in every other environment, but the module should be independentenough to be used in another context. We usually want to fulfill this criteriaas 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 canunderstand each module without having to know the others, or, at worst, byhaving to examine only a few of the others"When maintaining software there is a need to identify where the fault is. Byhaving 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 codeitself, there will be less misunderstandings when interpreting what the moduledoes. Descriptions also help with paving the way for an analysis, making iteasier to create a software design with the module integrated and also what’snecessary to implemented the module.It’s always a good idea to keep a description inside the module. This reducesthe chance of having a document with a description which is out of sync withthe module. This will steadily remind the developer that the documentationneeds 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 theproblem 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 makesoftware possible to expand is very important. Ad hoc solutions are quite com-mon and with designs allowing extensions to be connected into the solutionit becomes more expandable. This raises requirement of the software design,since flexibility might be a comprehensive task to implement. Nowadays weare supposed to be able to configure anything, from our custom fit car to ourfunctionality 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 madefrom modules and being directly able to change a module instead of changingthe whole system, the process takes less time. These are just a few exampleswhy it’s important to not make modules dependent on other modules so wedon’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 conditionoccurring at run time in a module will remain confined to that module, or atworst will only propagate to a few neighboring modules"If an error can occur, it will occur(Murphy’s law). It’s important to keep theerror within the module and not spreading it to other modules. If an erroris spread from a module this may create undefined behavior which makes ithard to track down its source. This criteria is not about how to solve the errorbut 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 oreven 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 iteasier to localize where changes needs to occur (The Continuity criteria) as wellas 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 softwareinto separate modules which may be used for later composition.

• Few Interfaces - A module should communicate with as few other modules aspossible. The requirement to change several modules when changes need tobe implemented becomes less and the occurrence of an error will be spread toas few modules as possible. By having as few dependencies as possible it alsohelps the composability criteria, since it makes it easier to fit into differentdesigns when less modules are required. This also assists in the continuityand 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 lowerthe 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 othertheir communication should be clearly defined and their dependencies shouldbe visible. This assists in decomposability and composability by showingwhich 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. Thisrule supports the continuity criteria by showing which modules need to bechanged and the understandability criteria by defining which modules need tobe 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 wanta user to be able to access all parts because they might be fundamental forthe 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 havingeverything public we will also make the module interfaces smaller.

17

CHAPTER 3. IMPORTANT AREAS

3.4 High availabilityAvailability is an important factor in system design. It’s the time which a system isfunctional and working, but this doesn’t have to mean that a system should alwaysbe available. Sometimes we want a system to only be available during a short periodof 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 their99.99% availability. When discussing the high availability we usually talk about"the nines"[11] shown in the table.

Nines Percentage Downtime in a year1 90% 36.5 days2 99% 3.65 days3 99.9% 8.75 hours4 99.99% 52 minutes5 99.999% 5 minutes6 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’scritical for it to be available for usage. When we can’t pinpoint these times wefavor a generally high availability percentage. With the Table 3.1 we get a quickoverview.

3.4.1 Issues which may interfere with high availabilityBelow 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 unavailableat a time, the whole system might not function correctly. This may be avoided bymirroring the module and reroute the work flow through the duplicate to avoidtotal unavailability. Another example is network load balancing for not locking outcertain modules when large amounts of data are being sent or having an emergencyroute which the data may travel on. This emergency route (backup system) shouldbe a totally separate process to minimize the chances of them both being unavailableat 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 easierto sabotage a system. This attack might use the weakness in a system with aslow processing time, to make the system look like it has been halted, or a bugin the network configuration. To prevent DoS attacks it’s important to detect theattack patterns and malicious behavior and stop them before they continue for toolong. A common reason why systems crash is because of low data validation. Bysending unexpected data into the system an unexpected behavior might be theresult. Enforcing comprehensive data validation may be a large task to do but it isan 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 servicerequest will be rejected. A common example is databases and access to the samedata. When two requests on the data source are performed at the same time it maycause one request to be rejected while the other one proceeds. Deadlocks, wheretwo asynchronous requests are waiting for each other to finish before any of themcan 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 thebest case it may not cause any damage at all. By designing correct exceptionhandling the system can catch these bugs and faults for reporting to the systemdevelopers 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 tobecome offline. By having a design which allows run-time upgrades the whole systemdoesn’t have to become offline and may still function with perhaps only a small delayon request execution. Developing a system with the possibility to perform run-timeupgrades may be difficult to develop, but the availability issue can be solved inmany other ways. For example a server upgrade might be performed in batchesinstead of taking down all servers at the same time so there will always be someservers available.

19

Chapter 4

Two architectural patterns described

In this chapter the reader is given a detailed description of two architectural patternswhich are used throughout this thesis. By giving these descriptions the reader willhopefully 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 eachoffer their own unique functionality. With SOA comes certain strengths such asre-usability but also weaknesses such as extended development time for certainfunctionalities. 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 providedas well as the communication to and between them.

SOA became popular with the usage of web services[15]. Web services are theset of protocols which services can be published, discovered and used in a tech-nology neutral standard form. SOAP, REST, CORBA and Java RMI are otherimplementations with the SOA pattern.

4.1.2 Service

The main building blocks in SOA are the services and their communication. Aservice implements a reusable functionality and has a clear description of what itsfunctionality is, how to use the service and where to access it. Services are looselycoupled, simplified for the service consumer and allow changes to a single servicewithout having an impact on any other services. Here is a representation of aselection 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 betweenitself and the consumer which places obligations on the provider and consumer

• Interoperability - With well defined interfaces the services can interact witheach other without encountering issues because of their implementation oraccess

• Independent - The services should be independently

– Developed– Deployed– Maintained

4.1.3 ConnectionCommunication is done in a heterogeneous environment, with little or no knowledgeof the consumer. As long as the service consumer fulfills the formal contract it willreceive 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 exchangemessages 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 canlead to errors in communication but when a collection of services are interoperableit means that they can interact without encountering these issues. This is verysimilar to loose-coupling but loose-coupling does not guarantee there won’t be anyissues 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 implementationof the service.

22

4.2. EVENT-DRIVEN ARCHITECTURE (EDA)

• It becomes easy to add new services to the provider while not changing anyof 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 inspecific areas.

• The pattern allows evolution without changing existing implementations.

• It offers scalability because we can add new functionality without changingthe 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 thedifficulty worth it or are the services even necessary?

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

• Separation needs managing.

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

• Overhead when wanting a certain functionality. Suddenly it has to be madethrough 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 DescriptionEvent-Driven Architecture (EDA) is an architectural pattern which focuses on thecommunication between components through processing events. The pattern alsodescribes 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 workflow, sometimes a transformation and sometimes the event might also result in noaction being taken at all. This pattern promotes an asynchronous, loosely coupledand flexible implementation. The system performs the work first after the eventhas been received which makes it asynchronous. All the event subscribers havedifferent implementations and shouldn’t have any kind of dependencies betweeneach other which makes the subscribers loosely coupled and the system also becomesvery flexible to changes. An event-driven system usually consists of one or manyevent producers, some sort of messaging queue and the event consumers who reactaccordingly to an event.

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

4.2.2 Components in EDA

Event

An event refers to an action which has occurred either inside or outside our businesslogic. An event refers to the specification (definition of the type of event) and eachoccurrence (the current instance of the event) For the event to be meaningful fordownstream subscribers, the event specification should be described in businessterms for easier understanding of what has occurred.

An event contains a header and the body. Many Object-Oriented Programinglanguages implement the event with event type, event name, event timestamp, eventoccurrence and event creator. The event body should contain enough informationso that any subscriber handling the event shouldn’t have to retrieve any additionalinformation 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 createsthe event and sends it to the event channel. The event generator does not knowof anything past the event channel. Since there may be several different eventgenerators it may be required to transform the event in a specific format so it maybe transported correctly by the event channel and thereafter handled correctly bythe event processing engine.

Event channel

The event channel transports the standard formatted event produced by the eventgenerator 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 maystart a work flow, call a service or notify a human of the event. It may also publishthe event to downstream event-driven activity.

Downstream Event-driven Activity

The downstream event-driven activities receive the event since they subscribe tothe 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 enginepublishes the event. The subscribers of the event may be other automated servicesor non automated services. The automated services then perform an action suchas start a work flow, publish the event to a dashboard or even store the event. Asystem 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 eachsubscriber possible triggering different workflows. This allows expandabilitywhile not modifying the existing code (Open Closed principle).

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

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

• Easier to maintain when each subscriber which processes the event triggerstheir work independently from each other. This makes it easier to maintainthe system due to most business logic being performed in the event processingengine 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 wemight 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 arealways situational.

• It is hard to track the event along the multiple subscribers. Therefore EDAis mostly used for asynchronous flows since the system may publish the eventand 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 havingthe constraints of working life and experiencing them first hand we hoped to be ableto make some conclusions and gain insights info how architectural patterns are usedin working life context. The conclusions drawn from this experience are empiricaland not in any way definite conclusions.

5.1 Project descriptionThis project was a research project with a minor implementation part. What wasof interest in this project were the possibilities and limitations of the integrationbetween Vidispine MAM(Media Asset Management system) by Vidispine and Pre-lude(Metadata logging software) by Adobe System Incorporated as well as their ownlimitations. The implementation part was to make a proof of concept/prototypeof a possible integration between the two systems. This integration was a PreludeExtension. The extension was written in Actionscript which is an Object Orientedlanguage 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 GoalThe goal of this project was to gain experience of how to implement an architecturedesign in working life. By documenting factors, limitations and conflicts of interestregarding architecture design and architectural patterns we wanted to see issueswhich would possibly occur in other types of projects. By applying theory anddesigning architecture design prototypes we hoped to gain a better understandingon 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 projectwas the Prototype design phase (chapter 7). In this chapter we will explain andjustify why we selected a certain design for implementation.

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

5.4 AssetsThe 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 onUbuntu 10.04 LTS. Adobe contributed with a SDK and API documentation forAdobe Prelude. Vidispine had their own API documentation for the VidispineMAM. Adobe had an integration engineer available for development questions andMediasmiths 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 Preludehas 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 moredetailed views of search options and much more. Instead of getting a whole clipas 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 severaltime spans where goals occurred. Integrations with Prelude are made through anextension to Prelude.

Vidispine Media Asset Management v3.0.5

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

30

5.5. PROJECT PLAN

“An architectural pattern is a description of element and relationtypes together with a set of constraints on how they may be used. Apattern can be thought of a set of constraints on an architecture- onthe element types and their pattern of interaction and these constraintsdefine 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). Thelanguage is made for the Adobe Flash Player and Adobe AIR environments. Flexis an open source framework which extends Actionscript and helps the developer tobuild 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 limitwas set to three months. The main phases were:

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

• Prototype design phase - Several prototype implementation designs weremade 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 designwas selected and it was implemented. If the implementation design would shownegative signs or other effects which would impact the project negatively, achange to the prototype design or scope of the project would be possible toadd at the midway project evaluation. Thereafter the implementation phasecontinued. The phase also contained evaluations. The project evaluationresulted in two reports. An evaluation report was handed over to Mediasmithsas well as the implementations source code. The other evaluation report wasmainly a discussion about the implementation based on the new experienceand theory. A set of questions was discussed. Further detail will be explainedbelow.

31

CHAPTER 5. INTRODUCTION

5.6 Selection of prototypeThe patterns that have been selected for this Master Thesis are Service-OrientedArchitecture 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 prototypedesign?

• 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 adecision of which prototype implementation was selected to be implemented.

5.7 Midway Project evaluationDuring an implementation of a project, due to a vast variety of circumstances, theproject might have to be re-evaluated and assessed again. In this case it could benecessary due to new information about the different integration parts that couldchange the picture or the choice of prototype design.The Midway Project evaluation considered if there were any circumstances where achange 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 theselection of prototype implementation design.

5.8 Final Project evaluationThese questions were discussed with the newly gained view of the experience. Theviewpoint 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 differentdifficulties?

• What major problems occurred?

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

5.9 Reaching a conclusionBy evaluating the project experience we wanted to be able to give our currentsuggestions and/or answers to the thesis problem statements. Any specific eventsthat could have changed the project outcome was discussed as well as how theycould 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 revealissues, possible risks which could cause damage and other possible conditions. Inthis case the project had many assets which were completely new to the developerand therefore needed to be overviewed.

6.1 Available assetsThe 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 PreludeIntegrating with Prelude is usually done through an extension. This extension usesthe Flex library which involves Actionscript. All programmatic communicationwith Prelude is done through the extension. Prelude does not expose any kindof data but instead allows an extension to listen to specific events which triggerson user actions(EDA). These events have bodies of the format of XML. To replyor trigger events in Prelude we had to dispatch our own events with a specificevent 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 hasrecently begun and therefore the examples might be in the earliest stages. Thesamples mostly show that things happen through events with a message body suchas XML, by showing printouts, but not much else. Due to the lack of any kind ofdocumentation we have to make assumptions on what kind of actions trigger whichevent, and assume that the body has the format of XML and is constantly returningthe same structure. One requirement is that the extension needs to use the Flex3.5 library since Adobe Prelude uses this library. Since no XML schemas or API-documentation have been given, uncertainty on how to communicate with Preludeexists. One sample demonstrates communication with Prelude. Due to all thesecircumstances the possibilities and limitations of communication with Prelude needto be re-reviewed at a later stage. This presents a major risk that some functionalitymay not be possible at all.

6.3 Vidispine MAMVidispine MAM API is a RESTFUL-web service. REST stands for Representationalstate transfers, which has several benefits. One is that each entity has their ownURI(Uniform Resource Identifier). The main difference between SOAP and RESTis that REST is more lightweight with less headers, less XML and will therefore uselower bandwidth. RESTFUL-web services uses the http protocol and the headersPOST, PUT, DELETE and GET to be able to add, change, delete or get data. Flex3.5 has full support of SOAP services by consuming the wsdl(web service descriptionlanguage). A wsdl describes how to use the web service. RESTFUL-web services hasa counterpart named wadl(web application description language) but Flex 3.5 doesnot have any support for wadl(Flex 4.0 has full support). Both the wsdl and wadlare meant for promoting the reuse of the web services by describing the web-serviceswith their own format. Vidispine MAM is well documented with their up-to-datewiki page about the API. They have a clear and consistent layout of each possibleaction which can be performed by Vidispine MAM and the wiki offers examples fornearly every task. The Vidispine MAM is configurable and its data model is quiteadaptable due to using a generic data model.

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

Vidispine MAM uses the RESTFUL-web service and it’s well documented withclear 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 iswrapped within the RESTFUL-web service.

37

Chapter 7

Prototype design phase

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

Prelude is implemented with an Event Driven Architecture. It communicatesonly through events. Prelude can only be communicated with through an exten-sion. Since our implementation required communication with Prelude we had toimplement an extension. Vidispine is using the Service Oriented Architecture, com-munication is made through the RESTFUL web-service API. The Prelude extensionuses 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 animplementation. Actionscript has all the necessaries to support an Event DrivenArchitecture(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 getthe system running.

7.2 Prototype designsWe 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 designDescriptionA monolithic approach. All the different layers, presentation, business logic andthe data-layer communication are embedded in the same component(the extension).For small programs a monolithic approach is acceptable since it’s only meant todo a specific task. This is considered bad coding since we want modularity and itsbenefits 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 dependenton any other modules and could potentially have a lower execution time when notransport 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 logicDescriptionA Service Oriented Architecture approach. All the business logic would be ab-stracted to the application server. By having this approach all the business logicwould be reusable for future implementations which may be on different platformsor environments. As long as it could communicate with the application service thebusiness logic would be accessible. It required a defined messaging protocol betweenthe extension and the application server. The extension would have communicationmodules and the GUI-module. The application server would handle all businesslogic. The application server would as well have it’s own communication modulesand 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 tomaintain. 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 ownmodules. These strengths would make the implementation cost effective. The mostcost 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 serverwould be using without any changes to the extension. And if the application serverwas going to become outdated we could swap it as well. Business logic could beadded to the application server and we wouldn’t have to update the old extensionsbecause 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 latencyissues

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

When setting up this implementation an extra step of setting up the applicationserver would be needed. This could be undesirable when the client for the projectonly wanted a single deployment. This also required the application server to beavailable and to be able to handle the workload it would get. With several clientspotentially connected to the same application server it would be important to es-timate the usage and if necessary allocate more bandwidth or even setup severalapplication servers.

43

CHAPTER 7. PROTOTYPE DESIGN PHASE

Design 3

Figure 7.3. The single deployment with modularity

Single deployment with modularityDescriptionThis architecture design used modularity to achieve Separation of Concerns. With-out an application server, Service Oriented Architecture would not be used fully butit would still use the Service Oriented Architecture where the Vidispine module andthe Prelude module could be considered to be different services. The re-usabilityof the code would be high since we could change the Vidispine module for anotherMAM module. The Prelude module would also be possible to be exchanged for an-other module which would offer similar functionality as Prelude, perhaps a Premieremodule. 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 wouldaccept requests from the business logic to send requests to external services. Theseservices would reply to the communication module. However the other minor modulewould be an interpretation module and would receive the reply give by the servicethrough the communication module. The interpretation module would interpret thereply 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 onlyrequires the two systems and the extension to work. With modularity comes main-tainability, easier testing with smaller modules, reusable code and a Separation ofConcerns. 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 designencapsulates the business logic. Only applications with a similar environment to themodule can reuse the implementation. The application server however could havean independent entry point(platform independent API). The only way to re-use thebusiness 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 timelimit was one month. Since the communication with Prelude was asynchronous andPrelude already implemented EDA we believed that adapting to it would be morebeneficial then not adapting. The implementation was going to use a GUI(GraphicalUser Interface) and it was going to perform actions from user interaction. This didfit 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 wewere not sure when we would reuse the code. The modules could be used either torealize 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 fasterand easier, the focus could be placed upon development instead of testing. Testingis an important part of programming and even if was a prototype we would performa 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 serverwould 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 serversince there was not any absolute need of an application server and it made theimplementation more cost efficient and easier to deploy. Design 2 was therefore notimplemented after receiving directions of the project owner.

Since design 1 and 3 were both realizable we decided to base our selection bydiscussing 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 eitherthe GUI or in Prelude the event gets relayed into the processing and afterwardsa specific event could be sent to the Vidispine MAM for postprocessing actions.

• How well was the “Separation of Concerns” and modularity in the prototypedesign? Design 1 was a monolithic approach. It did not separate any logicat all. Design 3 was using Separation of Concerns, perhaps not as muchas possible but to a certain degree. Design 3 was preferred considering thiscriterion.

• What was the difficulty level to deploy the implementation?Design 2 with its implementation of SOA with an application server would bethe most difficult implementation to deploy. Design 1 and 3 would have thesame deployment procedure. Their differences would more likely to be on theinside 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 VidispineMAM. All these modules could potentially be reused if the interfaces betweenthe modules were clearly defined. Design 1 would only have a single modulewith all the functionality embedded. The re-usage of the code in Design 1was therefore non-existent. The prototype would exist specifically for thisimplementation. 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 toimplement the design “The single deployment with modularity”(Design 3) becauseit offered modularity and its benefits included an easy deployment and no need forhaving an application server. Since this was going to be a prototype implementationwe did not find the necessity to offer the business logic as a service because therewas at that time no application which would like to be able to use the businesslogic. The code in the prototype could be re-used to some extent and we believedit would be better practice than implementing a monolithic design.

47

Chapter 8

Prototype implementation & evaluationphase

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

8.2 Midway evaluationThere were no concerns regarding the prototype architecture design. There hadbeen no changes regarding the Vidispine MAM. We had decided to set the scopeof 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 reasonwas because of the late arrival of the Prelude API documentation and because ofa few major tasks being not documented in the API documentation. Solving thesetasks took longer than expected because we didn’t think some configuration hadto be done before being able to perform some actions. Instead we thought we hadimplemented 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 thecontact living in another timezone (Europe, America) and some questions had tobe sent to other developers (in Asia). All these issued could be avoided with awell-documented API. We decided to skip creating interfaces between the modulesand instead let it be tightly coupled. The interfaces could be implemented at a laterstage.

8.3 Final project Evaluation

The project ended well. A prototype implementation was successfully implementedduring 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 implementationthan intended. EDA was implemented without any major problems. The only issuewhich existed was how the message body was supposed to be structured. Since nokind of validation could be made prior to sending the message to the systems, theyhad to be tested through "trial and error". Reflecting back on the criteria in section5.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’ta valid choice. The project was an integration project between two differentsystems. Due to one of them already implementing EDA, the implementationitself had a functional GUI and the communication being asynchronous itbecame evident that the implementation needed to support EDA and thereforeEDA was implemented. The project time limit was not enough to implementSOA and there was also no need of the benefits of the patterns. There wasnot enough time to be able research other architectural patterns which mighthave been a better fit. Instead the focus was on starting an implementationas 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 wassuccessfully implemented and fitted well with the needs of the implementation.The communication was in many ways asynchronous and event driven whichwas a good match for an implementation of EDA. There was not enough timein the project to research other architectural patterns which would have hada positive impact on the implementation.

• How well modularized was the prototype?

We implemented the extension through four modules, the GUI, the businesslogic 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. Thebusiness logic module could probably also be better modularized into a datamodel, business logic for GUI and a processing module. But the functionalitywhich we implemented was very limited and we didn’t feel the necessity toimplement so many modules since we believe it would take longer time todefine 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 tightcoupling with the data model we implemented. Parts of the code could bere-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 thecommunication between the modules would be done through interfaces thenthe 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 abstractingthe modules into smaller modules. The modules would be as mentioned ear-lier in How well modularized is the prototype?. The main question here wason which level the "Separation of Concerns" should be placed. If we tried toseparate as much functionality as possible into different modules, the develop-ment process could turn into a process of defining the communication betweenthe modules and deciding the abstraction. Due to the project time limit wedid not spend as much time as we would like on the design which could hadimprovements on the "Separation of Concerns" aspect but the implementationturned 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 byseveral modules it becomes easier to maintain. Improvements which couldhave been done would include unit testing for each module and adding inter-faces between the modules instead of the tight coupling which exists at themoment. If a change needs to be implemented it might be that more thanjust the module needs to be changed. If we had more time and if it would beprioritized, we would definitely add interfaces to the modules and thereafteradd unit tests to get code coverage of the logic which was performed. We hadwritten comments in the code but we believed if we could we would try tomake the code simplified but still performing the task. Perhaps a TDD (TestDriven Development) approach would have been a good idea to minimize thecode.

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 thetime 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 otherone (Vidispine MAM) used a RESTful webservice as API. A requirement wasalso that the prototype was going to have a GUI. With a pre-study resultwhich didn’t show any major limitations we could start the implementation.Even though there wasn’t any documentation of one of the systems, therewas proper documentation of the interface of the RESTful webservice. Byimplementing a prototype design which was using "Separation of Concerns"it became possible to perform development within the areas which we hadknowledge about. By mocking(simulating) the Prelude module we could startthe development without any major limitations.

• Time consumption?

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

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

The discussions with seniors were mainly about requirements and the goalof the project. Due to receiving necessary information quite late into theprocess, some functionalities had to be put aside to be able to keep to thetime plan. Also requirements on the prototype were raised from the discussionwith seniors. One example is the requirement of making the project easy todeploy. This lowered the possibilities for the application server prototype andafter 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 Adobewhich had a negative impact on the project. The development time was lowerthen expected due to not receiving the API documentation in time. Due toweak documentation a lot of functionality had to be tested before it could beused.

• Is it difficult to deploy the implementation to a customer?With an implementation which is pretty much stand-alone it becomes quiteeasy to deploy the implementation. If the implementation would require anapplication server it would need to be configured and maintained. The im-plementation only required the minimum configurations and we believed if itwould be packaged in an installer the installation could either be centrallydistributed 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 whatwas expected. In the midway evaluation, we had to change the scope of the projectbut the goal was achieved.

The project requirements changed the possible architecture designs which couldbe 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 arequirement 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 theirfullest. A design which would according to theory be superior to other designs, dueto 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 easierto 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 decidehow the architecture design would look like, but instead the project specificationhad limitations and requirements which changed the whole scope. The main goalwith the implementation was to modularize as much as possible. This directionwas chosen because we wanted to be able to reuse the code and if needed, since theproject was prone to change, change different modules without affecting the wholeimplementation. We successfully made the implementation modularized enough tomake testing easy. This was achieved by having “Separation of Concerns” as muchas possible to separate different tasks. If we would like to change the database, onlya single class in our implementation had to be switched out. All this contributes tomake 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 extendedor new functionality needs to be implemented it wouldn’t be a hard task since theimplementation was modularized and the “Separation of Concerns” are clear.

The prototype implementation didn’t go as good as we hoped to. Without anAPI-documentation which covers all the basic areas, an implementation will bedelayed 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 towork on a specific area. But when the distribution of time amongst Vidispine MAMand Prelude got too unbalanced we had to ask ourself, could this be avoided? Weestimated our time used on testing undocumented API would be 10-25% which couldbe reduced with a well written API-documentation and examples. Even though wehad access to a developer at Adobe who could answer our questions it still tooktime due to time differences in Europe(us) and America(the resource). The timeneeded before starting the implementation was mostly put on the Pre-study. Byclarifying what we were going to work with and after some discussion with theseniors at Mediasmiths, a much clearer picture could be made about what would beimplemented. The pre-study and the discussion with seniors took about 10 days ofresearch. We extended the second implementation phase by one week due to gettingthe 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 architecturedecisions some configurations needs to be set manually.

The prototype implementation was a proof of concept. Therefore it should byno 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 academicworld we hadn’t really thought that much about the new but ordinary factors, inworking life, which may have a decisive role. We can now understand why othershaven’t tried to compare architectural pattern a larger scale. The application whichimplements most architecture patterns or the most efficient architecture patternsfor the given task might not always be the one which will be implemented.

Sadly no method for comparing architectural patterns could be created. Wedidn’t gain any more knowledge about how a comparison of architectural patternis performed nor gain any directions towards guidelines in how a comparison wouldhave been done. Perhaps in a work application there are too many factors whichmust be satisfied which render a possible method useless. Even though if we had amethod which could compare architectural patterns there is still a possibility thatthere may be factors which force us to make different decision. The developer mayhave to sacrifice flexibility and functionality to be able to finish a product becausethe deadline in a real world application may be the most crucial factor. A misseddeadline might mean unexpected costs which may jeopardize the project or eventhe development team or in worst case even the company.

Due to factors such as requirements and time it might not be possible to findan architectural pattern which is a better fit than an architectural pattern whichthe developer knows. With a new pattern the developer needs to spend time on thearchitectural pattern. The developer needs to find knowledge about the pattern,read up, fully understand its application and how it works as well as understandhow it may be implemented in the current context. This results in even moretime consumption on research than actual progress forward. Since the numberof architectural patterns is huge it might be hard to find the specific architecturalpatterns which improve the result. It might only be time consumption which resultsin nothing.

We believe that in many cases delivering a system which performs the specifiedaction A good enough is better than delivering a system which performs the specifiedactions 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 featurewhich can be removed and is not critical.

Architectural patterns are very specific and clarify when a pattern should beused, its purpose and which prerequisites are needed to be fulfilled. Even thoughit 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 appliedarchitecture pattern are not used then why should the pattern be implemented inthe first place?

In this project, time was a very important factor. Since we didn’t receive theAPI documentations in an early stage it stalled the development a little since wecould only make assumptions of how to work with the system. This had an impacton our project plan which resulted in down prioritizing finding a better architecturalpattern/prototype design to apply and instead use our current knowledge to be ableto deliver in time.

The academic world actually has more freedom within this area than workinglife. Maybe it is not the best way to tackle the issue of "Which is the best fittingarchitectural pattern" with finding a method to be able to compare the architecturalpatterns. It’s too specific and the difference between architectural patterns is so vastas well as the related factors.

We would like more case studies to be able to draw general conclusions. But webelieve that there are many factors which influence the development of software andsome of these factors have a larger impact than others. Some factors are criticaland some are not, but there are always some factors which change the selection ofarchitectural 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 tobe 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. howwe communicate with the other systems, what functionality needs to be integratedetc.

Factors outside the academic world have a major impact. There are factorswhich disregard the technical details: time and money, are factors which are non-negotiable: project result requirements and more. Time has had a large impact onthe project. With a fixed deadline, we didn’t have as much time as we wanted tofor 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 suddenchange, like gaining additional information about a system, opens new possibilities.But due to already having started the project we had less time. Decisions needed tobe made and we had to sacrifice a more versatile solution to avoid being late withthe project delivery. This project showed the importance of a thorough pre-studyand 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 whichmay improve the design. The time cost would be too high and it could risk theproject. 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 acertain context and they require certain requirements to be fulfilled before theyshould 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 areasthey can sometimes be implemented together to gain both of their advantages anddisadvantages. It takes a substantial amount of time to search for an architecturalpattern, understand it and gain enough knowledge to be able to apply it. Whenapplying an architectural pattern we must consider if we need its benefits versusthe extra difficulty of implementation. The project time plan needs to be taken toaccount.

11.3 MethodNo method could be established by our project. Factors such as environment andtime were too strong, and there was no choice between architectural patterns or timeto research for an architectural pattern to be implemented. No conclusions fromcase study experience could be drawn which would help towards creating guidelinesin a comparison of architectural patterns since there was never a discussion aboutdifferent 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. Technicalreport, 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 FirstDesign 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. Technicalreport, College of Computer Science, Northeastern University, 1995.

[7] Artur Trosin. Separation of concern vs single responsibility principle ( soc vssrp ). Technical report, 2009.

[8] Robert C Martin and Micah Martin. Agile Principles, Patterns, and Practicesin C#. Prentice Hall, 1st edition edition, 2006.

[9] Michael Jones. Loose coupling is good - tight coupling is the devil. The SoftwareDevotional, 2009.

[10] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 2ndedition 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. Masterthesis, McMaster University, 2007.

[13] Thomasl Erl. SOA Principles of Service Design. Prentice Hall, 1st editionedition, 2007.

63

BIBLIOGRAPHY

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

[15] Douglas K Barry. Service-oriented architecture (soa) definition. Technicalreport, 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

BackgroundPrelude is the working name of an upcoming product from Adobe which among other things canbe used as a cataloging solution.

It gives the user the ability to review media in a variety of formats (codec, wrapper, operationalpattern, bit rate etc) and also the ability to add comments (metadata) to the media as a whole orspecific sections of the media (aka sub­items). Additionally, there are plug­ins to Prelude forspeech­to­text for instance which automatically create sub­items with the text associated withthe 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 togenerate 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 MAMAn enterprise MAM system can in the "worst" case hold hundreds of thousands of hours ofmedia content and in such an environment it becomes crucial to provide users with good searchfacilities.The indexing and search components are key but without good and descriptive metadata therewill not be anything to search for.

Integration taskWe 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 forthe 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 VidispineMAM system and the metadata will be transferred as well.Alternatively, create a placeholder item in Vidispine straight away and create metadata sets inVidispine as they are created in Prelude.

2) Logging of existing content

APPENDIX A. PROJECT DOCUMENTATION

66

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

Prototype functional requirements

Function Description/comment Importance1­5

Ability to insert media intoVidispine

5

Ability to insert (whole)asset metadata for mediainto Vidispine

5

Ability to render and alsocreate, update, deleteasset metadata in Prelude

5

Ability to insert timecodespecific metadata intoVidispine

5

Ability to render and alsocreate, update, deletetimecode specificmetadata (sub­item) inPrelude media timeline

5

Ability to differentiatebetween different types ofsub­items incommunication withVidispine

4

Ability to differentiatebetween different types ofsub­items when renderingon Prelude timeline

4

67

Investigate if it is possibleto enforce rules in Preludein terms of how differentsub­items affect eachother.

E.g. sub­items of certain types may not overlap,sub­items of type X must be contained withinsub­item of type Y.

5

Error handling onacquisition

E.g. lost connection to Vidispine, don’t leaveorphaned data in Visipine or media on localworkstation, recover work­in­progress data incase of application crash

2

Ability to search Vidispinefor assets

Ability to present searchresult in Prelude

Ability to load selectedsearch result into Prelude

Obtain video and keep Vidispine identifier forvideo.Obtain asset metadata and sub­item informationand display in Prelude.

Instruct Vidispine to createproxy for acquired media

2

Instruct Vidispine to createkeyframes for acquiredmedia

2

Ability to listen tonotifications from Vidispineabout updates to thecurrently loaded assetincluding sub­items

4

Ability to display (modifycurrently rendered) resultof notifications fromVidispine abotu currentlyloaded asset includingsub­items

4

APPENDIX A. PROJECT DOCUMENTATION

68

www.kth.se

Powered by TCPDF (www.tcpdf.org)