- CORBA
Inhoudsopgave Hoofdstuk 1.RMI...2 1.1.Inleiding...2 1.2.De remote...4 1.3.Het remote...5 1.4.De server...6 1.5.De server opstarten...8 1.6.De client applicatie...8 1.7.De stub en skeleton en...10 1.8.De client opstarten...11 1.9.Callbacks...11 1.10.Classloading en security...14 1.11.RMI en firewalls...18 1.11.1.Communicatiepoorten instellen...18 1.11.2.HTTP protocol...19 Hoofdstuk 2.CORBA & RMI-IIOP...20 2.1.CORBA...20 2.2.JAVA IDL...21 2.2.1.De definiëren...22 2.2.2.De vertalen naar JAVA bestanden...22 2.2.3.De server ontwikkelen...24 2.2.4.De client ontwikkelen...25 2.2.5.Client en server opstarten...26 2.3.RMI-IIOP...27 2.3.1.De code...28 2.3.2.Compilatie en generatie van de stubs/skeletons...32 2.3.3.Het opstarten van de applicaties...33 2.3.4.IDL genereren...33 Copyright 2012 Noël Vaes - 1 - www.noelvaes.eu
1.1. Inleiding Hoofdstuk 1. RMI RMI is de afkorting van Remote Method Invocation. Het is een technologie waarbij het mogelijk is dat een in de ene virtuele machine een methode aanroept van een ander in een andere virtuele machine. Deze technologie wordt gebruikt bij gedistribueerde applicaties voor de communicatie tussen client en server. De client en de server bevinden zich in een verschillende virtuele machine en doorgaans ook op een verschillend systeem. De communicatie tussen beide 's gebeurt hierbij via het netwerk op basis van JRMP (Java Remote Method Protocol) dat gebaseerd is op TCP/IP. Client machine Server machine Client Remote JRMP TCP/IP netwerk In bovenstaande tekening wordt op eenvoudige wijze weergegeven hoe het ene een methode oproept van een ander (remote ) in een andere virtuele machine. De parameters worden hierbij door het RMI-subsysteem over het netwerk doorgestuurd naar de andere virtuele machine waar de methode door het het remote wordt uitgevoerd. Eventuele resultaten worden op dezelfde manier via het netwerk teruggegeven aan het oproepende. We gaan nu deze communicatie en de achterliggende systemen wat meer in detail bekijken. Een remote is een dat zijn functionaliteit van op afstand (remote) ter beschikking stelt. Dit wil zeggen dat dit een aantal methoden heeft die opgeroepen kunnen worden door een in een andere virtuele machine. Deze methoden moeten gedefinieerd worden in een afzonderlijke die afgeleid is van java.rmi.remote. Het remote dient deze te implementeren. Aan de client zijde krijgt het client- een stub- ter beschikking dat dezelfde implementeert. Dit stub- dient als proxy om de methode-aanroep over het netwerk door te sturen naar de server. De server beschikt over een skeleton- dat communiceert met het stub- Copyright 2012 Noël Vaes - 2 - www.noelvaes.eu
en de meegegeven parameters in ontvangst neemt. Het stub- zal op zijn beurt de methode van het remote oproepen. Eventuele teruggegeven waarden worden door het skeleton- teruggegeven aan het stub- dat deze op zijn beurt aflevert aan het client-. Client machine Server machine Client stub skeleton Remote JRMP TCP/IP netwerk Voor de communicatie tussen client en server zijn dus volgende elementen nodig: 1. De remote die bepaalt welke functionaliteit door het remote ter beschikking wordt gesteld. Deze wordt geïmplementeerd door het remote en het stub-. 2. Een remote dat deze implementeert en de concrete implementatie voorziet. 3. Een skeleton- dat de oproep van het stub- in ontvangst neemt en de methode van het remote aanroept. 4. Een stub- dat de remote implementeert en de methode-aanroep via het netwerk doorstuurt naar het skeleton-. 5. Een client- dat een methode van het stub- oproept. De remote, het remote en het client- moeten door de programmeur ontwikkeld worden. Het stub- en skeleton- worden ofwel gegenereerd door de RMI compiler ofwel dynamisch aangemaakt door de (vanaf Java 5). Nu rijst de vraag hoe het client- een referentie kan bekomen naar een stub dat overeenkomt met een skeleton- op de juiste server. Zo'n referentie kan op twee manier bekomen worden: 1. Via een return-waarde van een of andere methode. Eens een referentie naar een stub- in een beschikbaar is, kan die als parameter doorgegeven worden. Blijft dan de vraag hoe de eerste keer deze referentie bekomen wordt. 2. De eerste referentie naar een stub- wordt bekomen via het RMI register. Dit RMI register is een applicatie die doorgaans draait op de server waar het remote zich bevindt. Dit remote moet zich in dit register registreren. Vervolgens kan een remote client een referentie opzoeken in dit register. Het RMI Copyright 2012 Noël Vaes - 3 - www.noelvaes.eu
register stelt vervolgens een juist geconfigureerd stub- ter beschikking. opzoeken Server machine RMI register Client machine registreren Client stub skeleton Remote JRMP TCP/IP netwerk In het vervolg van dit hoofdstuk zullen we aan de hand van een voorbeeld de details van RMI onder de loep nemen. 1.2. De remote De eerste stap in het ontwikkelen van een client-server applicatie is het definiëren van de remote. Deze bepaalt welke methoden beschikbaar worden gesteld door remote en. Remote s moeten aan de volgende voorwaarden voldoen: 1. Ze moeten afgeleid zijn van java.rmi.remote. Dit is een marker- zonder methoden. Ze dient enkel om aan te geven (te markeren) dat en die deze implementeren remote en zijn. Dit zorgt ervoor dat deze en op een speciale manier behandeld kunnen worden door het RMI subsysteem. We komen hier later nog op terug. 2. Iedere methode van de remote moet een java.rmi.remoteexception gooien. De reden hiervoor is dat iedere methodeaanroep via het netwerk gebeurt en dat er steeds het risico bestaat dat er communicatieproblemen optreden. Dergelijk problemen worden steeds gemeld via deze RemoteException. 3. Alle parameters van de methoden moeten ofwel serialiseerbaar zijn, ofwel zelf remote en zijn. Serialiseerbare en worden immers via het serialisatie-mechanisme over het netwerk doorgestuurd van de stub naar het skeleton. In het skeleton wordt het terug gedeserialiseerd. Dit impliceert overigens dat de server steeds werkt met een gedeserialiseerde kopie van het originele dat als parameter werd meegegeven. Men noemt dit om deze reden ook call-by-value. Voor remote en liggen de zaken anders. Hier wordt het niet geserialiseerd maar wordt een nieuw stub- (op de server) en skeleton- (op de client) gecreëerd. De server krijgt m.a.w. een referentie naar een stub- Copyright 2012 Noël Vaes - 4 - www.noelvaes.eu
. Iedere methode-aanroep wordt bijgevolg doorgestuurd naar het remote op de client. We noemen dit daarom ook call-by-reference. 4. Ook alle return-waardes van de methoden moeten ofwel serialiseerbaar zijn, ofwel remote en zijn. Als voorbeeld gaan we een chat-applicatie ontwikkelen met een chat-server en chatclient. Als eerste stap moeten we een remote definiëren voor een chatbox. Maar eerst definiëren we een voor de boodschappen die we naar de chatbox sturen: package be.noelvaes.chat; import java.io.serializable; public Message extends Serializable{ public String gettext(); public String getusername(); } Vermits een boodschap over het netwerk geserialiseerd wordt, leiden we de af van de Serializable. Alle implementerende klassen zijn daardoor in principe ook serialiseerbaar. In deze voorzien we enkel methoden om de boodschap en de naam van de gebruiker op te vragen. Voorts definiëren we de remote voor de chatbox: package be.noelvaes.chat; import java.rmi.*; public ChatBox extends Remote { public void sendmessage(message msg) throws RemoteException; } Deze is afgeleid van java.rmi.remote en tevens gooit de enige methode een java.rmi.remoteexception. Opdracht 1: De remote definiëren Maak in je IDE een nieuw JAVA-project met de naam ChatBox. Voorzie een folder src voor de broncode en een folder build/classes voor de gecompileerde klassen. Stel de IDE ook op de juiste wijze in. Maak de Message en compileer. Maak de ChatBox en compileer. 1.3. Het remote Het remote moet de functionaliteit van de remote implementeren. Op dit moment houden we deze functionaliteit heel eenvoudig. We laten de chatbox de ontvangen boodschap gewoon afdrukken in de console. Later gaan we dit uitbreiden zodat alle aangemelde gebruikers een boodschap ontvangen. Copyright 2012 Noël Vaes - 5 - www.noelvaes.eu