Gelaagde Architecturen (1): Bijlage
Verantwoording van het ‘Logica In Lagen’ referentiemodel Bijlage bij ‘Meer inzicht in gelaagde architectuur - Deel 1: Uitleg, terminologie en methoden’ [Pruijt10]. Leo Pruijt, Lectoraat Architectuur van Digitale InformatieSystemen, Hogeschool Utrecht
1. Inleiding In ‘Meer inzicht in gelaagde architectuur - Deel 1’ [Pruijt10] is het ‘Logica In Lagen‘ referentiemodel geïntroduceerd: het doel, de eisen waar rekening mee is gehouden, de inhoud en het beoogde gebruik. In deze bijlage wordt de structuur van het referentiemodel toegelicht en beschreven hoe de inhoud zich verhoudt tot geraadpleegde werken van toonaangevende auteurs. Tenslotte worden in de discussie een aantal openstaande vragen behandeld. Hebt u opmerkingen of antwoorden op vragen, email die dan s.v.p. naar
[email protected].
Inhoudsopgave 1.
INLEIDING...................................................................................................................................................... 1
1.
DE OPZET VAN HET 'LOGICA IN LAGEN' (LIL) REFERENTIEMODEL ................................................. 2
2.
VERGELIJKING VAN HET LIL-REFERENTIEMODEL MET DE VAKLITERATUUR .............................. 3
3.
DISCUSSIE .................................................................................................................................................... 5
4.
LITERATUUR................................................................................................................................................. 6
© Hogeschool Utrecht/Leo Pruijt
1
Gelaagde Architecturen (1): Bijlage
1. De opzet van het 'Logica In Lagen' (LIL) referentiemodel 1.1 De structuur Het LIL-referentiemodel onderscheidt en definieert soorten logica. Een soort logica bevat typen functionaliteit die ondeling samenhang vertonen en elkaar aanvullen. Zij geven een concretere invulling aan de verantwoordelijkheid van het soort logica. Een soort logica bevindt zich op een bepaald hiërarchisch niveau ten opzichte van de andere soorten logica. De onderstaande figuur toont het metamodel van het LIL-referentiemodel. 0..1 isBovengeschiktTenOpzichteVan LogicaSoort
0..1
-naam -verantwoordelijkheid -ookBekendAls 1 * FunctionaliteitsType -Naam -Omschrijving -Voorbeeld
1.2 De soorten logica en typen functionaliteit De onderstaande tabel toont de vijf soorten logica en de daarbij behorende typen functionaliteit. Zie [Pruijt10] voor een beschrijving van de verantwoordelijkheden van de soorten logica en voorbeelden van de typen functionaliteit. Logicalaag Presentatie logica
Type Functionaliteit User Interface opbouwen Events afvangen
Taakspecifieke logica
Events afhandelen Besturen van de taak
Domein logica
Processtatus bijhouden Processpecifieke bewerkingen uitvoeren Ophalen en opslaan van gegevens.
Infrastructuurabstractie logica
Generieke bewerkingen uitvoeren Data persistentie abstraheren
Infrastructuur logica
© Hogeschool Utrecht/Leo Pruijt
Security abstraheren, … Data technisch beheren Programma’s beheren en deployen
2
Gelaagde Architecturen (1): Bijlage
2. Vergelijking van het LIL-referentiemodel met de vakliteratuur Bij het ontwerpen van een lagenmodel, passend bij de eisen die aan een specifiek systeem zijn gesteld moeten verschillende soorten logica onderscheiden en geordend worden. Het LILreferentiemodel biedt een overzicht van de soorten logica die binnen enterprise information systems voorkomen, geeft de soorten logica zo zuiver mogelijke namen en definieert die. De soorten logica zijn onder andere gedestilleerd uit de beschrijvingen van lagenmodellen in toonaangevende literatuur. Mede om het risico te vermijden dat belangrijke soorten logica gemist worden. Onderstaand wordt van een aantal belangrijke bronnen beschreven wat zij hebben bijgedragen bij het tot stand komen van het LIL-referentiemodel. Ook het verschil in terminologie komt daarbij aan bod.
2.1 Pattern-oriented Software Architecture [Buschmann96] Bevat een beschrijving van het concept van het lagenmodel in de vorm van het ‘Layers’ pattern. Het verschil in abstractie tussen verschillende lagen wordt goed uitgelegd. Maar voor enterprise systems worden geen voorbeelden gegeven van lagenmodellen of soorten logica.
2.2 Software architecture in practice [BaClKa02] en Documenting Software Architectures [Clements03] Bevat een beschrijving van de principles van het lagenmodel en mogelijkheden om die te documenteren. Maar voor enterprise systems worden geen voorbeelden gegeven van lagenmodellen of soorten logica.
2.3 Applying UML and Patterns [Larman05] Bevat een beschrijving van de prominente plaats van 'Layers' binnen de 'Logical Architecture'. Larman onderkent dat er vele lagenmodellen in omloop zijn en geeft in figuur 13.4 van zijn boek een overzicht van 'common layers in an information system logical architecture'. Daarin onderscheidt hij zes lagen, geeft ze namen, beschrijft andere namen waaronder ze voorkomen en beschrijft voorbeelden van functionaliteit per laag. De lagen zijn: UI, Application, Domain, Business Infrastructure, Technical Services, Foundation. Larman vormt een belangrijke bron voor het LIL-referentiemodel. De overeenkomsten en verschillen zijn: • De definitie van logical bij Larman wijkt af van die in de artikelenserie over het lagenmodel, waarin de betekenis van logisch gebaseerd is op TOGAF [TOG09]. Larman onderscheidt de 'logical architecture' ten opzichte van de 'deployment architecture'. •
De eerste drie lagen komen redelijk overeen met die in het LIL-referentiemodel.
•
Larman definieert de verantwoordelijkheid van iedere laag niet duidelijk, maar geeft alleen voorbeelden van functionaliteit.
•
De term ‘Application’ is onduidelijk en wordt door verschillende auteurs geheel verschillend gebruikt. Larman geeft zelf ook al aan, want onder 'Domain' geeft hij aan: Also known as 'Application'. Daarom is die term uit het model van Larman vervangen door ‘Taakspecifieke logica’.
•
Hetzelfde geldt voor 'Domain', die is in het LIL-referentiemodel vervangen door 'Domeingenerieke logica'.
•
Larman’s laag ‘Business Infrastructure’ is weggelaten en in het LIL-referentiemodel opgenomen binnen 'Domeingenerieke logica'. Zie de discussie.
•
Larman’s onderste twee lagen ‘Technical Services’ en ‘Foundation’ zijn onduidelijk van naam en slecht gedefinieerd. Maar voor zover af te leiden is, zijn ze te mappen op de LILtermen ' Infrastructuurabstractie logica' en 'Infrastructuur logica'.
© Hogeschool Utrecht/Leo Pruijt
3
Gelaagde Architecturen (1): Bijlage
2.4 Patterns of Enterprise Application Architecture [Fowler03] Bevat een beschrijving van de principes, voor- en nadelen van layering. Een drie-lagen model wordt behandeld (presentation, domain, data source), waarbij het soort logica per laag ook beschreven wordt. Verder worden drie patterns beschreven om de domain layer te implementeren. De overeenkomsten en verschillen zijn: • De soorten functionaliteit die Fowler bechrijft zijn in het LIL-referentiemodel terug te vinden. •
De lagen van Fowler zijn niet een op een te mappen op de soorten logica van het LILreferentiemodel. Want de beschrijvingen per laag van Fowler zijn onvoldoende duidelijk om bijvoorbeeld te bepalen welke typen functionaliteit uit de 'Taakspecifieke logica' binnen 'Presentation' vallen en welke binnen 'Domain'. Omgekeerd zou het LIL-referentiemodel hier juist kunnen helpen goed te definiëren welke typen functionaliteit in welke laag thuis horen.
2.5 Domain Driven Design [Evans04] Bevat een beschrijving van de basisprincipes van een lagenmodel. En beschrijft een vier-laags model: User Interface, Application, Domain, Infrastructure. En deze lagen worden gedefinieerd. De overeenkomsten en verschillen zijn: • De bovenste drie lagen komen, voor wat betreft hun inhoud, sterk overeen met de bovenste drie in het LIL-referentiemodel. Een belangrijk verschil is echter het onderscheid taakspecifiek en domeingeneriek, dat het LIL-referentiemodel maakt en Evans niet. Zie verder de discussie. •
De namen van enkele lagen zijn, vanwege gebrek aan eenduidigheid, niet overgenomen.
•
De onderste laag van Evans is in twee delen gesplits in het LIL-referentiemodel.
2.6 SOA Design Patterns [Erl09] Bevat een fors hoofdstuk over service layers. Ook wordt een getrapt lagenmodel geïntroduceerd. Op het hoogste niveau worden onderscheiden: Business process layer, Business interface layer, Application layer. De Business interface layer wordt opgedeeld in: application services layer, business services layer, orchestration services layer. En Business services worden ingedeeld in task-centric services en entity-centric services. Op basis van de service abstracties worden verschillende scenario's geconfigureerd. De overeenkomsten en verschillen zijn: • Service lagenmodellen zijn wezenlijk anders van opzet. Een service laag staat doorgaans niet voor een bepaald type functionaliteit. Dit komt omdat een service doorgaans verschillende typen functionaliteit combineert om een dienst te leveren. •
De terminologie van Erl wijkt sterk af van die van bovenstaande auteurs. Met name Erl’s definitie van 'application logic' is zeer afwijkend van die van Larman en diverse andere auteurs uit de object geörienteerde wereld. Het staat voor de alle functionaliteit die fysieke applicaties kunnen leveren, tot aan ‘load balancing service’, et cetera toe.
•
Een interessant onderscheid in typen services dat Erl maakt is die tussen task-centric services en entity-centric services. De term taakspecifieke logica uit het LILreferentiemodel is afgeleid van Erl’s ‘task centric service’. Omdat deze term de lading beter dekt dan bijvoorbeeld 'application logic'.
2.7 Enterprise SOA [KrBaSl05] Bevat een paragraaf over 'Layers on the Enterprise Level', waarin een ook een lagenmodel met vier typen services worden onderscheiden: enterprise layer, process layer, intermediary layer, basic layer. Ook wordt uitgelegd dat deze lagen op enterprise niveau niet verward moeten worden met lagen binnen een applicatie. De overeenkomsten en verschillen zijn: • Uit de analyse zijn geen nieuwe soorten functionaliteit te voorschijn gekomen.
© Hogeschool Utrecht/Leo Pruijt
4
Gelaagde Architecturen (1): Bijlage
3. Discussie 1. Veel auteurs maken geen onderscheid (of maken dit onvoldoende duidelijk) tussen business logica/rules die algemeen geldend en herbruikbaar is en business logica die alleen geldig is binnen de context van een proces(stap). Bij veel auteurs valt alles onder Domain. In het LIL-referentiemodel valt de eerste categorie binnen de Taakspecifieke logica en de tweede categorie binnen de Domeingenerieke logica. Dit is gedaan vanwege de kwaliteitsattributen analyseerbaarheid en herbruikbaarheid: - Herbruikbare functionaliteit hoort in een lagere laag thuis dan niet-herbruikbare. - De analyseerbaarheid van het herbruikbare deel van een systeem wordt verminderd als het wordt vervuild met niet-herbruikbare functionaliteit. Vragen: 1.1. In hoeverre is het onderscheid tussen de twee soorten logica terecht? 1.2. Zijn er ook nadelen om die twee soorten in een speciek lagenmodel over verschillende logische en fysieke lagen te verdelen? 2. De soorten logica zijn hiërarchisch ten opzichte van elkaar geplaatst, waardoor het LIL-referentiemodel zelf ook weer een lagenmodel vormt. Dit is gedaan om het ondersteunende karakter en de herbruikbaarheid van een 'lager' soort logica duidelijk te maken. Vragen: 2.1. Is dat wel duidelijk of schept dat juist verwarring? 2.2. Leidt dit er niet toe dat hele lagen uit het LIL-referentiemodel zullen worden gepositioneerd in een een laag van een specifiek ontworpen lagenmodel? 2.3. Zijn er alternatieven? 3. De typen functionaliteit die zijn onderkend zijn, ondanks het bronnenonderzoek, misschien toch niet volledig. Daarnaast zijn vele keuzen mogelijk in naamgeving en aggregatie van typen functionaliteit. Vragen: 3.1. Zijn de typen functionaliteit die zijn onderscheiden duidelijk en goed samenhangend? 3.2. Ontbreken belangrijke typen functionaliteit? 3.3. Moet de 'Business infrastructure' laag van Larman niet leiden tot een type functionaliteit 'Domeingenerieke Utilities' onderaan binnen de 'Domeingenerieke logica'? Moet er überhaupt binnen iedere logica laag niet een type functionaliteit 'Utilities' worden onderscheiden? Dat is nu niet gedaan, omdat utilities geen overeenkomsten hoeven te hebben in het type functionaliteit, maar alleen in het feit dat ze doorgaans klein en herbruikbaar zijn. Zo weinig samenhang rechtvaardigt geen apart type. Bij het ontwerp van een specifiek lagenmodel en met name het fysieke lagenmodel, kan besloten worden of daarvoor aparte lagen/package gecreëerd worden.
© Hogeschool Utrecht/Leo Pruijt
5
Gelaagde Architecturen (1): Bijlage
4. Literatuur [BaClKa02]
[Buschmann96]
[Clements03]
[Erl09]
[Evans04]
[Fowler03]
[KrBaSl05]
[Larman05]
[Pruijt10]
[TOG09]
Bass, Len; Clements, Paul; Kazman, Rick Software architecture in practice Addison Wesley Publishing, 2003 Buschmann, Frank et all Pattern-Oriented Software Architecture: A System of Patterns John Wiley, 1996 Clements, Paul, et al Documenting Software Architectures Software Engineering Institute, Addison Wesley Publishing, 2003 Erl, Thomas SOA Design Patterns Prentice Hall, 2009 Evans, Eric Domain Driven Design Addison Wesley Publishing, 2004 Fowler, Martin; Patterns of Enterprise Application Architecture Addison Wesley Publishing, 2003 Krafzig, Dirk, et all Enterprise SOA Prentice Hall, 2005 Larman, Craig Applying UML and Patterns Pearson Education, 2005 Pruijt, Leo ‘Meer inzicht in gelaagde architectuur - Deel 1: Uitleg, terminologie en methoden’ Release - Vakblad voor de softwarearchitect, december 2010 The Open Group TOGAF version 9 Van Haren Publishing, 2009 Of als gratis download via www.opengroup.org/architecture
© Hogeschool Utrecht/Leo Pruijt
6