Arkkitehtuurityylejä ja patterneja - Courses...Wikit, Google docs, MS Sharepoint, muut ... – Rinnakkaisuuden ja päällekkäisten päivitysten hallinta on mietittävä tarkkaan

Arkkitehtuurityylejä ja patterneja

Luento 3

19.9.2017 1581358 Ohjelmistoarkkitehtuurit

Oppimistavoitteet

• Yleisesti käytettyjä arkkitehtuuripatterneja ja -tyylejä– N-Tier, Klassinen MVC, Jaettu tietovarasto,

Microservices

• Viestinvälitys skaalautuvan ja hajautetunarkkitehtuurin mahdollistajana

19.9.2017 581358 Ohjelmistoarkkitehtuurit 2

Tyylien ja patternien käytöstä• Platoninen vs. ”ruumiillistunut” tyyli/patterni

– Platoninen tyyli/patterni on ideaalinen kuvausarkkitehtuuriratkaisusta

– Käytännön toteutuksissa esiintyvät tyylien/patternieninstanssit (”ruumillistumat”) ovat harvoin täysin ”puhtaita”,eli niissä on tehty jotain perusteltuja poikkeuksia jalisäyksiä ratkaisun rakenteisiin ja rajoitteisiin

– Tyylit ja patternit ovat yleistyksiä• Olennaisimmat piirteet kiteytettynä• Yleistys, joka määrittelee arkkitehtuurien luokan

– On myös paljon sovellusalue- ja teknologiakohtaisiapatterneja, joilla on rajallisempi sovellusala

• Esim. yksityiskohtaisia ”reseptejä” tietyn teknologian käyttöön


ARKKITEHTUURIPATTERNEJA


Kolmitasoarkkitehtuuri (N-Tier)


Display(Presentation)

’business' logic

Persistent state(Datastore)

Käyttäjän näkymäJ:n dataan ja toimintoihin-datan katselu-datan muokkaus

Service requests Values to display

Käli-elementin sisältö

Operaatiot, joita käyttäjähaluaa järjestelmän tekevändatan perusteella (liiketoiminta-prosessit ja –entiteetit)Data requests data values

Olio

Datan pysyvä talletus jajakaminen eri sovellustenkesken

Tietokantataulun rivi

N-Tier?

• Käytännössä isoissa järjestelmissä puhutaan kolmentason sijaan usein monitasoisesta rakenteesta (N-Tier)

• Business logic –taso jaetaan yleensä edelleen (1)palvelupyyntöjen vastaanoton ja käyttäjä-istuntojenhallinnan tasoon sekä (2) palvelut toteuttavienoperaatioiden ja ”business-olioiden” tasoon

• Business-oliot taas käyttävät yritysjärjestelmätasonpalveluita (tietokannat, toiset järjestelmät)

• N on siis yleensä 4 tai jopa 5


Kolmitasoarkkitehtuuri (N-Tier)

• Sovellusalue– Hajautetut, data-intensiiviset informaatiojärjestelmät

• Edut– Helpottaa tietoturvan, suorituskyvyn ja saatavuuden

optimointia eri tasoilla niille sopivilla tavoilla– Lisää järjestelmän modulaarisuutta ja muunneltavuutta,

koska eri tasojen välille täytyy sopia määrämuotoisetkommunikaatioprotokollat (-> loose coupling)

• Haitat– Kustannukset, monimutkaisuus (datan esitystapojen

muunnokset, virhetilanteiden käsittelyn haasteet)


Klassinen Model-View-Controller (MVC)[malli-näkymä-ohjain]

• Sovellusalue: monimuotoisiakäyttöliittymänäkymiä sisältävät interaktiivisetjärjestelmät

• Motivaatio:– Ohjelmistolla on erilaisia käyttäjiä ja näillä erilaisia

tarpeita käyttöliittymään liittyen– Samaa informaatiota pitää pystyä esittämään ja

käsittelemään eri muodoissa– Käyttöliittymän tulisi olla helposti muutettavissa

• Krasner, G., Pope S: Cookbook for Using the Model-View-Controller UserInterface Paradigm in Smalltalk-80, JOOP Aug./Sep.,1988.


Klassinen MVC

• Kolmenlaisia komponentteja– Malli-komponentit ovat vastuussa laskentaan liittyvän

tiedon (tai tilan) säilytyksestä– Näkymä-komponentit ovat vastuussa tiedon

esittämisestä käyttäjälle– Ohjain-komponentit ovat vastuussa käyttäjän ja

järjestelmän välisen vuorovaikutuksen ohjaamisesta• Ottavat esimerkiksi vastaan hiiren näpäyksiä, näppäimen

painamisia jne. ja muuntavat nämä mallikomponenttientilaan vaikuttaviksi operaatioiksi


Klassinen MVC


Klassinen MVC

• Mallikomponentit eivät riipu mistään (tietystä)näkymä- tai ohjainkomponentista

• Muutokset mallikomponenteissa välitetäännäkymille Tarkkailija-suunnittelumallinmukaisesti– Eli vain niille näkymille, jotka ovat ilmaisseet

kiinnostuksensa muutoksiin


MVC - arviointia• Etuja

– Useita näkymiä samaan tietoon– Näkymiä on helposti lisättävissä jopa dynaamisesti– Ohjaimen voi helposti vaihtaa– Voi toimia perustana sovelluskehykselle (Smalltalk, Web -

applikaatiot)• Ongelmia

– Lisää mutkikkuutta– Yksinkertainen käyttäjätoimenpide saattaa aiheuttaa monia

päivityksiä näkymään (päivityksen laajuutta voi olla vaikeakontrolloida)

– Voi olla työlästä löytää sopiva datan esitysmuoto ja haku-/päivitysoperaatiot mallin rajapintaan käyttöliittymän (näkymän)suorituskyvyn (responsiivisuus) kannalta


Muunnelmia• Monesti ei ole tarpeen erottaa ohjainta ja näkymää

– Erityisesti, jos kullakin näkymällä olisi joka tapauksessaoma ohjain, jonka kautta voidaan suoraan manipuloidanäkymää

• Voimakas kytkentä (strong coupling)– Käytännössä monissa käyttöliittymäkehyksissä (GUI

frameworks) ”kontrollerikoodi” liitetään UI elementteihinsuoraan tapahtumankäsittelijöinä

• Ts. komponentti voi toimia sekä näkymä- ettäohjainkomponenttina. Yhteen malliin voi liittyä monta<näkymä, ohjain> -paria.– Huom – juuri ohjaimen rooli ja tehtävät vaihtelevat eniten

MVC-patternin eri ”ruumiillistumissa”!


Muunnelmia

• Yleensä on tarkoituksenmukaista tarjota mallin dataanäkymälle muodossa, josta sitä on helppo kopioidakäyttöliittymän elementtien arvoiksi ja päinvastoin– Mallin oliot voivat olla rakenteeltaan monimutkaisia ja

niiden kenttien tietotyypit voivat olla käyttöliittymänkannalta epätarkoituksenmukaisia

– Näkymän ja mallin väliin määritellään näkymämalli(ViewModel), joka suorittaa tarvittavat muunnokset jasuodatukset esitystapojen välillä (ynnä muuta tarpeellista)

– Riippuvuudet: Näkymä -> Näkymämalli -> Malli– Kts. esim: https://msdn.microsoft.com/en-

us/magazine/dd419663.aspx


ARKKITEHTUURITYYLEJÄ


Arkkitehtuurityylien luokitteluista• Tyylejä on pyritty luokittelemaan eri tavoin vuosien varrella

– Kurssikirja (Fairbanks) ei luokittele tyylejä lainkaan– Bass, Clements ja Kazman (Software Architecture in Practice, 3.

painos) taas kutsuvat tyylejä patterneiksi ja luokittelevat neomalla tavallaan

– …jne.• Yleisiä luokitteluja hyödyllisempiä ryhmittelyjä ovat

patternikielet (Pattern Languages), jotka kokoavatyhteenkuuluvia (design-) patterneja laajemmiksikokonaisuuksiksi– Esim. mikropalvelujen, pilvipalvelujen tai sulautettujen

järjestelmien suunnitteluun ja toteutukseen liittyvät patternit– Palaamme tähän mikropalvelu –arkkitehtuurityylin kohdalla


Jaettuun tietovarastoon perustuvaarkkitehtuuri

• Data centered - Shared state - Repository• Joukko komponentteja ylläpitää yhteistä dataa

tietovarastossa– Erilaisia muunnelmia sen mukaan, kuinka aktiivinen

rooli tietovarastolla on• Kahdenlaisia komponentteja

– Keskitetty tietorakenne: tietovarasto– Asiakaskomponentit: hakevat tietoa tietovarastosta ja

muokkaavat sitä• Järjestelmän kontrolli määräytyy tietovaraston

sisältämän datan tilan mukaan


Jaetun tietovaraston arkkitehtuuri


processor 1processor 2

stateKäsittelijät toisistaanriippumattomia


• Vuorovaikutus käsittelijöiden välillä tapahtuuainoastaan tietovaraston kautta

• Käsittelijöiden tietovarastoon tekemät muutoksetjohtavat vaiheittain haluttuun lopputulokseen

• Käsittelijän aktivointi– Käsittelijät voivat pollata tietovarastoa tutkiakseen onko

tila sellainen, mistä käsittelijä pystyy jatkamaan toimintaa• jos on, käsittelijä tuottaa tuloksia, jotka kirjaa tietovarastoon

– Tietovarasto voi aktivoida käsittelijän jonkin säännönperusteella, esimerkiksi sisällön muuttumisen perusteella

• vrt tietokantatriggerit



• Käsittelijät voivat toimia rinnakkain– Edellyttää samanaikaisuuden hallintaa: tiedon

lukitusàmiten estetään yhtä käsittelijäävaraamasta koko tietovarastoa itselleen (liianpitkäksi aikaa)?

• Esimerkkejä– Tekoälysovellukset (blackboard-arkkitehtuuri),

Wikit, Google docs, MS Sharepoint, muutverkkotyöalustat…



• Etuja– Muunneltavuus & laajennettavuus (itsenäiset,

toisistaan riippumattomat käsittelijät)– Rinnakkaisuuden hyödyntäminen

• Haittoja– Rinnakkaisuuden ja päällekkäisten päivitysten

hallinta on mietittävä tarkkaan


Microservices

• Nousussa oleva, vielä hieman täsmentymätöntyyli yritysjärjestelmien palvelinpuolenarkkitehtuuriksi– Vastaveto monoliittisiksi koetuille perinteisille

kolmikerrosarkkitehtuureille (N-tier)– Tukee Continuous X –käytäntöjä (continuous

integration, deployment jne.)

• ~ Unixin pipes and filters ajattelutapasovellettuna palvelujen toteuttamiseen


Monoliitti• Käytäntönä on pitkään ollut rakentaa web-sovellus yhtenä fyysisenä

pakettina, joka voidaan sellaisenaan asentaa ja ottaa käyttööntuotantopalvelimella– Esim. Java-teknologialla toteutettu kolmitaso –web-sovellus koostetaan yhteen

WAR-pakkaukseen, joka sisältää http-pyyntöjen käsittelyn ja web-sivujengeneroinnin, business-logiikan ja tietokantakerroksen

– Pakkaus voidaan asentaa suoraan http-palvelimelle (esim. Tomcat) taisisällyttää osaksi palvelimen asennuspakettia

• Yleensä web-sovellus on toteutettu käyttäen jotain sovelluskehystä(framework), joka tarjoaa koko joukon hyödyllisiä apupalveluja, muttatoisaalta pakottaa käyttämään kehyksen suunnittelijoiden päättämäärakennetta– komponenttityypit, riippuvuudet ja koodin suoritukseen liittyvät piirteet– Tyypillisesti sovellusta ajetaan yhdessä prosessissa (1 säie/palvelupyyntö); jos

tarvitaan lisää kapasiteettia (säikeet loppuvat tai vasteajat kasvavat liikaa)pitää käynnistää uusia instansseja, joita kuormistusta säädellänkuormantasaajan (load balancer)avulla


Monoliitti• Etuja

– Oppimiskynnyksen ylityttyä kehittäjälle helppo ja turvallinen– Kehittäjä voi keskittyä oleelliseen ja jättää monet teknisesti vaativat asiat kehyksen vastuulle

(transaktiot, komponenttien automaattinen kytkentä, tietoturva jne.)• Haittoja

– Sovelluksen eri osien päivittäminen eri tahtiin voi olla mahdotonta (sovellus pitää testata jaasentaa yhtenä kokonaisuutena)

– Sovelluksen käynnistyminen voi olla hidasta ja testien suoritus saattaa kestää pitkään– Voi olla vaikeaa ylläpitää hyvää modulaarisuutta muutosten heijastusvaikutusten estämiseksi– Jos jokin tietty sovelluksen osa muodostuu suorituskyvyn pullonkaulaksi, koko sovelluksesta

pitää luoda uusia instansseja (vertikaalinen skaalaus) sen sijaan, että yksittäisen osankapasiteettia voitaisiin kasvattaa esimerkiksi rinnakkaisilla kopioilla (horisontaalinen skaalaus)

– Pilvipalvelualustojen tarjoamasta suorituskyvyn ja kustannusten skaalautuvuudesta ei saadatäyttä hyötyä (sekä ylös- että alasskaalaus)

– Usein vaikeaa käyttää eri toteutusteknologioita sovelluksen eri osissa– Syntyy vahva riippuvuus käytettyyn teknologia-alustaan


Microservices• Perusidea: palvelinsovellus

– Koostuu kokoelmasta pieniä, erillisiä palveluita– Jokaista palvelua ajetaan omassa prosessissaan– Palvelut kommunikoivat kevyitä mekanismeja käyttäen (verrattuna ESB-

väyliin), esimerkiksi HTTP resurssi-API:eja• Palvelu

– Osituksen perusteena liiketoimintaprosessit ja –toiminnot (yksi per palvelu,single responsibility principle)

– Voidaan ottaa käyttöön (deployment) itsenäisesti ja automaattisesti– Voidaan skaalata (lisätä kapasiteettia) horisontaalisesti palvelu kerrallaan

• Minimimäärä pavelujen keskitettyä hallinnointia– Palvelujen toteutus mahdollista eri ohjelmointikielillä ja kirjastoilla– Palvelut voivat käyttää omia tiedonhallintaratkaisujaan– Hyvä skaalautuvuus (+ ja -) tavoitteena

• Transaktioiden sijaan tarvitaan toisenlaisia menetelemiä tiedon eheydentakaamiseksi– Orkestrointi mikropalveluja käyttävien komponenttien vastuulla


Microservices

19.9.2017 581385 Ohjelmistoarkkitehtuurit 26http://martinfowler.com/articles/microservices/images/decentralised-data.png

Microservices

• Martin Fowlerin sivut– http://martinfowler.com/microservices/– http://martinfowler.com/articles/microservices.ht

ml• Katso esimerkiksi Fowlerin key-note esitys

aiheesta GOTO Berlin 2014 –konferenssissayoutubesta– Linkki videoihin löytyy microservices –

resurssisivulta (1. linkki yllä)


Microservices pattern language

• Chris Richardsonin sivusto– http://microservices.io/patterns/index.html


VIESTINVÄLITYS JA SKAALAUTUVAARKKITEHTUURI


Hajauta ja hallitse!• Ongelma: miten toteutetaan asiakkaiden ja palvelujen välinen

kommunikointi hajautetussa, heterogeenisessäpalveluympäristössä, jossa…– Monia eri ohjelmointikieliä ja toteutusteknologioita käytössä– Halutaan välttää suoritusaikaisten komponenttien välisen suoran

kommunikaation aiheuttamia suorituskyvyn pullonkauloja– Halutaan skaalautuvuutta, jossa voidaan dynaamisesti lisätä (ja

vähentää) palvelevia komponentteja– Halutaan löyhät kytkennät komponenttien välille piilottamalla niiden

toteutusteknologioiden yksityiskohdat (esim. ohjelmointikieli)– Halutaan joustavuutta ja ketteryyttä arkkitehtuuriin– Halutaan lisätä asynkronisuutta, jotta asiakkaan ei tarvitse jäädä

odottamaan, kun palvelin käsittelee pyyntöä, vaan se voi jatkaa muitatoimintojaan ja käsitellä palvelimen lähettämän vastauksen senvalmistuttua


Kommunikoi viestein• Ratkaisu: komponentit kommunikoivat

lähettämällä toisilleen viestejä– Viesti abstrahoi ja kapseloi palvelupyynnön (ja

vastauksen), siihen liittyvät attribuutit ja datan(payload) sekä protokollan

– Viestin hyötykuorma voi olla iso tai pieni– Viestintä voi olla

• synkronista (lähettäjä jää odottamaan) tai• asynkronista (lähettäjä jatkaa toimintaansa)

– Viesti voidaan lähettää (1) tietylle kohteelle tai (2)yleislähetyksenä (broadcast) kaikilletunnetuille/kiinnostuneille kohteille


Message (Java Message Service 2.0)

”Messages, as described here, are asynchronousrequests, reports or events that are consumedby enterprise applications, not humans. Theycontain vital information needed to coordinatethese systems. They contain precisely formatteddata that describe specific business actions.Through the exchange of these messages eachapplication tracks the progress of theenterprise.”


Viestinvälityksen peruskäsitteitä(Esimerkkinä JMS 2.0)

• Point-to-Point vs. Publish-and-Subscribe– Queue vs. Topic– ”Involved” vs. Fire-and-Forget


ReceiverProvider

Point-to-Point


Sender

Queue

Synch. Asynch. / Synch.

Sender

Asynch.

Jono (queue) on erillinen nimetty resurssi (Provider-palvelimella), johon lähettäjä javastaanottaja muodostavat erikseen yhteyden (eivät siis suoraan toisiinsa)- Kummankaan ei tarvitse tuntea toista osapuolta (osoitetta tms.)

Receiver

Point-to-Pointmonta vaihtoehtoista vastaanottajaa


SenderProvider

ReceiverSender

Receiver

- Vain yksi vastaanottaja saa viestin (point-to-point)!- Viestissä välitetty data ja/tai pyydetty palvelu

prosessoidaan vain yhden kerran- JMS spesifikaatio ei määrää, miten saaja valitaan

Queue

Point-to-Point


Sender

Provider

Q1

Receiver

Q2

Request-Reply – tarvitaan kaksi jonoa(”Involved” relationship)

ReceiverSender

Publish-and-Subscribe


Consumer

Sender

ProviderConsumer

Publisher

Consumer

Topic

Fire-and-Forget: julkaisijaa ei kiinnosta, ketkä viestin saavat– tai saako kukaan – ja mitä ne sillä tekevät

Viestinvälitysarkkitehtuurit• Tyypillinen tilanne (roolit)

– Julkaisija – Tilaaja (Producer/Publisher – Subscriber)– Tuottaja – Kuluttaja (Producer/Sender – Receiver/Consumer)

• Ohjelman (prosessin) sisällä julkaisijat ja tilaajat voidaankytkeä suoraan (esim. Tarkkailija-patterni)– Yksinkertaisimmillaan julkaisija pitää kirjaa vastaanottajista ja

tietosisällön muuttuessa välittää tiedon tilaajilleproseduurikutsun välityksellä.

– Tilaaja rekisteröityy vastaanottajaksi ja toimittaa rekisteröinninyhteydessä vastaanottorajapinnan (call-back)

• Hajautetussa sovelluksessa tarvitaankommunikointiprotokolla ja välittäjä (broker, JMS 2.0Provider) huolehtimaan viestinvälityksestä


ViestinvälitysarkkitehtuuritVälittäjä (Broker)

• Välittäjä (broker) tietää vastaanottajat(rekisteröityminen tai konfigurointi)– Julkaisija toimittaa viestin välittäjälle– Välittäjä toimittaa viestin edelleen siitä kiinnostuneille

tilaajille (filtteröinti)– Tilaaja käsittelee viestin

• Välittäjään (broker) ja asynkroniseen viestintäänperustuvaa arkkitehtuuria voidaan käyttää yleisestipalveluarkkitehtuurin runkona ”perinteisemmän”etäproseduurikutsuihin perustuvan Asiakas-Palvelinarkkitehtuurin sijaan– Palveluekosysteemit


ViestinvälitysarkkitehtuuritVälittäjä

• Arkkitehtuurissa määriteltävä seuraavat asiat:– Keskenään kommunikoivat komponentit– Viestit, joiden avulla kommunikointi tapahtuu ilman,

että lähettäjä tuntee vastaanottajan (tai vastaanottajalähettäjän) fyysistä sijaintia (protokolla, syntaksi)

– Operaatiot, joilla komponentit reagoivat viesteihin(komponenttien ymmärtämä kieli, semantiikka)

– Säännöt, joiden avulla komponentit ja viestitrekisteröidään järjestelmälle

– Palvelutasolupaus (viestien elinaika, taattu toimitus,transaktiot jne.)



• Säännöt, joiden perusteella välittäjä tietää,mille komponentille viesti on lähetettävä– Viestin vastaanottajan selvittäminen:

• yleisviesti (multiple dispatch; viesti kaikille, jotkutkäsittelevät, toiset eivät)

– etu: vastaanottajan ei tarvitse etukäteen kertoa, mitä viestejäse haluaa vastaanottaa

• komponentit kertovat rekisteröinnin yhteydessä, mitäviestejä (viestin tyyppi tai muu tunniste) ne haluavatvastaanottaa (tai keneltä)



• Rinnakkaisuus: missä määrin välittäjä jakomponentit toimivat rinnakkain– Viestinvälittäjillä ja vastaanottajilla viestijonot

(välittäjän laatikko, vastaanottajan laatikko)– Voiko viestijono olla jaettu eri vastaanottajien

kesken– Puskurointi, palvelutasot


Esimerkkejä

• RabbitMQ on suosittu open-sourceviestinvälityspalvelu, joka tukee moniakieliä/ympäristöjä ja erilaisia viestinvälitys-protokollia http://www.rabbitmq.com

• JMS 2.0 – Java Message Service APIhttps://jcp.org/en/jsr/detail?id=343


TapahtumapohjaisetViestinvälitysarkkitehtuurit

• Tapahtumapohjaiset arkkitehtuurit (event-based, eventdriven)

• Komponentit kommunikoivat aiheuttamallatapahtumia (event)

• Tapahtumat voivat välittyä kaikille muillekomponenteille, joista jotkut käsittelevät ja toiset eivätnoteeraa– Tapahtumien lähetys voidaan myös rajoittaa julkaisija –

tilaaja rakenteen tapaan – tapahtuma lähetetään vaintapahtuman tyypistä kiinnostuneille

– komponentteja ei ole kuitenkaan lokeroitu jokojulkaisijoiksi tai tilaajiksi vaan komponentti voi toimiakumpanakin


Tapahtumapohjainen viestintä


:Component :Component :Component

:Component :Component

publishsubscribe

Väylä /Event bus

TapahtumapohjaisetViestinvälitysarkkitehtuurit

• Tapahtuma– Tilanne, joka voi sattua ohjelman suorituksen aikana– Edellyttää reagointia joiltain järjestelmän osilta (vrt. signaali)– Tapahtumaan liittyy usein pieni määrä dataa (ei välttämättä yhtään)– Lähde = tapahtuman synnyttävä komponentti– Tarkkailija = tapahtumaan reagoiva komponentti

• Lähde lähettää tapahtumailmoituksen sitä tarkkailemaan rekisteröityneelletarkkailijalle

– Esimerkiksi Signals & Slots1 Qt-sovelluskehyksen olioarkkitehtuurissa• Lähde tietää dynaamisesti tarkkailijoidensa olemassaolon, mutta ei niiden

tarkkaa tyyppiä– Tapahtumaväylää käytettäessä lähteet eivät tiedä tarkkailijoistaan (vrt. MVC, Observer -mallit)

• Ilmoituksen lähetys voidaan hoitaa proseduurikutsuna tai sanomanvälityksenä(event bus, message bus)

• proseduurikutsu synkroninen (esim Qt Signals & Slots)• Sanomajono asynkroninen/synkroninen


1http://en.wikipedia.org/wiki/Signals_and_slots,http://qt-project.org/doc/qt-5.0/qtcore/signalsandslots.html

Javan tapahtumamalli


EventListenerInterface

eventHappened(MyEvent)

Observer

ConcreteEventListerner

implements

eventHappened(Event)

update

EventSource

ListenerContainer

addEventListener(EVLI)notifyAll

CEL-1

Instance of

calls

ES1

EventObject

MyEvent

addEventListener( )Ev1creates

eventHappened( )calls

Vapaasti toteutettavissa EventListener

Viestinvälityksen arviointia

• Etuja– Joustavuus, muunneltavuus, modulaarisuus

• Uusien tuottajien/julkaisijoiden ja kuluttajien/tilaajiendynaaminen lisääminen

• Välittäjän/väylän tekemät automaattisetesitystapamuunnokset, erilaisia palvelutasoja toteutettavissa(varmistettu perillemeno vs. fire and forget)

• Komponenttien omatahtinen evoluutio

– Paljon käytettyjen välittäjä-/väyläratkaisujen hyväksikehittynyt laatu

• Luotettavuus, skaalautuvuus, suorituskykyoptimoinnit, jne.


Viestinvälityksen arviointia

• Haittoja– Välittäjän tai tapahtumaväylän tuoma

suoritusrasite (overhead) ja suorituskyvynoptimointimahdollisuuksien kaventuminenverrattuna suoriin (IPC-) yhteyksiin

– Välittäjä tai väylä on kriittinen komponentti (singlepoint of failure), jonka luotettavuus pitää saadapaljon korkeammaksi kuin kommunikoivienkomponenttien


Documents

Arkkitehtuurityylejä ja patterneja - Courses...Wikit, Google docs, MS Sharepoint, muut ... – Rinnakkaisuuden ja päällekkäisten päivitysten hallinta on mietittävä tarkkaan