Próbálom megtörni magamban a megszokott gondolkodási sémákat. Tervezek egy nagy, többrétegű LOB alkalmazást. A szervizrétegnek elsődlegesen a WPF rich klienst kell kiszolgálni, de jó lenne, ha mobil kliensek is tudnák ezt fogyasztani.
Ha a szerviz interfész finom felbontású, sok kicsi metódussal, akkor a kommunikáció sok időt rabol el, lassú lesz az app (chatty interfész).
Ha durva felbontású (chunky), akkor megvan a veszélye, hogy a fogyasztó WPF app formjaihoz lesz illesztve, célirányosan, így akkor meg mobil kliensek nem fogják tudni hatékonyan fogyasztani.
Egy érdekes alternatívát láttam a probléma feloldására itt és itt.
Ebben az összes kliens-szerviz kommunikáció message alapú, teljesen aszinkron. Egy kitöltött form adatait elküldik egy queueba, a szerver pedig egy másik üzenettel válaszol erre. Azaz a kliens alapjaiban aszinkron, és a válaszok események formájában jönnek vissza.
A message alapú kommunikáció nagy előnye, hogy az üzeneteket össze lehet nyalábolni, és egyben elküldeni. Így a szerviz lehet finom felbontású, de a kommunikáció mégis gyors, nem sok kis darabból áll. Érthetően ezt szinkron, rpc jellegű szerviz hívásokkal nem lehet megcsinálni.
Ez a fajta queued, service bus alapú gondolkodásmód szokatlan nekem, de nagyon szimpatikus. Van valakinek tapasztalata ilyen rendszer tervezésével? Bármilyen url, pointer, könyv, személyes tapasztalat érdekelne. Úgy érzem nagy dolgokat lehet ezzel összerakni, csak meg kell alaposan értenem.
Még egy gondolat. WCF proxyk használatával az alapban message alapú, asszinkron kérés-válaszokból összeraknak egy RPC jellegű kommunikációt, úgy, hogy a kliens vár a szerver válaszára. Aztán a kliens kedvéért, hogy ne blokkoljuk le a GUIt csinálunk háttérszálat, ahol bevárjuk a szerviz válaszra váró szálat. :)
Miért nem használunk eleve aszinkron üzenetváltásokat, és akkor sokkal egyszerűbb lesz a kép. A kliens bepostázza a kérést a buszra, és megy tovább. Amikor a válasz megjön, akkor meg erről eseményben értesül. Nyilván itt is vannak háttérszálak, hisz ki fogadná akkor a szervertől jövő választ, és ki hívná vissza a kliens eseményeken keresztül, de valahogy akkor is tisztábbnak tűnik a kép, mint az erőltetett RCP-jellegű módszernél. Nem?
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
7 COMMENTS
A WPF Prism keretrendszerben van egy event aggregator szolgáltatás, ami így működik:
http://compositewpf.codeplex.com/wikipage?title=Event%20Aggregator
G.
Mármint a GUI üzenetalapú összedrótozásához segítséget ad, nyilván kell alá egy queue, vagy service bus is. Mi használjuk az Event Aggregation szolgáltatást is a Prism-ből, de alatta sima szinkron WCF hívások vannak. Mivel a Event Aggregation az UI thread-be is tud eseményt küldeni fel a felületre, és background thread-ként is tud esemény küldeni a lenti rétegekbe, így egyszerűbb az architektúra.
Ha sok űrlap van, akkor egy idő után az Event Aggregation eseményeihez tartozó típusok el fognak szaporodni, de ezeket általában lehet tipizálni, és/vagy a filter paraméterrel célzottan küldeni.
A Prism Event aggregation az én fejemben arra való, hogy GUI komponensek között laza csatolással lehessen eseményeket közvetíteni.
Nem értem, mi köze ennek a szerviz hívásokhoz?
Szerintem ez az RPC dolog egyszeruen szemlelet kerdese. Alapban az uzenet alapu kommunikacio jo dolog, hogy kliensoldalrol hogy oldod meg, az pedig egy teljesen masik tema, es szerintem a te dolgod.
A “Még egy gondolat”.. kezdetű részhez: ha így generálod a proxy-d:
svcutil … /a /tcv:Version35
akkor lehet GUI szálról indítani aszinkron WCF szerviz hívást, és szépen eseményben jön vissza a válasz, ráadásul az esemény visszatalál a GUI szálra.
A linkekről, amit megadtál: én csak speciális esetekben használnék ilyen queue alapú architektúrát. Pl ha valami spéci mérőeszközök tolják fel folyamatosan az adatokat a központba, akkor oda lehet, hogy jó – éppen nincs kapcsolat, akkor sem veszik el semmi, majd később mennek az adatok, programból meg nem kell erre figyelni.
Vagy ha embereknek (pl parkolóőröknek) a kis kézi kütyüjére kell program, oda lehet hogy jó, mert az ember beírogatja az adatot, aztán nem érdekli, hogy az mikor megy a szerverhez. Ekkor jó a queue, mert nem örülne a parkolóőr, ha fél óráig nyomkodnia kellene a retry-t, hogy folytathassa a munkát.
Akkor is jól jöhet, ha komponensek egymás között kommunikálnak, és nem ember által indított műveletekben vesznek részt, akik várják az eredményt. Ugyanakkor egy közönséges asztali alkalmazásnál nem látom a nagy előnyét. Miért nem? Mert sok esetben a felhasználó műveletei egymásra épülnek. Ha nem sikerül egy lépés, akkor meg kell várni, hogy sikerüljön. Mindegy a felhasználónak, hogy a sikeres művelethez egy szervizhívást újra kell hívni a kódodnak, vagy egy queue-ból az egyszercsak magától elmegy, ő ott szépen várja az eredményt, és nyilván elvárja a lehetőségét, hogy adott ponton megnyomhassa a cancel gombot (és akkor queue esetén lehet kibogarászni a már betárazott üzenetet, azaz pont azzal kell szívni, ami eredetileg az előnye). Az is jobb egy felhasználónak, ha az arcába ugrik egy kapcsolódási hiba ablak (tudja nyaggatni a rendszergazdát), mintha homokórázik vagy csak szimplán várakozik az alkalmazás, mivel a queueból még el sem mentek a kérések.
Maga a cikkíró sem győzőtt meg engem a stílusával, pl ilyet írni, hogy “WCF, for example, makes it easy to ignore the fact that you’re making a method call over the network.”. Az összes WCF-es könyv azt súlykolja, hogy nem metódus hívásokról van szó, hanem üzenetekről, és ennek a szellemében kell megtervezni egy SOA-s rendszert.
Szóval az én véleményem: szerintem nem egyértelműen lenne jó megoldás, bár bizonyos helyzetekben vannak előnyei. A kérdés, hogy nálad mik lennének az előnyei.
Azért egy komplett message (queue) alapú architektúránál igen komoly kérdések merülnek fel! Vannak területek amelyekre tökéletesen alkalmas, főként ahol alkalmazható a pub/sub típusú megoldás. Üzenetek esetén amire érdemes már tervezéskor figyelni:
– sorrendiség, számít-e, hogy az üzenetek milyen sorrendben kerülnek feldolgozásra, főleg skálázott rendszerekben
– tartósság, mivel nincs visszajelzésed egy üzenetről, vett-e a feldolgozó oldal, mi történik az üzenettel ha a kliens lehal, vagy ha a túloldal éppen nem ér rá, hibázik, vagy nem is fut
– TTL, mikor évül el egy üzenet, kliens szerver architektúrákban fontos kérdés, a kliensről sose tudni mikor tér vissza
van egy nem túl friss, de szerintem ma is aktuális pdf a témában:
http://msdn.microsoft.com/en-us/library/ms978729.aspx
REST-et javaslom inkább.