Enterprise JavaBeans sammenlignet med idealet for en komponetmodel

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

Indhold 1 Sammenfatning 4 2 Indledning 4 3 Komponentbaseret softwareudvikling 4 3.1 Vision...................................... 5 4 Den idelle komponent 6 4.1 Kontrakter.................................... 6 4.2 Grænseflade................................... 6 4.3 Navngivning................................... 7 4.4 Interaktion standard.............................. 7 4.5 Funktionelle og ikke-funktionelle krav..................... 7 4.6 Komponentdokumentation........................... 8 4.7 Black-/whitebox................................. 8 5 Certificering 8 5.1 Interoperabilitet................................. 9 6 Indsættelse 10 7 Sammensætning af komponenter 10 7.1 Sammensætningsformer............................. 11 7.2 Tidspunkt for ressourcebinding........................ 12 8 Vedligeholdelse og udskiftning af komponenter 12 9 Component Services 13 9.1 Objektoprettelse og -tilstandslagring..................... 13 9.2 Messaging / Event notification......................... 14 9.3 Sikkerhed.................................... 14 10 Opsummering af krav 14 10.1 Komponenter.................................. 14 2

10.2 Rammeværk................................... 15 10.3 Kontrakter.................................... 16 11 EJB sammenlignet med idealet 16 11.1 Komponent................................... 16 11.2 Rammeværk................................... 19 11.3 Kontrakter.................................... 21 12 Konklusion 23 3

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

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

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

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

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

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

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

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

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

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

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. 10.1 Komponenter Komponenter skal være tilstandsløse, jf. afs. 4. Komponentmodellen skal angive, hvordan kontekstafhængigheder angives og efterprøves, jf. afs. 4.4. Komponentmodellen skal definere, hvordan man angiver og efterprøver required og provided grænseflader, jf. afs. 4.5. 14

Komponenten skal kunne pakkes i binært format, jf. afs. 4.7. 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. 5.1. 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. 9.1. Komponentmodellen skal specificere, hvordan komponrnter abonnerer på og udsender notifikationer, jf. afs. 9.2. Komponentmodellen skal tilbyde en service, der regulerer adgang til komponenter, jf. afs. 9.3. 10.2 Rammeværk Komponentmodellen skal specificere hvilke protokoller, der anvendes til kommunikation imellem frameworks, jf. afs. 5.1. Det bør være muligt at efterprøve interoperabilitet af et rammeværk eksempelvis mod en referenceimplementering, jf. afs. 5.1. 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. 7.2. 15

10.3 Kontrakter Komponentmodellen skal specificere, hvorledes interaktions- og komponentkontrakter specificeres, jf. afs. 4.1. Komponentmodellen skal specificere, hvorledes en grænseflade specificeres, jf. afs. 4.2. Komponentmodellen skal definere et navneskema for komponenter og grænseflader, jf. afs. 4.3. Komponentmodellen skal stille krav til formel dokumentation, jf. afs. 4.6. 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. 6. 11 EJB sammenlignet med idealet I dette afsnit vil Enterprise JavaBeans version 2.1 blive vurderet i forhold til idealet, som opstillet i afsnit 10. 11.1 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. 4.3.3 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

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. 20.2 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. 23.2 s. 502-504 [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. 4.1.1 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

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. 4.1.1 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. 3.1.6 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

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. 19.1 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. 3.1.2 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. 4.1.1 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.3.1.2 19

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. 3.1.5 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. 25.2.6 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

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. 20.5 [3]. Sammensætteren af komponenterne må definere security roles vha. method permissions, der defineres for hver security role i indsættelsesbeskrivelsen. jf. 21.1 [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. 4.2.2 [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. 4.2.1 [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. 4.2.1 s. 45-46 [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

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. 4.2.2 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.1.3 [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.1.3 [3]. Dermed har en komponent ikke en tilpasningsgrænseflade, som er defineret i modellen og kravet er derfor ikke opfyldt. :o( 22

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

Litteratur [1] William T. Councill George T. Heineman. Component-Based Software Engineering Putting the Pieces Together. Addison-Wesley, 2001. [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, 2002. [3] Linda G. DeMichiel. Enterprice JavaBeans Specification, Version 2.1. Sun Microsystems., November 2003. Kan ses på nettet på http://java.sun.com/products/ejb/docs.html. [4] Linda G. DeMichiel. Enterprice JavaBeans Fundamentals. Sun Microsystems, March 2005. Kan ses på nettet på http://java.sun.com/developer/onlinetraining/ejbintro.html. 24