Results 1 to 8 of 8

Thread: Kbmmw WIB messaging transport

  1. #1

    Kbmmw WIB messaging transport

    Hallo hallo (Benno),

    Ben een beetje aan het experimenteren geslagen met WIB. Als ik nu zowel query services als WIB gebruik, moet ik dan zowel een ServerTransport gebruiken en een messagingServerTransport of is het afdoende om messagingServerTransport te gebruiken? Ik kreeg de indruk dat het messaging transport ook gebruikt kon worden voor niet WIB gebruik , maar als ik het test dan werkt WIB wel, maar bij het ophalen van een query krijg ik de foutmelding "Invalid data. No subject."


    Bij voorbaat dank!

  2. #2
    Hmmm das een goeie .

    Volgens mij kun je volstaan met alleen de WIB. De truc is daar alleen om de subscriptions en topics goed te zetten.

    Je moet dat dan uiteraard wel zowel aan client als server kant goed opzetten.

    Heb het zelf nog niet zo gebruikt, maar volgens mij zitten er bij de demo's ook wat WIB zaken. Ook zou je eens in de kbmMW newsgroup kunnen zoeken (er is een search machine die ze ook archiveert waar ik nu ff niet op kom). Er zijn volgens mij al eens eerder discussies over geweest.

    Het mooie van hoe kbmMW is opgezet is dat je dezelfde services kunt laten werken met meerdere soorten transport. Dus sommige clients kun je gewoon laten communiceren via standaard transport terwijl je voor andere bv een zipped (of ander) transport gebruikt.

  3. #3
    Ja er zit een voorbeeld bij van een asynchrone query voorbeeld bij, waarin inderdaad een named query wordt aangeroepen vanuit een message (met slechts message transport). Maar toen ik de query gewoon wilde openen zonder gebruik te maken van message kreeg ik foutmeldingen. Misschien moet je als je gebruik maakt van message transport wel overal messages gebruiken ipv query.open.

    Mijn project is redelijk gevorderd nu en ik wil niet weer de hele boel omgooien, ik denk dat ik gewoon een extra transport erop gooi. Zoals ik het begrijp is het transport voor WIB wel beperkt tot standard, dus geen http e.d. Als dit inderdaad het geval is kan het misschien ook geen kwaad om twee transporten te hebben, dan kan ik de overige services over http gooien, mochten er firewalls in de weg zitten.

    Het blijft wel leuk speelgoed

  4. #4
    Het principe tussen de normale transporten en de WIB is ook anders.

    In de normale (oude) standaard transporten stuurt je client een request naar de server. De server voert dit request uit en stuurt een response naar je client. Vroeger moest je dan bv als je een lang lopend proces had op de server een threaded oplossing maken op de client, die de request stuurt en wacht op antwoord. Zou je dat niet threaded doen dan blockt je client al die tijd.

    Met de WIB maak je gebruik van messaging. Je gebruikt queues zowel aan de zender kant als de ontvanger kant. Daardoor maakt het niet meer uit hoe lang bv een proces op de server duurt of wanneer het uitgevoerd gaat worden, je response queue triggert gewoon een event als er een bericht voorbij vliegt waarop jij je geabonneerd hebt.

    Firewalls zijn altijd lastig, vooral aan de server kant. Grote problemen aan de client kant ben ik nog niet echt tegengekomen, maar ik zit vooral in het kleinbedrijf met meestal eenvoudige internet aansluitingen. Je kunt bij kbmMW ook vrij simpel een ISAPI module maken, die bv als een proxy fungeert voor de achterliggende server.

    Het blijft wel leuk speelgoed
    Yep en je blijft nieuwe dingen leren omdat het framework zo flexibel is.

    In de nieuwste blaise staat een artikel van Kim (nu al in de engelse versie) over zijn XSD converter en de serialization / deserialization componenten in kbmMW. Als je de enterprise editie hebt dan heb je ook de XSD converter. De streamers zelf zitten ook in de lagere edities.

  5. #5
    Moet nog heel even schakelen van request - response model naar messages. Gaat nog wel even duren ben ik bang...
    Wat vreemd dat je juist problemen ervaart met firewalls aan de server kant, ik zou verwachten dat dit juist aan de client vaker verkeerd gaat. Vanaf welke versie is XSD trouwens beschikbaar? Ik heb versie 4.4 ent

    Is het niet zo dat als je er een ISAPI van maakt, dat je dan direct via http(s) communiceert?

    Moet toch maar een keer een abonnement nemen op Blaise.

  6. #6
    hij zou in jouw ent moeten zitten.

    ISAPI is een DLL die je op IIS installeert. Volgens mij kan apache het tegenwoordig ook.

    Sommige bedrijven willen de voordeur alleen open zetten op bv een IIS omgeving. Achterliggende applicatie servers kun je dan verstoppen achter die proxy.

    Zelf heb ik de ISAPI bv ook gebruikt voor een licentie server. Klanten loggen eerst op die machine in en krijgen dan als ze een geldige licentie hebben een object terug met gegevens over app server, poort e.d.

  7. #7
    Volgens het WIB whitepaper p26 moet het zeker mogelijk zijn om gewone een request response uit te voeren, het muntje is alleen nog niet gevallen bij me... Zal wel weer een klein lullig dingetje zijn dat ik vergeten ben Krijg het niet aan de praat. Dat messaging in combinatie met de file server is ook wel interessant.

    Heb zo een soort gelijk licentie project liggen dat ik ooit had gemaakt met een webservice in combinatie met TPOnguard. Ik had dit toen gekoppeld aan online webwinkel. Kbmmw leent zich hier alleen veel beter voor, zeker als je ook op een makelijk manier inzicht wil krijgen in bijvoorbeeld het aantal activaties, ip-adressen waarvan uit geactiveerd is en dergelijke.

  8. #8
    Het heeft even geduurd, maar ik heb het antwoord. De instellingen voor een gewone REQuest RESponse heb je de volgende subscriptions nodig:

    De server moet subscriptions hebben voor REQ.> EN SUB.> eventueel kun je nog filteren op nodeid functie e.d.
    De client moet en subscription hebben voor RES.> ook deze kun je eventueel nog filteren.

    Het probleem met het omzetten van de ge-update async query demo naar een request response model, is dat het resultaat van de query in gedeeltes naar de client wordt verstuurd. Omdat dit laatste in een request response model niet mogelijk is geeft het foutmeldingen als je i.p.v. Query.AsyncOpen Query.Open gebruikt.

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
  •