Kirk Knoernschild har skrevet en god bog omhandlende applikationsarkitekturer på Java platformen. Helt konkret gør Knoernschild brug af OSGi som et eksempel igennem bogen, hvilket giver læseren et godt indblik i, hvordan det er muligt at udvikle ”enterprise” applikationer. I bogen findes en række eksempler på kildekode som kan bruges i forhold til OSGi, men desværre er bogen ikke det bedste medie til at formidle den slags viden.

Der findes dog nogle problemstillinger i forhold til Knoernschilds syn på begrebet arkitektur. Jeg har tidligere skrevet om dette i blogindlægget ”Forvaltning af applikationer (1)” , hvor jeg kom ind på en af de antagelser, som Knoernschild gør brug af.  Helt specifikt omtaler Knoernschild behovet for at udarbejde arkitektur artefakter for alle lag i stakken for applikationerne. Det synspunkt er jeg ikke enig i og fra mit synspunkt er det ikke nødvendigvis den korrekte fremgangsmåde at anvende i en dynamisk verden, da der sjældent vil være ressourcer nok i små og mellemstore virksomheder til at arbejde med artefakterne. Hertil vil det ofte være et krav fra forretningsenhederne at dem som egentlig besidder kompetencerne til at udarbejde kompetencerne skal allokeres til nye projekter.

Trods den noget bizarre fremgangsmåde til arkitektur så har bogen en række interessante elementer og mange gode kildekodeeksempler som anvendes til at forklare mønstrene som Knoernschild anvender. Knoernschild kommer dog ind på nogle gode pointer igennem bogen en af disse er repræsenteret i citatet nedenfor:

”These large systems are still difficult to maintain, extend, and manage. The current principles and patterns of object-oriented development fail in helping manage the complexity of large software systems because the address a different problem” – Knoernschild (2012)

Knoernschild kommer ind på måder på som applikationsarkitektur kan bruges til at håndtere de problemstilligner som objekt-orienterede sprog står overfor. En af disse fremgangsmåder er modulopbygning af Java applikationerne og anvendelsen af en service som OSGi. I forhold til begrebet modulopbygning kommer Knoernschild ind på en pointe i forhold til størrelsen eller enheden som modulet skal være bygget op omkring  og dette kommer til udtryk i citatet nedenfor:

”A software module is deployable, manageable, natively reusable, composable, stateless unit of software that provides a concise interface to consumers.” – Knoernschild (2012)

Ovenstående definition er meget bred og for generel, men Knoernschild kom ind på en nærmere definition af, hvordan et modul kan bygges op, og i den forbindelse nævner Knoernschild EAR, WAR og JAR filer. Knoernschild kommer senere ind på at en modulær opbygning og en SOA-opbygning ikke som sådan er modstridende, men services er en anden fremgangsmåde en moduler. Sidst i det samme kapitel anbefaler Knoernschild at JAR filen er den bedste kandidat af de førnævnte filtyper på et egentligt modul på Java platformen, hvilket kommer til udtryk i citatet nedenfor:

”The best candidate as the unit of modularity on the Java platform is the JAR file!” – Knoernschild (2012)

Knoernschild kommer med ind på en modulopbygning af applikationerne fordi det giver en arkitektur og dermed et it-system som er i stand til at være en tilpasningsdygtig, og i den forbindelse kommer Knoernschild ind på det specielt er nødvendigt for Java platformen, hvilket kommer til udtryk i citatet nedenfor:

”Modularity is a key element of designing software systems with a flexible and adaptable architecture. There is a need for modularity on the Java platform, especially in developing large enterprise software.” – Knoernschild (2012)

Herudover kommer Knoernschild ind på Java platformen har en opbygning som gør det svært at få en modul opbygning til at virke og det kan være med til at gøre udviklingen af applikationen ekstra svær at vedligeholde. Konerschild udtrykker dette i citatet nedenfor:

”In other words, there is no way to hide implementation details. Everything is global, which impedes modular design. A runtime module system provides the ability to hide implementation details” – Knoernschild (2012)

Denne fremgangsmåde kan vise sig relevant i forhold til forvaltning af applikationen. Applikationsarkitektur er nødvendigt for at kunne strukturere applikationen ud fra nogle fundamentale principper som blandt andet overholder n-lagsmodellen. I forhold til  n-lagsmodellen kommer Knoernschild ind på, hvordan de kan kobles sammen igennem nedenstående citat:

”If I truly have a layered system, then I should be able to break out each layer into a separate module where modules in the upper layers depend on modules in lower layers, but not vice versa” – Knoernschild (2012).

Personligt klassificerer jeg bogen vurderingen 6 ud af 10 mulige, da jeg samtidigt føler, at bogen kan forbedres væsentligt på visse punkter.

Konklusion

Bogen er hæderlig, og Knoernschild bruger en række eksempler samt referencer til kilder, hvormed der ikke er tale noget der virker helt selvopfundet. Jeg er noget forundret over Knoernschilds fremgangsmåde til arkitektur og måden, hvorpå de forskellige artefakter skal udarbejdes og det er en fremgangsmåde, som jeg i de fleste tilfælde vil antage fejler.

Til trods for dette kan jeg anbefale andre at læse bogen især, hvis I har interesse i forhold til udvikling af applikationer på Java platformen.

Kilder

Knoernschild, Kirk. Java Application Architecture Modularity Patterns with Examples Using OSGi. Upper Saddle River, NJ: Prentice Hall, 2012.