Enterprise Java Beans Assignment 1

Transkript

1 Enterprise Java Beans Assignment 1 Distribuerade System HT 02 Fredrik Lundgren Andreas Nyberg fredrikbjurefors@hotmail.com goca8363@student.uu.se frlu4469@student.uu.se andreas.nyberg@hushmail.com

2 Innehållsförteckning Abstrakt 1 Inledning 2 Allmänt om EJB 2.1 Mål med EJB 2.2 EJB vs vanliga javaklasser 2.3 Komplicerad uppbyggnad 3 Beans 3.1 EJB server 3.2 EJB container 3.3 Home interface och Home object 3.4 Remote interface och EJB object 3.5 EJB client 3.6 Enterprise beans 3.7 Entity beans 3.8 Session beans 3.9 Enterprise Java Beans kontra MTS/COM+ 4 En jämförelse, bönor, queing & cachning 4.1 Plattformsoberoende och programmeringsspråk 4.2 Skalbarhet 4.3 Säkerhet 4.4 Pris 4.5 Slutsats 4.6 Referenser 5 Fredrik Lundgren 2 Andreas Nyberg

3 1 Abstrakt Den här rapporten innehåller grundläggande beskrivning av Enterprise Java Beans (EJB). Vi börjar först med att ge en lätt övergripande skildring av EJB, men som senare övergår i en mer detaljerad beskrivning. Dessutom så kommer det att göras en jämförelse med andra tekniker såsom MTS/COM+ med fokusering på för och nackdelar. Vårt mål är att du som läsare, efter genomläsningen får en bättre uppfattning om tekniken. 2 Inledning 2.1 Allmänt om EJB EJB är en komponentarkitektur för att skapa skalbara, distribuerade, flerskikts applikationer som gör det möjligt att utveckla dynamiskt uttänjbara servrar. På detta sätt kan man utvidga funktionaliteten hos en server. EJB brukar blandas ihop med JavaBeans, men sanningen är att de bara har liknande koncept. Den styrs inte av JavaBeans specifikationen utan av en helt egen massiv specifikation som beskriver serversidan. Sen EJB teknologin introducerades för några år sen så var det en makalös stund för många utvecklare. Denna uppståndelse berodde på att EJB underlättade utveckling av middleware applikationer genom att den erbjöd automatiskt support för olika tjänster som säkerhet, transaktion, databas koppling, med flera. Figur 1. Middlewares placering i förhållande till klienter och data. 2.2 Mål med EJB Specifikationen för EJB försöker uppnå en rad olika mål. Fredrik Lundgren 3 Andreas Nyberg

4 Ena målet var att göra det lättare för utvecklare att utveckla applikationer. Med det menas att frigöra dem från low level system detaljer som att hantera transaktioner, trådar, balansering osv. Utvecklare kan istället koncentrera sig mer på affärslogiken. En annan målsättning var att göra EJB till standard för klient/server applikationer i Java världen. Exakt som JavaBeans så kan EJB komponenter från olika försäljare kombineras för att få en bruklig server. Komponenterna kommer självklart att kunna köras på efterkommande servrar utan att behöva kompileras om. Det här är en fördel gentemot plattformsberoende lösningar. Huvudämnet som definieras i EJB specifikationen är EJB ramverket, speciellt definitionen av överenskommelsen mellan komponenterna på servern och servern. Ansvar från klienten, servern och individuella komponenten har noga beskrivits. En utvecklare av komponenten har en annorlunda roll än utvecklaren av servern, och specifikationen förklarar ansvaret för de båda. Slutligen så skulle man också få EJB kompatibelt med andra Java API och CORBA. 2.3 EJB vs. vanliga Java klasser EJB komponenterna blir ruskigt simpla tack vare den välbyggda middlewaren. Metoder för pooling, transaktionssäkerhet, containerstyrda persistance (ansvar för statushållning), containerstyrda relationer och data cachning. Använder man vanliga javaklasser måste man implementera allt detta själv. 3 Komplicerad uppbyggnad 3.1 Beans Beans är de grundläggande komponenterna i EJB. De tillhandahåller de dataoperationsmetoder som klienterna ska kunna anropa. Man skiljer på två typer av beans: Session beans och entity beans. En session bean utgör vanligtvis ett temporärt objekt i en applikation. Varje klient kan skapa/avsluta en session bean. entity beans är permanenta objekt som representerar persistent data, t.ex. en databas. Alla klienter som utnyttjar en entity bean får tillgång till samma data. Fredrik Lundgren 4 Andreas Nyberg

5 För att en bean ska kunna vara åtkomlig för klienter måste den få hjälp av ett antal komponenter som ansvarar för kommunikationen. Dessa komponenter beskrivs nedan. Figur 2 a) Klienten använder sig av serverns JNDI (naming service) för förfrågan om en bönas hemgränssnitt. b) Servern ger klienten en referens till bönans hemgränssnitt (EJB Home). c) Klienten anropar någon av metoderna i EJB Home för att erhålla en referens till bönans fjärrgränssnitt (EJB Object). d) EJB Home ser till att bönan knyts till klienten. e) Klienten erhåller en referens till bönans EJB Object. f) Klienten anropar någon av de dataoperationsmetoder som erbjuds via EJB Object. g) EJB Object vidareförmedlar klientens metodanrop till bönan. h) Bönan utför önskad operation, t.ex. databasmanipulation. i) När klienten är färdig anropas bönans EJB Home och sessionen termineras. 3.2 EJB server EJB servern ger en miljö i vilken EJB containers kan exekvera. Den utför systemservice för multiprocessing, laddningsbalans och enhetsåtkomst. EJB server gör EJB containrarna synliga för omvärlden. Man kan likna EJB servern med CORBAs Object Transaction Monitor (OTM) Fredrik Lundgren 5 Andreas Nyberg

6 3.3 EJB container Beans placeras i en EJB container, som har det övergripande ansvaret för kommunikationen med klienter. EJB container ser även till att de gränssnitt som klienterna behöver för kommunikationen skapas. Detta sker via en s.k. Deployment Descriptor. En EJB container gör gränssnitten tillgängliga för omvärlden genom att registrera dem i serverns JNDI (naming service). 3.4 Home interface och Home object Metoder för att lokalisera, skapa och ta bort instanser av EJB klasser är definierade i home interface. Home object är implementationen av home interface. EJB utvecklaren måste först definiera Home Interface för sin bean. EJB container serverägaren tillhandahåller verktyg som automatiskt genererar implemetationskoden för home interface som är definierad av EJB utvecklaren. 3.5 Remote interface och EJB object EJB objektet är klientens syn på enterprise bönan och implementeras av remote Interface. Remote interface listar affärsmetoderna som är tillgängliga för enterprise bönan. Utvecklaren av enterprise bönan definierar remote interface. Verktygen som är nödvändiga för att generera implementationskoden för tillhörande EJB object tillhandahålls av containerserverägaren. 3.6 EJB client EJB klienten lokaliserar den EJB container som innehåller en EJB böna genom Java Namning and Directory Interface (JNDI). EJB klienten använder sig sedan av EJB containern för att anropa beanmetoder. EJB klienten får endast en referens till en EJB objektinstans och inte till enterprise bönan självt. Klienten använder home objekt för att lokalisera, skapa och radera en instans av en enterprise bean. När klienten anropar en metod får EJB objektetets instans en förfrågan och delegerar den vidare till den tillhörande bönans instans ger den de nödvändiga funktionerna. Fredrik Lundgren 6 Andreas Nyberg

7 3.7 Enterprise Beans Enterprise beans är byggstenarna i applikationer för tunna klienter. De kan användas en och en eller tillsammans med flera andra beans. En EJB består av kod med metoder av affärslogik. Det finns två typer av enterprise beans. Den ena är entity beans. Dessa används ofta vid arbete med databaser. Den andra typen är session beans som skapas oftast skapas av klienten under inloggning och kan innehålla fakta om vilka rättigheter användaren har, transaktioner mm. 3.8 Entity Beans Flera klienter kan använda samma entity bean. Livslängden på en entity bean är inte begränsad till livslängden av den virtuella maskinen i vilken den exekveras. En krasch av VM kan resultera i att den nuvarande transaktionen förstörs, men entity bönan förstörs inte och inte heller referenserna som klienterna har till bönan. Den kan därmed överleva nedstängning av systemet. Container managed persistance: I denna typ av entity bönor är EJB container ansvarig för att spara status. Alla fält som hanteras av containers måste specifieras i deployment descriptor. Bean managed persistance:bönan hanterar sparandet av status och detta gör att container inte behöver göra några databasanrop. 3.9 Session Beans En session bean skapas av klienten och existerar endast under en session. Den utför operationer som t ex databasåtkomst och beräkningar på förfrågan av klienten. En session bean överlever inte en systemkrasch. Stateless session beans: Denna typ av sessionsbönor har ingen intern status. Just för att de är statuslösa behöver de inte passificeras och kan användas av flera klienter. Stateful session benas: Dessa har intern status. Endast en klient kan existera per böna. Fredrik Lundgren 7 Andreas Nyberg

8 Session Bean Medlemmarna I en session bean innehåller konversationsstatus. En session bean kan hantera databasåtkomst för en klient. P.g.a. att session beans konverserar endast med en klient i taget kan den lagra information om klientens läge. En session bean livstid är begränsad till livslängden hos klienten. Session beans kan vara transaktionella. Session beans klarar inte en serverkrasch Entity Bean Medlemmarna i en entity bean innehåller data ur domain model. Entity beans kan ge databasåtkomst till flera klienter. Entity beans lagrar inte information om klientens läge eftersom den delas av flera klienter. En entity bean kvarstår så länge som datan i databasen finns kvar. Entity beans är transaktionella. Entity beans klarar en serverkrasch. Tabell 1. Kort beskrivning av SessionBeans och EntityBeans 4 Enterprise Java Beans kontra MTS/COM+ Ett stort problem för företag idag är att välja vilken "middleware" de skall använda till sina applikationer. Vilka aspekter skall spela in? Plattformsoberoende, pris, programmeringsspråk eller säkerhet med flera. Allt har sin grund i CORBA och RPC. Föregångaren till COM+, MTS (Microsoft transaction server) kopierade det bästa från CORBA enligt gammalt hederligt recept och skapade ett väl fungerande "middleware". EJB i sin tur kopierade från MTS. MTS är en enkel transaktionserver som bygger på microsofts COM protokoll. EJB använder i sin tur IIOP protokollet (med flera) på samma sätt. I och med tillkomsten.net så bytte MTS skepnad till COM+. Fredrik Lundgren 8 Andreas Nyberg

9 4.1 En jämförelse, bönor, queing & cachning. De olika servertyperna har olika fördelar. COM+ är lite simplare att förstå med bara en typ av transaktion samt en typ av komponent. EJB har istället flera olika sorters komponenter eller beans. Dessa bönor har utöver detta olika tillståndstyper beroende på vilken användning man vill ha. En stateless sessionbean kan jämföras med en algoritm som ligger öppen och kan användas av alla som jobbar mot servern. Ingen data sparas inom bönan. För multipla användare t.ex. en valautaöversättningsalgoritm. En stateful sessionbean håller reda på tillståndet för just en klient. Kan liknas vid en kundvagn för en specifik kund. Entitybean är kontakten mot databasen och håller reda på tillståndet för ett objekt i taget. T.ex. ett kundkonto. Dessa komponenter som passar utmärkt för t.ex. elektronisk handel har ingen motsvarighet i COM+ som bara har en sorts komponent. Den komponent som COM+ tillhandahåller är en stateless och väldigt lik den stateless sessionbean som EJB har. Skillnaden ligger i att vid kreationen av en EJB komponent anropas databasen direkt och kontakten finnes redan vilket sker senare i en COM+ komponent då kontakten oftast är inbakad i klassanropet. COM+ använder sig utav metoder för att sprida serverarbetsbördan på flera noder i ett cluster, "Component Load Balancing". Queing är en metod unikt för COM+. Ifall en server inte är tillgängligt vid en klients anrop köas klienten med dess anrop. I EJB får man prova att kontakta gång på gång. Vilket sänker prestandan markant. Båda använder en metod för pooling som gör att objekt inte förstörs efter användning utan läggs i en pool till dess att de anropas igen. 4.2 Plattformsoberoende och programmeringsspråk. Helt beroende på vilka grundförutsättningar som finnes. EJB är precis som namnet säger helt till Java och kommer inte att blanda in flera språk vare sig nu eller i framtiden. Med.NET/COM+ generationen stöds en mängd av programmeringsspråk däribland Java om än halvhjärtat (inte i närheten av stödet i EJB). Har företaget kompetens nog att skapa sina applikationer Fredrik Lundgren 9 Andreas Nyberg

10 enbart med Java kan EJB vara ett starkt alternativ. Flera språkmöjligheter är givetvis billigare i rent fortbildningssyfte. Vad gäller plattformsoberoendet är det inte mycket att orda om. Har man behov av att kunna köra applikationerna på flera olika plattformar eller enbart på något som inte är windowsbaserat är det bara EJB som gäller 4.3 Skalbarhet Skalbarheten skiljer sig inte speciellt mycket mellan servertyperna. Man kan konstatera att fler stateless sessionbeans ökar skalbarheten. 4.4 Säkerhet Säkerheten sker komponentvis och är inte beroende av vilken användare som anropar komponenten. COM+ är lite mer översiktligt och lättolkat vad gäller säkerhet vilket gör det lätt att konfigurera. Att skriva säkerhetshanterare är lätt i Java men lite knepigare i C++ och Visual C Pris Hur skall man mäta priset? Pris per transaktion eller framtida kostnader vid uppskalning? Med tonvikt på pris per transaktion blir övervikten ganska så rejäl till COM+ fördel. Plattformsoberoendet har sitt pris i komplexitet (JVM mellanlager) vilket gör att tiden per transaktion för en EJB komponent blir ca 10 gånger den för en transaktion skriven i C för COM+. En COM+ server skulle således klara av klienter på samma tid som en EJB server klarar 1000 klienter. EJB kostar mer i inköp samt mer per transaktion så COM+ har ett pris en bit under en tiondel av vad EJB har per transaktion. Prisdiskussionen kan spetsas ytterligare då COM+ följer med i Windows NT baserade operativsystem medan EJB måste köpas in separat oberoende av plattform. Fredrik Lundgren 10 Andreas Nyberg

11 4.6 Slutsats Plattformsoberoende och låg kostnad, knappast. Användning av Java och andra språk samtidigt, knappast. COM+ EJB Språk Många Java Plattform Windows NT De flesta Protokoll DCOM Vilket som helst Stateless components Ja Ja Stateful components Nej Ja Queued components Ja Nej Pooling Ja Ja Kostnad per transaktion Låg Hög Inköpskostnad Ingen Ja Tabell 2. En snabb översikt på skillnaderna mellan COM+ och EJB. 5 Referenser Flertalet introduktionskurser om EJB finns på java.sun.com/j2ee/ Ett whitepaper finnes på wp.pdf Fredrik Lundgren 11 Andreas Nyberg