[ALG/Ontwikkeling] Vastlopen tijdens ontwikkeling...

[Verwijderd]

... van een geschikte architectuur.

Op het moment van schrijven ben ik bezig met het op papier zetten van wat in mijn ogen een redelijk geschikte architectuur is voor een project waar we op dit moment aan het werken zijn.
Echter, hoe meer er op papier verschijnt hoe meer vraagtekens en bomen-waardoor-ik-het-bos-niet-meer-zie ontstaan.

De opzet van de applicatie is redelijk eenvoudig;
Allereerst is een GUI gedeelte (2 andere aparte projecten, een mobiele applicatie en een (meerdere) webapplicaties).

Het GUI gedeelte tracht te communiceren met de database door middel van XML-RPC. Dat werkt op zich prima, als ik een test servletje tevoorschijn tover en met een XmlRpcClient een request doe pikken de handler en server deze op en krijg ik de gewenste output in mijn, in dit geval, browser venster.
Maar dit levert tevens een kronkel in mijn hoofd op, want hoe kan ik nu het beste de verschillende queries aanpakken.

Momenteel gaat het nog als volgt:
GUI -> roept de xmlrpchandler aan -> xmlrpchandler laat de query uitvoeren door de Database klasse -> xmlrpchandler spuugt data terug naar de client applicaties.

*Het probleem is eigenlijk dat ik een enorme lijst met handler methods ga krijgen in mijn handler met bij behorende enorme lijst met queries, hoe kan ik dit het best generaliseren naar een meet standaard query template (als dit al mogelijk is natuurlijk).

Toch heb ik het gevoel dat er iets niet lekker gaat, maar ik krijg niet echt houvast op het grotere plaatje, waarschijnlijk gebrek aan ervaring op dit vlak.
Daarom mijn vraag aan jullie; hoe zouden jullie een architectuur voor een dergelijke applicatie ontwerpen en zit ik al een beetje op de goede weg op deze manier?

[ Voor 8% gewijzigd door Verwijderd op 15-11-2006 13:00 ]

[EfBe]

Je denkt in technologische details, maar waar het om draait is functionaliteit. Wat moet de applicatie kunnen (qua functionaliteit), op welk platform moet het draaien en andere randvoorwaarden en daarna ga je een selectie maken van de functionaliteit die je NU gaat bouwen.

Met die subset ga je een technical research doen, hoeft niet in detail, maar dat je niet voor dingen komt te staan als "wat we willen kan niet met dit platform, we moeten van platform/database/whatever wisselen", en daardoor je project in gevaar komt.

Met die resultaten ga je globaal de architectuur opzetten. Omdat je een overview hebt van welke functionaliteit je wilt maken, weet je ook grofweg wat je nodig hebt. Heb je bv geen functionaliteit die een xml webservice vereist, dan hoef je die ook niet te bouwen of op te nemen in je architectuur.

Het hangt van je team grootte af hoe je nu te werk gaat. Sommigen zeggen je moet eerst 1 feature helemaal van boven tot onder bouwen, en dan uitbouwen. Anderen zeggen je moet eerst de algemene lagen maken voor alle features en dan de features verder invullen.

De waarheid ligt altijd in het midden met dit soort dingen, daar er geen vast stramien is wat altijd werkt op 1 na: CSSE. CSSE staat voor Common Sense Software Engineering, een term die ik maar bedacht heb om software engineering op basis van logisch nadenken te betitelen, tegenwoordig wordt alles agile genoemd ookal heeft het er geen reet mee te maken, maar een acronym wel nodig lijkt om begrepen te worden.

[Verwijderd]

De keuze voor XML-RPC als protocol voor dataoverdracht tussen de verschillende eindpunten en database is tot stand gekomen met de volgende gedachte:
-> Gemak dient de mensch; XML-RPC is een bestaand, eenvoudig te implementeren protocol wat voor het versturen/ontvangen van data gebruik maakt van een ander al bestaand protocol (HTTP).
Door dit te gebruiken slaan we 2 vliegen in 1 klap: er hoeft geen nieuw protocol opgesteld te worden voor de opmaak van data en aangezien we HTTP gebruiken hoeven we ook geen rekening te houden met het ontwikkelen van een communicatie lijn.

Waar we/ik tegenaan lopen is óf een beperking in mijn kunnen (wat heel goed mogelijk is) of een beperking in XML-RPC die ons niet in staat stelt het gewenste op deze wijze uit te voeren.
Waardoor ik dus naar een alternatieve oplossing voor dataoverdracht tussen de applicaties en database moet zoeken

Edit; ik denk dat ik op deze manier de plank volledig mis heb geslagen en het protocol probeer te misbruiken voor iets waarvoor het niet bedoelt is. Terug achter het tekenbord maar weer

[ Voor 9% gewijzigd door Verwijderd op 15-11-2006 16:24 ]