[Java] MD5 checksum berekenen over data

[Standeman]

Ik heb een systeem dat elke minuut een product catalogus verstuur van server A naar server B via een webservice. Belangrijk is dus dat op server B dezelfde catalogus aanwezig is als op A (met het verschil van een minuut). Op deze manier wordt de catalogus dus gesynchroniseerd.

Op zich werkt het prima, maar ik vind het niet zo efficient. Wat ik eigenlijk wil gaan doen is via diezelfde webservice op server B een MD5 checksum van deze product catalogus opvragen, daarna deze zelf berekenen op server A op basis van de originele data en wanneer hij niet klopt pas de hele catalogus versturen. (Ik zou ook nog een delta kunnen maken tussen beide catalogussen, maar dat is net iets te veel werk voor de tijd die ik heb).

Ik zat te denken om alle velden die in een product catalogus zitten te concatteneren tot 1 grote string en daar een MD5 hash van te maken die ik dan kan vergelijken.

Ik vroeg me af of dit wel een handige manier is?

[RobIII]

Standeman schreef op vrijdag 21 augustus 2009 @ 13:10:
...<snip>...maar dat is net iets te veel werk voor de tijd die ik heb...<snip>...Ik vroeg me af of dit wel een handige manier is?

Niet echt. Waarom gebruik je niet gewoon een replicatie mogelijkheid van je DBMS ofzo? Die kan vaak "realtime" je gegevens op A en B gelijk houden. Sowieso lijkt het versturen van de complete catalogus iedere minuut me wat overkill; tenzij je een catalogus van 3 producten hebt ofzo
En gebruik je geen DBMS dan kun je misschien nog wel op filesystem niveau replicatie gebruiken (a-la DFS ofzo). Kort: Is er niet veel simpeler iets op te zetten met bestaande oplossingen i.p.v. zelf gaan zitten prutsen? Waarom moeilijk doen als 't makkelijk kan?

[ Voor 27% gewijzigd door RobIII op 21-08-2009 13:26 ]

[Mammon]

Is het niet veel makkelijker om op server A een lijstje bij te houden met wat veranderd is en dan deze veranderingen door te sturen?

[matthijsln]

En gewoon de laatste datum van wijziging bijhouden?

Dus zoiets als conditional GET in HTTP, maar dan voor je webservice. Als je webservice REST is kan je conditional GET (Last-Modified en If-Modified-Since) gewoon al gebruiken.

[Standeman]

RobIII schreef op vrijdag 21 augustus 2009 @ 13:23:
[...]

Niet echt. Waarom gebruik je niet gewoon een replicatie mogelijkheid van je DBMS ofzo? Die kan vaak "realtime" je gegevens op A en B gelijk houden. Sowieso lijkt het versturen van de complete catalogus iedere minuut me wat overkill; tenzij je een catalogus van 3 producten hebt ofzo
En gebruik je geen DBMS dan kun je misschien nog wel op filesystem niveau replicatie gebruiken (a-la DFS ofzo). Kort: Is er niet veel simpeler iets op te zetten met bestaande oplossingen i.p.v. zelf gaan zitten prutsen? Waarom moeilijk doen als 't makkelijk kan?

Alles gaat via een webservice omdat Server A bij een klant ergens ver weg staat en server B bij ons. Replicatie gaat dus niet lukken omdat de servers alleen via een HTTP protocol bij elkaar kunnen komen.

Mammon schreef op vrijdag 21 augustus 2009 @ 13:24:
Is het niet veel makkelijker om op server A een lijstje bij te houden met wat veranderd is en dan deze veranderingen door te sturen?

Ik heb geen toegang tot het applicatie mee waar de productcatalogus wordt ingevoerd / gewijzigd (is van de klant). Ik mag alleen selecties doen op de (access) database in een aantal specifiek tabellen. Om een wijziging te detecteren zal ik dan alsnog een MD5 hash moeten maken van de data (denk ik) en deze met elkaar vergelijken.

[roy-t]

Kun je er niet voor zorgen dat Server A de transfer initieert, er worden maar aan 1 kant dingen veranderd neem ik aan. Je kunt het ook nog op te lossen door bij een request van b alleen "OK" terug te sturen als alles nog het zelfde was, en anders de hele catalogus.

[Borizz]

Standeman schreef op vrijdag 21 augustus 2009 @ 13:51:

Ik heb geen toegang tot het applicatie mee waar de productcatalogus wordt ingevoerd / gewijzigd (is van de klant). Ik mag alleen selecties doen op de (access) database in een aantal specifiek tabellen. Om een wijziging te detecteren zal ik dan alsnog een MD5 hash moeten maken van de data (denk ik) en deze met elkaar vergelijken.

En je kan in die selectie niet aangeven dat je alleen producten wil zien die gewijzigd zijn na een bepaalde datum + tijd??

[Standeman]

Borizz schreef op zaterdag 22 augustus 2009 @ 17:10:
[...]


En je kan in die selectie niet aangeven dat je alleen producten wil zien die gewijzigd zijn na een bepaalde datum + tijd??

Helaas niet. Dat zou wel enorm makkelijk zijn geweest.

[Standeman]

*schopje*

Misschien nog mensen met interessante ideëen?

[Confusion]

Wij gebruiken in eenzelfde situatie de hashcode van het catalogus object (door JAX-WS gegenereerd; hashcode() is geimplementeerd) . Bij ieder request dat de client doet, stuurt hij de hashcode van 'zijn' catalogus mee. Als er een nieuwere catalogus, met een andere hashcode, beschikbaar is, dan verschillen de hashcodes en krijgt de client bericht dat hij een nieuwe catalogus op moet halen.

Omdat er teveel wijzigingen waren en de client te vaak 'haal een nieuwe catalogus' te horen kreeg, zijn we later een hashcode per product gaan gebruiken: zo kunnen er ondanks wijzigingen succesvol producten verkocht worden. Er hoeft alleen een nieuwe catalogus gehaald te worden als er een product verkocht gaat worden waar iets aan gewijzigd is.

[Standeman]

Ik was in de veronderstelling dat method implementaties van objecten niet beschikbaar zijn bij de client. Of hebben jullie hashcode() in de bean zelf geimplementeerd (of als attribute in de bean staan).

Ik moet eerlijk bekennen dat JAX-WS nog niet helemaal in de vingers heb.

[Confusion]

Standeman schreef op vrijdag 28 augustus 2009 @ 10:37:
Ik was in de veronderstelling dat method implementaties van objecten niet beschikbaar zijn bij de client.

Dat zijn ze ook niet: de waarde wordt gewoon als los veld meegestuurd in de response op de getCatalogue() WS call (waarin een lijst producten zit, die per product ook weer een hashcode veld heeft) en vervolgens wordt in iedere purchaseProduct() call de hashcode van zowel de catalogue als het product meegestuurd.

(In werkelijkheid is het proces iets complexer; er zit bijvoorbeeld een stap met reserveringen tussen en er kan enige tijd tussen een reservering en een aankoop zitten).

[Standeman]

Ah, ik snap het helemaal. Ik denk dat het zelfde soort mechanisme ga gebruiken. Imo is het de meest elegante oplossing die ik in deze omstandigheden kan vinden.