Der finde en række gode grunde til at anvende den klassiske tre-lags-model der i gamle dage blev advokeret for i SOA tankegangen. Den klassiske tilgang består af et præsentationslag, et logik lag og et datalag. Typisk stilles der krav om at alle funktionskald skal passerer igennem de tre-lag og anvende generaliserede webservices i et så stort et omfang, som det er muligt. Tanken er i teorien god, men der findes ofte en række problemstillinger ved at anvende mønstret når det kommer til stykket, hvilket vil sige generaliserbarheden ofte kan vise sig svær at implementere i praksis. Tanken om de tre lag giver god mening i tilfælde af organisationer der råder over rigtig mange webservices der udgør integrationer mellem applikationer i systemlandskabet.

Fordele ved tre-lags mønstret

Nedenfor har jeg opstillet mine syn på tre-lags mønstret:

• Generaliserbarheden af webservices.
• Genbrugelige webservices.

Anvendelsen af de tre lag giver god mening for organisationer der udvikler mange integrationer, men de kræver en meget stram styring for at organisationen opnår gevinster ved investeringen i tre lags mønstret. Fordelene kan høstes, men det kræver en beslutning på topniveau i organisationen og som håndhæves med henblik på den videreudvikling af organisationens systemlandskab.

Ulemper ved tre-lags mønstret

Nedenfor har jeg opstillet ulemperne ved tre-lags mønstret:

• Øget kompleksitet.
• N-tier arkitektur opstår hurtigt.
• Længere udviklingstid.
• Stram governance bliver nødvendig at håndhæve for hvert eneste udviklingsprojekt

Det kræver en bestemt type ledelse og en proaktiv dialog for at opnå positive resultater ved implementering af et tre-lags mønster.

Omstilling til ruter

Et alternativ til tre-lags mønstret er Apache Camel ruter. Ruterne er ofte mindre komplicerede end anvendelsen af de tre lag ved, at man i udviklingsarbejdet ikke fokusere på samme håndhævelse af udvikle webservices for hvert af de tre lag for at håndtere en data transaktion.

Ruterne kan generaliseres og laves om til biblioteker der importeres ind i ny udvikling af andre ruter der har behov for samme karakteristika. Dermed sagt så falder behovet for styring på hver integration set i forhold til og integrationen kan generaliseres eller, og fokus ændrer sig til at mani højere grad arbejder i retning af at få centrale biblioteker der kan generaliseres og genanvendes og flere webservices der er målrettet at transaktioner kan gennemgøres, så data kan flyttes mellem de rette informationssystemer i organisationenre.

Kan de tre lag ”bare udskiftes”?

Integrationerne skal udvikles fra bunden, da det er urealistisk at udskifte integrationerne og tilpasse dem så de passer med de ”end-points”, og dermed sagt så kan laget ikke bare udskiftes, men det kræver en indsats og en række udviklingsprojekter. Det vil sige at følgende aktiviteter skal sættes i gang:

• Indsamling af eksisterende dokumentation.
• Identificering af end-points der kan generaliseres.
• Udvikling af nye integrationer skal tage udgangspunkt i ruter frem for tre-lag.
• Håndtering af driftsopgaver og en samtidig prioritering af genudvikling af de nødvendige integrationer.
• Afklaring af situationer, hvor organisationen har fraveget best-praksis og komponenter skal erstattes af applikationer der understøtter styring af de nødvendige webservices til at sende data mellem de rigtige fagsystemer.

Dermed sagt så kan det for organisationer der har forretningsbehov for at udveksle data mellem applikationer at anvende de relativt mere simple integrationer der kan udvikles via Apache Camel ruter.

Konklusioner

I organisationer der ikke råder over tusindvis af webservices, så kan det give mening at gå udskifte integrationsmønstret fra de tre-lag til Camel-router der i deres design ofte vil være mindre komplicerede. Mindre komplicerede integrationer og nemmere styringsmodeller (governance) leder til hurtigere udvikling og en mere overskuelig udviklingsproces. Det vil igen lede til at de leverancer der kommer ud af processen understøtter organisationernes forretningsbehov.