[web app] Stukken business logic als jobs afhandelen

[flowerp]

Ik werk aan een web applicatie waarin eigenlijk twee soorten acties voorkomen:

1) De user doet een request en er moet informatie getoond worden
2) De user geeft het systeem een opdracht voor iets wat niet direct een resultaat terug geeft.

Een voorbeeld van 1 is iets standaards als "alle producten in het systeem opvragen", terwijl 2 bijvoorbeeld een bestelling is.

In mijn systeem gebeurd er afhankelijk van de user van alles en nog wat na een bestelling. Er gaan onder andere 4 emailtjes uit (naar account manager, naar user zelf, naar admin en naar aanbieder van dat produkt). Daarnaast runt er nog een zooi aan andere business logic.

Het punt is dat in de traditionele web applicaties er meestal sprake is van een request die geheel afgehandeld word, waarna de user een bedank pagina of iets dergelijks te zien krijgt. Nu is het natuurlijk zo dat de user hier eigenlijk helemaal niet op hoeft te wachten. Nadat alle validaties zijn doorlopen zou de user meteen de bedankt pagina kunnen krijgen, terwijl de rest van de code asynchroon doorloopt.

In Java zou ik bijvoorbeeld een gedeelte van de business logic als een Quartz job kunnen schedulen. De response time is veel lager en dus de ervaring voor de user beter. Tevens is de web bak weer sneller beschikbaar om nieuwe requests af te handelen.

Helaas zijn er ook nadelen. Mocht er onverhoopt toch nog wat fout gaan in de business logic, dan kan ik daar de user niet meer van op de hoogte brengen. Elke user begrijpt dat als ie een error page krijgt de actie waarschijnlijk niet gelukt is, maar na een bedankt pagina gegeven te hebben kun je user niet 5 minuten later lastig vallen (bv via email) dat het toch niet goed ging.

Erger is het geval dat de machien die de busines logic uitvoert er onverhoopt mee stopt. De job gaat dan verloren en de user komt hier niet snel achter. Nu heeft Quartz bv wel de mogelijkheid om jobs in een DB op te slaan, maar dat continu opslaan van jobs geeft dan weer extra load die zeker in het geval van kleine jobs de overhead niet waard is.

Zijn er hier mensen die (een deel van) hun systeem op een dergelijke wijze hebben opgezet en hier hints & tips over hebben?

[-FoX-]

Als ik de beschrijving van jouw probleem even doorlees, is het eerste wat in mij opkomt MDB (message driven beans). Het is aangeraden om bij het gebruik van een container ook gebruik te maken van message-driven beans. Een andere manier zou het gebruik van threads in de hand werken; maar ik denk dat dit beter vermeden kan worden in de container. MDB bieden een handige en makkelijke manier aan om berichten te verwerken en de nodige database wijzigingen aan te brengen onder een globale transactie.

Het Spring framework voorziet, vanaf zijn 2.0 release, ook support voor asynchrone messaging. Misschien is het handig om hier ook eens naar te kijken.

[remcotolsma]

Je zou de gebruikers van de web applicaties ook een melding kunnen geven dat de 'opdracht' nu wordt uitgevoerd en dat ze over enkele minuten een bericht krijgen of dit geslaagd is of niet. Je kunt er ook bij vermelden dat ze verder kunnen surfen binnen de web applicaties / website.

Met behulp van AJAX kun je dan om een bepaalde tijd 'vragen' of de betreffene 'opdracht' geslaagd is of niet. Zodra de opdracht is voltooid is en een resultaat bekend is kun je een melding geven op het scherm van de gebruiker (met behulp van JavaScript)

Dit heeft wel als nadeel dat wanneer de gebruiker de web applicatie / website toch verlaat hij ook geen resultaat heeft terug gekregen. Eventueel zou je dan nog een e-mail kunnen versturen...

[JKVA]

Ik heb de indruk dat je het heel moeilijk wilt oplossen.

1. Is het niet een idee om eerst een "transactie/job/o.i.d." in een database op te slaan.
2. Dan ga je je acties verrichten
3. En als die klaar zijn update je je database met de gegevens over de transactie. (een aangepaste status bijvoorbeeld)

Bij een fout kun je ook allemaal kanten op, aangezien elke zichzelf respecterende API gewoon netjes Exceptions opgooit of iig foutcodes, aan de hand waarvan je ook acties kunt verrichten, zoals de status van de transactie bijwerken of een mailtje sturen o.i.d.

Of denk ik nu te makkelijk en zie de helft over het hoofd???

[megamuch]

Ik zou de user altijd een ok terug geven (als de betreffende request tenminste ok is). Gaat er wat fout dan zou ik de applicatie zo bouwen, dat je de businesslogic opnieuw kan uitvoeren.

bijv.
Als de mail server eruit ligt, is niet van belang voor de user. Zodra hij weer up is, zou jouw systeem gewoon moeten verder gaan waar hij gebleven was. Ik weet niet wat voor businesslogic er nog meer op de achtergrond gebeurt, maar ik zou toch de jobs opslaan totdat ze daadwerkelijk ok zijn bevonden. Dan kan je ze discarden.