Genbrugelighed i SOA og Digital Tinglysning

 og Vi havde besøg af en person, der skulle dele sine erfaringer ved at udvikle serviceorienteret. En af hans kommentarer var, at han ikke oplevede genbrugeligheden af services. Det får mig til at understrege behovet for at definere, hvad man forstår ved en service.

Hvis man definerer sit servicebegreb for applikationsnært, vil den typisk ligge tæt op af implementeringen af løsningen og kan derfor være svær at genbruge udenfor applikationens initielle 'interessefære'.

Det er min holdning, at en service skal indkapsle en forretningsproces, ellers ser jeg det ikke som en service, men mere en lokal implementering af løst koblet funktionalitet i applikationen.

Så udfordringen ved at lave genbrugelige services, drejer sig altså om at lave genbrugelige manuelle og automatiske forretningsprocesser.

En service skal ændres, når den skal genbruges!

En anden kommentar var, at når servicen skulle genbruges, skulle den ændres, for at passe til den nye anvendelsesmåde.

Det ser jeg heller ikke som værende i strid med servicetankegangen. Det er en naiv tankegang, hvis man forventer, at man kan designe en service, som ikke skal ændres, efterhånden som brugsmønstret udvikles.

Det er vigtigt at designe servicen ud fra en forventning om, at den skal ændres og samtidig holde fast i kerneområder af servicen, som ikke bliver ændret.

Fuldmagtsbogen som genbrugelig service

For eksempel har vi i Digital Tinglysning behov for en fuldmagtsservice, som skal opfylde tre funktioner:

  • Det skal være muligt at indsende fuldmagter på papir, som Tinglysningsretten OCR-læser og derved digitaliserer
  • Det skal være muligt at indsende en digital fuldmagt, signeret med digital signatur. 
  • Det skal være muligt for tredjepart, at forespørge i fuldmagtsbogen gennem servicekald

Det er Tinglysningsrettens forventning, at denne fuldmagtsbog bliver en generel offentlig fuldmagtsservice, som kan bruges i mange sammenhænge, som intet har med tinglysningen at gøre

Kerneområdet af en sådan offentlig fuldmagtsservice er defineret til, at der altid vil være en fuldmagtshaver, en fuldmagtsgiver samt et objekt, man giver fuldmagt til at disponere over. Hvad det er, for en dispositionsret man giver fuldmagt til, vil variere efter hvem, der vil bruge servicen. Fuldmagt til at lyse et skøde på en ejendom, fuldmagt til at hente en pakke på posthuset, fuldmagt til at underskrive et regnskab osv.

Det betyder, at hvis fuldmagtsservicen skal genbruges, skal fuldmagtshaver og fuldmagtsgiver være enten en virksomhed eller en person. Ellers kan man ikke bruge denne service.

Objekterne vil også udvides efterhånden, som anvendelsesområdet udvides, men betragtes alligevel som en del af kerneområdet.

Fra Tinglysningsrettens side vil den være født med muligheden for at angive ejendom, stelnummer, CPR og CVR, som vil være genbrugelige i mange andre sammenhæng. Det er forventningen, at der skal tilføjes yderligere objekter, efterhånden som anvendelsesområdet udvides (pakkeID, journalID osv.).

Den sidste del, som beskriver selve fuldmagten, vil variere efter hvert anvendelsesområde og det er ikke forventningen, at det kan genbruges på tværs af anvendelsesområder og er derfor ikke en del af kerneområdet.

På trods af at fuldmagtsservicen skal ændres, for at kunne genbruges i nye sammenhænge, ser jeg dette som en genbrugelig service, der indkapsler Tinglysningsrettens forretningsproces til manuel og automatisk håndtering af fuldmagter.

Andre eksempler på genbrugelige forretningsservices fra Digital Tinglysning

Ud fra samme princip er der defineret et antal andre genbrugelige services, som Tinglysningsretten forventer, kan blive fællesoffentlige service.  F.eks.

  • **Bilagsbankservice** ? Hvor man kan lægge et bilag ind med visse metadata og alle kan tilgå dette bilag. Kerneområdet i bilagsservicen er hele servicen (bilaget betragtes blot som et BLOB).
  • **Underskriftmappeservice **- Mulighed for at lægge et XML-dokument, der skal signeres med XML-DigSig i en virksomheds eller persons underskriftmappe. Vrksomheden eller personen kan derefter besøge sin underskriftmappe og skrive under med digital signatur. Kerneområdet af underskriftmappeservicen er personer/virksomheder der skal skrive under samt underskriftmetoden. Dokumentet der skal underskrives vil variere efter anvendelsesområde
admin adminusers billede

Kommentarer (24)

Brian Hvarregaard

Det er vel muligt/nødvendigt at skelne mellem services på forskellige niveauer. Jeg er enig i at services der modellerer en forretningsprocess ikke skal være nær så uafhængige af forretningen som en service der eksempelvis opretter kalenderaftaler.

Min pointe er at man ikke kan skære alle services over een kam, men er nødt til at se på hvilket lag i arkitekturen de befinder sig i, der er forskellige typer services og ikke dem alle er forretningsservices. Typisk er det således at din specifikke forretningsservice benytter en eller flere mindre specifikke services som hver især igen benytter en eller flere mindre specifikke services, for til sidst at ende med nogle atomare services der ikke kan opdeles yderligere - det i hvertfald i teorien.

Jeppe Cramon

En lagdelt SOA arkitektur har bestemt genbrug af de lavere liggende services, til gengæld opnår du ofte også en rigtig hård kobling hvilket går direkte i mod SO's intentioner om løst koblede services - Bill Poole beskriver det ret godt her: http://bill-poole.blogspot.com/2008/05/layered-service-models-are-bad.html

Han har også et godt eksempel på problemerne med SOA og genbrug: http://bill-poole.blogspot.com/2008/04/soa-and-reuse.html

/Jeppe

Henrik Hvid Jensen

Det er også den diskussion jeg tager i "Har it-afdelingen kuppet SOA?" http://www.version2.dk/artikel/9666-har-it-afdelingen-kuppet-soa

Det er selvfølgelig interessant at opbygge sin løsning i henhold til SO-principper, men de services der betyder noget for forretningen er dem der udstilles til brug, når der skal integreres på tværs af applikationer og/eller organisatoriske skel.

Den måde som man opbygge de underliggende komponenter på, er vigtige for en ordentlig og fleksibel arkitektur, men hvor løst koblet de kan/skal være, er et teknisk design spørgmål og det er ofte ikke den bedste løsning at opbygge disse for løst koblet.

Henrik Hvid Jensen

Det er også den diskussion jeg tager i "Har it-afdelingen kuppet SOA?" http://www.version2.dk/artikel/9666-har-it-afdelingen-kuppet-soa

Det er selvfølgelig interessant at opbygge sin løsning i henhold til SO-principper, men de services der betyder noget for forretningen er dem der udstilles til brug, når der skal integreres på tværs af applikationer og/eller organisatoriske skel.

Den måde som man opbygge de underliggende komponenter på, er vigtige for en ordentlig og fleksibel arkitektur, men hvor løst koblet de kan/skal være, er et teknisk design spørgmål og det er ofte ikke den bedste løsning at opbygge disse for løst koblet.

Klaus Hansen

Jeg mener at det er skræmmende at der bruges e-Tinglysning som en success for SOA og et bevis for genbrugelighed. Min forståelse er at netop e-Tinglysning har været udsat for hæftige forsinkelser og gået langt over budgettet, med en leverandør der blev tildelt maksimal bod.
På samme måde ville jeg heller ikke heller ikke nævne AMANDA som et godt eksempel på at få udbredt OS/2. (sjovt nok samme leverandør)
Faren for at de gode SOA tanker bliver skudt til hjørne i mange organisationer, er netop at det er dyrt og tager lang tid.
Man bliver nødt til at tage forretningsmæssige briller med. Men de glemmes mange gange af for akademiske arkitekter og SOA fortalere. Hvis omkostninger for at genbruge overstiger at bare bygge på ny, hvorfor strække sig så langt i det hellige navn af genbrugelighed.
Jeg har længe ikke fattet hvorfor man bliver ved at tæske langhalm på genbrugelighed som argument for SOA. Der er mange andre gode argumenter, men genbrugelighed ligger langt nede på listen efter min mening.

Jeppe Cramon

Vi skulle lave OO for at få genbrugelighed - Det fik vi ikke - andet en for meget meget generelle ting som tekniske klasser.

Så skulle vi lave komponenter for at få genbrugelighed - Det fik vi heller ikke meget af - Det vi lærte var desto mere generelle komponenter var, desto større genbrugelighed havde de, fordi der var færrest mulige antagelser. Jo mere specialiseret en komponent var, desto med værdi gav den, desto mindre genbrugelig var den.

Og nu prøver igen med SOA. Den eneste måde at få genbrugelighed er lagdelt SOA eller Event baseret SOA. Lagdelt er hvor services bygger på andre services (mere generelle services), der igen bygger på endnu mere generelle services. Det giver genbrugelighed, men også en voldsom KOBLING mellem services, så ændringer i en meget generel service giver kaskade effekter i ALLE de services der bruger den.

Genbrug = Hård Kobling
SO = Løs kobling
Lagdelt SOA = Hård kobling og genbrug
Event baseret SOA = Løs kobling og genbrug

Det hænger altsp ikke sammen med lagdelt SOA - Den eneste måde at lave tilpas løst koblede services på er at bruge en Event baseret tilgang til SO(A).

Jeppe Cramon

Vi skulle lave OO for at få genbrugelighed - Det fik vi ikke - andet en for meget meget generelle ting som tekniske klasser.

Så skulle vi lave komponenter for at få genbrugelighed - Det fik vi heller ikke meget af - Det vi lærte var desto mere generelle komponenter var, desto større genbrugelighed havde de, fordi der var færrest mulige antagelser. Jo mere specialiseret en komponent var, desto med værdi gav den, desto mindre genbrugelig var den.

Og nu prøver vi igen med SOA. Den eneste måde at få genbrugelighed er lagdelt SOA eller Event baseret SOA. Lagdelt er hvor services bygger på andre services (mere generelle services), der igen bygger på endnu mere generelle services. Det giver genbrugelighed, men også en voldsom KOBLING mellem services, så ændringer i en meget generel service giver kaskade effekter i ALLE de services der bruger den.

Genbrug = Hård Kobling
SO = Løs kobling
Lagdelt SOA = Hård kobling og genbrug
Event baseret SOA = Løs kobling og genbrug

Det hænger altsp ikke sammen med lagdelt SOA - Den eneste måde at lave tilpas løst koblede services på er at bruge en Event baseret tilgang til SO(A).

Henrik Hvid Jensen

Jeg ser også hændelser som centrale i SOA (se her http://www.version2.dk/artikel/9795-haendelser-en-vigtig-ingrediens-i-soa og http://www.version2.dk/artikel/9796-haendelser-er-vigtige-for-forretningen)

Det asynkrone kommunikationsmønster er væsentlig for genbrugeligheden på tværs af applikationer og organisatoriske skel og det sker på bekostning af at man ofte ikke kan designe brugergrænseflader med forventning om øjeblikeligt svar.

Jeg ser dog ikke alle asynkrone services som hændelser, men det har jeg debatteret i ovenstående blogs.

Anonym (ikke efterprøvet)

[quote]Det asynkrone kommunikationsmønster er væsentlig for genbrugeligheden på tværs af applikationer og organisatoriske skel og det sker på bekostning af at man ofte ikke kan designe brugergrænseflader med forventning om øjeblikeligt svar.[quote]
Det er da nok noget nær den største gang ævl jeg har hørt.

Mener du seriøst, at 'unreliable' transaktioner er vejen frem?

Det er næsten for patetisk at forklare med Adam og Eva,, men lad os forestille os følgende forretningsgang:
1) Jeg sende en anmodning om byggetilladelse.
2) Får intet svar, da det er 'asynkront'.
3) Godt så, jeg går i gang med byggeriet.
4) Hov for s*tan, den blev afvist.

Hvad gør jeg så?

Jack Ekman

Hej

Genbrugelighed er et af de vigtige salgsargumenter for SOA. Og muligheden for genbrugelighed er også tilstede, men det tager typiske 2-3 projektiterationer (svarende til 2-3 år) før man i SOA projekter får opbygget en kritisk masse af services og overlappende forretningsprocesser. Dermed går der også et stykke tid, før genbrugelighed bliver en signifikat faktor. Det følger iøvrigt helt Gartners modenhedsskala for SOA, som siger, at man skal forvente en vis investering i SOA, før man begynder at kunne bruge alle fordele.

Tilsvarende er det min erfaring, at der er stor forskel på interne og eksterne services. Services der bruges internt i et firma er typisk en blanding af genanvendelige forretningsorienterede services og mere specifikke tekniske services. Derfor kan procentdelen af interne services, der genanvendes være forholdsvis lav.

Eksterne services, der skal bruges af andre organisationer, som f.eks. dem der udstilles i e-tinglysning, vil af natur være mere "grov-kornede" for at kunne understøtte bredt genbrug. Derfor vil genbrugsfaktoreren her forhåbentlig være noget højere end for de interne services.

Min samlede pointe er, at diskussionen om genbrug i SOA hurtig blive forsimplet, hvis man ikke få sat konteksten rigtigt. På samme måde, som det kan være svært at diskutere "god sikkerhed" i IT projekter.

En anden vigtig pointe er, at genbrugs salgsargumentet, bør indgå som en af flere vigtige salgsargumenter for interne SOA projekter. Andre vigtige vil eksempelvis være

  • Overblik over integrationsarkitektureren ()
  • Standardisering af kaldmønstre og dataformater
  • Bedre mulighed for ensartet overvågning og fejlhåndtering.
  • Mulighed for effektivt og hurtigt at oprette nye services

Disse argumenter er typisk af lige så stor værdi for virksomheder, der står med en spagettiarkitektur og gerne vil igang med SOA.

Henrik Hvid Jensen

Jeg forstår ikke hvorfor du mener at asynkron kommunikation udelukker reliability. Det offentliges RASP-protokol (http://digitaliser.dk/resource/391706) er jo netop et eksempel på en Reliable Asynkron Secure Protokol.

Hvis du ikke afventer svar på et servicekald, når om det kommer asynkront, før du går i gang, men blot antager, at det at du sender en anmodning er tilstrækkeligt, er vel selve problemet i det du beskriver.

Nikolaj Brinch Jørgensen

@Henrik
Men OIO RASP var det ikke den som eTL skrottede og erstattede med JMS :-)

Anyway jer er dog helt enig med dig. Vi kan stadig lave reliabiliy med asynkronitet. Den med byggetilladelsen er da for værdiamputeret som argumentation.

Asynkronitet er dog begrænset til de use cases der lader det implementere (jeg mener - sikkert som du - at kunden skal udfordres på disse use cases, så de kan omlægges til at supportere asynkronitet).
EDA har mange andre fordele, bla. en betydeligt nemmere og bedre skalering.

Problemet med SOA er ikke manglende genbrug mv. men egentlig hvordan det forvaltes på et projekt.

Jeppe har ret i, at om vi kalder det klasser eller komponenter, eller systemer - så er genbrugbarheden størst der hvor man kan tage noget og flytte det med sig - og det er kun meget generelle systemer (mest frameworks og lignende), hvor det lader sig gøre.
Helt snævre forretningsmæssige processer/services har meget lidt genbrugbarhedsværdi, da de er specifikke for et helt specielt domæne (måske subdomæne) i forretningen, og ingen andre kan på nogen måde bruge dem.

Hvis man nu forestillede sig at de services der blive udviklet skulle følge gængs programmeringsskik i form at OCP, så ville man jo ikke ændre en service ved en rettelse/ændring/ny forbruger, man ville oprette en ny der vill tilfredsstille dette krav, bruge den logik der er til rådighed til frembringelse af denne nye service, og lade begge køre ved siden af hinanden. Overvårgningen skal da nok fortælle os senere hvis en af de services der er defineret ikke længere er i brug, ellers har service governor vel styr på det, eller hur?

Jeg mener ikke SOA skal sælges på genbrug, der er ikke forretningen i det, for så er det verdens dyreste måde at få genbrug på. SOA er so far den dyreste måde at løse et forretningsproblem IT mæssigt på.

Lagdelt SOA??? Sikke noget - i skulle skamme jer :-)

Henrik Hvid Jensen

Nikolaj,

OIO-RASP er udsat ikke skrottet

Det er min overbevisning, at det at udbyde services til at samarbejde med andre virksomheder, bliver kritiske for en virksomheds konkurrenceevene. Og på sigt afgørende for virksomhedens overlevelse. det bliver udviklingen på internettet, at vi går fra at være primært designet til at fremvise data for menensker til at udbyde funktionaltiet, der kan forbruges af maskiner. Denne funktionalitet udbydes i form af services

I http://www.version2.dk/artikel/9666-har-it-afdelingen-kuppet-soa skriver jeg bl.a:

Forståelsen af webservice er på 90’er niveau

Det er min vurdering, at webservice-forståelsen hos forretningen er på niveau med forståelsen af hjemmesiders muligheder i midten af 90’erne. Dengang var det ofte nogle kreative it-folk, der lavede nogle spændende hjemmesider ofte uden en fast forankring i forretningens strategi.

De virksomheder som først forstod at inkludere hjemmesiders potentiale i deres forretningsstrategi, opnåede en konkurrencefordel.
På samme måde er det med services, de virksomheder, som først inkluderer services potentiale som en naturlig del af deres forretningsstrategi, vil opnå konkurrencemæssige fordele, der langt overstiger de fordele, som hjemmesiderne giver

Nikolaj Brinch Jørgensen

Henrik,

Men genbrug, det kommer af sig selv kun når noget bliver alment anvendeligt (både eksternt og internt i virksomheden).

Man kan så vælge at gribe sine services an på flere måder, og det er nok der hvor vi er enige - man griber det forkert an, hvis man overhovedet griber det an.
De fleste virksomheder er ikke klar over potentialet forretningsmæssigt, og det er vores job at agitere for det og overbevise dem. Derefter skal vi selvfølgelig følge det ordenligt op, og levere det lovede (her er der som oftest et problem i SOA projekter fordi alt for hæle bliver hugget osv.).

Dog kan det sagtens lade sig, men man skal se sig for, og ikke smide al god lærdom ud (en god idé er at læse og forstå Postel's Law når vi snakker webservices).

Der er i mine øjne en alt for stor tendens til at se services som RCP over HTTP, hvilket er i direkte modstrid med forretningens interesse.

Ligesom en del arkitekter jeg har arbejdet med ikke rigtig er interesseret i den enkelte virksomheds forretning, og så begynder det altså at blive svært at lave SOA.

God artikel iøvrigt.

Henrik Hvid Jensen

Hej Nikolaj,

Enig, En af de store udfordringer bliver når udviklere skal udvikle til de "ukendte" forbrugere på internettet og ikke til de trygge brugere indenfor murene

Nikolaj Brinch Jørgensen

Det er klart udviklernes udfordring (og de andre projektansatte for den sags skyld).

Dog synes jeg arkitektrollen tit lider af kompentencemangel (jeg skal skynde mig at sige, at jeg ikke ser dig der :-) ).

Enterprise Ariktektur er i mine øjne koncentreret omkring non-funktionelle krav til et projekt/en løsning - mere præcist de forretningsmæssige krav. Derfor er det heller ikke nogen dårlig idé at alliere sig med nogle forretningskonsulenter, hvis evne det er at kunne sætte sig ind i forretningens problemstilling og udfordre den, for til sidst at ende op med en løsning på den.

Der er så flere lag af roller der skal ind over for at der kan komme noget ud i den sidste ende. Men de funktionelle krav skal afspejle de forretningsmæssige, så det kan derfor ikke nytte noget at man igen og igen starter på de funktionelle krav i en samling use cases - man er nødt til som arkitekt at tage helikopteren op og se om det overhovedet hænger sammen på en forsvarlig måde.

En lærdom der kan drages ind, er det vi har lært af LEAN og TPS, nemlig at mindske variation og fragmentation, da det er noget af det dyreste i enhver forretning helt ned på proces niveau.

Hvis man kun taler med de kommende brugere, vil de oftest helst have et system der bare gør det de er vant til at udføre manuelt, og så har man i mine øjne opnået meget lidt.
Det er mere sundt at få lavet f.eks. value stream maps over processerne som de er, og så eliminere det spild der er og rette til så variation og fragmentation mindskes mest muligt.
Men dette skal ske højere i forretningen, ud fra forretningens mål.

Det er også efter min erfaring nemmere at komme ind med sit budskab hvis man således kan forklare business casen ud fra en besparelse og øget konkurrenceevne som følge.

Dog er diverse BPM værktøjer af så ringe kvalitet endnu, at de ikke rigtigt fordre den agilitet, som forretningen gerne skulle kunne trække ud af investingen. Det er jo målet at lave kontinuerlig proces forbedringer, og ikke statisk big bang a la BPR og lignende.

Henrik Hvid Jensen

ESB'en tilføjede ikke den nødvendige værdi i forhold til det ekstra lag det medførte. Du skal være opmærksom på, at e-TL er en enkelt applikation og ESB'en giver oftest størst værdi hvor flere applikationer skal kommunikere.

Det mellemlag som finanssektoren har lagt ind er derimod et naturligt sted for en ESB.

Henrik Hvid Jensen

Jge er enig med dig i at det er en tro på at dette er fremtiden fremfor interview med eksisterende brugere, der skal drive virksomheden fremad mod internettes næste trin.

Hvis man for 10-15 år siden havde spurgt om en bankkunde kunne tænke sig at betjene sig selv via internettet, ville de havde sagt "at de godt kunne lide den personlige kontakt i banken" eller "at de så ikek andet behov end telefonbanken

Nikolaj Brinch Jørgensen

Ligesom det der internet er så "usikkert", så der kan vi ikke handle (man kan konspirere om det er detailhandlen der har haft en interesse i at bremse e-handel?).

For 20 år siden var telefonbanken, sikekrt også utænkeligt.


ESB'en (i hvert fald et integrationslag) kan give god mening, selvom om der er tale om en enkelt applikation. Flere ESB produkter er dog enormt dyre, måske er det der Gartner senest har anbefalet netop Open Source ESB'erne til større installationer :-).

Selv i en enkelt applikation (som ikke er distribueret), kan et integrationslag give god mening, da den giver en god isolation mellem de forskellige komponenter, og dermed baner vejen for en hurtigere vej mod genbrug på længere sigt.

Temmelig mange gange kan et sådan integrationslag også fordre en højere hastighedsudvikling, og som sagt fjerne hårde bindinger, der på sigt vil låse evolutionen af en komponent fast. Der kan man se se på projekter som ActiveMQ (in VM brokering) og Apache Caml.

Jeppe Cramon

Der er jeg lodret uenig - Tilføj en ESB NÅR der findes et behov for at flere applikationer skal integrere med applikationen eller hvis applikationen har behov for at kommunikere med flere eksterne parter hvor der er behov for protokol/besked transformationer.
Indtil da er en ESB blot et ekstra stykke software der skal konfigureres, ændres, deployes til.

Jeg går ikke ud fra at du mener at det giver mening at en applikation skal kommunikere med sig selv gennem en ESB ?

Keep it simple!

/Jeppe

Nikolaj Brinch Jørgensen

Jeg går ikke ud fra at du mener at det giver mening at en applikation skal kommunikere med sig selv gennem en ESB

Nej det har jeg ikke sagt. Jeg sagde et integrationslag, det kan du så selv kode (Jeppe), eller du kan tage et på hylderne der overholder en åben standard.

Der er jeg lodret uenig - Tilføj en ESB NÅR der findes et behov for at flere applikationer skal integrere med applikationen eller hvis applikationen har behov for at kommunikere med flere eksterne parter hvor der er behov for protokol/besked transformationer.

Nu tror jeg der er en del kommunikation ud og ind af huset på e-TL.
Samtidigt kan man ved omlægning af legacy tinglysningssystemer, såsom skibstinglysning, i en transitionsfasen koble det gamle legacy system på det nye system, uden de store vanskeligheder, og på den måde få en glat transition (kan nok forklares bedre - men jeg tror du forstår hvad jeg mener).

[quote]Indtil da er en ESB blot et ekstra stykke software der skal konfigureres, ændres, deployes til. [quote]
Behøver der ikke være, når vi snakker integrationslag.

Iøvrigt tror jeg granulariteten af en enkelt applikation er til diskussion i dette her tilfælde (her kan du hjælpe Henrik).
Jeg tror Henrik mente e-TL er et enkelt system, men ikke en enkelt applikation.


Noget helt andet...

Hej Jeppe, hvordan går det så? :-)

/NEKO

Jeppe Cramon

Hej Neko

Det går rigtig godt - Håber alt er vel hos dig? :)

Hvis vi snakker integrationslag mod andre systemer, så er jeg enig i at en ESB kan give mening i stedet for at skrive integrationslaget selv.

Men med eTL, der er en applikation med et kerne modul med flere grænseflader (interne/eksterne portaler, ekstern integrationsflade), så bør man stadig vurdere om en ESB giver mening. Hvis JMS kan klare alle nuværende eksterne integrations opgaver, hvorfor så besvære sig med en ESB? Man kan vente med omkostningen til behovet er der og en ESB måske ligefrem giver besparelser ;)

For portalerne, så befinder disse sig indenfor service grænsefladen og derfor giver det god mening at integrere disse uden en ESB og i stedet benytte bedre kommunikations protokoller/former (f.eks. RMI)

Bill Poole, som jeg linkede til tidligere, har noge gode forklaringer på hvorfor det giver mening: http://bill-poole.blogspot.com/2008/03/services-and-user-interfaces.html

/Jeppe

Log ind eller opret en konto for at skrive kommentarer