Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien
Toon posts:

[.NET] Callback over het net

Pagina: 1
Acties:
  • 650 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Hallo, ik ben een programma aan het ontwerpen die ook jobs kan schedulen. Deze kan dus bijvoorbeeld op middernacht een job uitvoeren. Nu is het punt alleen dat meerdere applicaties een job kunnen aanmaken, en deze moet dan wel een notificatie krijgen dat de job gedaan is, met het daarin het resultaat. Nu wil ik dat wel op een 'push' manier, pull functionaliteit zit er al in.

Ik zat zelf te denken om een interface te definieren voor bijv. een webservice welke de clients inplementeren. Zodra de job is uitgevoerd wordt deze door de host aangeroepen en op die manier wordt de client op de hoogte gebracht. Is dit een goede/werkbare oplossing? Of is er iets slimmers?

  • whoami
  • Registratie: December 2000
  • Nu online
Wat als de client een job scheduled die moet uitgevoerd worden, en die client wordt nadat de job gescheduled is, afgesloten, en komt niet meer 'online' ofzo voor een week ?

Voor feedback van dergelijke systemen laat ik de server gewoon een mail sturen met daarin de nodige informatie over de job die uitgevoerd werd. (Successvol of niet, wat er juist gebeurd is , etc.. )

https://fgheysels.github.io/


  • Flard
  • Registratie: Februari 2001
  • Laatst online: 25-11 23:28
Zit je in een lokaal netwerk? In zo'n geval is Remoting over het algemeen wel een goede optie. (Al is dit wel redelijk zware kost)

Andere opties zijn namelijk ook het draaien van een service aan de client kant, waardoor deze dus ook een server wordt. Maar zoals je kunt begrijpen werkt dat nogal moeilijk onder routers en dergelijke.

Over het algemeen zie je dan ook eerder een poll-methode, dus gewoon om de x seconden/minuten kijken of de taak voltooid is.

Een andere optie, die volgens mij ook door Exchange wordt gebruikt (kan even geen reference vinden) is een blocking call. In theorie komt het hierop neer:
Je connect over HTTP naar een webserver. Deze geeft nog niks terug, dus je verbinding 'blokkeert'. Zodra de server informatie heeft gooit hij deze over je verbinding en sluit hem. In dat geval open je meteen weer opnieuw de vebrinding (die weer meteen blokkeert) en verwerk je je gegevens.
Uiteraard is het ook mogelijk dat er een timeout optreed op je HTTP-verbinding, in dat geval connect je ook meteen weer.
Hierdoor krijg je dus wel een quasi-push-methode, al kost deze denk ik wel wat werk om te implementeren.

Verwijderd

Topicstarter
Bedankt voor de replies. En ik zal iets meer achtergrond informatie verschaffen over de applicatie.

De clients zijn eigenlijk andere services/applicaties in het netwerk, dus niet eind-gebruik client pc. In principe zijn deze altijd aanwezig en online, m.u.v. een storing, onderhoud, restart o.i.d. dus als een push niet werkt, zal deze bij het herstarten de poll-mechanisme gebruiken om de status van de job op te vragen, en eventueel alsnog te wachten op de push van de server.

De clients zullen zodra de job is afgehandeld nog iets moeten doen met het resultaat, de clients zijn eigenlijk verandwoordelijk voor hun eigen job.

Hoe staat het remoting verhaal in verhouding met de webservice interface die de client zou implementeren? Deze zal ook een interface moeten definieren waaraan de clients moeten voldoen neem ik aan? En kan deze techniek ook gebruikt worden voor niet .net clients?

  • Flard
  • Registratie: Februari 2001
  • Laatst online: 25-11 23:28
Bij Remoting kun ja als connectie kiezen voor SOAP berichten over een HTTP-kanaal, dit is dus theoretisch gewoon een webservice. Je zult echter waarschijnlijk wel opnieuw de communicatie moeten maken.
(Overigens hebben bij Remoting Clients geen interface nodig, maar juist de server, aangezien de clients niet het originele object hebben).

Ik denk dat als je puur webservices wil hebben dat je niet onder polling uit komt..

Verwijderd

Topicstarter
Flard schreef op donderdag 18 oktober 2007 @ 10:38:
Bij Remoting kun ja als connectie kiezen voor SOAP berichten over een HTTP-kanaal, dit is dus theoretisch gewoon een webservice. Je zult echter waarschijnlijk wel opnieuw de communicatie moeten maken.
(Overigens hebben bij Remoting Clients geen interface nodig, maar juist de server, aangezien de clients niet het originele object hebben).

Ik denk dat als je puur webservices wil hebben dat je niet onder polling uit komt..
De communicatie moet in mijn geval ook opnieuw gemaakt worden, soms is een job uren verwijderd van de uitvoering, zoniet dagen, dus in de tussentijd moet de connectie niet opgehouden worden.

De webservices zijn puur de communicatiekanalen in dit geval, deze zijn een aparte laag in de betreffende applicaties. De job-host applicatie zal dan ook altijd draaien, als service, en de client-applicaties kunnen hierin jobs schedulen via de webservice. Deze service kan dan ook gerust een zelfde soort call doen naar de client-webserivce, om deze te laten weten dat de job uitgevoerd is. M.a.w. het gaat mij zeker wel lukken met deze webservices, maar ik ben er nog niet van overtuigd dat het de mooiste technische oplossing is ;)

Verwijderd

Is het niet mogelijk of Microsoft WCF te gaan gebruiken? Hierbij kan je makkelijk een webservice hosten binnen een applicatie (of windows service) zonder dat je IIS nodig hebt. Je kan dan dmv configuratie een bepaald protocol kiezen bijvoorbeeld NetTcpBinding in jouw geval.

Ik weet dan zeker dat je een mooie technische oplossing hebt ;)

  • TheNameless
  • Registratie: September 2001
  • Laatst online: 07-02 21:38

TheNameless

Jazzballet is vet!

Mooiste oplossing zou natuurlijk een WS-Addressing oplossing zijn.
En dan met name via de <ws:ReplyTo/> constructie.

Maar naar mijn ervaringen kan dit nog wel eens gaan zorgen voor interoperabiliteit's problemen :'(

Ducati: making mechanics out of riders since 1946


Verwijderd

Topicstarter
WCF schoot mij ook net te binnen, ik heb er nog niet echt mee gewerkt, en ik ken de technologie nog niet zo goed. Maar het lijkt inderdaad een erg mooie oplossing. Als ik echter een webservice binnen mijn applicatie wil hosten met dat WCF, dan kan ik zodra ik een IIS heb draaien hem echter niet op poort 80 hebben draaien? Dat zou namelijk erg fijn zijn voor firewall issues e.d.
Het ziet er iig erg bruikbaar uit... Iemand enige praktische ervaring met interoperabiliteit en WCF?

En welk gebied ging ws:replyto fout qua interoperabiliteit?

  • whoami
  • Registratie: December 2000
  • Nu online
Remoting == .NET only.

Dat je bij .NET remoting geen interfaces nodig hebt, is maar gedeeltelijk juist. Hoe ga jij aan je clients nl. laten weten welke methods er beschikbaar zijn, wat de API is, zonder ze op te zadelen met de bijhorende logica ?

https://fgheysels.github.io/

Pagina: 1