Page 1 of 2 1 2 LastLast
Results 1 to 15 of 18

Thread: webservice

  1. #1
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382

    webservice

    Ik lees voornamelijk slechte verhalen over Delphi Webservice. (nooit iets mee gedaan zelf, maar wil dat wel gaan doen).
    Ernstige performance problemen bijvoorbeeld.
    https://robertocschneiders.wordpress...ability-tests/
    https://robertocschneiders.wordpress...-tests-part-2/

    Ik kan ook niet heel enthousiast worden over de manier waarop datasets van server naar client gestuurd worden in de design-klik voorbeelden die voorhanden zijn.
    Kan het allemaal wat eenvoudiger? Is Datasnap de enige delphi manier die standaard aangeboden wordt om een webservice te bouwen? Zo ja wat is een echt goed alternatief?
    Er zijn vast mensen die hier meer verstand van hebben...

  2. #2
    Datasnap is alweer 2 jaar dood verklaard (officieel heet het dan af en doen ze er niets meer aan behalve minimaal onderhoud). Dat is bekend gemaakt door Marco Cantu op de laatste be-delphi (john jij was daar ook toch?). Grootste probleem met datasnap is dat het niet schaalbaar is door de architectuur. Persoonlijk vond ik ook de koppeling tussen client en server te strak.

    Er zijn zeker alternatieven. De laatste BE-Delphi ging over middleware.

    Mijn persoonlijke favoriet is kbmMW. Kost wat moeite om onder de knie te krijgen maar dan heb je ook een erg krachtig framework. Als je met datasets wilt werken is dat mogelijk, ook een orm kan. kbmMW heeft een gratis versie (de codegear edities) waar je mee aan de gang kunt. Die mogen ook commercieel gebruikt worden, maar worden niet geupdate en bevatten geen source. De codegear editie is wel voldoende om een gevoel te krijgen van de architectuur en manier van werken.

    Wil je meer een ORM achtig framework dan kun je nog kijken naar mormot. De auteur heeft toen ook een lezing gegeven en ik was onder de indruk van wat het kon. Mormot is freeware.

    TMS heeft ook 2 producten voor remote data, een simpele en een meer uitgebreid compleet framework (aurelius).

    Ook remobject bestaat volgens mij nog. Ik weet niet hoe actief die nog zijn.

    Radserver (van embarcadero) is wat ik qua opzet gezien heb ook beter opgezet dan datasnap. Je zit dan alleen wel altijd met runtimes voor wat je wegzet bij klanten.

    Opties genoeg dus. Succes.

  3. #3
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Wat Marco heeft gezegd, kan ik bevestigen.
    Het nadeel van all die middleware producten zijn de tutorials. Vaak wordt gezegd: kijk naar de voorbeelden.
    Je moet er tijd in steken (wat ik nog steeds moet doen).
    Delphi is great. Lazarus is more powerfull

  4. #4
    Het nadeel van all die middleware producten zijn de tutorials. Vaak wordt gezegd: kijk naar de voorbeelden.
    Je moet er tijd in steken (wat ik nog steeds moet doen).
    Dat klopt, je moet het concept van middleware gaan begrijpen. Een aantal zaken werken compleet anders dan klassieke client server, daarnaast moet je het concept van services gaan begrijpen.

    Maar is dat niet met alles zo? De delphi apps die we bouwen zijn toch ook niet zo simpel als de drag en koppel demo's van de verkooppraatjes.

  5. #5
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    Benno, is er ergens een - bij voorkeur Nederlandstalige - duidelijke uitleg over de mogelijkheden van kbmMW ?
    Erik

  6. #6
    ik heb een paar redelijk basis artikelen geschreven voor Blaise en ook een aantal artikelen van Kim en Fikret zijn vertaald naar Nederlands. Maar het meeste materiaal is engelstalig en dat zal ook niet snel veranderen denk ik.

    Op http://www.components4developers.com/ zijn onder de menu optie docs de nodige whitepapers te vinden over kbmMW.

    Maar jij schrijft in je kop over webservice terwijl je in de rest van de vraag hebt over middleware oplossingen. Wat wil je bereiken?

  7. #7
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Met veel interesse Erik(lang)'s links gelezen. Als iemand een link weet voor de opmerkingen van Marco Cantu (met name wat er fout was in de architectuur) dan graag.

    Zelf heb ik altijd het idee gehad dat Datasnap meer voor bedrijfsintern netwerk gebruik geconcipieerd is, en dat er ergens een vacuum gevallen is (als in, geen planning voor services op internet naar eindklanten) in de tijd dat codegear dacht dat alles toch naar .NET zou gaan. (in late Codegear tijden (D2007) was er ook nog een tijd ECO/Bold)

    Ik ben van plan "ooit" wat met Mormot te gaan klooien, vn FPC related. (en beetje werk, onze servers zijn Linux)

  8. #8
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    En dat allemaal lezende denk ik weleens: ik bouw het allemaal zelf:
    - stuur rauwe bytes naar server - server verwerkt zijn bytes.
    - ontvang rauwe bytes van server - client verwerkt zijn bytes.

  9. #9
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Sterker nog, daar ben ik al mee bezig :-)

    probe clients die data (logrecords met statistiek, en cutouts van beelden) versturen, server die deze beheert en per serie in een file stuurt (alles van een serie in een file is een eis van de klant), en clients die kunnen viewen (verschillende rollen).

    De per file eis, het OLAP achtige analyse van de data (geen queries, maar gewoon alles walken) en de integratie van beeld data zijn de hoofdredenen zelf wat te rommelen. Gelukkig is dit allemaal bedrijfsintern, dus security is niet echt van belang.

    File storage, maar lopen series zijn altijd memory gecached, en bij een request voor een oudere serie wordt die ook gecached. (de eerste acccess laat de index in de cache, beelddata altijd direct van disk).

    De mormot toepassingen boven zijn voor in ons bedrijf administratief, de zelfdoe oplossing is voor wat we verkopen (Vision).

    Die mormot opmerking moet ik overigens even nuanceren. Ik begin met de evaluatie van mormot vanwege die redenen. Een enorm harde eis is echter het roadwarrior scenario (werken in een client zonder connecties, submit wanneer connectie+zinnige conflict resolutie).

  10. #10
    Als iemand een link weet voor de opmerkingen van Marco Cantu (met name wat er fout was in de architectuur) dan graag.
    de opmerkingen over architectuur zijn niet van Marco maar van mij. Geen link dus, al heeft Marco wel ooit gereageerd op de "end of life conclusie" van de be=delphi.

    En dat allemaal lezende denk ik weleens: ik bouw het allemaal zelf:
    - stuur rauwe bytes naar server - server verwerkt zijn bytes.
    - ontvang rauwe bytes van server - client verwerkt zijn bytes.
    Als dat alles is wat je wilt zou ik gewoon indy gebruiken en een rest interface ontwerpen.

    Maar middleware doet veel meer. Denk aan caching, zaken als fail over en load balancing. Verder zijn frameworks zoals kbmmw gewoon een grote gereedschapskist.

    Mormot is zeker ook een mooi framework, maar is een orm. Ga je met rest api's aan de gang is dat prima, wil je op de dataset manier werken heb je wat meer werk. kbmmw is meer opgezet vanuit het dataset idee, maar heeft hele krachtige streamers en marshalling aan boord om ook orm makkelijk te maken.

    Het hangt dus heel erg af van wat je wilt en waar je het voor nodig hebt. Het domein waar Marco in werkt (beeldverwerking) is zo specifiek dat ik me afvraag of dat in een generiek framework te vangen is. Real time trading systemen waar latency cruciaal is is ook een voorbeeld waar je niet wegkomt met een generiek framework als kbmmw.

  11. #11
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Mormot en kmbMW zitten zeker in mijn bewustzijn en wil ik zeker eens bekijken.
    Vaak krijg ik wel het gevoel dat het allemaal veel te ingewikkeld is / lijkt.
    De overvloed aan "gedoe" (componenten) om wat data op te halen en weg te schrijven.
    Daar komt dat gevoel vandaan

    Ik wil de huidige client-server exe die ik onderhoud eens omschrijven zodat ie ook via internet kan werken (met een lokale exe) en connectie met sql server leggen.
    En ben nog geen manier tegengekomen om dit - zonder complete herschrijving - van het programma voor elkaar te krijgen.
    Searching-mode... Er komt wel een keer wat uit :-)

  12. #12
    je zou eens naar asta kunnen kijken. Die maakt deze use case wat makkelijker, maar zo snel je meer wilt loop je vast.

  13. #13
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Benno View Post
    Het hangt dus heel erg af van wat je wilt en waar je het voor nodig hebt. Het domein waar Marco in werkt (beeldverwerking) is zo specifiek dat ik me afvraag of dat in een generiek framework te vangen is. Real time trading systemen waar latency cruciaal is is ook een voorbeeld waar je niet wegkomt met een generiek framework als kbmmw.
    Ja en nee. Het is cruciaal dat de data zo snel mogelijk uit de vision probes moet verdwijnen. (die tot 1GByte/s sustained voor de kiezen krijgen). Een Indy client stuurt het naar de statistiek server.

    Dit is het eigenlijke systeem en staat los van de vision. De data is vn logrecords/statistiek/events, maar deze zijn vaak door de klant op de vision bakken in elkaar te klikken. Sommige hebben ook nog aan de data vastzittende afkeurbeelden. Er zijn geen mutaties (behalve caches en indexen), logging only. Daarom is ook geen backup nodig. Voor sommige klanten is lange termijn data niet nodig, en is eens in de 5 jaar data verlies door een SSD/HDD sterfte acceptabel. Anders zet je er, afhankelijk van wensen, gewoon een tweede applicatie als hot spare naast en die is tevens backup. Evt ook nog een RAID systeem, maar de meeste klanten hebben een voorkeur voor meer redundante goedkope (en goedkoop te onderhouden) systemen dan een dure server.

    Firebird doet databases op file basis, dus dat zou in theorie nog kunnen, maar beelden in de DB zit bij mij niet lekker. Misschien als ik tot de nek in FB zat en wist hoever ik kon gaan, dat ik dat zou kiezen. Maar de vision systemen zitten vol met binaire protocollen en files, dus dat ligt simpelweg meer voor de hand en is meer recht toe recht aan.

    De overal statistiek voor de actieve series/runs is wel een punt van zorg, dat is OLAP achtig en vereist snel door zeer grote datahoeveelheden heen gaan (tot een miljoen logrecords per etmaal, doe maar eens een in elkaar te klikken querietje over een maand)

  14. #14
    Stijn Sanders develyoy's Avatar
    Join Date
    Jun 2008
    Location
    GentBrugge, Belgi?½
    Posts
    1,046
    Ik kom (weer) wat laat op een thread zoals deze, maar toch had ik graag aangeknoopt met wat uitleg over de optie die ik in gelijkaardige gevallen zoals deze tegenwoordig steevast aanwend. Ik zat ook met veel zorgen en vraagtekens over de bestaande mogelijkheden op binnen Delphi met het web te werken, en vond ze allemaal uiterst ver verwijderd van de relatief rechtlijnige onwikkelaars-ervaring die ik mocht genieten van een PHP projectje dat ik voorheen mocht doen. Ik had intussen al met pure HTTP en ISAPI gewerkt, en was met InternetExplorer's IInternetProtocol aan het spelen (intussen gedegradeerd tot een draak uit de oudheid), dus besloot ik toch maar aan xxm te beginnen. Ik wou zeker de kracht en de snelheid van de Delphi compiler gebruiken om een website vanuit een DLL te draaien, en de HTML en server-side code in dezelfde files, net zoals (oude) PHP (tegenwoordig hebben ze daar ook een frame-work emidemie).

    Het is dus niet echt een web-service, moet ik waarschuwen, in de pure zin van het woord. Ikzelf ben enigzins minder overtuigd van ORM's, maar gezien ik het basis-principe van PHP wou nabootsen, kan je perfect een objecten-XML-web-service-ding maken in een xxm project, en kan je volledig zelf instaan voor (de-)serialisatie van je objecten. Eventueel naast een volledig uitgebouwde web-front-end.

    Wel is het de bedoeling om je ene DLL vlot te kunnen wisselen tussen een lokale debug-oplossing naar een live IIS hosting, of 'los' met xxmHttp, of met een kleine aanpassing in een specifieke exe met alleen je eigen project... Je kan alle kanten uit.

    In dit tijdperk van het web merk ik meer en meer dat mensen het appreciëren dat je een uitgebreide installatie-procedure kan vermijden door de applicatie beschikbaar te stellen via de browser. Je kan dan wel geen visual designs doen zoals je met VCL gewend bent, maar de vele praktijkvoorbeelden tonen aan dat je al snel tegen limieten aanloopt en/of onwaarschijnlijk lelijke achterliggende HTML krijgt. Dus doe je die beter zelf, en kan je die goed in de gaten houden dat er niets fout loopt. (Basis-)kennis over HTML en client-side JavaScript zijn tegenwoordig sterk aan te raden, en kan je zeker in andere contexten ook aanwenden.

    Jammer genoeg vond ik tot heden slechts weinig mensen die ook de kracht van Delphi uitgebreid aanwenden voor server-side zaken, en en gevorderde kennis hebben van dynamische HTML, en in xxm ook een veelzijdig platform vinden om alledaagse dingen op te lossen zoals hot-updates, vlotte module-registratie en auto-compile. Mocht je een voorbeeld van een volledig project willen inkijken kan ik tx aanraden.

  15. #15
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    owowoow NOG meer info en mogelijkheden :-)
    Dank

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •