Enterprise JavaBeans sammenlignet med idealet for en komponetmodel
|
|
- Ada Frederiksen
- 8 år siden
- Visninger:
Transkript
1 Enterprise JavaBeans sammenlignet med idealet for en komponetmodel af Eva Nilsson, Asger Bruun, Tim Hallwyl og Miriam Tang Datalogisk Institut Københavns Universitet April 2005
2 Indhold 1 Sammenfatning 4 2 Indledning 4 3 Komponentbaseret softwareudvikling Vision Den idelle komponent Kontrakter Grænseflade Navngivning Interaktion standard Funktionelle og ikke-funktionelle krav Komponentdokumentation Black-/whitebox Certificering Interoperabilitet Indsættelse 10 7 Sammensætning af komponenter Sammensætningsformer Tidspunkt for ressourcebinding Vedligeholdelse og udskiftning af komponenter 12 9 Component Services Objektoprettelse og -tilstandslagring Messaging / Event notification Sikkerhed Opsummering af krav Komponenter
3 10.2 Rammeværk Kontrakter EJB sammenlignet med idealet Komponent Rammeværk Kontrakter Konklusion 23 3
4 1 Sammenfatning Vi har i denne rapport opstillet en række krav til den idelle komponentmodel på baggrund af vores studier i forbindelse med kurset Komponent Baseret Softwareudvikling. Udgangspunktet for vores ideal er den på kurset anvendte litteratur [1] og [2]. Derefter har vi lavet en sammenligning af idealet med Enterprise Java Beans (EJB) ud fra EJB 2.1 specifikationen [3], og vurderet i hvilken grad hvert enkelt krav er opfyldt. Resultatet af vores sammenligning viser a,t EJB overlader flere centrale elemtenter til Contaioner Provideren, hvilket giver en usikkerhed om hvordan, hvis overhovedet, disse elemeter er implementeret. Dette medvirker til en forringelse af forudsigligheden af komponenter og sammensætninger. Rapportens læsere forventes at have kendskab til fagområdets begreber og anvendelser. 2 Indledning Vi vil forsøge at opstille et ideal for en distribueret komponentmodel, og derefter sammenligne dette ideal med Java EnterpriceBeans. Dette omfatter afklaring af de anvendte begreber, som vil ske med udgangspunkt i kursusmatrialet, jf. [1], [2]. Før vi begynder vores analyse og beskrivelse af den ideelle distribuerede komponentmodel, vil vi kort introducere de omgivelser, som modellen skal anvendes i, samt en vision for komponentbaseret softwareudvikling (CBSE), som tager udgangspunkt i den vision, der er defineret i [2]. 3 Komponentbaseret softwareudvikling Visionen for CBSE er fokuseret på, at man hurtigt skal kunne bygge applikationer af høj kvalitet; det vil sige med en forudsigelig adfærd. Det sker ved at komponere (compose) eksisterende softwarekomponenter (components), der er uafhængigt certificeret og købt på et åbent marked. Vi vil senere gå i dybden med definitionen af den ideelle softwarekomponent. Indledningsvist kan vi definere en komponent som et stykke software, der indkapsler funktionalitet bag en specificeret grænseflade. Økonomien i visionen er baseret på genbrugeligheden af komponenter. De relativt 4
5 høje omkostninger i forbindelse med udviklingen af en komponent, udjævnes af de meget lave reproduktionsomkostninger. Det er en markedsmodel vi kender fra blandt andet hardware- og medicinalindustrien. Markedsprisen for en komponent falder i takt med at flere køber den, og udviklingsomkostningerne bliver indtjent. Derved vil det, som hovedregel, være billigere at købe en komponent, frem for selv at udvikle den. I denne forbindelse er fleksibilitet prioriteret frem for ydelse. En softwarekomponent er udviklet i overensstemmelse med en specifik komponentmodel (component model). En komponentmodel er specifikationen af et rammeværk, hvori komponenter kan sættes sammen til en applikation. Et komponentrammeværk (component framework) er en implementation af en sådan komponentmodel. Således er Enterprise JavaBeans (EJB) en komponentmodel, hvor IBM WebSphere, BEA WebLogic og JBoss Application Server er eksempler på rammeværk, der implementerer modellen. En komponent, der er i overensstemmelse med komponentmodellen, vil kunne anvendes på et hvilket som helst rammeværk, der implementerer komponentmodellen. Komponenter og rammeværk kan certificeres af troværdige myndigheder, for at understøtte et åbent marked baseret på tillid til de udbudte komponenter. Certificering er vigtigt, da komponenter ofte handles uden indsigt i implementeringen, det vil sige uden kildekode og med begrænset dokumentation. Komponentmodellerne er almindeligvis lavet til en bestemt, men meget generelt formuleret, type af applikationer. Enterprise JavaBeans er eksempelvis udformet med forretningsapplikationer som fokus. Det, sammen med hensynet til den praktiske anvendelse gør, at der findes flere forskellige komponentmodeller med forskelligt fokus. Samtidigt findes der også flere komponentmodeller med samme fokus, eksempelvis EJB og Microsofts COM+. Vores fokus er primært på komponentmodeller til distribuerede applikationer generelt, men i forbindelse med beskrivelsen af hvilke specifikke services, en model bør stille til rådighed, rettes fokus mod forretningsapplikationer. 3.1 Vision På grund af markedsmekanismerne for et åbent komponentmarked, vil man kunne få komponenter væsentligt billigere end ved egen udvikling. Resultatet er hurtigere og billigere udvikling af applikationer med en høj grad af forudsigelighed, hvilket i software er lig 5
6 med kvalitet. Den hurtigere udvikling af applikationer giver kortere time-to-market. Det overfører de økonomiske fordele ved genbrug af enkelte komponenter til produktionen af komponentbaserede applikationer. Visionen kan opdeles i tre hovedpunkter: Hurtig sammensætning af komponenter og rammeværk Forudsigelse af egenskaber og adfærd Certificering af komponenter For at afgøre hvor vidt EJB lever op til visionen, vil vi i det følgende definere de vigtigste begreber og opstille ideal for komponenter og komponentmodellen. 4 Den idelle komponent Den idelle komponent er en tilstandsløs softwareenhed, der repræsenterer en proces. Komponenten interagerer med omverdenen via komponentmodellens grænseflader. Komponentens adfærd og funktioner specificeres i kontrakter og grænseflader. 4.1 Kontrakter En kontrakt specificerer forudsætningerne for, at en komponent fungerer efter hensigten (preconditions) samt, hvad klienten derpå kan forvente af komponenten (postconditions). Hvis kontrakten ændres, kræver det, at komponenten såvel som klienten godtager ændringen. Der er to typer kontrakter: Interaktionskontrakter, som specificerer gensidige forpligtelser mellem interfacetyper og komponentkontrakter, der specificerer interaktionsmønstre, der udgår fra komponenten. For at kunne sikre sammenlignelighed med andre komponenters kontrakter, skal komponentmodellen specificere, hvorledes interaktions- og komponentkontrakter specificeres. 4.2 Grænseflade En komponentgrænselade er en abstract beskrivelse af komponentens adfærd ift interaktioner med andre komponenter samt restriktioner ift. hvornår interaktionerne må ske. En 6
7 component understøtter en givent grænseflade, hvis komponenten indeholder en implementation af alle operationer, som definers af interfacet. Ved at benytte grænseflader, opnår man, at komponenter kan ændres internt, så længe, de bliver ved med at overholde grænsefladen. For at en komponent kan udskiftes med en anden, der implementerer samme grænseflade uden, at der skal foretages yderligere ændringer, er det et krav, at komponentmodellen skal specificere, hvorledes en grænseflade specificeres. 4.3 Navngivning For at sikre, at komponenterne og deres grænseflader i en komponentmodel entydigt kan identificeres, er et standardiseret navneskema en nødvendig del af en komponentmodel. 4.4 Interaktion standard Interaktionsstandarden er den del af kontrakten, der specificerer typen af kontekstafhængigheder, som en komponent kan have. En kontekstafhængighed handler om, at noget uden for komponenten skal være opfyldt. Det kan feks. være, at en ændring i en anden softewarekomponent vil medføre en ændring i den afhængige komponent. Det kan også betyde, at operativsystem, softwareelementer eller andre komponenter skal overholde givne krav, for at komponenten kan overholde sine forpligtelser. Komponentmodellen skal angive, hvordan kontekstafhængigheder angives og efterprøves. 4.5 Funktionelle og ikke-funktionelle krav Det skal være klart, hvilke funktionelle krav, der er til en komponent, og disse krav skal afspejles i komponentens interface. En komponent understøtter et provided interface, hvis komponenten indeholder en implementation af alle de operationer, der er defineret i det givne interface. En komponents påkrævede grænseflade (required interface) angiver hvilke typer af andre komponenter, som komponenten har brug for. Ikke-funktionelle krav kan feks være ydelsesspecifikationer til systemet, som komponenten kører på. Komponentmodellen skal derfor definere hvordan man angiver og efterprøver required og provided grænseflader 7
8 4.6 Komponentdokumentation Der kan i mange tilfælde være brug for mere dokumentation, end kontrakten og grænseflader stiller tilrådighed. Feks. kan forbrugeren i visse tilfælde have brug for at vide, hvilke forretningsregler og -processer, der benyttes uden at vide, hvordan de er implementeret feks. i form af UML-diagrammer eller usecases. Derfor vil det være ideelt, at komponentmodellen stiller krav til formel dokumentation. 4.7 Black-/whitebox Hvor vidt en komponent kun skal afleveres til consumeren i binært format, eller om komponentens kildekode skal medsendes, afhænger af flere ting. Som udgangspunkt vil en komponentproducent ofte have kommerciel interesse i at kildekoden holdes hemmelig, men på den anden side kan der også være sikkerhedsmæssige eller idealistiske interesser forbundet med at kildekoden ønskes tilføjet til pakken med softwarekomponenten. Hvis komponentforbrugeren feks. er en bank, kunne man forestille sig, at banken selv vil sikre sig, at de sikkerhedsmæssige foreskrifter rent faktisk overholdes. Hvis komponentproducuceren går ind for opensourceprodukter, kunne man ligeledes forestille sig, at han ønsker kildekoden medsendt. I praksis vil det nok oftes kun være det binære format, der udleveres, da det udover at beskytte komponentproducerens intellektuelle rettigheder også fylder mindre og hindrer, at en komponent kan misbruges ud fra en indsigt i komponentens implementation. Desuden er det ikke meningen, at forbrugeren skal lade noget afhænge af en implementation, der kan blive ændret når som helst. Meningen med en komponent er, at grænsefladen, indsættelsesbeskrivelsen (deployment description) og certificeringen skal være tilstrækkelig til at forudsige en komponents egenskaber, så forbrugeren ikke har brug for at beskæftige sig med komponentens implementation. Derfor er det vigtigt, at den idelle komponent kan pakkes i binært format. 5 Certificering Certificering af komponenter er essentielt for at kunne etablere tillid til et åbent marked, hvor komponenter kan handles og for at sikre forudsigeligheden af en given komposition jf. visionen for CBSE i afsnit 3.1. Certificeringen af en komponent betyder, at en kom- 8
9 ponent besidder anerkendte kvaliteter, og at måden hvorpå komponenterne interagerer i rammeværket, er garanteret i overensstemmelse med anerkendte metoder. Certificeringen kan omfatte funktionelle som ikke-funktionelle krav, herunder adfærd, operationel hastighed, dataintegritet mv. Vi skal ikke gå i dybten omkring selve certificeringsprocessen, men blot konstatere, at den bør udføres af en uafhængig tredjepart det vil sige hverken leverandøren eller kunden. Ideelt set vil en komponentmodel specificere hvorledes en komponentcertificering kan valideres og kræve, at et rammeværk automatisk validerer denne certificering ved indsættelse (deployment) af komponenten. En komponents certifikat kunne eksempelvis være den certificerende myndigheds digitale signatur af komponenten. Signaturen kan eksempelvis inkluderes i komponentens indsættelsesbeskrivelse. Et rammeværk kan også certificeres, i overensstemmelse med komponentmodellen. Det er med til at skabe et marked for forskellige implementationer af en komponentmodel og sikre, at en komposition giver samme adfærd, uanset hvilket certificerede rammeværk, der benyttes. Vi vil dog heller ikke beskæftige os med certificering af rammeværk, da det ligger uden for vores fokus. 5.1 Interoperabilitet Komponentmodellen bør afklare spørgsmålet om interoperabilitet mellem forskellige implementationer. Certificeringen bør sikre, at komponenter og rammeværk er implementeret i overensstemmelse med komponentmodellen. Dvs. at hvis komponenten virker på SUNs EJB-server, skal den også virke på IBM s EJB-server, eftersom de er underlagt samme komponentmodel. En distribueret komponentmodel må dertil sikre, at komponenter og komponentservere kan kommunikere på tværs af netværk. Derfor skal komponentmodellen specificere hvilke protokoller, der anvendes til kommunikation imellem frameworks. Ideelt bør der også være mulighed for at efterprøve interoperabilitet af et framework, eksempelvis mod en referenceimplementering. Konkurrerende komponentmodeller er ofte ikke fuldt kompatible, f.eks kan de som COM+ og EJB være udsprunget af forskellige problemstillinger. Af markedshensyn kunne man forestille sig at det er en fordel at specificere, hvordan der kan integreres med andre udvalgte komponentmodeller, men vi stiller ikke krav til den ideelle komponentmodel 9
10 om interoperabilitet med andre komponentmodeller. Til gengæld stiller vi krav til den idelle komponentmodel om, at komponenter skal kunne udvikles og afvikles uafhængigt af operativsystemer, programmeringssprog og rammeværk. 6 Indsættelse Indsættelse (deployment) er processen, der skal klargøre en komponent til at blive eksekveret. Dvs. det handler om, hvordan en component skal installers, konfigureres og registreres, og omfatter typisk tre trin installation, konfigurering og instantiering af komponenten, så den er klar til at kunne bruges. En indsættelsesbeskrivelse for en component skal indeholde oplysninger, der er nødvendige, for at en komponent kan tages i brug. Disse oplysninger skal benyttes af den komponentinfrastruktur, som komponenten indsættes i. Ved at lave indsættelsesstandarder, kan man minske en komponents omkostninger. En indsættelsesstandard (deployment standard) specificerer strukturen og semantikken for indsættelsesbeskrivelsen. Indsættelsesprocessen, der specificeres i en indsættelsesstandard, skal være defineret i komponentmodellen. Komponenttilpasning (customization) handler om forbrugerens evne til at tilpasse komponentens adfærd forud for dens installering og brug. Komponenter tilpasses vha. deres tilpasningsgrænseflade, idet komponenter ofte vil være blackbox-implementeringer. Tilpasningsgrænsefladen gør det muligt for tilpasnings- og indsættelsesredskaber at klargøre en komponent til et bestemt formål, og derfor bør den idelle komponent have en tilpasningsgrænseflade. 7 Sammensætning af komponenter I komponentbaserede systemer er sammensætning af komponenter en fundamental del. Udover at bygge systemer udelukkende bestående af komponter, er ideen også, at det er muligt at bygge nye komponenter ud fra allerede eksisterende komponenter. Disse ting bliver mulige via sammensætning af komponenter. Det, at to komponenter bliver sammensat betyder, at den ene komponents ressourcer bliver tilgængelige for den anden komponent, eller at ressourcerne bliver bundet til den anden komponent. 10
11 7.1 Sammensætningsformer Der er forskellige former for sammensætning, som en komponentmodel kan vælge at understøtte feks., at to komponenter kan sammensættes. Det, at modellen understøtter en sammensætning betyder, at der er defineret en standard kontrakt, som klart definere, hvordan en sammensætning skal foregå. Hvis en komponent ikke understøtter en bestemt form for sammensætning, betyder det, at udvikleren af en komponent er nødsaget til at lave nogle antagelser om, hvordan en senere sammensætning vil ske. Disse antagelser er nødvendige, da der ikke er en standard, som man kan være sikker på andre komponenter overholder. Dette betyder også, at der bliver lagt en begrænsning ind i sammensætningsmulighederne, som en komponent har, da den kun sammensættes med dem, som passer til antagelserne. Hvis komponentmodellen derimod understøtter en sammensætning, betyder det, at komponenter kan udvikles helt uafhængig af andre dele, og dermed skaber det mere uafhængighed mellem komponenterne og de andre dele i systemet. En understøttelse vil dog betyde, at modellen bliver mere kompleks,eftersom den skal definere flere standarder. I det følgende diskuteres de, ifølge Bachman [2], fem mest almindelige former for sammensætninger. Simpel sammensætning: To eller flere komponenter i samme rammeværk sættes sammen. Denne sammensætning er fundamentet i hele tankegangen om komponentbaserede systemer og skal derfor understøttes. Uensartet sammensætning: Komponenter i forskellige frameworks sættes sammen. Dette bruges bla. i forbindelse med distribuerede systemer. Da visionen er den ideelle distribuerede komponent model, må det antages at der vil forekomme en del af denne form for sammensætning. Dermed bør dette også understøttes. Rammeværksindsættelse: Et rammeværk kan sættes ind i et andet rammeværk. Et rammeværk kan optræde som komponenter og dermed sættes sammen med andre komponenter. Rammeværksudvidelse: Plugins, der kan udvide funktionaliteten af rammeværket. Komponent (sub assembly): Komponeter sammensættes til en ny komponent, som får en ny grænseflade således, at den fremstår som en ny komponent. Dette er en del af den beskrevne ide i starten af afsnittet, og derfor skal dette også understøttes. 11
12 Af hensyn til fleksibilitet vil vi stille som krav til den idelle komponentmodel, at den understøtter ovenstående sammensætninger pånær rammeværksudvidelse, fordi det indebærer en risiko for at der skabes afhængighed ift. plugins, der ikke er en del af komponentmodellen. 7.2 Tidspunkt for ressourcebinding I forbindelse med sammensætning er det også interessant at kigge på, hvornår bindingen af ressourcerne sker. Dvs. hvor vidt der allerede i udviklingsprocessen skal tages beslutninger om hvordan en evt. senere ressource binding skal ske. I denne forbindelse bruges begreberne sen og tidlig binding. Tidlig binding betyder, at beslutningen om en evt. binding allerede tages i udviklingsprocessen af en komponent. Dette kræver, at udvikleren i udviklingsprocessen sætter nogle begrænsninger for hvordan en senere binding vil ske. Dette kunne feks. være, at bindingen referere til et bestemt type grænseflade. Dvs. at bindingen senere kun vil kunne ske til komponenter, der implementere denne grænseflade. Dette er ret ufleksibelt og skaber afhængighed mellem komponenterne, der strider imod vores vision, og derfor vendes blikket nu mod sen binding. Ved sen binding sætter udvikleren ingen begrænsninger for en senere binding. Derimod kræver sen binding, at komponentmodellen stiller nogle krav til udviklingen af en komponent. Det kræver bla., at der er krav om, hvordan en komponent tydeliggør dens services. Disse ting medfører, at komponentmodellen bliver mere kompleks, da den skal definere flere standarder. Trods denne øgede kompleksitet i komponentmodellen er sen binding at foretrække, fordi den øger fleksibiliteten i forbindelse med komponentudskiftning, understøtter brug af tredjeparts komponenter og understøtter det nskede komponentmarked. Den idelle komponentmodel bør påtvinge sen binding ved at lade al kommunikation og ressourcebinding ske via rammeværket mhp at sikre fleksibilitet via løs kobling. 8 Vedligeholdelse og udskiftning af komponenter Vedligeholdelsesfasen kan være den længste i et systems livscyklus. Gennem denne periode kan der være behov for videreudvikling for at opfylde ændrede krav fra omverdenen eller for at udnytte nye og bedre muligheder. For forbrugeren foregår vedligeholdelsen af 12
13 dennes komponentbaserede system, ved at delkomponenter omkonfigureres dvs. opdateres, udskiftes eller fjernes, og denne omkonfigurering bør kunne ske uden skadelig konsekvens. Der vil derfor blive stillet krav om, at den idelle komponent understøtter versionering af komponenter, der sikrer bagudkompabilitet. Det skal klart fremgå, hvordan udskiftningen af versioner skal ske samt tillades, at det sker på et kørende system uden driftsafvigelser. 9 Component Services En distribueret komponentmodel bør ift. det potentielle marked indeholde en standardisering af køretidsomgivelser til støtte for eksekvering af dens komponenter. Generelt vil disse funktioner i en objektorienteret komponentmodel inkludere services til objekt oprettelse, håndtering af livscyklus for den enkelte komponent, persistens og af kommercielle hensyn også en form for licensstyring. Komponentmodeller der feks er distribuerede kan have nytte af services, der virker mellem fjernt beliggende servers til meddelelses-håndtering, notifikationer, lokalisering af services og sikkerhed. 9.1 Objektoprettelse og -tilstandslagring Selv om komponenterne selv er tilstandsløse, er det ikke usædvanligt, at de opererer med tilstandsfulde objekter. Det kan i en forretningsorienteret applikation eksempelvis være kunde- og fakturaobjekter. Udover at kunne læse objekternes tilstand, kan komponenterne have behov for at foretage ændringer i, og transaktioner over, et eller flere objekters tilstande. Nogle objekter refereres fra flere andre objekter. Eksempelvis kan et fakturaobjekt hentes fra det kontoobjekt, hvor det er bogført eller fra kundeobjektet som faktureres. Både af hensyn til dataintegriteten og af hensyn til systemets samlede ressourceforbrug, er det oplagt, at komponentmodellen tilbyder central håndtering af objektoprettelse og -lagring samt skrivelåse og transaktioner. Med central oprettelse af objekter (object creation), kan der sikres mod, at der er flere forskellige objekter, der repræsenterer samme data. Når en komponent skal bruge et bestemt objekt, vil det kunne få udleveret en reference til objektet fra den centrale service. Skal en anden komponent benytte samme objekt, vil den centrale service kunne udlevere 13
14 samme reference. Skal en komponent ændre i et objekts tilstand, må komponenten først opnå en skrivelås, således at der kun er én komponent, der kan ændre objektets tilstand ad gangen. Den centrale service skal facilitere objektlagring (object persistence), eventuelt via nedarving til objekterne. For at understøtte denne procedure, vil alle objekter have en unikt identifikation. Derudover skal denne service også håndtere nye objekter, som komponenterne opretter, eksempelvist oprettelse af et nyt fakturaobjekt. 9.2 Messaging / Event notification Messaging baseres på en kø, hvorfra modtagerkomponenten kan tage beskeder. Event notification går ud på, at en komponent kan abonnere på en anden komponents events. Komponentmodellen skal specificere, hvordan komponenter abonnerer på og udsender notifikationer. 9.3 Sikkerhed Sikkerhed kan være en service som komponentmodellen stiller til rådighed, og dermed behøver komponenterne ikke selv at implementerer sikkerhedsfunktionaliteten. Da sikkerhed er vigtig i distribuerede systemer, skal den ideelle model tilbyde en service, der regulerer adgang til delte komponenter. 10 Opsummering af krav Den idelle komponentmodel skal opfylde følgende krav, fordelt på krav til henholdsvis komponenter, rammeværk og kontrakter Komponenter Komponenter skal være tilstandsløse, jf. afs. 4. Komponentmodellen skal angive, hvordan kontekstafhængigheder angives og efterprøves, jf. afs Komponentmodellen skal definere, hvordan man angiver og efterprøver required og provided grænseflader, jf. afs
15 Komponenten skal kunne pakkes i binært format, jf. afs Komponentmodellen skal specificere, hvorledes en komponentcertificering kan valideres og kræve, at et rammeværk automatisk validerer denne certificering ved indsættelse af komponenten, jf. afs. 5. Komponenter skal kunne udvikles og afvikles uafhængigt af operativsystemer, programmeringssprog og rammeværk, jf. afs Komponentmodellen skal understøtte versionering af komponenter, der sikrer bagudkompabilitet, jf. afs. 8. Det skal klart fremgå, hvordan udskiftningen af versioner skal ske samt tillades, at det sker på et kørende system uden driftsafvigelser, jf. afs. 8. Komponentmodellen skal tilbyde en central oprettelse og lagring af objekter, jf. afs Komponentmodellen skal specificere, hvordan komponrnter abonnerer på og udsender notifikationer, jf. afs Komponentmodellen skal tilbyde en service, der regulerer adgang til komponenter, jf. afs Rammeværk Komponentmodellen skal specificere hvilke protokoller, der anvendes til kommunikation imellem frameworks, jf. afs Det bør være muligt at efterprøve interoperabilitet af et rammeværk eksempelvis mod en referenceimplementering, jf. afs Følgende komponentsammensætninger skal understøttes: Simpel, uensartet, rammeværksindsættelse og komponent(sub assembly), jf. afs. 7.1 Komponentmodellen bør påtvinge sen binding ved at lade al kommunikation og ressourcebinding ske via rammeværket mhp a.t sikre fleksibilitet via løs kobling, jf. afs
16 10.3 Kontrakter Komponentmodellen skal specificere, hvorledes interaktions- og komponentkontrakter specificeres, jf. afs Komponentmodellen skal specificere, hvorledes en grænseflade specificeres, jf. afs Komponentmodellen skal definere et navneskema for komponenter og grænseflader, jf. afs Komponentmodellen skal stille krav til formel dokumentation, jf. afs Indsættelsesprocessen og -beskrivelsen, der specificeres i en indsættelsesstandard, skal være defineret i komponentmodellen, jf. afs. 6. En komponent skal have en tilpasningsgrændseflade, jf. afs EJB sammenlignet med idealet I dette afsnit vil Enterprise JavaBeans version 2.1 blive vurderet i forhold til idealet, som opstillet i afsnit Komponent Komponenter skal være tilstandsløse EJB arbejder med tre typer af beans session, entity, og message-driven hvoraf kun session og message-driven beans er komponenter i vores terminologi. Entity-beans er tilstandsfulde data-objekter. Message-driven beans er per definition tilstandsløse, jf s. 51 [3]. Der findes to typer session beans: stateless og stateful. Begge er tilstandsløse i forhold til komponentdefinitionen, hvor tilstandsløshed betyder, at en komponent kan udskiftes med en anden uden datatab. En sådanne udskiftning kan dog ikke ske imens komponenten er i gang med at udføre en proces, fordi komponenten uundgåeligt vil have en midlertidig tilstand 1. Processen for en tilstandsfuld session bean rækker over flere metodekald fra samme 1 Hvor i processen, beregningen er nået, er en tilstand, men ofte vil beregningen også gøre brug af midlertidige variable. 16
17 klient, og under denne proces har komponenten en midlertidig tilstand. Det afgørende i forhold til komponentdefinitionen er, at tilstanden er midlertidig at tilstanden ikke skal gemmes over forskellige anvendelser af komponenten, hvorfor komponenten kan udskiftes mellem to processer uden datatab. Der er afvigelser i anvendelsen af begrebet komponent, men EJB-komponenter er tilstandsløse. :o) Komponentmodellen skal angive, hvordan kontekstafhængigheder angives og efterprøves En Bean får fat i sine kontekstafhængigheder via JNDI ENC. Indsætteren benytter redskaber, der stilles til rådighed af containeren til at skabe de kontekstreferencer, som er erklæret i indsættelsesbeskrivelsen, jf s. 440 [3]. Containeren kan evt. selv sørge for at efterprøve, om kontekstafhængigheder er opfyldt. Dermed specificerer komponentmodellen kun hvordan kontekstafhængigheder angives og ikke, hvordan de skal specificeres. :o Komponentmodellen skal definere, hvordan man angiver og efterprøver required og provided grænseflader I indsættelsesbeskrivelsen skal bean-leverandøren angive referencer til de home, remote og local grænseflader, der udgør komponentens udbudte (provided) grænseflade samt EJBreferencer til andre komponenter som komponenten er afhængig af (required), jf s [3]. Det er en manuel opgave at efterprøve, om eksterne afhængigheder er understøttet, eventuelt ved brug af værktøjer leveret fra rammeværksproducenten, og dermed er dette krav kun delvist opfyldt. :o Komponenten skal kunne pakkes i binært format I EJB skal en bean pakkes ind en jar fil (ejb-jar file) sammen med indsættelsesbeskrivelsen. Det fremgår af specifikationen, jf s 44 [3], at komponentmodellen kan håndtere beans, der er i byteformat, eftersom det ikke er nødvendigt, at genoversætte en bean, før den skal bruges. EJB opfylder altså kravet om, at komponenter kan pakkes binært. :o) 17
18 Komponentmodellen skal specificere, hvorledes en komponentcertificering kan valideres og kræve, at et rammeværk automatisk validerer denne certificering ved indsættelse af komponenten Komponentcertificering indgår ikke i specifikationen. :o( Komponenter skal kunne udvikles og afvikles uafhængigt af operativsystemer, programmeringssprog og rammeværk Det er et erklæret mål for EBJ-arkitekturen, at komponenter kan udvikles under et andet operativsystem, end hvor de afvikles, som følge af Java s Write Ones Run Anywhere filosofi, jf. 2.1 s.31 [3]. Dette binder dog også komponenter til Java programmeringssproget. Standardkomponenter, der udvikles i overensstemmelse med specifikationen vil kunne indsættes og afvikles på arbitrære EJB-rammeværk. Anvender komponenten services, udover de, der er defineret i specifikationen, og som er specifikke for et bestemt rammeværk, vil komponenten kun kunne afvikles på rammeværk der understøtter disse services, jf s. 44 [3]. :o Komponentmodellen skal understøtte versionering af komponenter, der sikrer bagudkompabilitet I specifikationen står der, at Container Provider en typisk sørger for at understøtte versionering af de installerede EJB-componenter, så de kan blive updateret uden at eksisterende klienter lider skade. Desuden stiller container en typisk redskaber til rådighed, der gør det muligt, at kontrollere og styre containeren og beans ne i containeren på kørselstidspunktet jf s. 38 [3]. Ansvaret for versionering er dermed lagt ud til containeren, i stedet for at ansvaret varetages af modellen. Hvis der ikke er versionsstyring, er bagudkompatibilitet heller ikke sikret. :o( 18
19 11.2 Rammeværk Komponentmodellen skal specificere hvilke protokoller, der anvendes til kommunikation imellem rammeværker Specifikationen kræver, at en container skal implementerer adgang via Java Remote Method Invocation (Java RMI), og at dette skal ske indenfor begrænsninger der sikrer kompatibilitet med CORBA s Internet Inter Orb Protocol (IIOP), jf s. 413 og 416 [3]. :o) Det bør være muligt at efterprøve interoperabilitet af et framework, eksempelvis mod en referenceimplementering Sun Java System Application Server Platform Edition 8 og Java Application Verification Kit (AVK) stiller J2EE Reference Implementations verktøjer til rådighed, og EJB er derfor ideel på dette punkt, jf. [4]. :o) Følgende komponentsammensætninger skal understøttes: Simpel, uensartet, rammeværksindsættelse og komponent(sub assembly) Komponentsammensætning kan i EJB-arkitekturen ske før eller efter indsættelsen af komponenterne. Instruktioner om sammensætning noteres i indsættelsesbeskrivelsen for den samlede pakke, der indeholder de anvendte komponenter. I forbindelse med indsættelsen skal disse instruktioner manuelt fortolkes og anvendes, jf s. 36 [3]. Sammensætning sker således ved at sikre, at de påkrævede komponenter er tilstede og eventuelt specificere, hvilke specifikke implementationer, der skal anvendes. Der er ikke direkte specificeret mulighed for indsættelse af rammeværk, komponenter fra andre rammeværk eller komponent sub assembly. :o( Komponentmodellen bør påtvinge sen binding ved at lade al kommunikation og ressourcebinding ske via rammeværket mhp. at sikre fleksibilitet via løs kobling En EJB-komponent kan inkluderes i en samlet applikation uden, at der skal ændres i kildekoden, og uden at komponenten skal genoversættes, jf s. 44 [3]. Denne egenskab trækker i retningen af sen binding, der yderligere understøttes af, at indsættelsesbeskrivelsen refererer til grænseflader, som kan implementeres af vilkårlige komponenter, jf
20 s. 447 [3]. Al kommunikationen mellem komponenter sker via rammeværket dvs containeren, og komponentmodellen er derfor ideel ift. at understøtte sen binding. :o) Det skal klart fremgå, hvordan udskiftningen af versioner skal ske samt tillades, at det sker på et kørende system uden driftsafvigelser Ansvaret for udskiftning af komponenter på et kørende system er i specifikationen givet videre til container-leverandøren, jf s. 38 [3]), og komponentmodellen understøtter dermed ikke dette ideal. :o( Komponentmodellen skal tilbyde en central oprettelse og lagring af objekter EJB tilbyder en central container-managed service til oprettelse og lagring af entity beans. Kravene til objekterne og servicen er veldefineret i en kontrakt i specifikationen, jf. 10. s. 141 [3]. :o) Komponentmodellen skal specificere, hvordan komponenter abonnerer på og udsender notifikationer Specifikationen kræver, at en EJB-container skal give adgang til Java Message Service 1.1 (JMS), og denne J2EE-service understøtter såvel beskedhåndtering, som notifikationer mellem løst koblede komponenter, jf s. 568 [3]. :o) Komponentmodellen skal tilbyde en service, der regulerer adgang til komponenter EJB har program- og indsættelsesgrænseflader, der lader komponentenudvikleren referere til ressourcer vha. resource manager connection factory references (rmcf-referencer). Rmcfreferencerne bindes til den egentlige rmcf, der er et objekt. Dette objekt er konfigureret i containeren og benyttes til at oprette forbindelser til en ressource-manager. Rmcf-referencer skal erklæres i indsættelsesbeskrivelsen. For at tilgå ressourcer skal komponentudvikleren lave en rmcf-reference i komponenten. Vha. JNDI-grænsefladen findes rmcf-objektet, og derefter kaldes en metode i rmcf en mhp. at få oprettet en forbindelse til ressourcen. Som udgangspunkt kan flere komponenter dele adgang til en ressource manager, men komponentudvikleren kan ændre en værdi i indsættelsesbeskrivelsen, så adgangen ikke kan deles. 20
21 Komponentudvikleren kan vælge imellem to typer ressourcestyringsautentifikation, der enten giver indsætteren lov til at sætte sign-on informationen op eller lader komponenten gøre det selv. Containeren skal stille værktøjer til rådighed, så indsætteren bla. kan specificere bruger- og passwordinformation for de komponenter, der må benytte grænsefladen, jf [3]. Sammensætteren af komponenterne må definere security roles vha. method permissions, der defineres for hver security role i indsættelsesbeskrivelsen. jf [3]. Rmcf er en service, der regulerer adgangen til ressourcer, og dermed lever EJB op til idealet. :o) 11.3 Kontrakter Komponentmodellen skal specificere, hvorledes interaktions- og komponentkontrakter specificeres EJB arbejder med to former for kontrakter: komponentkontrakter og client-view-kontrakter. Komponentkontrakten er en kontrakt mellem bean og container. Den udfylder samme rolle som den i idealet beskrevne komponentkontrakt. I EJB specifikationen, jf [3], bliver det klart specificeret, hvilke krav som komponentkontrakten skal opfylde. Client-view-kontrakten er en kontakt mellem en klient og en container. Den beskriver bla. de grænseflader, som en given bean i containeren har, og som en klient kan benytte. Da al interaktion til og fra beans går igennem containeren, specificerer clientview-kontrakten, hvorledes interaktionen foregår, og dermed er en client-view kontrakt en interaktionskontakt. EJB specificerer i specifikationen, jf [3], hvilke elementer, som kontrakten skal indeholde bla. hvilke grænseflader, der skal angives, og hvad grænsefladerne skal definere. På den måde er det specificeret, hvordan en interaktionskontakt specificeres. Ud fra ovenstående må det konkluderes, at EJB opfylder kravet om, at komponentmodellen skal specificere, hvorledes interaktions- og komponentkontrakter specificeres. :o) Komponentmodellen skal specificere, hvorledes en grænseflade specificeres En bean skal udvide og implementere grundlæggende grænseflader, som er defineret af standarden. Beans har home- og remotegrænseflader, jf s [3]. Home-grænsefladen definerer metoder til at oprette, fjerne og finde objekter. Home-grænsefladen specificeres af komponentudvikleren, og containeren opretter en klasse, der implementerer Home- 21
22 grænsefladen. En komponent, der har remote klienter stiller en remote Home-grænseflade til rådighed, som udvider javax.ejb.ejbhome-grænseflade og komponenter, der har lokale klienter stiller en LocalHome grænseflade til rådighed, der udvider javax.ejb.ejblocalhomegrænsefladen. Session beans og Entity beans skal implementere container callbacks ne, der er defineret i hhv. javax.ejb.sessionbean-grænsefladen og i javax.ejb.entitybeangrænsefladen, jf s. 47 [3]. EJB specificerer dermed i høj grad, hvordan en grænseflade skal specificeres. :o) Komponentmodellen skal definere et navneskema for komponenter og grænseflader EJB anvender en standard navngivning til identifikation af komponenter og grænseflader, Java Naming and Directory Interface (JNDI), jf. s. 46 og 86 [3]. :o) Komponentmodellen skal stille krav til formel dokumentation EJB kræver ikke, at en komponent skal ledsages af dokumentation. Specifikationen giver ej heller anbefalinger for, hvilken formel dokumentation en komponent kan indeholde. :o( Indsættelsesprocessen og -beskrivelsen, der specificeres i en Indsættelsesstandard, skal være defineret i komponentmodellen I følge EJB specifikationen, jf [3], sker indsættelsen vha. redskaber som containeren stiller til rådighed. Dermed er indsættelsesprocessen ikke klart defineret i selve modellen, men er blevet lagt ud til containeren at definere. Ud fra dette kan det konkluderes at EJB ikke opfylder kravet, om at indsættelsesprocessen skal være defineret i modellen. Derimod opfyldes kravet om, at en indsættelsesbeskrivelse er klart defineret i modellen. Dette gøres ved at EJB har en indsættelsesbeskrivelse, hvor det i specificationen er klart defineret, hvad den skal indeholde, jf. 23 [3]. :o En komponent skal have en tilpasningsgrændseflade Tilpasning af komponenter sker via redskaber stillet til rådighed af containeren, jf [3]. Dermed har en komponent ikke en tilpasningsgrænseflade, som er defineret i modellen og kravet er derfor ikke opfyldt. :o( 22
23 12 Konklusion I forhold til vores ideal for komponentmodeller har EJB en række udvikingspunkter. Flere centrale elementer er udeladt af specifikationen og overladt til Container Provideren at implementere. Dette gælder eksempelvist redskaber til efterprøvninger af komponenternes resourceafhængigheder. I forbindelse med indsættelse og udskiftning af komponenter er processen ikke specificeret, og der er ikke understøttelse af versionering, hvilket samlet giver en dårlig life-cycle management af komponenter. Et af de centrale emner i visionen for komponentbaseret softwareudvikling er certificering af komponenter et emne der er helt udeladt i specifikationen. Dertil kommer, at der ikke stilles krav til formel dokumentation af komponenter, hvilket resulterer i et upålideligt komponentmarked. Mulighederne for forskellige sammensætninger og abstraheringer over sammensætninger er meget begrænsede, og tilpasning af komponenter skal ske via properitære redskaber som Container Provideren skal levere. Disse mangler viser at EJB ikke kan indfri visionen for komponentbaseret softwareudvikling, som fremstillet i afsnit 3.1. Manglerne hæmmer udviklingen af et marked for genbrugelige komponenter og svækker mulighederne for hurtigt at lave forudsigelige og rammeværksuafhængige sammensætninger. 23
24 Litteratur [1] William T. Councill George T. Heineman. Component-Based Software Engineering Putting the Pieces Together. Addison-Wesley, [2] Charles Buhman Santiago Comella-Dorda Fred Long John Robert Robert Seacord Felix Bachman, Len Bass and Kurt Wallnau. Volume II: Technical Concepts of component- Based Software Engineering. Carnegie Mellon Software Engineering Institute, [3] Linda G. DeMichiel. Enterprice JavaBeans Specification, Version 2.1. Sun Microsystems., November Kan ses på nettet på [4] Linda G. DeMichiel. Enterprice JavaBeans Fundamentals. Sun Microsystems, March Kan ses på nettet på 24
Service Orienteret Arkitektur
Service Orienteret Arkitektur Datalogisk Institut 22. november 2004 v/ Vidensleverandør Henrik Hvid Jensen, SOA Network henrikhvid@soanetwork.dk (c) SOA Network, 2004 1 Indførelse af et servicelag (c)
Læs mereLEVERANCE 1.3. Model for kvalitetssikring
LEVERANCE 1.3 Model for kvalitetssikring Udarbejdelse af kvalitetssikringsmodel, krav til open source kode og dokumentation og godkendelsesprocedurer m.v. Samt fokus på understøttelse af CE-mærkning. 1
Læs mereArkitektur for begyndere
Denne guide er oprindeligt udgivet på Eksperten.dk Arkitektur for begyndere Denne artikel beskriver forskellige basale n-tier arkitekturer. Som man bør kende og have valgt inden man går igang med at udvikle
Læs mereKoncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele
LEVERANCE 2.1 Koncept for systemforvaltning af den fælles open source kode, herunder procedure for opfølgning på software-versioner af OpenTele Konceptet beskriver, hvordan koden forvaltes, og hvordan
Læs mereEG Data Inform. Byggebasen. WCF og webservices. Jens Karsø
EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...
Læs mereEA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:
Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor
Læs mereSmartFraming Et vindue til nationale sundhedssystemer. Version 3.0
SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med
Læs mereVersion Dato Beskrivelse 1.0.0 26/11/2012 Initial version 1.2.0 05/03/2013 Tilføjet eksempel med Template Agent, generelt udvidet dokumentet.
MOX og APOS2 Forord Dette dokument er en del af APOS version 2 manualerne. APOS version 2 (APOS2 herefter) er et organisation, klassifikation og personale system baseret på Sag & Dokument standarderne.
Læs mereIt arkitektur- og sikkerhedskrav Løn og personalesystemsudbud. Region Midtjylland 2010.
It arkitektur- og sikkerhedskrav Løn og personalesystemsudbud Region Midtjylland 2010. 1 1 Indledning 1.1 Versionshistorie Version Dato Ansvarlig Status Beskrivelse 1.0 2010-05-04 HENSTI Lukket Definition
Læs mereIT-Basecamp 2013. Real World Java EE Patterns Adam Bien. Real World Java EE Patterns, Adam Bien Copyright Lund&Bendsen A/S
IT-Basecamp 2013 Real World Java EE Patterns Adam Bien 1 Indhold Lidt om mig Baggrund for valg af emnet Bogens opbygning Fra J2EE til JEE 5/6 Overflødiggjorte patterns Fremhæve et par patterns 2 Kenneth
Læs mereUnderbilag 14 C: Afprøvningsforskrifter til prøver og tests
Underbilag 14 C: Afprøvningsforskrifter til prøver tests Udbud om levering, installation, implementering, support, drift vedligehold af Borgeradministrativt System (BAS) Indhold underbilag 14 C Afprøvningsforskrifter
Læs mereTDCs Signaturserver. 11/05 - Version 1.0 2005 TDC Erhverv Sikkerhed og certifikater
TDCs Signaturserver Side 2 Indhold Indledning...3 Teknisk projekt... 3 Tekniske forudsætninger... 3 Installation af klienten... 4 Udstedelse af signatur... 4 Anvendelse af signaturen... 6 Eksport af signaturen...
Læs mereCitrix CSP og Certificate Store Provider
Project Name Document Title TDC Citrix Citrix og Certificate Store Provider Version Number 1.0 Status Release Author jkj Date 5-10-2006 Trademarks All brand names and product names are trademarks or registered
Læs mereWeb services i brug. Anvendelse uden for biblioteksverdenen
Web services i brug Anvendelse uden for biblioteksverdenen Agenda Visionen bag webservices Tre cases Et kig fremad Nordija Etableret i marts 1998 Udviklingsprojekter Forretningskritiske applikationer Komponenter
Læs mereKURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB
KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål
Læs mereIKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION
DATO DOKUMENT SAGSBEHANDLER MAIL TELEFON 5. december 2016 16/10604-1 Tina Jonsen tjon@vd.dk +45 7244 2220 IKT TEKNISK KOMMUNIKATIONS- SPECIFIKATION Thomas Helsteds Vej 11 8660 Skanderborg vd@vd.dk EAN
Læs mereKrav og vejledning til kommunernes fremtidige it-udbud
Klik her for at angive tekst. Krav og vejledning til kommunernes fremtidige it-udbud I forbindelse med det forestående monopolbrud udarbejder KOMBIT i samarbejde med kommunerne en trin-for-trin drejebog,
Læs mereKapitel 21: Softwarearkitektur designprincipper
Kapitel 21: Softwarearkitektur designprincipper Miriam Tang Jacob Jensen Lars Christensen Jacob Atzen Onsdag 9/3 Dagens program Definitioner Analyseværktøjer Designprocessen Raffinering Afrunding Design
Læs mereApp til indmelding af glemt check ud
App koncept til indmelding af glemt check ud App til indmelding af glemt check ud 5. mar. 2015 Side 1 App koncept til indmelding af glemt check ud 1 Introduktion Flg. er en besvarelse til en idekonkurrence
Læs mereBilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer)
Klik her for at angive tekst. Bilag 4: Udkast til kommunal drejebog for Serviceplatformen (Hører til dagsordenspunkt 9: Krav og vejledninger til kommunernes kravspecifikationer) Krav og vejledning til
Læs mereUnderstøttelse af LSS til NemID i organisationen
Understøttelse af LSS til NemID i organisationen Table of contents 1 Dette dokuments formål og målgruppe... 3 2 Introduktion til LSS til NemID... 4 2.1 Forudsætninger hos organisationen... 5 2.1.1 SSL
Læs mereServiceorienteret Arkitektur
Serviceorienteret Arkitektur Seniorkonsulent, forfatter og Ekstern Konsulent Henrik Hvid Jensen Enterprise Architecture, Dansk IT, København 1. juni 2006 C O N N E C T I N G B U S I N E S S & T E C H N
Læs mereRibe Amts forslag til EPJ-arkitektur
EPJ og integration: Ribe Amts forslag til EPJ-arkitektur Esben Dalsgaard IT-leder, Sundhedsområdet, Ribe Amt eda@ribeamt.dk Problemstillinger - set fra en datalogisk-arkitektonisk synsvinkel 2-delt arkitektur
Læs mereAssignment #5 Toolbox Contract
Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal
Læs mereBAT Installationsvejledning. Version 1.0
BAT Installationsvejledning Version 1.0 Oktober 2013 1 BAT Installationsvejledning Indledning Denne vejledning er rettet til den IT ansvarlige på de uddannelsessteder, der skal anvende BAT systemet. Vejledningen
Læs mereSOSIGW. - Driftsvejledning for SOSIGW 1.0. Indeks
SOSIGW - Driftsvejledning for SOSIGW 1.0 Indeks Indeks... 1 Revisionshistorik... 2 Introduktion... 2 Kontrol af korrekt driftstilstand... 2 Ændring af statisk konfiguration... 2 Logfil... 2 Backup... 3
Læs mereErhvervserfaring 2000 - Senior IT Specialist, IBM 1995 2000 Systemudvikler, Dan Net 1987 1995 Systemudvikler, KMD
Personlige data Navn: Kurt Koch Nielsen Adresse: Holmeås 8, 2670 Greve Telefon hjem: +45 43 90 50 75 Telefon mobil: +45 28 80 94 17 E-mail: kurt@kochnielsen.dk Fødselsdato: 19-02-1967 Civilstand: Gift,
Læs mereTræningsmodulIII. EPC Processen fra kontrakt til garanterede besparelser. Projekt Transparense. www.transparense.eu
TræningsmodulIII. EPC Processen fra kontrakt til garanterede besparelser Projekt Transparense EPC processen Overblik over hovedfaser Klient Beslutning om EPC Kontrakt Implementering af andre foranstaltninger
Læs mereKulturministeriets it-arkitekturpolitik
Kulturministeriets Kulturministeriets Januar 2012 Udgivet af Kulturministeriet Udarbejdet af Kulturstyrelsen H.C. Andersens Boulevard 2 1553 København V www.kulturstyrelsen.dk post@kulturstyrelsen.dk Kulturministeriets
Læs mereNEMID MED ROBOTTER. Muligheder samt en anbefaling til at løse NemID-opgaver med robotter
NEMID MED ROBOTTER Muligheder samt en anbefaling til at løse NemID-opgaver med robotter 1 En softwarerobot må ikke handle på vegne af et menneske med vedkommendes NemID. Men hvilke andre muligheder er
Læs mere1 Ordliste 2. 2 Indledning 3 2.1 Problemstillinger... 3 2.2 Problemformulering... 4 2.3 Problemafgrænsning... 4 2.4 Mål med projektet...
Indhold 1 Ordliste 2 2 Indledning 3 2.1 Problemstillinger.................................. 3 2.2 Problemformulering................................ 4 2.3 Problemafgrænsning................................
Læs mereIntroduktion til MeMo
Introduktion til MeMo 1. februar 2019 CIU I forbindelse med Digitaliseringsstyrelsens udbud af Næste generation Digital Post løsningen (NgDP) er der udviklet en ny model for udveksling af digitale postmeddelelser,
Læs merespørgsmål til CATIA 3DEXPERIENCE on the Cloud
30 spørgsmål til CATIA 3DEXPERIENCE on the Cloud 1) Hvad er CATIA 3DEXPERIENCE on the Cloud? Dassault Systèmes har investeret betydelige ressourcer i at udvikle en Cloud platform til Product Lifecycle
Læs mereVersion 1.0. Vilkår for brug af Støttesystemet Adgangsstyring
Version 1.0 Vilkår for brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående monopolbrud konkurrenceudsætter KOMBIT
Læs mereGuide til kravspecifikation
Side 1 af 10 10. november 2008 Guide til kravspecifikation Version 1.0. Denne guide indeholder en række råd til brug i kravspecifikationer for IT systemer, der skal anvende NemLog-in løsningen. Hensigten
Læs mereIT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007
IT- og Telestyrelsen 21. august 2007 Sagsnr. 032071-2007 Holsteinsgade 63 2100 København Ø Att. Palle Aagaard FESD Grænseflade til CMS-løsninger, høringssvar fra Gentofte Kommune Gentofte Kommune har med
Læs mereCivilstyrelsen. Lex Dania editor 2010. Installationsvejledning. Version: 1.0 2012-03-09
Installationsvejledning Version: 1.0 2012-03-09 Indhold 1 INDLEDNING... 3 1.1 HVAD ER LEX DANIA EDITOR 2010?... 3 1.2 FORUDSÆTNINGER FOR ANVENDELSE... 3 1.2.1 Hardware... 3 1.2.2 Software... 3 1.3 DISTRIBUTION
Læs mereDOKUMENTBROKER Koncept
DOKUMENTBROKER Koncept Copyright 2012 INDHOLDSFORTEGNELSE 1 Hvad er DokumentBrokeren?...1 1.1 Formål...1 1.2 Fordele...1 1.3 Baggrund...2 2 Komponenter...3 2.1 Dataflet...4 2.2 Platform og teknologi...4
Læs mereDokumentet/dokumenter der kommenteres på: Fælles retningslinjer for webservices. Organisationen der kommenterer: SKAT - Løsningsarkitektur og Test
Kommenteringsskema 15. januar 2018 Sekretariatet for Initiativ 8.1. BEMÆRK: Alle indsendte kommentarer offentliggøres (på arkitektur.digst.dk). Såfremt du ikke ønsker en kommentar offentliggjort, bedes
Læs mereVejledning i opsætning af MQ
NemKonto KMD Lauritzens Plads 1 9000 Aalborg www.nemkonto.dk support@nemkonto.dk Vejledning i opsætning af MQ 20-11-2008 Side 1 Økonomistyrelsen er ansvarlig for NemKonto, som udvikles af KMD Beskrivelse
Læs mere3D matriklen i et fremtidsperspektiv
3D matriklen i et fremtidsperspektiv Lars Bodum Center for 3D GeoInformation Aalborg Universitet Esben Munk Sørensen Land Management Aalborg Universitet Hvad er problemet? Vi diskuterer mange gange løsninger
Læs mereHillerød Kommune. It-sikkerhedspolitik Bilag 9. Udvikling, anskaffelse og vedligeholdelse
It-sikkerhedspolitik Bilag 9 November 2004 Indholdsfortegnelse 1 Formål...3 2 Ansvar og roller...3 2.1 Byrådet...3 2.2 Kommunaldirektøren/ Direktionen...3 2.3 Ledere, fagchefer mv...3 2.4 It gruppen, It
Læs mere1. Release- og Versioneringsstrategi for Serviceplatformen og services
7. januar 2014. Serviceplatformen 1. Release- og Versioneringsstrategi for Serviceplatformen og services Nærværende notat beskriver Serviceplatformens Release- og Versioneringsstrategier. Formålet med
Læs merePID2000 Archive Service
PROLON CONTROL SYSTEMS Herstedvesterstræde 56 DK-2620 Albertslund Danmark Tlf.: (+45) 43620625 Fax: (+45) 43623125 PID2000 Archive Service Bruger vejledning Juni 2002 Denne manual beskriver brugen af softwaren
Læs mereKontraktbilag 5 Spørgsmål og svar til udbudsmaterialet
Sagsnr. -23-4-82--3 Kontraktbilag 5 Spørgsmål og svar til udbudsmaterialet Spørgsmål og svar vedrørende UDBUDSMATERIALET (Indsæt selv ekstra rækker efter behov, men behold venligst systematikken): HUSK
Læs mereSYSTEMDOKUMENTATION AF POC
DIGITALISERINGSSTYRELSEN POC PÅ ORKESTRERINGSKOMPONENTEN SYSTEMDOKUMENTATION AF POC Version: 1.1 Status: Endelig Godkender: Forfatter: Copyright 2019 Netcompany. All rights reserved Dokumenthistorik Version
Læs mereInstallationsvejledning SAS Foundation 9.2 SAS Enterprise Guide 4.2. Windows Vista
Installationsvejledning SAS Foundation 9.2 SAS Enterprise Guide 4.2 Windows Vista Oversigt Inden installationen... 3 Udpakning af softwaren... 4 Kopiér licensen ind... 6 Installationen... 7 Yderligere
Læs mereUndgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur
Side 1 af 5 Vejledning 2. august 2013 NITRI Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Indholdsfortegnelse Formål...2 Virksomhedssignatur...2 Funktionssignatur...3
Læs mereWHITEPAPER DokumentBroker
WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,
Læs mereProduktbeskrivelse for
Produktbeskrivelse for Service til opfølgning på behandlingsrelationer NSP Opsamling Tjenesteudbyder Opfølgning Notifikation Side 1 af 7 Version Dato Ansvarlig Kommentarer 1.0 22-12-2011 JRI Final review
Læs mereProgram for møde fredag d. 22/2-2002
Program for møde fredag d. 22/2-2002 Disposition for den indledende præsentation af problemstillinger Kort beskrivelse af projektets struktur, hvilket leder frem til hovedtemaet for den efterfølgende diskussion
Læs mereVigtig Release Information Udfasning af TLS 1.0 kryptering i Connect-løsningen
11.10.2018 Vigtig Release Information Udfasning af TLS 1.0 kryptering i Connect-løsningen Version 1 VIGTIG INFORMATION VEDR. CONNECT Denne information bør tilgå IT-afdelinger samt enkeltbrugere af Connect.
Læs mereKRAV TIL INFRASTRUKTUR
KRAV TIL INFRASTRUKTUR VERSION 4.2.8 SEPTEMBER 2015 Indholdsfortegnelse 1 Generelt... 1 2 Servermæssige krav til -modulerne... 1 2.1 Systemmæssige krav i servermiljø... 1 2.2 Hardwaremæssige krav i servermiljø...
Læs mereMindstekrav til udstyr (fase 1) Løsningsbeskrivelse
Mindstekrav til udstyr (fase 1) Løsningsbeskrivelse Indholdsfortegnelse 3.1 INDLEDNING 2 3.2 MINDSTEKRAV TIL SLUTBRUGERNES KLIENTER MV 2 3.2.1 Mindstekrav til hardware for PC-klienter 2 3.2.2 Mindstekrav
Læs mereKursusgang 11. Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing
Kursusgang 11 Oversigt: Sidste kursusgang Værktøjer til udvikling og implementering af HCI-design Oversigt over Java Swing Design af brugerflader 11.1 Samme sted Forskellige steder Sidste kursusgang Samtidigt
Læs mereKontrakt om Drift, Videreudvikling, Support af tilskuds- og kontroladministrative. Bilag 9 Dokumentation
Kontrakt om Drift, Videreudvikling, Vedligeholdelse og Support af tilskuds- og kontroladministrative systemer m.fl. Bilag 9 Dokumentation 16. marts 2018 Version 1.0 Side 1/8 [Vejledning til tilbudsgiver:
Læs mereComponent based software enginering Diku 2005 Kritikopgave
Component based software enginering Diku 2005 Kritikopgave Nicolas Møller Henschel 17. april 2005 1 Indhold 1 Indledning 3 2 Indhold 3 2.1 Introduktionen.......................... 3 2.1.1 Mangler..........................
Læs mereObjektorientering. Programkvalitet
1 PROSA-Bladet nr. 4 1993 Objektorientering = Programkvalitet? Af Finn Nordbjerg, adjunkt ved Datamatikeruddannelsen, Aalborg Handelskole 1. Indledning Objektorientering er blevet et edb-fagets mest udbredte
Læs mereEfficient Position Updating
Efficient Position Updating Pervasive Positioning, Q3 2010 Lasse H. Rasmussen, 20097778 Christian Jensen, 20097781 12-03-2010 1 Introduktion Denne rapport har til formål at beskrive implementeringen og
Læs mereVersion 8.0. BullGuard. Backup
Version 8.0 BullGuard Backup 0GB 1 2 INSTALLATIONSVEJLEDNING WINDOWS VISTA, XP & 2000 (BULLGUARD 8.0) 1 Luk alle åbne programmer, bortset fra Windows. 2 3 Følg instrukserne på skærmen for at installere
Læs mereSikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded
Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering
Læs mereForskellige Java versioner
Denne guide er oprindeligt udgivet på Eksperten.dk Forskellige Java versioner Denne artikel beskriver lidt om de forskellige Java versioner. Den forklarer J2SE/J2ME/J2EE, plugin/jre/sdk og Sun Java/Microsoft
Læs mereLUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09
LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,
Læs mereDM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort. Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267
DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267 December 17, 2009 3.1 Valg at brugsmønster til udvidelse
Læs mereADIS, WS og Meta Service
ADIS, WS og Meta Service Om ADIS, Web Services, Værktøjer og Meta Service. Michael Jacobsen Technology Network Management Agenda ADIS og dens udvidelse ISOagriNET Web Service med eller uden fuldt objektmodel
Læs mereIntroduktion. Jan Brown Maj, 2010
Jan Brown Maj, 2010 Introduktion OIOXML har eksisteret som det centrale datastandardiseringsparadigme siden 2002. Til OIOXML-konceptet er der et regelsæt betegnet OIO Navngivnings- og Deignregler (NDR),
Læs mereISO 9001:2015 OG ISO 14001:2015 NYE VERSIONER AF STANDARDERNE ER PÅ VEJ ER DU KLAR? Move Forward with Confidence
ISO 9001:2015 OG ISO 14001:2015 NYE VERSIONER AF STANDARDERNE ER PÅ VEJ ER DU KLAR? Move Forward with Confidence HVORFOR 2015 REVISIONEN? I en verden hvor de økonomiske, teknologiske og miljømæssige udfordringer
Læs mereTM Sund. NemSMS/Digital Post brugervejledning. TM Care a/s Niels Hemmingsens Gade 9, København K
TM Sund NemSMS/Digital Post brugervejledning TM Care a/s Indhold TM Care a/s... 1 Indhold... 2 NemSMS / Digital Post generelt... 3 Opsætning af standardmodtagere... 4 Afsendelse af NemSMS / Digital Post...
Læs mereStandardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners
Standardiseret tilgang til Software Asset Management ISO19770 ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners 1 WG21 historien ISO19770 arbejder i WG21 under ISO Etableret i 2001 Første standard 19770-1
Læs mereAftale om serverhosting
Version: 3.0125 - d. 25. januar 2013 Aftale om serverhosting mellem Kunde (Herefter kaldet kunden) Adresse Post og by CVR: xxxx xxxx Wannafind.dk A/S (Herefter kaldet leverandøren) Danmarksvej 26 8660
Læs mereBilag 15 Leverandørkoordinering
Bilag 15 Leverandørkoordinering Version 0.8 26-06-2015 Indhold 1 VEJLEDNING TIL TILBUDSGIVER... 2 2 INDLEDNING... 3 3 LEVERANDØRENS ANSVAR... 4 4 LEVERANDØRENS KOORDINERINGS- OG SAMARBEJDSFORPLIGTELSE...
Læs mereBeskyttelsen af edb-programmer
Indledning Beskyttelsen af edb-programmer Definition af edb-program Pensum: Immaterialret, 1. udg, Schovsbo og Rosenmeier En række instruktioner eller oplysninger, fikseret i en hvilken som helst form
Læs mereUnderbilag 2.24 Kommunernes it-miljø
Underbilag 2.24 Kommunernes it-miljø Indholdsfortegnelse Vejledning... 3 1 Indledning... 3 2 Sagsbehandling Klientmiljø... 3 2.1 Operativsystem... 3 2.2 Browser... 5 2.3 Runtime Miljøer... 6 2.4 Fysiske
Læs mereForms Composer. Document Producer 1. Document Producer
1 I Lexmark TM, version 3.1, kombineres softwaren til udformning af e-formularer med et serverprogram for e-formularer. Du kan nu oprette dine egne formularer og kombinere dem med scripts og på den måde
Læs mereKOMBIT Byg og Miljø FAQ. Byg og Miljø. Version 1.1 24. januar 2014 BHE
KOMBIT Byg og Miljø FAQ Byg og Miljø Version 1.1 24. januar 2014 BHE Indhold Login og rettigheder... 3 Aktiviteter, sager, projekter... 4 Regler... 5 Proces... 6 Kommunikation... 7 Filer... 8 Integration
Læs mere132-400 kv AC Station. Kontrolanlæg Relæbeskyttelse. Dataudveksling med SIMEAS SAFIR. ETS-52-01-04 Rev. 1
132-400 kv AC Station Kontrolanlæg Relæbeskyttelse Dataudveksling med SIMEAS SAFIR ETS-52-01-04 Rev. 1 teknisk standard Dokument nr. 60386/10, sag 10/5371 - ETS-52-01-04 v. 0 1/10 REVISIONSOVERSIGT Dokumentnummer:
Læs mereObjects First with Java A Practical Introduction Using BlueJ
Objects First with Java A Practical Introduction Using BlueJ En introduktion til objektorienteret programmering for begyndere ud fra et software engineering aspekt Om at programmere i Java, ikke om værktøjet
Læs mere23. maj 2013Klik her for at angive tekst. HHK/KMJ. Vejledning til brug af Støttesystemet Adgangsstyring
23. maj 2013Klik her for at angive tekst. HHK/KMJ Vejledning til brug af Støttesystemet Adgangsstyring kombit@kombit.dk CVR 19 43 50 75 Side 1/10 1. Indledning og vejledning I forbindelse med det forestående
Læs mereAPPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright
APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR EG Copyright Infrastruktur er mere end nogle servere... Den Mentale Infrastruktur Den Fysiske Infrastruktur Den Mentale Infrastruktur Vi vil jo gerne have vores
Læs mereFESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø
FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har
Læs mereGuide til integration med NemLog-in / Signering
Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere
Læs mereKOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen.
1 2 KOMBIT er ejet af KL og kommunerne. Det er kommunerne, der via KL har bedt om udvikling af Byg og Miljø, og som betaler for løsningen. Det er frivilligt for kommuner at aftage systemet. Iht. den fælleskommunale
Læs mereIt-sikkerhedstekst ST9
It-sikkerhedstekst ST9 Single Sign-On og log-ud Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST9 Version 1 Juli 2015 Single Sign-On og log-ud Betegnelsen Single Sign-On (SSO)
Læs mereProcedurer for styring af softwarearkitektur og koordinering af udvikling
LEVERANCE 2.3 Procedurer for styring af softwarearkitektur og koordinering af udvikling Procedurerne vil omfatte: Planlægning af udfasning af gamle versioner af OpenTele Planlægning af modning af kode
Læs mereProducts Solutions Services. Nye muligheder, nye oplevelser. Personlig og digital. Mit Endress+Hauser.
Products Solutions Services Nye muligheder, nye oplevelser. Personlig og digital. Mit Endress+Hauser. Nye muligheder, nye oplevelser. Personlig og digital. Mit Endress+Hauser. 2 Nye New muligheder, possibilities,
Læs mereDM507 Algoritmer og datastrukturer
DM507 Algoritmer og datastrukturer Forår 2016 Projekt, del I Institut for matematik og datalogi Syddansk Universitet 29. februar, 2016 Dette projekt udleveres i tre dele. Hver del har sin deadline, således
Læs mereFremdrift og fælles byggeblokke
INDSATSOMRÅDE 5 Fremdrift og fælles byggeblokke Forudsætningen for at udvikle et mere nært, sammenhængende og effektivt sundhedsvæsen er at sammentænke digitale løsninger og bygge en fælles digital infrastruktur,
Læs mereINSPIRE og Geodata-info
INSPIRE og Geodata-info MapInfo Netværksmøde, 13 Oktober 2011 Anders Friis-Christensen Kort & Matrikelstyrelsen andfr@kms.dk Disposition INSPIRE Hvad er Geodata-info? Indhold, rolle og anvendelse Opsummering
Læs mereOIS - Applikationskatalog
OIS - Applikationskatalog OIS arkitekturprodukter 25. januar 2018 Indledning Dokumentationen omkring OIS er struktureret med inspiration fra OIO Arkitekturguidens arkitekturreol, således at arkitekturprodukterne
Læs mereContinia Collection Management Kom hurtigt i gang med CLC version 1.3
Continia Collection Management Kom hurtigt i gang med CLC version 1.3 1 Baggrundshistorie for skift af CLC version fra 1.2 til 1.3 Med Collection Management version 1.15 medfølger også en ny version af
Læs mereDC LABEL - EN CENTRAL ETIKETLØSNING I SESAM, 26. FEBRUAR 2015
DC LABEL - EN CENTRAL ETIKETLØSNING I DANISH CROWN SESAM, 26. FEBRUAR 2015 Jens Barfred, Danish Crown Lars Bjerre-Harpøth, Frontmatec International fødevarevirksomhed med produktion og salg over hele verden
Læs mereTredjemandsprogrammel i K03. Alice Grünfeld, chefjurist
Tredjemandsprogrammel i K03 Alice Grünfeld, chefjurist 1 BEC BEC er ejet af en række banker og har derudover en række finansvirksomheder som kunder samt udbyder af flere brancheløsninger Omsætning ca.
Læs mereIt-principper. Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune
It-principper Bilag 1 til It- og Digitaliseringsstrategi for Sønderborg Kommune Indledning It-principperne er grundstenene for it-arkitekturen i Sønderborg Kommune. Principperne skal bidrage til, at vi
Læs mereD INTEGRATIONSDESIGN FOR DATAAFTAGERE
DIGST ORKESTRERINGSKOMPONENT D0180 - INTEGRATIONSDESIGN FOR DATAAFTAGERE Version: 1.3 Status: Endelig Godkender: Forfatter: Copyright 2019 Netcompany. Alle rettigheder forbeholdes. Dokumenthistorik Version
Læs mereDM507 Algoritmer og datastrukturer
DM507 Algoritmer og datastrukturer Forår 2017 Projekt, del III Institut for matematik og datalogi Syddansk Universitet 6. april, 2017 Dette projekt udleveres i tre dele. Hver del har sin deadline, således
Læs mereGuide til opsætning af Google Analytics Nye kunder Visiolab introduktion
Guide til opsætning af Google Analytics Nye kunder Visiolab introduktion Denne guide vil gøre dig i stand til at opstille din Google Analytics konto. Ydermere vil den være en hjælp til at forstå hvordan
Læs mereIt-håndbogen. Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret.
It-håndbogen Uddrag af artikel trykt i It-håndbogen. Gengivelse af denne artikel eller dele heraf er ikke tilladt ifølge dansk lov om ophavsret. Børsen Ledelseshåndbøger er Danmarks største og stærkeste
Læs mereTietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125
Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...
Læs mereBilag 6.2 IT-Revision
IT-Revision Bilag 6.2 IT-Revision Version: December 2016 Indhold Indledning... 3 Revisions enhed... 3 Security Governance og revision... 4 Intern revision... 5 Revisionserklæringer fra underleverandører...
Læs mereEasyIQ ConnectAnywhere Release note
EasyIQ ConnectAnywhere Release note Version 2.4 Der er over det sidste år lavet en lang række forbedringer, tiltag og fejlrettelser. Ændringer til forudsætningerne: o Klienten skal ved førstegangs login
Læs mere