Adviesrapport Hol.com

Adviesrapport Hol.com

Middletier Development Gerben Peters

411711

Stephan Bosch

13637

Klas:

ICD4a

Docent:

R. Middelkoop (MDL)

Vak:

MdlTr

Inleverdatum:

03-11-2006

Inhoudsopgave INHOUDSOPGAVE ....................................................................................................................1 INLEIDING ..................................................................................................................................2 MANAGEMENT SAMENVATTING ........................................................................................3 PROBLEEMSTELLING.............................................................................................................4 DOELSTELLING ........................................................................................................................6 WAT IS MIDDLEWARE? ..........................................................................................................7 SOORTEN MIDDLEWARE..............................................................................................................7 RPC ........................................................................................................................................8 MOM ......................................................................................................................................8 Distributed Objects............................................................................................................... 12 Database-oriented Middleware............................................................................................ 12 Transactional Middleware ................................................................................................... 12 Message Brokers .................................................................................................................. 13 WAAROM MIDDLEWARE? ......................................................................................................... 14 RMI.............................................................................................................................................. 15 DE TECHNIEK ............................................................................................................................ 15 VOOR DE ONTWIKKELAAR ......................................................................................................... 16 CORBA ....................................................................................................................................... 20 DE TECHNIEK ............................................................................................................................ 20 VOOR DE ONTWIKKELAAR ......................................................................................................... 22 RMI VS. CORBA ....................................................................................................................... 24 EJB............................................................................................................................................... 25 DE TECHNIEK ............................................................................................................................ 25 Wanneer EJB? ...................................................................................................................... 25 VOOR DE ONTWIKKELAAR ......................................................................................................... 25 Installatie.............................................................................................................................. 25 Gebruik ................................................................................................................................. 27 Client interface ..................................................................................................................... 27 Home interface ..................................................................................................................... 27 Bean implementatie .............................................................................................................. 28 EJB CONCLUSIE ......................................................................................................................... 28 LITERATUURLIJST ................................................................................................................ 29 INDEX ......................................................................................................................................... 30

Inleiding In dit adviesrapport willen wij graag een advies uitbrengen over de te gebruiken technieken m.b.t. de nieuw te ontwikkelen middleware. Middleware is de naam voor de koppeling tussen de bestaande applicatie en de nieuwe gebruikerskant, in dit geval de internet site. Hiervoor zijn een aantal technieken toe te passen, met elk zijn voor- en nadelen. Met behulp van dit verslag willen wij een toepassing aanraden en toelichten waarom het in dit geval de beste keuze is. Er zullen 3 alternatieven aan het licht komen, namelijk RMI (Remote Method Invocation), Corba (Common Object Request Broker Architecture) en EJB (Enterprise Java Beans). Wat deze technieken inhouden komt later in dit verslag aan bod.

Adviesrapport middleware HOL.com

2

Management samenvatting Mogelijkheden

RMI

•

Eenvoudige implementatie op bestaande applicaties. Corba

•

Implementatie taal onafhankelijk, applicaties geschreven in bijvoorbeeld .Net, Delphi, Java, C, etc. kunnen met elkaar communiceren op applicatie-code-niveau. Enterprise Java Beans

•

Schaalbare, onderhoudsvriendelijke componenten. Voor- en nadelen raming

RMI

Corba

EJB

Voorkennis

+

0

--

Leercurve

++

+

-

Ontwikkelgemak

+

-

0

Implementatie

++

+

0

Onderhoud

+

-

++

Kosten

++

++

++

Betrouwbaarheid

-

++

++

Functionaliteit

0

0

+

Snelheid

0

0

-

Schaalbaarheid

-

-

++

Flexibiliteit

0

0

+

Beveiliging

0

0

++

Ondersteuning

+

+

+

Conformiteit aan standaarden

0

++

0

Uitkomst

+

0

++

-- = negatief, - = redelijk negatief, 0 = neutraal/nvt, + = matig, ++ = positief Conclusie

Uit onze ervaringen is gebleken dat de keuze afhangt van de weging van de bovenstaande punten, uit de volgende beschrijving kunt u zelf de beste oplossing kiezen die het beste uw doelstellingen zal halen.

Kiezen we een eenvoudige implementatie die gemakkelijk door te voeren is voor ontwikkelaars dan is RMI de beste keuze. Willen we een schaalbare , onderhoudsvriendelijke oplossing die voorbereid is op de toekomst dan kiezen we voor EJB in combinatie met JBoss. Is het nodig om te communiceren tussen verschillende systemen met verschillende applicaties dan is CORBA de beste optie.


3

Probleemstelling Allereerst is er de site www.hol.com die inmiddels door vele klanten gevonden wordt. De huidige site bestaat uit dynamische webpagina’s die de klant door het bestelproces heen helpen. Aan het eind van het proces wordt er door de laatste pagina een mailtje gecomponeerd welke door een van de vele medewerkers verwerkt wordt tot een order. Als de order rond is wordt een bevestigingsmailtje gestuurd aan de klant, als deze tenminste zijn emailadres heeft ingegeven. Uitgevers nemen veelvuldig contact op met hol.com als er nieuwe boeken uit zijn. De uitgevers lopen al een tijdje rond in de automatiseringswereld en vonden het nodig een gemeenschappelijk dataformaat af te spreken waar alle informatie over nieuwe boeken instaat. Bij hol.com lopen ze nog achter; de informatie van uitgevers krijgen zij nog per post en alles wordt handmatig ingevoerd in de database. Het volgende plaatje illustreert de opbouw van de verschillende applicaties:

Figuur 1: Architectuur oude situatie


4

Het volgende Use Case Diagram geeft de systeemfuncties en actoren weer:

Figuur 2: Oude situatie


5

Doelstelling Allereerst volgt hier het UseCase Diagram met een andere samenhang tussen UseCases en Actoren:

Figuur 3: Nieuwe situatie

hol.com heeft een zeer drukke architect in dienst die her en daar wat heeft gehoord over RMI, CORBA en EJB. Hij heeft voor de bestaande softwarearchitectuur een aantal verbeterpunten in gedachten maar heeft een prototype nodig om wat zekerder te zijn over zijn advies richting zijn projectmanager. Sommige verbeterpunten zijn heel concreet, voor andere verbetersuggesties heeft hij alleen wat hersenspinsels op papier gezet. Aan jou om de concrete verbeterpunten uit te ontwikkelen en advies te geven over de hersenspinsels. Voor ieder van de technieken hebben wij een prototype gemaakt, mede hierop baseren wij ons advies wat voor u ligt.


6

Wat is Middleware? Kort samengevat is het doel van Middleware:

“Het doel van Middleware is het centraliseren van de software infrastructuur en zijn deployment.” Soorten Middleware In het algemeen kan middleware gezien worden als alle typen software die faciliteren in de communicatie tussen verschillende software systemen. Een soort van bemiddelaar tussen verschillende partijen. Er zijn veel verschillende typen middleware die onderling moeilijk van elkaar te onderscheiden zijn, mede doordat ze steeds meer dezelfde functionaliteiten krijgen.

Multi-tier architecture JSP/Servlet

ASP.NET Forms/Webservices presentation

Enterprise JavaBeans

presentation

ASP.NET Classes

business logic / component

CORBA

JMS

JDBC

business logic / component

JCA

“COM”

MSMQ

ADO.NET

middleware

middleware

SQLServer

SAP

Oracle Other App

CICS

Other DB

Cobol

Other App Other DB

data

data

Locatie Middleware in Multi-Tier Architecture

De volgende vormen zullen we kort toelichten om het beeld iets duidelijker te maken: •

Remote Procedure Calls (RPC’s)

•

Message Oriented Middleware (MOM)

•

Distributed Objects

•

Database-oriented Middleware

•

Transactional Middleware

•

Message Brokers


7

RPC Een Remote Procedure Call (RPC) is een protocol dat het een programma op een computer een aanroep laat doen op een subroutine op een andere computer, zonder dat de ontwikkelaar daarvoor de code hoeft te schrijven voor de interactie tussen deze twee. Een object georiënteerde toepassing hiervan, die we later zullen bespreken, is Remote Method Invocation (RMI).

Remote Method Invocation

MOM Een alternatief voor remote method invocations is messaging (berichten versturen). Het idee achter messaging is dat er een middleman tussen de client en de server zit die berichten van één of meerdere message producers ontvangt en deze door stuurt naar één of meerdere message consumers. De producer kan een bericht versturen en doorgaan met processing en eventueel op de hoogte gebracht worden als de consumer klaar is. Dit noemt men asynchronous programming een term die je bijvoorbeeld op het moment vaak hoort op het internet als men praat over de techniek AJAX1.

Messaging

De term Message-oriented middleware (MOM) wordt gebruikt voor infrastructuren die messaging ondersteunen. Een aantal producten die hier onder vallen zijn:

1

•

Tibco Rendezvous

•

IBM WebSphere MQ

•

BEA Tuxedo/Q

•

Sun Java System Messaging Server (JMS)

•

Microsoft MSMQ

•

Sonic Software SonicMQ

•

FioranoMQ

Asynchronous JavaScript and XML


8

Voordelen van messaging zijn: •

Nonblocking request processing Een client hoeft niet te wachten op het uitvoeren van het verzoek (request). Bijvoorbeeld als je een boek besteld op Hol.com dan kun je ondertussen doorgaan met browsen van de site, zonder dat je hoeft te wachten op het valideren van je creditcard.

•

Decoupling De verstuurder hoeft niet te weten wie het antwoord verwerkt, hij heeft alleen contact met de middleman. Hierdoor zijn de producers dus los gekoppeld (decoupled) van de consumers, zodat het mogelijk is om de consumers te veranderen zonder wijzigingen aan de producers.

•

Reliability Het is mogelijk om guaranteed delivery toe te passen, het is dan mogelijk om een bericht te versturen en er zeker van te zijn dat het aankomt, zelfs als de consumer tijdelijk niet beschikbaar is. De producer verstuurd het bericht naar de MOM middelman, die het bericht doorgeeft als de consumer weer beschikbaar is.

•

Support for multiple senders and receivers De meeste MOM producten kunnen berichten accepteren vanaf verschillende plaatsen en kunnen deze doorsturen naar meerdere ontvangers. Dit zorgt voor een uiterst schaalbaar systeem. Voor Hol.com zou dit bijvoorbeeld kunnen betekenen dat er meerdere websites gebruik kunnen maken van dezelfde MOM die deze doorstuurt naar een of meerdere servers die de bestellingen kunnen afhandelen.

Uiteraard zijn er ook nadelen aan het gebruik van messaging. Bijvoorbeeld de performance die lager kan zijn door het toevoegen van de extra laag (middleman).


9

Wanneer Messaging?

Wanneer moet je nu Messaging gebruiken en niet RMI-IIOP2? Er zijn in de praktijk een aantal voordelen aan messaging die ervoor zorgen dat je op dat moment beter voor messaging voor kunt kiezen. We zullen er een paar op een rij zetten die mogelijk betrekking hebben op Hol.com: •

Database performance Bij relationeel database verkeer, zoals in het geval van Hol.com het verwerken van een order, kan het zijn dat messaging een voordeel biedt. Het maakt het namelijk mogelijk om een message, in ons geval een order, in een secundairy message queue te zetten die dan op een later tijdstip verwerkt kan worden. Dit zorgt ervoor dat de database de belasting van piek uren kan wegwerken op de tijden dat het minder druk is. Dit werkt natuurlijk alleen als de verwerking niet meteen bevestigd moet worden, dus bij een validatie van een creditcard is dit niet handig.

•

Snelle afhandeling Een client wil niet wachten op antwoord als ze weten dat het antwoord toch niet komt. Bijvoorbeeld bij een methode die void retourneert zijn er twee mogelijkheden, namelijk er komt niets of er treed een exception3 op, als de client nooit verwacht dat er een exception optreed, waarom zou hij dan moeten wachten op een antwoord?

•

Many-to-many communications Als er meerdere partijen zijn die met elkaar praten, waarbij meerder producers en meerdere consumers met elkaar kunnen communiceren. Een scenario zou kunnen zijn dat Hol.com en andere boekenwinkels samen zouden werken en gegevens van meerdere leveranciers onderling uitwisselen.

•

Decoupling Zoals al besproken bij MOM een losse koppeling tussen verzender en ontvanger.

2

Internet Inter-Orb Protocol Wiki: http://en.wikipedia.org/wiki/Exception_handling ”Exception handling is a programming language construct or computer hardware mechanism designed to handle the occurrence of some condition that changes the normal flow of execution. The condition is called an exception”

3


10

Natuurlijk zijn er meerder voordelen te noemen voor het gebruik van messaging, maar die zijn volgens ons voor deze situatie niet echt van toepassing. Tegenover de voordelen zijn er altijd nadelen te noemen, net als bij de voordelen noemen we hier alleen de nadelen die van toepassing kunnen zijn op Hol.com: •

Zekerheid van succes Bij RMI-IIOP systemen kunnen er exceptions worden afgevangen, bij message-driven beans gaat dat niet.

•

Als je een resultaat verwacht Bij RMI-IIOP systemen krijg je het resultaat direct terug, omdat het verzoek meteen wordt afgehandeld. Bij messaging gaat dat niet gemakkelijk, namelijk messages die terug moeten worden gestuurd waar de client dan naar moet gaan luisteren.

•

Onderdeel van een transactie Als een bericht een onderdeel is van een transactie, zoals bij het bestellen en het afschrijven van de betaling via creditcard. Het zou vreemd zijn als er een betaling wordt verwerkt, maar geen bestelling aangemaakt kan worden in het systeem.

•

Request performance Omdat messaging langzamer werkt als RMI-IIOP, door het gebruik van een middleman, worden de verzoeken langzamer. Bij een website betekend dit dat verzoeken altijd binnen een bepaalde tijd4 moeten worden behandeld.

“One second (1.0) is about the limit for the user’s flow of thought to remain uninterrupted… Ten seconds (10.0) is about the limit for keeping the user’s attention focused on the dialog.” Jacob Niels - Designing Web Usability •

Een sterker gekoppeld, eenvoudiger system Synchroon ontwikkelen is eenvoudiger dan via messaging. Het is makkelijker om zelf datatypes te verzinnen en deze dan te gebruiken ten opzichte van het versturen van berichten, wat ook zorgt voor minder code. Daarnaast is het debuggen van de code veel gemakkelijker, omdat het namelijk vooraf bepaalde stappen aflegt.

4

Designing Web Usability – Jacob Nielson ISBN 1-56205-810-X


11

Distributed Objects Distributed objects vallen ook onder Middleware omdat ze zorgen voor de communicatie tussen verschillende applicaties. Een van de bekendste die we verderop zullen behandelen is de Common Object Request Broker Architecture (CORBA).

Database-oriented Middleware In een Multi-tier architectuur is er ook sprake van Middleware op het niveau van communicatie met de databases, hierbij valt te denken aan technieken als Open Database Connectivity (ODBC), Java Database Connectivity (JDBC), OLE DB, etc. Hier zullen we verder niet op in gaan, omdat dit onderdeel niet belangrijk is voor Hol.com.

Transactional Middleware

Onder Transactional5 Middleware vallen Transaction processing (TP) monitors en applicatie servers. JBoss6 is bijvoorbeeld een applicatie server die hieronder valt. Deze technologie verzorgt allerlei facetten die nodig zijn om een schaalbare client/server architectuur te ontwikkelen. Enterprise JavaBeans (EJB) maken gebruik van een applicatie server en zullen verderop worden behandeld. Een applicatie-server zorgt voor het delen van logica tussen applicaties, maar verschaft ook de verbinding met back-office applicaties zoals ERP-systemen, mainframes en databases. Een nadeel van Transaction oriented Middleware is dat het zorgt voor een sterke koppeling tussen de applicaties, wat weer ten koste gaat van de flexibiliteit.

5 Een transactie is een ondeelbare eennheid werk met een begin en een eind, deze vindt plaats of helemaal niet. 6 http://www.jboss.com/products/jbossas


12

Message Brokers Net als we de vraag stellen “Wat is Middleware” kunnen we ook de vraag stellen “Wat is een Message Broker”. Zodra je gaat zoeken kom je meteen de term “EAI” tegen wat staat voor Enterprise Application Integration, wat zoveel betekend als het samenbrengen van applicaties binnen een onderneming.

Traditioneel messaging

Je kunt Message Brokers zien als een extra laag bovenop de traditionele messaging systemen, zoals JMS en MSMQ. Deze laag zorgt ervoor dat het makkelijker is voor ontwikkelaars om informatie uit te wisselen tussen verschillende systemen, ze vertalen dus eigenlijk tussen applicaties, platformen, dataformaten hetgeen er ongeveer zo uitziet:

Message Broker

Communicatie gebeurt dan door middel van adapters, voorkomende technieken zijn bijvoorbeeld J2EE Connector Architecture (JCA) en XML, hier zullen we verder niet op in gaan.


13

Waarom Middleware? Wat is nu het voordeel van middleware ten opzichte van de oplossing zoals Hol.com nu gebruikt? Een duidelijke vraag, waar we hier een duidelijk antwoord op proberen te geven. Op het moment zijn er bij Hol.com twee systemen, een website en een losse applicatie, de website registreert de bestellingen die de interne mensen overnemen in de losse applicatie. Deze applicatie heeft de benodigde business logica om een bestelling uit te voeren en is dus een uitstekende kandidaat om dit door middel van een middleware over te nemen. De applicatie zal blijven functioneren, zonder veranderingen aan de bestaande code en het andere systemen krijgen (indirect) toegang tot de mogelijkheden die er in het bestaande systeem zitten. Ook communicatie met leveranciers wordt hierdoor mogelijk, bijvoorbeeld het toevoegen van boeken die besteld kunnen worden bij de leverancier.

“De noodzaak om snel en efficiënt op wereldschaal te werken verhoogt de noodzaak voor integratie over afdelingen of zelfs over organisaties.” Globaal kunnen we stellen dat de voordelen van Middleware gebruik zijn: •

De mogelijkheid om goedkoop kantoren en organisaties te koppelen via het internet.

•

De noodzaak voor organisaties om coöperatief data en bedrijfsprocessen uit te wisselen.

•

De wens om de generische diensten en het beheer van deze diensten te consolideren.

•

Verzorging van gecentraliseerd applicatiebeheer, inclusief startup, shutdown, onderhoud, recovery, load balancing en monitoring.

•

Open services en protocollen.

•

Het uitrollen van business logica op ieder moment, zonder beperkingen van infrastructuur.

•

Ondersteuning voor samenwerking van verschillende architecturen applicaties.

•

Minder verschil nodig in soorten, niveaus en vaardigheden van het programmeurpersoneel en de behoeft voor geavanceerde tool-building expertise binnen projecten.


14

RMI Java RMI (Remote Method Invocation) maakt het mogelijk functies aan te roepen vanuit een client applicatie in een server applicatie, op dezelfde manier zoals je dat normaal lokaal zou doen. RMI wordt volledig geschreven in Java, dit maakt RMI platform onafhankelijk, en zal dus op zowel een Microsoft-based als een Unix-based systeem gedraaid kunnen worden.

De techniek Allereerst een schets om aan te geven hoe de communicatie tussen client en server verloopt:

Remote Machine bind RMI Server Registry skeleton

return

call

lookup

stub

RMI Client

Local Machine

Situatieschets van een RMI client-server applicatie

De skeleton is in feite de structuur, of wel java code van de server applicatie, waarvan een aantal objecten door de RMI Server in het Registry worden bijgehouden. Het Registry fungeert als een telefoonboek waar alle adressen van beschikbare objecten worden bijgehouden, en opgevraagd kunnen worden van buitenaf.

In een stub wordt vastgelegd hoe er gecommuniceerd moet worden met deze remote objects die geregistreerd zijn binnen het Registry. Dit wordt vastgelegd in de vorm van een Interface. Deze interface bevat een definitie van alle beschikbare functies, en de daarbij horende argumenten.

Deze interface wordt vervolgens in de client applicatie gebruikt om objecten die gevonden worden in het Registry in onder te brengen. Dit zorgt ervoor dat voor de client-omgeving duidelijk is om welk object het gaat, en hoe ermee gewerkt dient te worden.


15

Voor de ontwikkelaar Het ontwikkelen van een client-server applicatie dat gebaseerd is op de RMI methode bestaat uit de volgende 4 stappen:

1. Definieer de remote interface 2. Implementeren van deze remote services 3. Programmeer de server applicatie 4. Programmeer de client applicatie

Daarna zijn de volgende 4 stappen nodig om de applicatie te starten:

1. Alle code compilen 2. Start de RMI server (hierdoor wordt het Registry geinitialiseerd) 3. Start de server applicatie 4. Start de client applicatie

Stap1 Definieer de remote interface Hierin leg je vast welke procedures er gestart/uitgevoerd kunnen worden op de server door de client. De functies bevatten nog geen functionaliteit, het gaat hier alleen om de omroep, met de bijbehorende parameters.

Als voorbeeld, om aan te geven hoe een interface er uit kan zien, gebruik ik een calculator. De calculator heeft een aantal functies, add, sub, mul en div. In dit geval verwachten alle functies de parameters a en b van het type long. De functie add zal a en b optellen, de functie sub zal b van a aftrekken, de functie mul zal a en b vermenigvuldigen en de functie div zal a delen door b.

De code ziet er dan als volgt uit: Public interface Calculator extends java.rmi.Remote { public long add(long a, long b) throws java.rmi.RemoteException; public long sub(long a, long b) throws java.rmi.RemoteException; public long mul(long a, long b) throws java.rmi.RemoteException; public long div(long a, long b) throws java.rmi.RemoteException; }

Hierbij is het van belang dat er wordt overgeërfd van een Remote object. Tevens moet elke functie een RemoteException op kunnen werpen, op het moment dat er tijdens de communicatie tussen client en server iets mis gaat.


16

Stap2 Programmeer de remote objects Wanneer de interface klaar is kan er een implementatie geschreven worden voor deze interface. Hierbij moeten de functies voorzien worden van de nodige functionaliteit. public class CalculatorImpl extends java.rmi.server.UnicastRemoteObject implements Calculator { public CalculatorImpl() throws java.rmi.RemoteException { super(); } public long add(long a, long b) throws java.rmi.RemoteException { return a + b; } public long sub(long a, long b) throws java.rmi.RemoteException { return a - b; } public long mul(long a, long b) throws java.rmi.RemoteException { return a * b; } public long div(long a, long b) throws java.rmi.RemoteException { return a / b; } }

Het is hierbij van belang dat er wordt overgeërfd van het UnicastRemoteObject en de in de vorige stap aangemaakte interface wordt geïmplementeerd.


17

Stap3 Programmeer de server applicatie Het object CalculatorImpl moet nu door de server in het Registry worden geplaatst, zodat deze van buitenaf te benaderen is. import java.rmi.Naming; public class CalculatorServer { public CalculatorServer() { try { Calculator c = new CalculatorImpl(); Naming.rebind("rmi://localhost:1099/CalculatorService", c); } catch (Exception e) { System.out.println("Trouble: " + e); } } public static void main(String args[]) { new CalculatorServer(); } }

Op deze manier wordt het object in het Registry geplaatst op het adres ‘rmi://localhost:1099/CalculatorService’, waarbij localhost de server is, en 1099 het poortnummer waarop het object ‘CalculatorService’ te vinden is.


18

Stap4 Programmeer de client applicatie De laatste stap voor de ontwikkelaar is het schrijven van de client applicatie. Wat hier moet gebeuren is dat op het in de vorige stap opgegeven adres het object weer wordt opgevraagd, en dat daar bewerkingen mee worden uitgevoerd. import import import import

java.rmi.Naming; java.rmi.RemoteException; java.net.MalformedURLException; java.rmi.NotBoundException;

public class CalculatorClient { public static void main(String[] args) { try { Calculator c = (Calculator) Naming.lookup("rmi://localhost/CalculatorService"); System.out.println(c.sub(4,3)); System.out.println(c.add(4,5)); System.out.println(c.mul(3,6)); System.out.println(c.div(9,3)); } catch (MalformedURLException e) { e.printStackTrace(); } catch (RemoteException e) { e.printStackTrace(); } catch (NotBoundException e) { e.printStackTrace(); } } }

Zoals je hier ziet wordt er een Calculator (c) opgevraagd aan het denkbeeldige telefoonboek, met het adres en de naam van het gezochte object dat we bij de vorige stap hebben vastgelegd. Nadat dat is gebeurd kan er met het Calculator object meerdere bewerkingen worden uitgevoerd. Hierbij is het van belang dat bovenstaande exceptions worden afgevangen.

Waar in alle gevallen rekening mee moet worden gehouden is dat classes die meegestuurd moeten worden over de lijn aan beide kanten moeten bestaan. Wanneer bijvoorbeeld aan een bestelsysteem voor boeken wordt gewerkt kun je je voorstellen dat er gebruik wordt gemaakt van een object ‘Boek’. Deze moet aan zowel de client- als de server zijde bekend zijn. Veelal wordt aan de client zijde gebruik gemaakt van een wrapper class. Dit houdt eigenlijk in dat alleen de noodzakelijke properties van de originele class worden overgenomen maar de overige properties en methoden niet. Dit zorgt ervoor dat aan de server zijde altijd het originele object weer herleden kan worden, maar niet telkens compleet over de lijn hoeft te worden gestuurd. Dit scheelt uiteindelijk in de performance. Bij het maken van deze wrapper class moet de interface ‘Serializable’ worden geïmplementeerd.


19

Corba Common Object Request Broker Architecture (CORBA) is een protocol ontwikkeld door Object Management Group (OMG). CORBA is tot op zekere hoogte vergelijkbaar met RMI. Het grote verschil is dat CORBA niet alleen werkt in Java maar ook in een groot aantal andere ontwikkelomgevingen en platformen. Zo is het bijvoorbeeld ook mogelijk een Java server applicatie te laten communiceren met een client geschreven in C. Dit maakt CORBA niet alleen platform onafhankelijk, maar is ook in een groot deel van de talen te implementeren. Omdat CORBA met zoveel omgevingen samen kan werken is het hier en daar ook iets gecompliceerder om het werkend te krijgen. Dit zal later in dit hoofdstuk duidelijk worden.

De techniek In Corba worden alle objecten eigenlijk verpakt in een interface, en de enige manier om met de objecten te praten is door middel van deze interface.

Elk object wordt verpakt in een interface

Zodoende maakt het voor de client niet meer uit waar en op wat voor een machine een operatie wordt uitgevoerd. Het ‘verpakken’ van objecten gebeurd door een zogenaamde IDL-compiler. IDL staat voor Interface Definition Language. Aan de hand van deze taal kan de IDL-compiler IDLstubs (client-side) en IDL-skeletons (server-side) in elke gewenste taal creëren waarvoor een IDL-compiler beschikbaar is.

Hieronder volgt een voorbeeld van een IDL bestand: module remotetime { interface ExactTime { string getTime(); }; };


20

Deze kan vervolgens worden vertaald door een compiler naar code voor de client (de stub) en de code voor de server (het skeleton). Onderstaande afbeelding geeft weer hoe dit in zijn werk gaat:

De werking van een IDL-compiler

Er is nu een _ExactTimeImplBase object en een _ExactTimeStub. Onderstaande afbeelding geeft weer hoe de verdere communicatie tussen de Client en de Implementation verloopt.

Een veel gebruikt protocol dat de communicatie tussen de ORB’s verzorgt is IIOP, wat staat voor Internet Inter-ORB Protocol.


21

Voor de ontwikkelaar Hiervoor is al duidelijk aan bod gekomen hoe CORBA in zijn werk gaat, wat betreft het aanmaken van stubs en skeletons. In dit stukje voor de ontwikkelaar wil ik een tipje van de sluier oplichten over de verdere implementatie van deze stub en skeleton op de client en de server.

Allereerst moet op de server de implementatie van het skeleton worden geschreven. In het al eerder genoemde voorbeeld met de ExactTime server levert dat de volgende code op: class ExactTimeServer extends _ExactTimeImplBase { public String getTime() { return DateFormat.getTimeInstance(DateFormat.FULL). format(new Date(system.currentTimeMillis())); } }

Dan rest ons nog de code van de server, welke eigenlijk altijd op dezelfde manier werkt, namelijk als volgt: // Remote application implementation public class RemoteTimeServer { // Throw exceptions to console: public static void main(String[] args) throws Exception { // ORB creation and initialization: ORB orb = ORB.init(args, null); // Create the server object and register it: ExactTimeServer timeServerObjRef = new ExactTimeServer(); orb.connect(timeServerObjRef); // Get the root naming context: org.omg.CORBA.Object objRef = orb.resolve_initial_references(“NameService”); NamingContext ncRef = NamingContextHelper.narrow(objRef); // Assign a string name to the object reference (binding): NameComponent nc = new NameComponent(“ExactTime”,””); NameComponent[] path = { nc }; ncRef.rebind(path, timeServerObjRef); // Wait for client requests: java.lang.Object svnc = new java.lang.Object(); synchronized(sync){ sync.wait(); } } }


22

Client implementatie: public class RemoteTimeClient { // Throw exceptions to console: public static void main(String[] args) throws Exception { // ORB creation and initialization ORB orb = ORB.init(args, null); // Get the root naming context: orb.omg.CORBA.Object objRef = orb.resolve_initial_references(“NameService”); NamingContext ncRef = NamingContextHelper.narrow(objRef); // Get (resolve) the stringified object // reference for the time server NameComponent nc = new NameComponent(“ExactTime”,””); NameComponent [] path = { nc }; ExactTime timeObjRef = ExactTimeHelper.narrow(ncRef.resolve(path)); // Make requests to the server object: String exactTime = timeObjRef.getTime(); system.out.println(exactTime); } }

Ook hierbij is het raadzaam gebruik te maken van ‘Wrapper classes’, zoals dit in het laatste deel over RMI beschreven is.


23

RMI vs. CORBA Hieronder volgt een korte opsomming van eigenschappen van beide technieken, die kunnen helpen een keuze te maken tussen beide.

RMI

CORBA

RMI is eenvoudiger om mee te werken

RMI maakt het mogelijk om alle interfaces

CORBA interfaces dienen in IDL te worden

gewoon in java te schrijven

geschreven

RMI is ontworpen om te werken met objecten

CORBA is platform en ontwikkeltaal

die geschreven zijn in Java

onafhankelijk

RMI objecten worden automatisch afgebroken

CORBA objecten worden niet automatisch

door de garbage collector

door de garbage collector afgebroken


24

EJB De techniek Sun creëerde Enterprise JavaBeans (EJB) samen met een aantal andere technieken (JSP, JNDI, Connector Architecture) en biedt het geheel aan onder de naam Java 2 Enterprise Environment (J2EE). EJB’s zijn de kern van de bundel.

Om met een EJB te kunnen werken heb je een Bean Container of EJB Container nodig dat de EJB-productie omgeving creëert. Een voorbeeld hiervan is de applicatieserver JBoss, een open source product, met een eenvoudige grafische installatie, beschikbaar voor bijna ieder platform.

De EJB Middleware Component Standard is ontwikkeld voor de volgende doelen: •

• • • • •

Componenten laten samenwerken. Enterprise beans ontwikkeld op verschillende tools kunnen gewoon samenwerken. Ook zal een bean ontwikkeld met andere tools draaien in iedere EJB omgeving. Lifecycle issues opvangen, zoals ontwikkeling, deployment en runtime. Eenvoudig programmeer model met toegang tot low-level APIs. Compatibility met bestaande platformen wat ervoor zorgt dat bestaande producten kunnen worden aangevuld om EJB te ondersteunen. Om interactie mogelijk te maken met EJB en niet-Java applicaties. Om compatible te zijn met CORBA.

De focus van de EJB standaard is dus het creeren van een standaard voor Java middleware, om zo programmeurs te beschermen van de vele verschillende problemen het ontwikkelen van gedistribueerde applicaties. Hierdoor kan de softwareontwikkelaar zich beter concentreren op de business logica in plaats van het schrijven van ingewikkelde infrastructuur software met de bijbehorende tools.

Wanneer EJB? Het gebruik van EJBs s aan te raden bij: • • • • •

Er bestaat de kans dat het systeem binnen 5 jaar te groot wordt voor één machine. Bijvoorbeeld Hol.com besluit om ook DVD’s te gaan verkopen. Processortijd en geheugen 7zijn makkelijk beschikbaar. Het systeem wordt professioneel gebruikt, zoals bij Hol.com door de medewerkers. Het systeem bestaat uit meerdere lagen, zoals een databaselaag, presentatielaag, etc. Het communiceert met meerdere partijen, denk hier aan communicatie met de website, leveranciers, etc.

Voor de ontwikkelaar Installatie Enterprise JavaBeans (EJBs) zijn onderdeel van het Java Platform, Standard Edition (Java SE), deze kan gedownload worden vanaf de website8 als een pakket JDK (momenteel 5.0 Update 9). De installatie die wij uitgevoerd hebben verliep zonder problemen door het pakket uit te pakken en uit te voeren met de juiste rechten. 7

EJBs gebruiken meer geheugen en processor-capaciteit dan gewone Java classes.

8

http://java.sun.com/javase/


25

Om EJBs te kunnen gebruiken hebben wij de applicatie server JBoss9 gebruikt, de installatie is na de installatie van het JDK erg eenvoudig, namelijk: java -jar xxxx-installer.jar

Vervolgens kun je in het grafische installatie kiezen voor de optie EJB of EJB-clustering en dat is dan de hele installatie. Na de installatie is er een directory structuur die er zo uitziet:

JBoss directory structuur

Het geheel wordt opgestart door onder Linux in te typen: sh run.sh

of onder Windows: run.bat

Verder hebben we gebruik gemaakt van de omgeving Eclipse10 met een aantal plugins die het werken met JBoss, RMI, etc. mogelijk maakten. We hebben tijdens onze testen gebruik gemaakt van de OpenWorkbench 3.0, maar in de praktijk is het ons nog niet gelukt om een kale installatie werkend te krijgen. Mocht er dus gekozen worden voor een dergelijke opzet, dan moet hier rekening mee worden gehouden. Een mogelijke tip is de Lomboz 11plugin die zou kunnen werken onder Eclipse met een installatie handleiding die we op deze locatie hebben aangetroffen: http://www.tusc.com.au/tutorial/html/chap1.html

9

http://www.jboss.org http://www.eclipse.org/downloads/index.php 11 http://sourceforge.net/projects/lomboz 10


26

Gebruik Een EJB bestaat uit drie bronbestanden: • • •

Client interface (bean interface of remote interface genoemd) extends javax.ejb.EJBObject

Home interface (maak een EJB van het gewenste type) extends javax.ejb.EJBHome

Implementatie van de bean extends javax.ejb.EnterpriseBean

meestal via een van de drie standaardtypes: javax.ejb.SessionBean javax.ejb.EntityBean javax.ejb.MessageDrivenBean

De Bean Container of EJB Container legt het verband tussen de verschillende bestanden in ons geval is dat en creëert de omgeving voor de beans, wij hebben gebruik gemaakt van de applicatieserver JBoss die een Java Runtime Enviroment (JRE) nodig heeft om te werken.

Dit geheel wordt samengevoegd door een XML-bestand beter bekend als de deployment descriptor. Deze hebben we zelf een keer aangemaakt dmv de wizard in Eclipse die vervolgens het geheel in elkaar zet en opneemt in het bestand ejb-jar.xml.

Client interface Een client interface kan bestaan uit een local en een remote interface, omdat een local interface aangeroepen kan worden op de virtuele machine waar het EJB object zich bevindt. import java.rmi.RemoteException; import javax.ejb.EJBObject; public interface Service extends EJBObject { public void maakOrder(Order order) throws RemoteException; }

Home interface Het is net als bij een client interface mogelijk om twee implementaties te maken van deze interface, namelijk de gewone home interface en een local interface. Als de local interface gebruikt wordt hoeven er geen RMI-aanroepen gedaan te worden, wat weer scheelt in de snelheid. Het grootste nadeel hiervan is dat het geheel dan niet meer schaalbaar is en transparant, iets wat wij persoonlijk altijd proberen te voorkomen. import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface ServiceHome extends EJBHome { Service create() throws RemoteException, CreateException; }


27

Bean implementatie Dit is een gewone class die de functionaliteit van de home en de client interface implementeert. Bijvoorbeeld zo: import java.rmi.RemoteException; import javax.ejb.SessionBean; import javax.ejb.SessionContext; public class ServiceBean implements SessionBean { public void maakOrder(Order order) { // code here } public public public public public

void void void void void

ejbCreate() {} ejbRemove() {} ejbActivate() {} ejbPassivate() {} setSessionContext(SessionContext sc) {}

}

EJB conclusie Enterprise JavaBeans (EJBs) zijn schaalbaar en betrouwbaar. Bovendien zijn ze eenvoudiger te maken dan een CORBA implementatie. Jammer genoeg is de installatie van de ontwikkelomgeving Eclipse in combinatie met de juiste plugins niet makkelijk uit te voeren, hier kunnen gemakkelijk problemen ontstaan. Verder is het maken van een deploy van de gemaakte Beans nogal een verwarrend voor mensen die nog geen XML ervaring hebben en die de JBoss server voor het eerst zien. Waar staat het, hoe configureer je het, wat moet ik aanklikken en waarom moet dat zo ging er bij ons meer als geregeld door het hoofd. De applicatie draait niet op dezelfde manier als een standaard Java applicatie, maar via de JBoss applicatie server wat in eerste instantie een vreemd gevoel is.

Wat ons verder is opgevallen is dat de hoeveelheid termen en verschillende tools die nodig zijn nogal afschrikkend werken, het duurde bijvoorbeeld erg lang voordat het duidelijk werd dat JBoss een applicatie server is waarin de EJBs worden gedeployed. De ontwikkelaar moet zelf een deploy descriptor aanmaken en deze door een speciale handeling in de omgeving op de juiste plek krijgen. Als de ontwikkelaar gewend is aan deze concepten lijkt het een erg fijne manier van werken met zeker fijne eigenschappen voor het onderhoud, maar in eerste instantie heeft het dus een hoge leercurve en schrikt het geheel af door de omvang. Zelf hebben wij voor het werken met EJBs en JBoss drie12 boeken aangeschaft, verscheidene websites bezocht en meerdere Linux installaties ondergaan, maar het geheel nog niet werkend gekregen. Gelukkig dat er een volledige ontwikkelomgeving klaarstond anders hadden we dit niet kunnen uitvoeren.

12

De volgende titels: - JBoss “A Developers Notebook” - JBoss at Work “A Practical Guide” - Mastering Enterprise JavaBeans 3.0


28

Literatuurlijst Mastering Enterprise JavaBeans™ 3.0 ISBN-10: 0-471-78541-5

Middletier Development Syllabus ICA

What is Middleware http://middleware.objectweb.org/

Wiki: Message-oriented middleware http://en.wikipedia.org/wiki/Message_Oriented_Middleware

Installing and Building the JBoss Server http://docs.jboss.org/jbossas/jboss4guide/r2/html/ch01.html

RMI http://java.sun.com/developer/onlineTraining/rmi/RMI.html#RMIArchitectureGoals CORBA http://wwwbruegge.in.tum.de/teaching/ss02/DistComp/Slides/Oliver.pdf


29

Index

A AJAX................................................................ 8 asynchronous programming.............................. 8

C CORBA .......................................................2, 28

D deploy descriptor ............................................ 28 Distributed objects .......................................... 12

E EAI .........See Enterprise Application Integration Eclipse ............................................................ 26 EJB ................... 2, 28, See Enterprise JavaBeans Enterprise Application Integration.................. 13 Enterprise JavaBeans ...................................... 25 ERP................................................................. 12 exception......................................................... 10

I IDL ................................................................. 20 IIOP ................................................................ 21 Interface .......................................................... 15

J J2EE................................................................ 25 J2EE Connector Architecture.......................... 13 Java Database Connectivity ............................ 12 Java Platform, Standard Edition...................... 25 Java SE .......See Java Platform, Standard Edition JBoss............................................................... 12 JCA .................See J2EE Connector Architecture JDBC ................ See Java Database Connectivity JDK................................................................. 25 JMS................................................................. 13

M Message-oriented middleware...........................8 Messaging ......................................................... 8 middleman ..................................................... 8, 9 Middleware........................................................ 2 MOM.......... See - Message-oriented middleware monitoring .......................................................14 MSMQ.............................................................13

O OLE DB ..........................................................12 OMG ...............................................................20 ORB ................................................................21

R recovery...........................................................14 Registry ...........................................................15 Remote Procedure Call......................................8 RMI ............................................................... 2, 8 RMI-IIOP ........................................................10 RPC ..........................See Remote Procedure Call

S Skeleton...........................................................15 Stub .................................................................15 Synchroon .......................................................11

T Transactional Middleware ...............................12

W Wrapper class ..................................................19

X XML.......................................................... 13, 27

L load balancing................................................. 14


30

Adviesrapport Hol.com

Recommend Documents