[java] communicatie tussen servers

[B-Man]

Ik ben bezig met de ontwikkeling van een gedistribueerde applicatie, die zal gaan draaien op meerdere machines. Ik heb al aardig wat zaken gelezen over CORBA, JMS, RMI, en consorten, en zie door de bomen het bos niet meer.

Er zitten verschillende soorten nodes in het systeem:

database nodes: Machines waar een databaseserver op draait, met hierop een eigen java interface die een verbinding met de management interface onderhoud, en verbindingen met de verschillende worker nodes onderhoud. Data toegang moet scalable zijn. Worker nodes krijgen door de management node een database node toegewezen. Database updates (SQL UPDATE queries dus) worden naar de management node verzonden, die ze verzend naar alle actieve database nodes, om ervoor te zorgen dat de database nodes in sync blijven. Worker nodes krijgen hun data direct van de aan hun toegewezen database nodes.

management nodes: een hoofd node + een backup node. Onderhoud verbindingen met alle overige nodes, en verzorgt de distributie van opdrachten. Houd tevens een lijst bij waarin staat welke opdracht op welke node uitgevoerd wordt.

worker nodes: verwerken opdrachten na verstrekking door de management node.

Ik wil het systeem hot-pluggable maken, m.a.w.: zodra ik een nieuwe worker node of database node aanzet, meldt deze zich aan bij de management node, en wordt deze nieuwe node opgenomen in de betreffende pool van nodes.

Ik kan de distributie van opdrachten naar nodes op verschillende manieren aanpakken: m.b.v. objecten: de opdrachten in een class inpakken, en deze naar de nodes distribueren, of een message-based systeem waarin een worker bijvoorbeeld een opdracht-ID krijgt, en de bijbehorende opdracht via de toegewezen database node kan opvragen...

De vraag waar ik mee rondloop is: wat voor protocol kan ik het beste gebruiken van intra-server communicatie ?

[MisterData]

Ik gebruik voor dat soort zaken altijd RMI, omdat dat gewoon het makkelijkst werkt. CORBA is imho onhandig en als je toch alleen met Java werkt, waarom dan niet gewoon RMI

[B-Man]

Oke. Ik las echter dat RMI aardig wat overhead heeft... Ik ben op zoek naar een protocol dat erg snel is. De applicatie gaat bij topdrukte (naar schatting) zo'n 25-40 berichten per worker node voor zijn kiezen krijgen.

Daarom ben ik aan het overwegen om zelf een simpel systeem te maken wat met Sockets werkt, maar dit is niet per se nodig, aangezien op rustige momenten dan ook sockets openstaan. Daarnaast moet de management node dan erg veel sockets afhandelen.

JMS ziet er wat dat betreft erg interessant uit, maar gezien het feit dat ik met geen van de genoemde protocollen ervaring heb, staat mijn vraag hier.

[reddog33hummer]

een mogenlijkheid is hier om XML-RPC te gebruiken of mischien zelfs soap.

met soap heb je de voordeel dat het implementatie independend is en over http of smtp gaat.

bij de andere zit je vaak aan 1 programeertaal of os vast.

met soap kan je ook bijvoorbeeld .net, java, perl php enz. allemaal aansluiten.

soap is language independend (xml)

[B-Man]

Oke. Ik ben echter niet op zoek naar een language independent protocol, gezien het feit dat alle nodes in java geimplementeerd zijn.

[Alarmnummer]

Ik denk dat SOAP ook vele malen trager is dan RMI door de vertaal slagen en de controles. Ik weet trouwens niet hoeveel langzamer RMI tov Sockets is want RMI is een laag over Sockets heen? (is niet zoveel met sockets en rmi bezig).

[B-Man]

Ik denk ook dat SOAP veel trager zal zijn, met name door de overhead van taalonafhankelijkheid.

RMI: weet het nog niet. JMS is erg interessant omdat ik dan ook publieke queues kan definieren, zodat ik bijvoorbeeld een melding aan alle worker nodes tegelijk kan verzenden.

[MisterData]

Op vrijdag 22 maart 2002 15:38 schreef Alarmnummer het volgende:
Ik denk dat SOAP ook vele malen trager is dan RMI door de vertaal slagen en de controles. Ik weet trouwens niet hoeveel langzamer RMI tov Sockets is want RMI is een laag over Sockets heen? (is niet zoveel met sockets en rmi bezig).

Volgens mij is RMI zelfs een laag over CORBA heen

[Alarmnummer]

RMI is zeker geen laag over Corba heen.

[mbravenboer]

Maar RMI ondersteunt wel het IIOP van CORBA. In feite moet je RMI scheiden in een standaard notatie voor gedistribueerde systemen en een implementatie, met daarbij het protocol.

Op dit moment ondersteunt RMI vooral zijn originele protocol: JRMP (Java Remote Messaging Protocol) en IIOP (Internet Inter-Orb Protocol). Ik ben zelf bezig met een SOAP implementatie. Ik ben zelf bezig met een SOAP implementatie voor samenwerking met .NET Remoting. Dit toont wel aan dat RMI volledig protocol onafhankelijk kan functioneren. Als je dus een CORBA applicatie wilt maken, kan je best van de RMI kijk op de zaak gebruik maken.

Over het algemeen verstaat men onder het gebruik van RMI dus vaak het gebruik van JRMP, wat vergeleken met SOAP haast wel een stuk sneller moet zijn.

[MisterData]

Misschien kun je JXTA gebruiken. Volgens dit artikel is JXTA precies wat je nodig hebt. Het is een API om P2P applicaties te ontwikkelen. In het artikel schrijft men o.a. dit:

At its core JXTA is simply a protocol for inter-peer communication. Each peer is assigned a unique identifier (peer ID). Each peer belongs to one or more peer groups in which the peers cooperate and function similarly and under a unified set of capabilities and restrictions. JXTA provides protocols for the basic functions -- create groups, find groups, join and leave groups, monitor groups, talk to other groups and peers, share content and services -- all of which are performed by publishing and exchanging XML advertisements and messages between peers.

IMHO best interresant, en het is open-source www.jxta.org

[The - DDD]

Ik zie dat je 35 tot 40 opdrachten per node verwacht. Afhankelijk van de omvang wat betreft data van 1 zo'n opdracht kan het aantal opdrachten verwaarloosbaar klein zijn. Hangt echter af van wat je precies stuurt.

Punt is dat je kijkt naar wat belangrijk is om te optimaliseren. Wordt er echt veel data over het netwerk gezet, ja dan heeft een low-level protocol misschien zin. Is echter de daadwerkelijk resulterende transactie omvangrijk dan kun je beter jezelf daarop richten.

In ieder geval...

RMI is in mijn ervaring een erg compact protocol mits je van JRMP gebruik maakt, dat is java only RMI. Zodra je IIOP gaat gebruiken krijg je inderdaad een behoorlijke dosis overhead.

Ik wil niet veel zeggen, maar is misschien een J2EE opzet niet wat. Ik heb geen idee van wat precies de problematiek is die je moet oplossen, maar het is maar een idee.

Wat je ook zou kunnen doen is gebruik maken van Servlets... Servlet? Ja servlets. Je kan namelijk ook je eigen servlet overerven zodat je niet http gebonden bent. Maar alles hangt af van wat jij precies voor doelen hebt voor het product.

[Verwijderd]

Op vrijdag 22 maart 2002 14:56 schreef B-Man het volgende:
Ik ben bezig met de ontwikkeling van een gedistribueerde applicatie, die zal gaan draaien op meerdere machines. Ik heb al aardig wat zaken gelezen over CORBA, JMS, RMI, en consorten, en zie door de bomen het bos niet meer.

Er zitten verschillende soorten nodes in het systeem:

database nodes: Machines waar een databaseserver op draait, met hierop een eigen java interface die een verbinding met de management interface onderhoud, en verbindingen met de verschillende worker nodes onderhoud. Data toegang moet scalable zijn. Worker nodes krijgen door de management node een database node toegewezen. Database updates (SQL UPDATE queries dus) worden naar de management node verzonden, die ze verzend naar alle actieve database nodes, om ervoor te zorgen dat de database nodes in sync blijven. Worker nodes krijgen hun data direct van de aan hun toegewezen database nodes.

management nodes: een hoofd node + een backup node. Onderhoud verbindingen met alle overige nodes, en verzorgt de distributie van opdrachten. Houd tevens een lijst bij waarin staat welke opdracht op welke node uitgevoerd wordt.

worker nodes: verwerken opdrachten na verstrekking door de management node.

Ik wil het systeem hot-pluggable maken, m.a.w.: zodra ik een nieuwe worker node of database node aanzet, meldt deze zich aan bij de management node, en wordt deze nieuwe node opgenomen in de betreffende pool van nodes.

Ik kan de distributie van opdrachten naar nodes op verschillende manieren aanpakken: m.b.v. objecten: de opdrachten in een class inpakken, en deze naar de nodes distribueren, of een message-based systeem waarin een worker bijvoorbeeld een opdracht-ID krijgt, en de bijbehorende opdracht via de toegewezen database node kan opvragen...

De vraag waar ik mee rondloop is: wat voor protocol kan ik het beste gebruiken van intra-server communicatie ?

B-Man,
kun je mij meelen op [e-mail] ???

[B-Man]

Op zaterdag 23 maart 2002 18:22 schreef The - DDD het volgende:
Ik zie dat je 35 tot 40 opdrachten per node verwacht. Afhankelijk van de omvang wat betreft data van 1 zo'n opdracht kan het aantal opdrachten verwaarloosbaar klein zijn. Hangt echter af van wat je precies stuurt.

Punt is dat je kijkt naar wat belangrijk is om te optimaliseren. Wordt er echt veel data over het netwerk gezet, ja dan heeft een low-level protocol misschien zin. Is echter de daadwerkelijk resulterende transactie omvangrijk dan kun je beter jezelf daarop richten.

In ieder geval...

RMI is in mijn ervaring een erg compact protocol mits je van JRMP gebruik maakt, dat is java only RMI. Zodra je IIOP gaat gebruiken krijg je inderdaad een behoorlijke dosis overhead.

Ik wil niet veel zeggen, maar is misschien een J2EE opzet niet wat. Ik heb geen idee van wat precies de problematiek is die je moet oplossen, maar het is maar een idee.

Wat je ook zou kunnen doen is gebruik maken van Servlets... Servlet? Ja servlets. Je kan namelijk ook je eigen servlet overerven zodat je niet http gebonden bent. Maar alles hangt af van wat jij precies voor doelen hebt voor het product.

De omvang zal per bericht verschillen.

Binnen mijn app zijn twee typen berichten te onderscheiden:

- opdrachten
- gegevens

De eerste soort zal erg klein zijn (een paar regels tekst hooguit). De tweede soort kan groot zijn, maar dit is niet per definitie zo. (5 regels min, 100 - 250 max). Er gaat geen binary data heen en weer.

Een gegevens-bericht wordt alleen verzonden als reactie op een opdracht (het antwoord/resultaat). Niet iedere opdracht resulteert in een antwoord.

JMS ziet/zag er interessant uit / maar is gecentraliseerd. Ik wil een systeem dat geen centrale server nodig heeft, zodat nodes hier niet afhankelijk van zijn.

[B-Man]

Op zaterdag 23 maart 2002 18:22 schreef The - DDD het volgende:
Wat je ook zou kunnen doen is gebruik maken van Servlets... Servlet? Ja servlets. Je kan namelijk ook je eigen servlet overerven zodat je niet http gebonden bent. Maar alles hangt af van wat jij precies voor doelen hebt voor het product.

Doel je ipv J2EE soms op EJB ? Ik neem aan van wel.

Ik denk inderdaad dat voor een aantal zaken EJB's interessant zijn. Servlet zijn in deze context een beetje het kleine broertje van EJB's, of niet ?

[MisterData]

Op maandag 08 april 2002 18:05 schreef B-Man het volgende:

[..]

De omvang zal per bericht verschillen.

Binnen mijn app zijn twee typen berichten te onderscheiden:

- opdrachten
- gegevens

De eerste soort zal erg klein zijn (een paar regels tekst hooguit). De tweede soort kan groot zijn, maar dit is niet per definitie zo. (5 regels min, 100 - 250 max). Er gaat geen binary data heen en weer.

Een gegevens-bericht wordt alleen verzonden als reactie op een opdracht (het antwoord/resultaat). Niet iedere opdracht resulteert in een antwoord.

JMS ziet/zag er interessant uit / maar is gecentraliseerd. Ik wil een systeem dat geen centrale server nodig heeft, zodat nodes hier niet afhankelijk van zijn.

Kijk anders eens naar JINI Dat is niet geheel gedecentraliseerd, maar kan zijn servers automatisch vinden en kun je emt behulp van JavaSpaces hele interresante distributed-compute systemen maken (check www.javaworld.com maar es op de serie "make room for javascapes" daar leggen ze een dergelijk systeem haarfijn uit). Ik ben er nu mee bezig en ik kan je zeggen dat JavaSpaces niet moeilijk is. Het werkt met RMI en daardoor kun je gewoon objecten heen-en-weer zenden. Wil je 'echte' P2P (gedecentraliseerd) dan zull je dus echt naar JXTA moeten kijken (www.jxta.org)

[B-Man]

Ik zit nu de serie artikelen over javaspaces (op javaworld.com) te lezen, en het ziet er zeker interessant uit!

Ik zit met verschillende de zaken de centraal danwel decentraal geregeld moeten zijn in mijn gedistribueerde app. Zo zal er een globaal warehouse (data store) moeten zijn waarin gegevens staan die nodig zijn bij het uitvoeren van taken. Hier kan een java space interessant voor zijn. Ik heb echter nog niet gelezen waar de data ie "in" de javaspace zit, "opgeslagen" is. Als dat op een centrale server is, is dat een SPOF.

Daarnaast zal een een queue zijn met taken, die door de worker nodes uitgevoerd moeten worden. Voor de taken geld echter dat deze in een bepaalde volgorde uitgevoerd moeten worden. Per taak houd het systeem bij wanneer de betreffende taak uitgevoerd moet worden. In de huidige situatie weet het systeem ook waar de taak wordt uitgevoerd. Vanuit een simpele front-end kan een gebruiker nl. de queue bekijken en taken annuleren.

Kortom: in ben er nog niet uit. Ik heb het model al een maand of drie in mijn hoofd zitten (globaal), en langzaam maar zeker begint het technisch gezien duidelijk te worden hoe ik het kan gaan implementeren/realiseren.

--

Nog iets waar ik rekening mee wil houden is scalability over verschillende clusters. Dit hoeft niet direct in de versie te zitten die ik nu aan het concepten ben, maar ik ben al wel aan het kijken hoe dit te realiseren kan zijn.
De app. zal na realisatie van de komende versie op een cluster draaien op een locatie. Ik wil echter dat het systeem in een later stadium ook schaalbaar moet kunnen zijn over meerdere lokaties (en clusters dus).

[MisterData]

Op dinsdag 09 april 2002 14:55 schreef B-Man het volgende:
Ik zit nu de serie artikelen over javaspaces (op javaworld.com) te lezen, en het ziet er zeker interessant uit!

Ik zit met verschillende de zaken de centraal danwel decentraal geregeld moeten zijn in mijn gedistribueerde app. Zo zal er een globaal warehouse (data store) moeten zijn waarin gegevens staan die nodig zijn bij het uitvoeren van taken. Hier kan een java space interessant voor zijn. Ik heb echter nog niet gelezen waar de data ie "in" de javaspace zit, "opgeslagen" is. Als dat op een centrale server is, is dat een SPOF.

Dat staat inderdaad niet echt duidelijk in die tutorial Maar ik denk dat het op de JavaSoft site wel te vinden is

Daarnaast zal een een queue zijn met taken, die door de worker nodes uitgevoerd moeten worden. Voor de taken geld echter dat deze in een bepaalde volgorde uitgevoerd moeten worden. Per taak houd het systeem bij wanneer de betreffende taak uitgevoerd moet worden. In de huidige situatie weet het systeem ook waar de taak wordt uitgevoerd. Vanuit een simpele front-end kan een gebruiker nl. de queue bekijken en taken annuleren.

Lees deel 6 maar es, daar hebben ze het over een systeem met van die queue's (Channels heten dat blijkbaar)

[B-Man]

Bedankt voor de tip, ik ga nu verder met deel 3, reageer wel weer als ik deel 6 gelezen heb.

[B-Man]

hmmm... "Make room for javaspaces" gaat maar t/m deel 5, en daar behandelen ze meerdere spaces, maar geen queues of channels.

Tevens las ik net dat javaspaces niet gedistribueerd over meerdere JVM's of machines werken... En dat is juist wat ik -als ik zou kiezen voor een data store- zou willen gebruiken.

[Verwijderd]

Ik vroeg me idd ook af 'waar' die javaspaces nou waren, maar dat staan dus helemaal aan het eind in deel 5: een javaspace draait slechts op 1 machine in 1 JVM! Dat is dus helaas wel een SPOF en dus wel bale. Wat ze zelf meteen als DE oplossing geven is om gewoon meerdere spaces te maken waarna je vervolgens het Jini protocol weer gebruikt om alle spaces op te vragen. Nu moet je zelf helaas wel de code schrijven als als client alle relevante spaces in de gaten te houden en als server alle spaces up to date te houden. Dat je dit allemaal zelf moet doen is natuurlijk wel jammer omdat er best wel wat complicaties kunnen optreden (client kan zelfde task/entry meerdere malen krijgen uit verschillende spaces, hoe krijg je een space in sync nadat hij uitgevallen is,etc,etc), maar goed, het moet natuurlijk allemaal niet TE makkelijk worden natuurlijk

Ik zit erover te denken JavaSpaces te gaan gebruiken in een productie omgeving waarbij de twee belangrijkste eisen stabiliteit (lijkt me wel goed te zitten omdat je dingen gemakkelijk (muv de spaces zelf dus) redundant uit kunt voeren) en snelheid zijn. Aangezien een paar tiende seconden het verschil kunnen maken dus veel winst of verlies ( <= beurshandel) en het moet gaan concurreren met een C++ + raw sockets applicatie vraag ik me af of deze oplossing veel langzamer zal zijn. Iets langzamer is niet erg aangezien je op deze manier gewoon wat extra servers kunt inpluggen die het snelheidsverschil hopelijk kunnen compenseren, maar ik vrees eigenlijk dat het een heel stuk trager zal zijn ... Iemand ervaring mee???

edit:

Oeps vergeten op refresh te drukken en je laatste post dus niet gezien...Je had dat van die meerdere spaces dus zelf ook al gezien...

[Verwijderd]

Als je de search trouwens gebruikt is er wel een deel 6!

[MisterData]

Op dinsdag 09 april 2002 17:02 schreef B-Man het volgende:
hmmm... "Make room for javaspaces" gaat maar t/m deel 5, en daar behandelen ze meerdere spaces, maar geen queues of channels.

Tevens las ik net dat javaspaces niet gedistribueerd over meerdere JVM's of machines werken... En dat is juist wat ik -als ik zou kiezen voor een data store- zou willen gebruiken.

Deel zes is er zekers wel Zoeken op "JavaSpaces" op JavaWorld en dan goed kijken

[B-Man]

Oeps inderdaad, er is wel een deel 6. Ben ik nu aan het lezen.

Tot dusver echter nog niets over het type lijst waar ik mee wil werken: mijn queue moet niet fifo zijn...
Als er een nieuwe taak wordt toegevoegd, heeft deze een timestamp, op basis van deze timestamp wordt de taak in de queue ingevoegd. Een worker haalt vervolgens de taak van de queue, die een timestamp heeft die gelijk is aan de huidige timestamp (of een timestamp in het verleden).

[B-Man]

Zo, ik weet nu ongeveer wat RMI, JINI, JXTA en JavaSpaces zijn.

Ik ben er nog steeds niet uit

Ik denk dat ik het als volgt op ga lossen:

- communicatie tussen management nodes onderling, management nodes en database nodes en management nodes en worker nodes implementeren m.b.v. JMS of JavaSpaces. Het gaat hier slechts om het verzenden van opdrachten. Ik moet ook gemakkelijk een opdracht kunnen verzenden naar alle worker nodes, of alle database nodes.
- communicatie tussen worker nodes en database nodes m.b.v. RMI. Gezien het feit dat ik geen hardcoded SQL queries in mijn worker nodes wil hebben, roept een worker nodes simpelweg een functie aan op een database node, die een object byValue teruggeeft.

Het gehele systeem P2P maken, en dus alle distributie-logica in de worker- en database-nodes verwerken lijkt me aardig complex worden, i.t.t. het onderbrengen van deze logica op een centraal punt: een management node, die redundant uitgevoerd kan worden.

Kunnen jullie me wat hints/tips geven m.b.t. het gebruik van RMI?

[B-Man]

#^*&$^

RMI ?

Kan ik met RMI eigenlijk het volgende:

In een worker node lopen verschillende Threads die simultaan "vragen" moeten kunnen stellen aan een toegewezen database node.
Kan ik ervoor zorgen dat deze "vragen" (m.a.w.: functie aanroepen) niet serieel maar parallel worden uitgevoerd m.b.v. RMI?

Ik lees net dat, zodra de RMI server meerdere aanvragen ontvangt van dezelfde client, deze serieel verwerkt...
Hoe kan ik dit oplossen ? Meerdere connecties naar de RMI server ? Het aantal Threads wisselt (er worden nieuwe Threads gestart indien nodig, en indien de server dit qua belasting nog trekt), en het mag dus niet te veel tijd kosten om een nieuwe Thread te starten.
Daarnaast wil ik de verbinding naar een database node wat de code betreft eigenlijk niet implementeren in een Thread, maar in het proces dat deze Threads managed...

volgen jullie me nog ?

[MisterData]

Over die timestamps : Je kan toch een Entry in een JavaSpace maken met een attribuut time en die entries dan ophalen met behulp van zo'n template (ben ik nog te volgen ? ). Dat is niet moeilijk RMI is ook niet moeilijk. Je moet gewoon even de vele tutorials doorlezen (heb ik ook gedaan)en dan kom je er wel uit

[B-Man]

Op vrijdag 12 april 2002 16:27 schreef MisterData het volgende:
Over die timestamps : Je kan toch een Entry in een JavaSpace maken met een attribuut time en die entries dan ophalen met behulp van zo'n template (ben ik nog te volgen ? ). Dat is niet moeilijk RMI is ook niet moeilijk. Je moet gewoon even de vele tutorials doorlezen (heb ik ook gedaan)en dan kom je er wel uit

Ja, dat kan. Maar JavaSpaces zijn voor mijn queue problematiek op een worker node niet interessant. Ik hoef de queue namelijk niet tussen verschillende JVM's te delen. Ik kan dus net zo goed een Vector of LinkedList gebruiken.

Het gaat dan ook niet zozeer om de afhandeling binnen een node, maar om de communicatie tussen de nodes. En dan met name paralle communicatie.

[B-Man]

Heb zojuist wat boeken besteld, om me nog wat verder in de materie in te lezen:

Concurrent programming in Java - Doug Lea
Distributed programming in Java - Q. Mahmoud
Jini - Kumaran, Ilango