[JAVA] Applicatie: welke technieken?

[verytallman]

Ik wil een applicatie maken die bestaat uit backend en frontend. De backend moet 24/7 draaien op een server omdat daar continue taken op uitgevoerd worden. De frontend moet een website zijn die direct contact heeft met de business laag van de backend.

Deze applicatie moet mijn huidige Java SE applicatie vervangen die gebruikt maakt van MVC. Aangezien ik al ervaring heb met Java wil ik Java gaan gebruiken. Ook zou ik graag gebruik willen maken van Spring en Hibernate omdat ik deze frameworks wil leren.

Ik heb al veel gelezen over allerlei technieken (EJB/GWT/Spring/JSF/JSP) maar ik weet niet welke combinatie van technieken/frameworks ik kan gebruiken om te bereiken wat ik wil. Ik zoek een duwtje in de juiste richting welke technieken ik moet gebruiken. Best practices zeg maar.

Zelf denk ik dat mijn backend moet bestaan uit Spring+Hibernate en de frontend(web) JSP. Beide draaien dan op dezelfde Glassfish server. Maar misschien dat iemand hier een betere combinatie van technieken weet.

[CodeCaster]

Voor de communicatie tussen de processen (server/client) is IPC een mooie zoekterm.

REST/SOAP is hip anno nu, maar wellicht wat overkill (lees: overhead) als het toch op dezelfde machine draait en er geen andere processen van buitenaf bij hoeven te kunnen.

[Verwijderd]

Ik kan qua duwtje helaas weinig bieden, wel zou ik graag meedoen / helpen bij het maken van dit alles. De genoemde technieken wil ik zelf ook onder de knie krijgen.

Zou je richting mij even iets kunnen laten weten als je er geen bezwaar tegen hebt dat ik mee doe?

Een PM zou geweldig zijn.

-- Om toch ook wat inhoudelijks bij te dragen:--

De geringe ervaring die ik heb zou ik tomcat + jsp + spring + hibernate doen.

Waarom tomcat ipv glasshfish? In mijn ervaring werkt dit net iets beter. (Glasshfish duurt het inloggen al eeuwen)

[verytallman]

@ CodeCaster: IPC heb ik zelf ook al eerder voorbij zien komen. Maar ik weet niet hoe ik dit in combinatie met bijvoorbeeld Spring/Hibernate/Glassfish kan gebruiken
@ simolokid: dit is voor mij een hobbyproject voor in de late uurtjes, maar de resultaten van het project stuur ik je graag op

[matthijsln]

verytallman schreef op woensdag 04 mei 2011 @ 20:09:
Zelf denk ik dat mijn backend moet bestaan uit Spring+Hibernate en de frontend(web) JSP. Beide draaien dan op dezelfde Glassfish server. Maar misschien dat iemand hier een betere combinatie van technieken weet.

Dit lijkt me een prima keuze. Misschien quartz als je continu taken wilt uitvoeren. Tip voor hibernate is om JPA annotaties te gebruiken.

CodeCaster schreef op woensdag 04 mei 2011 @ 20:15:
Voor de communicatie tussen de processen (server/client) is IPC een mooie zoekterm.

REST/SOAP is hip anno nu, maar wellicht wat overkill (lees: overhead) als het toch op dezelfde machine draait en er geen andere processen van buitenaf bij hoeven te kunnen.

Hij heeft al een desktop app en wil er juist een webapp van maken, dus dan wil je juist geen ipc. Ik zou eerst gewoon eens beginnen met HTML die door JSP's wordt gemaakt. Wil je dynamisch updates dan zou ik dat eerst doen met Ajax en JSON, bijvoorbeeld met jQuery.

Ik zou IPC, EJB, SOAP juist willen scharen onder de dingen die je niet zou moeten willen gebruiken Zijn te complex voor deze situatie en er zijn simpelere alternatieven voorhanden.

_{Voor een web mvc framework heb je enorme keus, mijn persoonlijke favoriet is Stripes}

[ Voor 6% gewijzigd door matthijsln op 04-05-2011 20:47 ]

[Verwijderd]

verytallman schreef op woensdag 04 mei 2011 @ 20:29:
@ simolokid: dit is voor mij een hobbyproject voor in de late uurtjes, maar de resultaten van het project stuur ik je graag op

Ondertusse kan ik ook andere dingen doen, bv. codeigniter php uitzoeken o.i.d.

Hobbyproject voor in de late uurtjes klinkt prima !

Ik heb zelf een vps, en aan je ts te lezen denk ik te kunnen gokken dat jij ook een eigen omgeving hebt.

Doe dus nog steeds graag mee

[RobIII]

Erg concreet is 't niet en ik vrees dat 't op een "post hier je favo combo frameworks/technieken/paradigma's/insert_whatever_here" wordt. Ik wil dus graag wat onderbouwing zien als mensen zaken gaan aandragen.
Onder voorbehoud laat ik 't topic nog open dus; met een schopje richting SEA (Welke programmeertaal moet ik leren?)

@simolokid: werving is bij ons niet gewenst; "jezelf werven" eigenlijk net zo min. Als je dan toch interesse hebt, hou 't dan uit 't topic en DM de TS even daarover.

[ Voor 22% gewijzigd door RobIII op 04-05-2011 20:52 ]

[Fuzzillogic]

matthijsln schreef op woensdag 04 mei 2011 @ 20:44:
[...]
Hij heeft al een desktop app en wil er juist een webapp van maken, dus dan wil je juist geen ipc. Ik zou eerst gewoon eens beginnen met HTML die door JSP's wordt gemaakt. Wil je dynamisch updates dan zou ik dat eerst doen met Ajax en JSON, bijvoorbeeld met jQuery.

Zou ik niet doen. Webtech is prima voor simpele form/table based GUIs, maar zodra het wat interessanter wordt loop je al snel tegen het feit aan dat HTML helemaal niet bedoeld is voor desktop-GUIs. En die overdaad aan libraries daarvoor maken het ook niet bepaald makkelijker en al helemaal niet beter. Mocht je toch webtech willen gebruiken, dan kun je eens kijken naar Wicket.

Java's WebStart vind ik toch bijzonder prettig, ook als gebruiker. Wat mij betreft is dat redelijk ideaal voor applicaties: zero-config install, altijd up-to-date, cross platform, een echte applicatie dus snel en gui's die werken zoals het hoort, en de mogelijkheid om offline te draaien. Het verbaast me echt dat het niet veel vaker gebruikt wordt.

Mbt RPC: vergeet good old RMI niet. Een Java-native manier van werken waar bij de communicatie zelf eigenlijk volledig geabstraheerd is. SOAP, XMLRPC, JSON-RPC en weet ik het zijn pas interessanter als je client een andere techniek gebruikt dan server, of als je meerder soorten clients gaat gebruiken.

[matthijsln]

Fuzzillogic schreef op woensdag 04 mei 2011 @ 20:58:
[...]
Webtech
[...]
Java's WebStart

Ik ben het met je eens dat er aan webapps ook nadelen zitten, zoals die er ook zijn voor jws. Maar zonder meer concrete input van wat de TS wil bereiken dan gaan we inderdaad een beetje een algemene discussie houden zoals RobIII zegt.

[verytallman]

Ik zal proberen wat meer input te geven. De desktop java app die ik nu heb voert taken uit die elk uur gestart worden dmv een timer. Deze taken worden achtereenvolgens uitgevoerd (zijn threads). Een voorbeeld van een taak: het ophalen van rss feeds. Daarnaast heeft de app velen views om gegevens in te voeren, die weer worden opgeslagen in een mysql database. Zo moet ik bijvoorbeeld feeds kunnen toevoegen of bewerken.

Voor de nieuwe app: het invoeren/bewerken van bijvoorbeeld feeds moet op de frontend(web) gebeuren. Ook moet de frontend de lijst van taken laten zien die worden uitgevoerd. De frontend is dus de interface van de backend. De backend voert alleen taken uit.

De reden van de nieuwe opzet/app is dat ik vanuit elke willekeurige pc de app wil kunnen benaderen. Ook wil ik de backend 24/7 laten draaien, iets wat op mijn eigen pc niet kan.

Ik geef graag meer informatie. Vraag maar raak

[ Voor 25% gewijzigd door verytallman op 04-05-2011 21:47 ]

[Varienaja]

Scheid je backend in een 'interface'-laag en een 'implementatie'-laag. In de interface definieer je de diverse services (denk aan een persistentie-service, een rss-verwerk-service, een scheduling-service). In de implementatie-laag, je raadt het al, implementeer je die dingen. De verschillende services kan je als Spring-beans vormgeven en laten starten.

Voor de presentatie creëer je een derde laag. Deze mag compile-time alleen van de interface-laag afhankelijk zijn. Maar runtime hang je natuurlijk je eigen implementatie eronder.

Dit is (heel) in het kort hoe wij op ons werk web-apps ontwikkelen. We gebruiken Hibernate/Spring op een JBoss applicatieserver. Voor de presentatie maken we gebruik van Echo3, maar daar ben ik absoluut geen fan van, als ik mocht kiezen werd het Tapestry5.

[verytallman]

@Varienaja: klinkt erg interessant. Alleen klinkt het erg conceptueel op dit moment. Met Spring/Hibernate maak ik de drie lagen? Heeft deze (programmeer)methode een bepaalde naam? Hoe leg ik de verbinding tussen Tapestry5/Echo3 en de backend?

[OrbitZ]

Play! Framework is voor een beginner een goed startpunt. De documentatie is vrij goed en er worden verschillende technologieën standaard ondersteund (MVC, JPA - Hibernate, Unit test, etc).

De leercurve is mijns inziens bij Play Framework een stuk eenvoudiger dan Tapestry/Spring.

http://www.playframework.org/

[tweakerbee]

Spring Framework heeft in ieder geval goede documentatie. Als je al bekend bent met het concept van Inversion of Control zul je de basis snel begrijpen. Spring integreert ook netjes met Quartz maar wellicht kun je het af met simpele JDK timer support. Bekijk hiervoor zeker eens de documentatie van Spring's scheduling. En lees deze blogpost. Voor het binnenhalen van de feeds kun je een library naar keuze gebruiken, die code zou je moeten kunnen hergebruiken vanuit je huidige project. Als web framework kun je ook kiezen wat je wilt, maar de meest eenvoudig optie is waarschijnlijk toch Spring WebMVC. Hierbij kun je ook uit verschillende presentatietechnieken kiezen, waarbij JSP misschien wel de makkelijkste is.

Begin met het lezen van de Spring documentatie, en bedenk wat je allemaal wilt doen met je applicatie. Bouw het dan stukje voor stukje op. Als je niet in een dependency hell terecht wilt komen kan ik je ook van harte aanraden om met Maven2 aan de slag te gaan.

[ Voor 0% gewijzigd door tweakerbee op 09-05-2011 15:11 . Reden: miste een woord ]

[Verwijderd]

verytallman schreef op woensdag 04 mei 2011 @ 21:40:
Ik zal proberen wat meer input te geven. De desktop java app die ik nu heb voert taken uit die elk uur gestart worden dmv een timer. Deze taken worden achtereenvolgens uitgevoerd (zijn threads). Een voorbeeld van een taak: het ophalen van rss feeds. Daarnaast heeft de app velen views om gegevens in te voeren, die weer worden opgeslagen in een mysql database. Zo moet ik bijvoorbeeld feeds kunnen toevoegen of bewerken.

Voor de nieuwe app: het invoeren/bewerken van bijvoorbeeld feeds moet op de frontend(web) gebeuren. Ook moet de frontend de lijst van taken laten zien die worden uitgevoerd. De frontend is dus de interface van de backend. De backend voert alleen taken uit.

De reden van de nieuwe opzet/app is dat ik vanuit elke willekeurige pc de app wil kunnen benaderen. Ook wil ik de backend 24/7 laten draaien, iets wat op mijn eigen pc niet kan.

Ik geef graag meer informatie. Vraag maar raak

Lang verhaal kort: je wil een webapplicatie maken met Java Dat is een erg brede vraag. Ik zou me richten op een van de frameworks tegelijk, want spring, hibernate, gwt / JSP allemaal tegelijk oppakken in een project is teveel.

GWT - een apparaat van Google dat Java omzet in Javacript. Met GWT kun je rich internet applications maken in Javascript, zonder dat je Javascript hoeft te schrijven.

Hibernate - een ORM / persistence laag.

Spring - een applicatieframework / IOC container

Ik ben zelf met Hibernate begonnen, omdat ik het zat was om steeds dezelfde SQL te moeten schrijven en om steeds objecten uit mijn query resultaat te moeten maken.

Ik zou zeggen, bepaal wat het belangrijkste onderdeel is dat je anders wil doen, verdiep je wat in die drieletterafkortingen en bepaal wat je leuk vindt om te leren, dan kunnen de mensen hier er wel een framework bij roepen.

Sowieso is er voor de algemene applicatie die je beschrijft geen unieke combinatie aan frameworks of technologien benodigd. Je kunt wat je beschrijft zelfs allemaal in 1 groot PHP bestand schrijven als je zou willen. Het gaat er dus vooral om wat je wil leren.

[ Voor 8% gewijzigd door Verwijderd op 10-05-2011 16:45 ]

[JKVA]

Ik kan niet zien welke versie van GlassFish je gebruikt, maar ik zou adviseren om bij de standaard Java frameworks te blijven (JSP/Servlets of JSF + EJB3 of CDI + JPA). Hiermee minimaliseer je de hoeveelheid configuratiewerk en JAR hell, omdat de server je dan al een groot aantal diensten aanbiedt. Het scheelt je een hoop integratiewerk.

Ook zaken als timers zitten gewoon in Glassfish (en ook in EJB).

Ik denk dat je dan de laagste drempel hebt, maar wel met een moderne technology stack waarop je in de toekomst verder kunt bouwen.

Spring+Hibernate+webframework+GlassFish+Maven integreren is vaak zelfs voor ervaren Javanen lastig, dus ik zou niet adviseren om meteen met zo'n stack te beginnen.

Eventueel kun je wel voor Maven kiezen en met een archetype een template applicatie genereren. Dat scheelt je veel uitzoekwerk.

Zie ook een voorbeeld van een Java EE 6 app: http://github.com/martijn...mo/tree/master/cigar-shop
Deze app vereist Glassfish 3.1.

[verytallman]

JKVA schreef op dinsdag 10 mei 2011 @ 16:49:
Zie ook een voorbeeld van een Java EE 6 app: http://github.com/martijn...mo/tree/master/cigar-shop

Zit hier ook documentatie bij?

[JKVA]

verytallman schreef op woensdag 11 mei 2011 @ 20:27:
[...]

Zit hier ook documentatie bij?

Nope. Dit was onderdeel van een presentatie die ik samen met een collega heb gegeven bij mijn vorige werkgever. De uitleg van de code stond voor een deel in de slides. Het was overigens alleen maar een demo van de nieuwe technologieën in Java EE 6, de architectuur (en functionaliteit) hebben we een beetje uit de duim gezogen ghehe. Ook was het geen Glassfish of Maven cursus ofzo. Dat was voorkennis voor die presentatie. Maar de code an sich geeft wel een idee hoe je een Java EE 6 app kunt bouwen.

Als je de sources uitchecked, met maven build en deployed op een kale Glassfish appserver, ga je zeker een foutmelding krijgen. Je moet o.a. JavaMail instellen, maar ik zou zeggen, commentarieer die code gewoon uit. Je hebt voorlopig toch vast geen mail nodig. Verder kun je volgens mij de default Glassfish DataSource gebruiken voor de database.

Deployen naar Glassfish kan met de admin console (bereikbaar onder poort 4848 meen ik) of vanuit je IDE. Wij gebruikten IntelliJ, maar Eclipse zal ook wel goed werken denk ik.

Ik zou zeggen, probeer het gewoon eens te builden en runnen. Dan heb je werkende code voor je die je kunt debuggen/begrijpen/aanpassen/fröbelen/etc. Scheelt je veel werk en van daaruit kun je verder kijken naar je eigen probleemdomein.

[verytallman]

We zijn alweer een tijdje verder en ik heb de kans gehad om mij meer te verdiepen in Spring/JSP/JPA/Hibernate. Leercurve is wat stijl maar het is erg leerzaam geweest tot nu toe.

Vooruitblikkend heb ik gegoogled naar de mogelijkheden van threads in J2EE. Het is namelijk de bedoeling dat ik inlog op de website, een thread start, vervolgens de browser afsluit maar dat de thread blijft doorgaan. Op elk moment dat ik inlog op de website wil ik zien welke threads bezig zijn en wat hun status is. De google search voor J2EE+threads is geen goede voorbode. Is het zinvol om met J2EE door te gaan voor deze requirements, of verspil in mijn tijd en kan het toch beter een desktop app worden?

De reden dat ik mijn desktop app wil vervangen met een J2EE oplossing is omdat ik mijn app 24/7 wil laten draaien en op elke willekeurige pc de app kan benaderen.

[bomberboy]

Als ik het zo lees denk ik dat je misschien gewoon een webservertje in je bestaande applicatie embedden?

Maar misschien moet je ook eens in meer detail vertellen wat je eigenlijk wil bereiken en wat de concrete vereisten zijn. Want met een backend/frontend, MVC en "het moet draaien op een server" (welke server? hosting? welk soort? j2ee hosting is bv relatief duur in vergelijking met webhosting)
Ik denk trouwens ook niet dat je naar J2EE op zoek bent (tegenwoordig is het trouwens JavaEE ipv J2EE)

In ieder geval zonder meer concrete info kan er niemand je op een gefundeerde manier iets aanraden.

[ Voor 3% gewijzigd door bomberboy op 18-08-2011 03:22 ]

[CodeCaster]

Het kán wel, maar een webserver is eigenlijk gewoon niet bedoeld voor langlopende processen. En als je één proces vanuit verschillende plekken wil benaderen wordt het helemaal tricky (voor elke hit of sessie wordt immers een andere thread opgestart, en die onderling laten communiceren is niet makkelijk).

Waarom niet gewoon een dedicated applicatie/service/daemon/giveitaname maken die altijd draait en de gegevensverwerking voor je doet, die je vervolgens vanuit je webapplicatie aanspreekt middels, goh, eeh, IPC?

[ Voor 11% gewijzigd door CodeCaster op 18-08-2011 09:12 ]

[verytallman]

Met de kennis van nu zal ik nog is vertellen wat ik precies wil bereiken. Met de desktop applicatie die ik nu heb kan ik gegevens in een database wijzigen en taken toevoegen die vervolgens als thread worden uitgevoerd. Ik zal een voorbeeld hiervan geven: in mijn database staat een tabel met gegevens over websites (het adres, de titel, commentaar, enz). In mijn applicatie kan ik websites toevoegen en bewerken. Daarnaast kan ik een taak toevoegen om deze websites om het uur te bezoeken, hiervoor wordt een thread gemaakt omdat deze taak ongeveer 5 minuten duurt. Ik kan aangeven of deze taak herhaald moet worden of oneindig moet worden uitgevoerd. Naast deze taak zijn er nog 5 taken (en threads dus) die worden uitgevoerd. In een tabel worden de taken weergeven die op dat moment worden uitgevoerd. In die tabel kan ik ook taken stoppen.

Om twee redenen wil ik deze desktop applicatie omzetten naar een JavaEE app:
- Ik wil de applicatie overal op elke computer kunnen benaderen
- De taken moeten 24/7 worden uitgevoerd, en ik wil mijn pc niet constant aan laten om zo de desktop applicatie te laten draaien

De taken moeten doorgaan wanneer ik mijn browser sluit. Wanneer ik op een andere computer de website bezoek, wil ik de taken zien die op dat moment worden uitgevoerd.

De JavaEE applicatie moet het liefst draaien in de Tomcat container, omdat ik dan mijn QNAP NAS kan gebruiken (daar draait Tomcat op).

[Remus]

verytallman schreef op woensdag 17 augustus 2011 @ 20:12:
We zijn alweer een tijdje verder en ik heb de kans gehad om mij meer te verdiepen in Spring/JSP/JPA/Hibernate. Leercurve is wat stijl maar het is erg leerzaam geweest tot nu toe.

Vooruitblikkend heb ik gegoogled naar de mogelijkheden van threads in J2EE. Het is namelijk de bedoeling dat ik inlog op de website, een thread start, vervolgens de browser afsluit maar dat de thread blijft doorgaan. Op elk moment dat ik inlog op de website wil ik zien welke threads bezig zijn en wat hun status is. De google search voor J2EE+threads is geen goede voorbode. Is het zinvol om met J2EE door te gaan voor deze requirements, of verspil in mijn tijd en kan het toch beter een desktop app worden?

De reden dat ik mijn desktop app wil vervangen met een J2EE oplossing is omdat ik mijn app 24/7 wil laten draaien en op elke willekeurige pc de app kan benaderen.

Misschien kan dit topic op stackoverflow je helpen: http://stackoverflow.com/...-a-code-block-or-a-method

Dit beschrijft @Asynchronous in meer detail: http://java.sun.com/devel...avaEE6Overview_Part3.html

[ Voor 5% gewijzigd door Remus op 18-08-2011 15:23 ]

[CodeCaster]

verytallman schreef op donderdag 18 augustus 2011 @ 15:04:
De taken moeten doorgaan wanneer ik mijn browser sluit.

Nogmaals, als je denkt dat het proces wat jou een webpagina laat zien (dus bijvoorbeeld een php-script, een IIS-applicatie of iets wat je in Tomcat hebt gemaakt) moet blijven draaien nadat je de browser sluit, zit je mis. In ieder geval wel als je daarna nog invloed wil hebben op dat proces.

Het kán wel, maar bijvoorbeeld in het geval van PHP: als dat proces (zeg, process.php?pid=123) bezig is, en je wil het cancellen (met bijvoorbeeld een POST naar stopprocess.php?pid=123), dan moet je dus zorgen dat de php-interpreter van stopprocess.php contact zoekt met de interpreter van process.php. En dat is lastig te realiseren, omdat het op de server ook twee aparte processen zijn.

Het kán wel, maar dan moet process.php telkens bijvoorbeeld de database query'en, memcache vragen, of via APC het shared memory uit te lezen om te kijken of het proces wat hij aan het verwerken is dermate van status is veranderd dat hij ermee moet stoppen. Deze status kun je vanaf een andere pagina wel zetten.

Maar dat is PHP. Als je met Tomcat stateful kunt werken en threads daarbinnen kunnen elkaar makkelijk benaderen, dan wordt het uiteraard een ander verhaal, maar ik begreep uit je eerdere posts dus al dat dat lastig is.

Als je dus gewoon één proces maakt wat onafhankelijk en eeuwig draait (en wellicht opgestart wordt bij een systeemstart, middels cron), kun je met je webinterface dit proces beïnvloeden door API-calls als int StartProcess(), process[] GetProcessList(), GetProcessStatus(int pid) en StopProcess(int pit), of door je statustabel bij te werken, die het verwerkingsproces telkens uitleest.

Remus schreef op donderdag 18 augustus 2011 @ 15:19:
[...]


Misschien kan dit topic op stackoverflow je helpen: http://stackoverflow.com/...-a-code-block-or-a-method

Ook dat is een optie, dat je vanuit de webinterface dus een thread opstart (die door blijft draaien) die hetzelfde doet als het proces-script uit mijn bovenstaande voorbeeld.

[ Voor 14% gewijzigd door CodeCaster op 18-08-2011 15:23 ]

[Remus]

CodeCaster schreef op donderdag 18 augustus 2011 @ 15:20:
[...]

Nogmaals, als je denkt dat het proces wat jou een webpagina laat zien (dus bijvoorbeeld een php-script, een IIS-applicatie of iets wat je in Tomcat hebt gemaakt) moet blijven draaien nadat je de browser sluit, zit je mis. In ieder geval wel als je daarna nog invloed wil hebben op dat proces.

Het kán wel, maar bijvoorbeeld in het geval van PHP: als dat proces (zeg, process.php?pid=123) bezig is, en je wil het cancellen (met bijvoorbeeld een POST naar stopprocess.php?pid=123), dan moet je dus zorgen dat de php-interpreter van stopprocess.php contact zoekt met de interpreter van process.php. En dat is lastig te realiseren, omdat het op de server ook twee aparte processen zijn.

Het kán wel, maar dan moet process.php telkens bijvoorbeeld de database query'en, memcache vragen, of via APC het shared memory uit te lezen om te kijken of het proces wat hij aan het verwerken is dermate van status is veranderd dat hij ermee moet stoppen. Deze status kun je vanaf een andere pagina wel zetten.

Maar dat is PHP. Als je met Tomcat stateful kunt werken en threads daarbinnen kunnen elkaar makkelijk benaderen, dan wordt het uiteraard een ander verhaal, maar ik begreep uit je eerdere posts dus al dat dat lastig is.

Als je dus gewoon één proces maakt wat onafhankelijk en eeuwig draait (en wellicht opgestart wordt bij een systeemstart, middels cron), kun je met je webinterface dit proces beïnvloeden door API-calls als int StartProcess(), process[] GetProcessList(), GetProcessStatus(int pid) en StopProcess(int pit), of door je statustabel bij te werken, die het verwerkingsproces telkens uitleest.


[...]

Ook dat is een optie, dat je vanuit de webinterface dus een thread opstart (die door blijft draaien) die hetzelfde doet als het proces-script uit mijn bovenstaande voorbeeld.

Advies gebaseerd op PHP voor een Java webapplicatie is nou niet echt het beste. In tegenstelling tot PHP is er één process dat de requests afhandelt en evt asynchrone zaken afhandelt. Herhaalde requests praten dus ook tegen precies hetzelfde proces. Het is dus zeker wel mogelijk om invloed uit te oefenen op andere threads of taken die door een Executor worden uitgevoerd.

[CodeCaster]

Dat zeg ik zelf toch ook al?

Maar dat is PHP. Als je met Tomcat stateful kunt werken en threads daarbinnen kunnen elkaar makkelijk benaderen, dan wordt het uiteraard een ander verhaal, maar ik begreep uit je eerdere posts dus al dat dat lastig is.

Maar het is dus mogelijk om met Java in Tomcat een thread op te starten die door een opvolgend http-request weer benaderd kan worden? Ook een paar uur later, als de thread dan nóg loopt? Als dat kan, is dat inderdaad een oplossing voor deze kwestie.

[Remus]

CodeCaster schreef op donderdag 18 augustus 2011 @ 15:32:
Dat zeg ik zelf toch ook al?

[...]


Maar het is dus mogelijk om met Java in Tomcat een thread op te starten die door een opvolgend http-request weer benaderd kan worden? Ook een paar uur later, als de thread dan nóg loopt? Als dat kan, is dat inderdaad een oplossing voor deze kwestie.

Technisch gezien kan het, maar over het algemeen wordt het in JavaEE applicaties afgeraden om je eigen Threads te maken (vandaar ook mijn advies om naar @Asynchronous te kijken).

Overigens benader je niet de andere Thread, maar een object dat het resultaat of de voortgang van de andere Thread bevat.

[bomberboy]

Tomcat is bovendien een Servlet Container en geen JavaEE Application Server, dus daar heb je weer heel wat extra beperkingen.

Met de laatste beschrijving die je geeft heb je gewoon genoeg aan een cron-job? (die dan een servlet, php script whatever aanroept waarin de gewenste logica zit en daarbij dan een config-interface om die cron-jobs te configureren)

Ik denk dat je het jezelf te moeilijk maakt en bovendien is je uitleg van wat je wil bereiken nog steeds niet voldoende helder voor mij.

[verytallman]

@Asynchronous: dit klinkt goed omdat ik threads vermijdt en het is geen webserver specifieke (jboss/tomcat enz) oplossing. Maar, als ik het goed begrijp, vereist dit wel het gebruik van EJB 3.1.

Ik lees echter dat Quartz ook werkt met threads, is dat geen oplossing?

Een cron-job die een servlet aanroept is inderdaad ook een optie. Ik ben echter alleen bekend met cron-jobs voor php, heeft iemand een linkje met leesmateriaal?

Welke oplossing het ook wordt, het is wel belangrijk dat een taak (bijvoorbeeld downloaden van een website) op een specifiek moment in de toekomst uitgevoerd wordt zonder dat ik mijn browser open heb staan. Bij het maken van een taak moet ik de datum en tijd kunnen instellen. Op een willekeurige computer met browser moet ik kunnen inloggen op de website en de status zien van die taak.

[bomberboy]

Zolang je aan Tomcat (en ook JavaEE) denkt moet je threads vergeten. Als je dan zelf threads begint te starten en beheren kan het alleen maar foutlopen.

Je kan prutsen met een Timer beginnen prutsen, maar eigenlijk zou ik dat ook afraden. (uitzondering beetje verder)

Voor ieder type taak die je hebt kan je een servlet maken en daar de nodige logica implementeren (voor éénmalige executie)

je maakt een web-interface (jsp of servlet based of iets anders) waarin je taken en uitvoeringstijden kan configureren enz. Die configuratie sla je op in een databankje dat vast ook wel beschikbaar is voor je NAS (of iets Java based built-in van Tomcat)

Voor iedere taak maak je een servlet die die uitvoert (eenmalig)

Je hebt één master-servlet die de config leest en beslist of taken moet uitgevoerd worden enz. Afhankelijk van de config roept die dan de andere taken aan.

Je NAS heeft vast wel zijn eigen cron-daemon die je kan gebruiken, als job stel je daar dan bv de http-get's in naar je servlets. Daarin configureer je dan gewoon een wget naar je master servlet om de x minuten, met x de granulariteit waarmee je dingen wil mee kunnen schedulen.

Indien het om een of andere strikt noodzakelijk is dat meerdere taken echt tegelijk gestart worden, dan kan je in je masterservlet een timer gebruiken om die te starten. Maar aangezien je NAS toch al niet zo'n powerhorse zal zijn dat daar goed mee om kan denk ik niet dat dit in dit geval een meerwaarde is.

Het enige wat moeilijk is indien je een taak tijdens zijn uitvoering wil geforceerd stoppen. (Dan moet je daarvoor een status in je DB opslaan en in de taak zelf regelmatig controleren of die moet gestopt worden).

Om te voorkomen dat er iets verschikkelijk vastloopt kan je de maximum execution time van de servlets beperken tot y aantal minuten.

Wanneer ik het heb over het aanroepen van een servlet is dat in principe steeds een http get of http post.

Je Tomcat zal dan zelf wel voor de nodige threads en het beheer ervan zorgen.

[verytallman]

@bomberboy: het enige nadeel van deze oplossing (cron jobs) is dat hij specifiek is voor mijn QNAP NAS. Voor het overzetten van de applicatie naar een andere webserver, zoals JBoss, zal weer gewerkt moeten worden met een andere cron-deamon.

[SPee]

Ik zou inderdaad Quartz gebruiken.
Als Quartz niet al iets standaards heeft, zou je nog een ApplicationListener kunnen maken die een Quartz schedule start en bij afsluiten weer stopt.
Eventueel zou die Listener zelf een Thread kunnen starten die eeuwig doorloopt en periodiek zijn taken uitvoert.

Zolang je die Thread goed beheert (start en stopt) kan het geen kwaad in een Tomcat omgeving. In een echte JEE omgeving ligt het anders, maar dat is hier niet het geval.
Over @Asynchronous: Volgens mij is dit bedoeld voor AJAX calls. Dus die toch een keer moeten stoppen en is dus niet geschikt voor scheduling (hij start alleen op afroep).

[Varienaja]

bomberboy schreef op donderdag 18 augustus 2011 @ 17:25:
Zolang je aan Tomcat (en ook JavaEE) denkt moet je threads vergeten. Als je dan zelf threads begint te starten en beheren kan het alleen maar foutlopen.

Waarom precies moet je Threads vergeten in Tomcat? Ik schrijf en onderhoud al jaren een applicatie die in Tomcat draait en gewoon Threads gebruikt. Vooral de java.util.concurrent-klassen zijn erg gemakkelijk in het gebruik, en ik ben nog nooit tegen problemen aangelopen. In elk geval geen Threading-problemen :-)

[Creepy]

Het probleem zit hem dan ook niet in Thread in combinatie met Tomcat. Dat kan toch echt prima en kan echt niet "alleen maar fout lopen". Ook met tomcat heb je een applicatie scope (itt tot alleen een request scope bij standaard PHP) waarin je dingen kwijt kan die na een request moeten blijven leven en hergebruikt kunnen worden door andere requests. Dus een lopende thread signallen kan prima. De eventuele threading problematiek waarin je terecht kan komen staat dan ook los van Tomcat

[ Voor 5% gewijzigd door Creepy op 18-08-2011 21:41 ]

[Remus]

Varienaja schreef op donderdag 18 augustus 2011 @ 18:12:
[...]

Waarom precies moet je Threads vergeten in Tomcat? Ik schrijf en onderhoud al jaren een applicatie die in Tomcat draait en gewoon Threads gebruikt. Vooral de java.util.concurrent-klassen zijn erg gemakkelijk in het gebruik, en ik ben nog nooit tegen problemen aangelopen. In elk geval geen Threading-problemen :-)

Het grootste probleem voorzover ik weet is dat je - afhankelijk van het gebruik - te veel Threads kan gaan aanmaken waardoor je uiteindelijk de OS limits van het aantal Threads bereikt, of gewoon een te groot liveness probleem creeërt doordat er teveel Threads om de beperkte CPU resources vechten.

[koli-man]

Remus schreef op vrijdag 19 augustus 2011 @ 08:40:
[...]

Het grootste probleem voorzover ik weet is dat je - afhankelijk van het gebruik - te veel Threads kan gaan aanmaken waardoor je uiteindelijk de OS limits van het aantal Threads bereikt, of gewoon een te groot liveness probleem creeërt doordat er teveel Threads om de beperkte CPU resources vechten.

Als je in het begin van een project over de architectuur nadenkt, en je hebt toevallig de pet op van software architect moet je altijd uitkijken met threads en timers. Heel vaak heb je ze gewoon niet nodig, en kun je het makkelijker oplossen. Een thread heeft altijd impact op je systeem. Dat gezegd hebbende....

Ik kan mij slecht voorstellen dat deze applicatie zoveel threads nodig heeft, dat de pc/nas/whatever het niet meer aankan. En tomcat heeft natuurlijk ook gewoon een thread pool, wat gedeeld kan worden tussen componenten...

[Janoz]

Het probleem met threads in een JEE omgeving is dat ze buiten het beheer van de container vallen. Een applicatie die op eigen houtje threads aanmaakt valt niet meer te stoppen door de container. Sterker nog, de kans bestaat dat je je hele applicatie server en/of virtual machine niet meer goed af kunt sluiten omdat er nog een thread loopt die niet door de container gestopt kan worden (Waardoor je de applicatieserver dus moet killen).

De standaard manier om dit soort dingen asynchroon af te handelen in een JEE omgeving is door gebruik te maken van Message Driven Beans.

@koli-man: Als je zelfs threads aan gaat lopen maken dan gaat dat volledig buiten wat voor threadpool van tomcat dan ook natuurlijk. Dat is nu juist net het probleem.

[voodooless]

Altijd een mooi verhaal, maar ondertussen gebruik je wel diverse libs binnen je JEE omgeving die zelf ook diverse threads aanmaken en gebruiken... dat mag dan opeens wel

Op zich is het ook allemaal geen probleem als je maar weet waar je mee bezig bent. Natuurlijk moet je je wel van te voren bedenken of je ze wel nodig hebt (wat vaak inderdaad niet zo is).

In dit geval zou ik het werkpaard scheiden van de presentatie laag, waarbij je de presentatie laag verdeeld in twee stukken: browser en webserver. Laat gewoon een andere (java) applicatie het werkt doen. Dan is het lekker flexibel. Je kunt er altijd voor kiezen om die extra app in je tomcat container te draaien zodat het een geheel is.

[Janoz]

voodooless schreef op vrijdag 19 augustus 2011 @ 10:50:
Altijd een mooi verhaal, maar ondertussen gebruik je wel diverse libs binnen je JEE omgeving die zelf ook diverse threads aanmaken en gebruiken... dat mag dan opeens wel

Klopt. Quartz, maar ook veel Spring. Maar het is goed wanneer je beseft wat de problemen kunnen zijn en in dit topic heb ik nog niemand gezien die de werkelijke nadelen voor ogen had. Hoewel de JEE specs zeggen dat het niet toegestaan is hou ik zelf altijd een 'nee, tenzij..' policy aan. Bij externe libs neem ik altijd aan dat zij goed hebben nagedacht over de restricties van de container (alhoewel aannemen, ik zoek het meestal even op ).

[Remus]

Janoz schreef op vrijdag 19 augustus 2011 @ 10:24:
Het probleem met threads in een JEE omgeving is dat ze buiten het beheer van de container vallen. Een applicatie die op eigen houtje threads aanmaakt valt niet meer te stoppen door de container. Sterker nog, de kans bestaat dat je je hele applicatie server en/of virtual machine niet meer goed af kunt sluiten omdat er nog een thread loopt die niet door de container gestopt kan worden (Waardoor je de applicatieserver dus moet killen).

De standaard manier om dit soort dingen asynchroon af te handelen in een JEE omgeving is door gebruik te maken van Message Driven Beans.

@koli-man: Als je zelfs threads aan gaat lopen maken dan gaat dat volledig buiten wat voor threadpool van tomcat dan ook natuurlijk. Dat is nu juist net het probleem.

Zijn er ook andere manieren om Threads te verkrijgen die managed zijn door de JEE container? (of evt een ExecutorService aanspreken van de container)?

[bomberboy]

Helemaal akkoord met wat Janoz vertelt ivm de threading binnen JEE en Servlet Containers zoals Tomcat;

Bovendien is er ook een onderscheid tussen het aanmaken van een eeuwig lopende thread binnen je container die je op een bepaald moment altijd wel kwijt geraakt (of waarvan je niet de garantie hebt dat je die proper kan afsluiten) en andere threads die bv wat rekenwerk doen en binnen de context van je servlet en/of Bean gestart en weer afgesloten worden. De eerste soort is de gevaarlijkste, de tweede al iets minder. Maar daar ging het hier niet echt over.

Remus schreef op vrijdag 19 augustus 2011 @ 11:37:
Zijn er ook andere manieren om Threads te verkrijgen die managed zijn door de JEE container? (of evt een ExecutorService aanspreken van de container)?

En waarom zou je persé een thread willen te pakken krijgen? (oprechte vraag!) Typisch wil je gewoon iets asynchroon laten uitvoeren. Daarvoor heb je geen thread nodig die je zelf aanmaakt, een JEE applicatieserver biedt daar al andere voorzieningen voor, zoals de door Janoz aangehaalde Message Driven Beans.

Het is net hetzelfde als met "gewone" events in een stand alone java (GUI) applicatie. In de achtergrond worden daar soms ook threads gebruikt zonder dat je het weet, soms ook niet. Dat hoeft net niet uit te maken. Binnen JEE is dat net hetzelfde (maar kan je daar dan MDB's voor gebruiken)

Een ander type application server is JAIN SLEE wat je het best kan omschrijven als de JEE voor Telecom doeleinden. Dat is helemaal event/message gebaseerd. Het grootste probleem is hier om als developer je mindset zo te krijgen dat je daar correct gebruik van maakt. En dat vraagt even wat tijd, maar biedt enorm leuke mogelijkheden.

maar ik wijk af...

[Remus]

bomberboy schreef op vrijdag 19 augustus 2011 @ 13:06:
En waarom zou je persé een thread willen te pakken krijgen? (oprechte vraag!) Typisch wil je gewoon iets asynchroon laten uitvoeren. Daarvoor heb je geen thread nodig die je zelf aanmaakt, een JEE applicatieserver biedt daar al andere voorzieningen voor, zoals de door Janoz aangehaalde Message Driven Beans.

Het is net hetzelfde als met "gewone" events in een stand alone java (GUI) applicatie. In de achtergrond worden daar soms ook threads gebruikt zonder dat je het weet, soms ook niet. Dat hoeft net niet uit te maken. Binnen JEE is dat net hetzelfde (maar kan je daar dan MDB's voor gebruiken)

Mijn vraag komt niet direct voort uit het programmeren voor een JEE applicatie zelf, maar voor een library die gebruikt kan worden in een JEE applicatie. Ik werk sinds kort aan de JDBC driver voor Firebird, en in een van de pooled DataSources wordt een aparte Thread gemaakt om idle connections te beheren en ik heb dit in meerdere JDBC drivers zien gebeuren. Dat gaat wel dus in tegen het 'maak geen threads aan in JEE', dus vroeg ik mij af of daar dus een betere manier voor is.

[bomberboy]

Ik moet toegeven dat ik al een tijdje uit JavaEE development ben, maar heb vroeger wel een aantal Resource Adapters (http://download.oracle.com/javaee/5/tutorial/doc/bncjy.html) geschreven. Heb net even door die code van toen gebladerd ter herinnering.

Wat ik toen gebruikt heb was onder andere de WorkManager. Zie http://download.oracle.co...spi/work/WorkManager.html Je kan een instantie daarvan opvragen aan de BootstrapContext. http://download.oracle.co...spi/BootstrapContext.html

Ik weet niet direct of het een gestandaardiseerde feature is, maar een aantal JavaEE application servers (BEA WebLogic nu Oracle, IBM Websphere) laten je toe om WorkManagers te configureren en deze via JNDI beschikbaar te maken aan je applicaties en ik veronderstel dus ook JDBC drivers etc. (veronderstelling!)
Uiteraard is iets als een JDBC driver of resource adapter wel van een andere orde dan een EJB of Servlet waar toch andere "regels" van toepassing zijn. (imho)

[YoupY]

Je zou naast async beans ook gebruik kunnen maken van een workmanager om taken asynchroon te draaien.

Zie o.a. http://www.devx.com/Java/Article/28815

Dit voldoet aan je J2EE wens en je krijgt geen unmanaged threads in je JVM, zodat dit geen problemen oplevert met een eventule shutdown van de app server. Sommige app servers kennen ook schedulers waarmee je ook nog deze taken kan beheren, maar ik weet niet zo zeker of deze onderdeel zijn van de J2EE spec

Als alternatief om async werk uit te voeren kun je ook nog gebruik maken van MDBs en JMS queue's. Het wordt dan wel een stuk moeilijker om dit werk nog te beheren...

[verytallman]

Een update over de uiteindelijke oplossing. De stack is geworden: JSF 2.0 + EJB 3.1 + JPA 2.0

In een EJB zit een methode checkTasks() die geannoteerd is met @Schedule. Deze annotatie heb ik ingesteld zodat de methode elke 10 seconde wordt uitgevoerd. De methode checkt of er een taak uitgevoerd moet worden.

De taak zelf wordt uitgevoerd door een methode die geannoteerd is met @Asynchronous.

Werkt perfect. Bedankt voor de hulp.