Web application ervaringen gevraagd

[Maverick2k]

Beste lezers,

Graag wil ik jullie ervaring vragen voor de volgende situatie (een project):

In een fabriekshal willen ze realtime objecten traceren, informatie van deze objecten wordt in een grote database opgeslagen. Nu is de bedoeling dat er modellen worden gemaakt die aan de hand van de gegevens voorspellingen doen. De modellen bestaan uit wiskundige operaties waaronder statistische operaties.

Nu is mijn vraag of het realtime weergeven van de gegevens efficiënt te verrichten is met een web application ipv een desktop application, aangezien het op meerdere clients moet worden weergeven. Hetgeen dus betekent dat de modellen worden geëxecuteerd op de server.

En welk framework is hiervoor geschikt, heb zelf naar GWT en Ruby on rails gekeken. Maar aangezien het aanbod van frameworks dermate groot is, en ik nog niet diep in de materie zit, wil ik graag om ervaringen vragen.

Alvast bedankt.

Maverick2k

Eventuele goede literatuur over dit onderwerp (architectuur, web applications) is van harte welkom.

[ Voor 5% gewijzigd door Maverick2k op 15-08-2010 23:48 ]

[Verwijderd]

Je kunt hier eigenlijk 2 dingen doen.

1. Webapplicatie maken
2. Applicatie op de server maken, en een webapplicatie voor de weergave/rapportage

Wat het best is is echt heel afhankelijk van eventuele koppelingen met hard/software en dat soort zaken. Maar serieus, ga dit niet zelf doen.

[Maverick2k]

Verwijderd schreef op zondag 15 augustus 2010 @ 23:52:
Je kunt hier eigenlijk 2 dingen doen.

1. Webapplicatie maken
2. Applicatie op de server maken, en een webapplicatie voor de weergave/rapportage

Wat het best is is echt heel afhankelijk van eventuele koppelingen met hard/software en dat soort zaken. Maar serieus, ga dit niet zelf doen.

Thnx voor de suggesties. Toch wil ik mij wel in deze materie verdiepen.

De ontkoppeling tussen de hardware wordt gemaakt door de database. De client pcs draaien windows of linux.

[RobIII]

Maverick2k schreef op zondag 15 augustus 2010 @ 23:43:
In een fabriekshal willen ze realtime objecten traceren

Define realtime. Daar zit namelijk al een behoorlijke crux.

[ Voor 10% gewijzigd door RobIII op 16-08-2010 00:53 ]

[rinkel]

Misschien handig om iets meer duidelijkheid te geven in welk soort objecten dit zijn.
Is het fabricage/assemblage/logistiek/workflow o.i.d. ? Daar is al enorm veel software voor geschreven. SAP (modules MM PM PP) / ISAH / Unit4 (logistiek/workflow/projects)/ MS dynamics/ etc. (ik werk zelf in die hoek) en is niet eenvoudig. Ik weet dat in sommige pakketten meer dan 500 manjaar zit. Daarin zit ook veel tracking/workflow/etc.

Maar wellicht zie ik het te ingewikkeld...

[ Voor 10% gewijzigd door rinkel op 16-08-2010 01:18 ]

[Fuzzillogic]

Laat je niet zomaar leiden door de opvatting dat een webapp makkelijker is als het op meerdere plaatsen gebruikt moet worden. Een "normale" desktop-app met SOAP of zelfs gewoon JSON kan net zo makkelijk, zo niet makkelijker de data van een server halen.

Ik ben behoorlijk afgeknapt op "webapps". De achterliggende techniek is ontzettend beperkt t.o.v. de mogelijkheden die Java/.NET/Qt je bieden. Met dit soort high-level omgevingen ben je veel vrijer in de keuze of het een thin of thick client moet worden. En zeker met wat complexere zaken vind ik Java toch heel veel fijner dan Javascript/HTML/PHP. Om nog maar te zwijgen over de usability van de web-UI's...

[Maverick2k]

Met de antwoorden die hieronder staan loop ik even vooruit op de echte specificaties.

RobIII schreef op maandag 16 augustus 2010 @ 00:52:
[...]

Define realtime. Daar zit namelijk al een behoorlijke crux.

Zeg dat er van 20 000 duizend objecten de locatie bekend is x + y coordinaten. Deze moeten om de 15 sec worden geupdate, met maximaal een vertraging van een 1 minuut. (realtime is misschien het verkeerde begrip als denkt aan milliseconden)

rinkel schreef op maandag 16 augustus 2010 @ 01:12:
Misschien handig om iets meer duidelijkheid te geven in welk soort objecten dit zijn.
Is het fabricage/assemblage/logistiek/workflow o.i.d. ? Daar is al enorm veel software voor geschreven. SAP (modules MM PM PP) / ISAH / Unit4 (logistiek/workflow/projects)/ MS dynamics/ etc. (ik werk zelf in die hoek) en is niet eenvoudig. Ik weet dat in sommige pakketten meer dan 500 manjaar zit. Daarin zit ook veel tracking/workflow/etc.

Maar wellicht zie ik het te ingewikkeld...

Het gaat om een onderzoeksproject met de nadruk op de modellen die erachter gebruikt gaan worden. Vandaar dat wij het zelf willen gaan uitvoeren. De objecten kunnen bestaan uit materialen (pallets, dozen, etc), gereedschap.

Maar bedankt voor de tip, ik ga ook is kijken hoe de modules van SAP Unit4 etc eruit zien.

Fuzzillogic schreef op maandag 16 augustus 2010 @ 01:38:
Laat je niet zomaar leiden door de opvatting dat een webapp makkelijker is als het op meerdere plaatsen gebruikt moet worden. Een "normale" desktop-app met SOAP of zelfs gewoon JSON kan net zo makkelijk, zo niet makkelijker de data van een server halen.

Ik ben behoorlijk afgeknapt op "webapps". De achterliggende techniek is ontzettend beperkt t.o.v. de mogelijkheden die Java/.NET/Qt je bieden. Met dit soort high-level omgevingen ben je veel vrijer in de keuze of het een thin of thick client moet worden. En zeker met wat complexere zaken vind ik Java toch heel veel fijner dan Javascript/HTML/PHP. Om nog maar te zwijgen over de usability van de web-UI's...

Ik moet er ook nog wat dieper induiken, want gwt (van google) is compleet in java of python te programmeren en dat wordt later omgezet naar javascript (ajax) etc. Maar ik zal is kijken hoe het met de expressiviteit zit.

Nogmaals bedankt voor de reacties

[Janoz]

IMHO is je benadering compleet verkeerd. Je hebt een probleem waarbij je 'realtime' een model van de werkelijkheid bij moet houden. Ik neem niet aan dat de werking van de applicatie bestaat uit medewerkers die constant op een website de lokatie van verschillende objecten aan het intikken zijn. Door nu tussen de GUI frameworks te neuzen is compleet verspilde moeite. Het is alsof je een auto aan het ontwerpen bent, en begint met het stuur (en daarnaast dat het stuur leidend is in alle andere technische ontwerp beslissingen).

Waar je juist nu naar moet kijken is welke techniek je gaat gebruiken om je model bij te houden en hoe je dit model ook daadwerkelijk 'in sync' met de werkelijkheid houd. Hoe ga je de state bij houden. Wat zijn de eisen mbt performance en reliability. Je moet nu niet kijken naar GWT, maar of je een JEE omgeving in gaat zetten of zelf een daemon bouwt. Of je de state volledig in de DB gaat houden of daar een laag tussen zet. Pas als je daar helemaal mee klaar bent kun je eens gaan kijken of je er nog een leuke GUI laag op gaat zetten.

[Maverick2k]

Janoz schreef op maandag 16 augustus 2010 @ 11:12:
IMHO is je benadering compleet verkeerd. Je hebt een probleem waarbij je 'realtime' een model van de werkelijkheid bij moet houden. Ik neem niet aan dat de werking van de applicatie bestaat uit medewerkers die constant op een website de lokatie van verschillende objecten aan het intikken zijn. Door nu tussen de GUI frameworks te neuzen is compleet verspilde moeite. Het is alsof je een auto aan het ontwerpen bent, en begint met het stuur (en daarnaast dat het stuur leidend is in alle andere technische ontwerp beslissingen).

Waar je juist nu naar moet kijken is welke techniek je gaat gebruiken om je model bij te houden en hoe je dit model ook daadwerkelijk 'in sync' met de werkelijkheid houd. Hoe ga je de state bij houden. Wat zijn de eisen mbt performance en reliability. Je moet nu niet kijken naar GWT, maar of je een JEE omgeving in gaat zetten of zelf een daemon bouwt. Of je de state volledig in de DB gaat houden of daar een laag tussen zet. Pas als je daar helemaal mee klaar bent kun je eens gaan kijken of je er nog een leuke GUI laag op gaat zetten.

Bedankt voor deze feedback, de metafoor met auto laat inderdaad zien dat mijn denkwijze naar een verkeerde kant is verschoven. Ik zal inderdaad even terug naar de basis moeten thnx

Mocht je weten waar nuttig informatie te vinden is over dit soort architectuur vraagstukken, hou ik mij aanbevolen.

[ Voor 4% gewijzigd door Maverick2k op 16-08-2010 11:56 ]

[Grijze Vos]

Maverick2k schreef op maandag 16 augustus 2010 @ 11:51:
[...]

Mocht je weten waar nuttig informatie te vinden is over dit soort architectuur vraagstukken, hou ik mij aanbevolen.

Als je die vraag zelf niet kunt beantwoorden (lees: zelf de literatuur niet kunt vinden) vraag ik me ernstig af of je de juiste persoon bent om dit project uberhaupt aan te pakken.

[Maverick2k]

Grijze Vos schreef op maandag 16 augustus 2010 @ 12:37:
[...]

Als je die vraag zelf niet kunt beantwoorden (lees: zelf de literatuur niet kunt vinden) vraag ik me ernstig af of je de juiste persoon bent om dit project uberhaupt aan te pakken.

Beetje kort door de bocht deze reactie. Natuurlijk heb ik zelf al het een en ander gevonden, maar als iemand relevante literatuur gelezen heeft die ik niet gelezen heb is dat handig om te horen.

Ik sta open voor suggesties en ben erg leergierig.

[RobIII]

Maverick2k schreef op maandag 16 augustus 2010 @ 14:09:
[...]


Beetje kort door de bocht deze reactie. Natuurlijk heb ik zelf al het een en ander gevonden

Als je dan eens even vertelt wat je hebt gevonden dan kunnen we daar relevante input op geven. Ook zijn we erg benieuwd naar je afwegingen (pro's en cons) van de reeds gevonden zaken die je hebt gemaakt zodat we daar ook feedback op kunnen geven. Dat maakt dit topic een stuk interessanter en geeft je meteen een 'running start'.

Maverick2k schreef op maandag 16 augustus 2010 @ 14:09:
maar als iemand relevante literatuur gelezen heeft die ik niet gelezen heb is dat handig om te horen.

Als je niet meldt wat je al gelezen hebt weten wij ook niet wat je nog niet gelezen hebt
Het is sowieso de bedoeling als je een topic opent (zie onze Quickstart) dat je vermeldt wat je al wél gevonden/geprobeerd hebt. Op die manier komen wij niet met zaken aankakken die je al lang en breed geprobeerd hebt en (bijv) hebt afgeschoten als mogelijke optie omdat X en Y voor jou niet voldoet of ... En zodoende hoeven wij weer niet onnodig tijd te stoppen in een post over iets wat je al weet

Maverick2k schreef op maandag 16 augustus 2010 @ 14:09:
Ik sta open voor suggesties en ben erg leergierig.

Zoals min-of-meer hierboven al geimpliceerd wordt: als dit een bedrijfskritisch proces wordt en je zou nog in de leerfase zitten (je zegt nu dat dat niet het geval is maar tot op deze post wisten we dat niet) dan is het niet erg verstandig om je leerproces op een bedrijfskritisch proces toe te gaan passen. Dat is wat Grijze Vos bedoelt mijn zijn post; en daar sta ik (en ik denk velen met hem en mij) vierkant achter. Zie het als zelfbescherming voor jezelf

[ Voor 13% gewijzigd door RobIII op 16-08-2010 14:24 ]

[Maverick2k]

RobIII schreef op maandag 16 augustus 2010 @ 14:22:
Zoals min-of-meer hierboven al geimpliceerd wordt: als dit een bedrijfskritisch proces wordt en je zou nog in de leerfase zitten (je zegt nu dat dat niet het geval is maar tot op deze post wisten we dat niet) dan is het niet erg verstandig om je leerproces op een bedrijfskritisch proces toe te gaan passen. Dat is wat Grijze Vos bedoelt mijn zijn post; en daar sta ik (en ik denk velen met hem en mij) vierkant achter. Zie het als zelfbescherming voor jezelf

Zoals al eerder vermeldt gaat het om een onderzoeksproject.

En voor de rest zou ik mijn resultaten vanavond of morgen in een post proberen samen te vatten.

[Maverick2k]

Alvast een gedeeltelijk update:

Wat betreft de status van het onderzoekproject, wij staan aan het begin van het onderzoek. Een architectuur voor de software moet nog ontworpen worden. De basiscomponenten zullen bestaan uit

• Database met locatiegegevens
• Modellen voor het maken van voorspellingen
• Presentatie

De wel bekende layers: Presentation, Business en Data komen hieruit naar voren. Belangrijke aspecten aan het systeem zijn interoperability en extensibility van de Presentation en business layer.

Architectural styles die ik aan het bekijken ben zijn SOA Service Oriented Architecture, ESA Enterprise Service-Oriented Architecture, VITA en database centric architecture.

Literatuur die ik gelezen heb of nog aan het lezen ben:

• Distributed Systems Principles and Paradigms (Tanenbaum, second edition)
• 4+1 View model
• SOA for dummies
• Reference model SOA

Overig:

• Video InfoQ: Beginning an SOA initiative

Daarnaast ben ik de stakeholders in kaart aan het brengen en hun wensen/eisen.

[ Voor 5% gewijzigd door Maverick2k op 17-08-2010 16:40 ]

[RedRose]

Klinkt als dat je te veel hooi op je vork gaat nemen in je eentje (?).

Ik wil je dringend aanraden om eerst een functional design te gaan maken en pas daarna naar architecturen gaan kijken. Eigenlijk moet je nog voor je naar architecturen gaat kijken eerst een POC maken die doet wat je functioneel gezien nodig hebt. En dat is imho eerst een "database" maken die je geautomatiseerd kan vullen met data. Dan heb je een testset en kan je beginnen aan je modellen.

Pas dan kan je eigenlijk pas een gedegen technical design maken en gaan denken over hoe je je data wil presenteren / integreren.

SOA / ESA / VITA zijn hier compleet niet van belang in dit stadium.

[Boss]

Je kan ook nog eens kijken naar pakketten als Enterprise Dynamics. Dat is een simulatie-tool voor (o.a. logistieke) processen. Deze tool kan je volgens mij ook koppelen aan de fysieke wereld d.m.v. sensoren. Die input kan je dan gebruiken voor het maken van overzichten en ook meteen simulaties uitvoeren die een verwachting doet voor de komende periode.

[djluc]

De weergave lijkt niet zo lastig maar hoe krijg je die informatie in je database, worden al die objectverplaatsingen reeds geregistreerd?