Szinkronizáció, hogyan?
Sziasztok,
A következő témában lennék kíváncsi a véleményetekre:
Teljesen általánosan, adott egy rendszer, ahol elég jelentős mennyiségű adat keletkezik, módosul, és törlődik nap, mint nap. Ezt az adatot több külső - számunkra gyakorlatilag fekete doboz - alakalmazás számára kell biztosítani.
Jelenleg egy webservice-el kérjük el az adott rendszertől az utolsó szinkronizáció időpontját és az ahhoz képest történt változást adjuk vissza válaszként.
Ezzel a megoldással az egyetlen probléma, hogy a kommunikációs folyamat nem ott indul, ahol az adat keletkezik.
Tehát egy olyan általános megoldást szeretnék találni, ahol függetlenül a programozási nyelvtől, platformtól, mindentől, a mi rendszerünk indítaná el a kommunikációt.
A lehetőségek amik erre eszembe jutottak:
- TCP-n vagy UDP-n keresztül küldök egy csomagot (egy nálunk regisztrált ip adott portjára) amiben jelzem, hogy új adat érhető el.
- a másik oldal számára biztosítunk egy webservice-t (SOAP) amit futtatnia kell
- előírjuk, hogy a kommunikációhoz a másik oldalon rendelkezni kell MQ szerverrel (illetve egy adott queue-kezelő rendszerrel) és azon keresztül küldjük az üzenetet
- a változásról mailt küldünk szintén regisztrált címre (ezt igazából már most elvetném, csak mintegy lehetőség felsorolom)
- vagy nagyon csúnya megoldás, adott URL-t meghívni, ha változás történik
Igazából a lista lefelé kb. azt tükrözi, hogy melyik megoldás felé hajlok leginkább...
Ha van valakinek ilyenben tapasztalata, akkor pls adjon ötletet, illetve, ha valaki használta valamelyik módszert, érdekelnének a buktatók, limitációk.
Minden új ötlet érdekel, mivel egyelőre tervezés előtti fázisban van a dolog...
Remélem nem írtam tele helyesírási hibákkal, de ha sokat gépelek és az nem kód és nincs highlight, akkor hajlamos vagyok rá... ;)
köszi,
Halee
■ A következő témában lennék kíváncsi a véleményetekre:
Teljesen általánosan, adott egy rendszer, ahol elég jelentős mennyiségű adat keletkezik, módosul, és törlődik nap, mint nap. Ezt az adatot több külső - számunkra gyakorlatilag fekete doboz - alakalmazás számára kell biztosítani.
Jelenleg egy webservice-el kérjük el az adott rendszertől az utolsó szinkronizáció időpontját és az ahhoz képest történt változást adjuk vissza válaszként.
Ezzel a megoldással az egyetlen probléma, hogy a kommunikációs folyamat nem ott indul, ahol az adat keletkezik.
Tehát egy olyan általános megoldást szeretnék találni, ahol függetlenül a programozási nyelvtől, platformtól, mindentől, a mi rendszerünk indítaná el a kommunikációt.
A lehetőségek amik erre eszembe jutottak:
- TCP-n vagy UDP-n keresztül küldök egy csomagot (egy nálunk regisztrált ip adott portjára) amiben jelzem, hogy új adat érhető el.
- a másik oldal számára biztosítunk egy webservice-t (SOAP) amit futtatnia kell
- előírjuk, hogy a kommunikációhoz a másik oldalon rendelkezni kell MQ szerverrel (illetve egy adott queue-kezelő rendszerrel) és azon keresztül küldjük az üzenetet
- a változásról mailt küldünk szintén regisztrált címre (ezt igazából már most elvetném, csak mintegy lehetőség felsorolom)
- vagy nagyon csúnya megoldás, adott URL-t meghívni, ha változás történik
Igazából a lista lefelé kb. azt tükrözi, hogy melyik megoldás felé hajlok leginkább...
Ha van valakinek ilyenben tapasztalata, akkor pls adjon ötletet, illetve, ha valaki használta valamelyik módszert, érdekelnének a buktatók, limitációk.
Minden új ötlet érdekel, mivel egyelőre tervezés előtti fázisban van a dolog...
Remélem nem írtam tele helyesírási hibákkal, de ha sokat gépelek és az nem kód és nincs highlight, akkor hajlamos vagyok rá... ;)
köszi,
Halee
Adat jellege
Módosítani kell a fekete dobozokat
Ellenkező esetben neked szolgáltató oldalon is pár dologot kezelned kell: mi történik, ha a kliens nem érhető el, mi történik ha queue nem megy, lejár az üzenet és senki nem vette el, neked kell ütemezni az adatküldést, ami persze nem biztos, hogy minden kliensnek megflelő időpontban lesz (pl. geológiailag messze lévő kliensnek a szerver éjszakai adatküldése lehet, hogy pont a kliens csúcsterhelési időszakában van)... Egy webservice esetén jól körülhatárolható módon kell egyszer elkészíteni a cuccot és biztosítani a futását, üzemeltetni is egyszerűbb, ráadásul a szerepkörök is helyükön vannak: te adatokat szolgáltatsz (szerver) a fekete dobozok adatokat kérnek (kliens). Az adatokat akkor viszi el a kliens amikor neki a legmegfelelőbb (persze szerver oldalon erre fel kell készülni, hogy az előző napi adatokat némelyik kliens a szerver napi csúcsán akarja elvinni, urambocsá külön adatbázis kezelje az adat szolgáltató és adatgyűjtő részeket, a szolgáltató lehet egy real-time replika is, a léneg, hogy ne zavarják egymást :). A webservice szabványos dolog, nem kell előírnod, hogy a kliens mivel (milyen nyelven megvalósított módon) éri azt el (3rd party fejlesztőként morcos lennék, ha ilyen-olyan mq termék támogatását is bele kéne vonnom a kliensembe, főleg ha olyan nyelven írtam az alkalmazásomat amihez nincs olyan mq támogatás amilyen rendszert használ a szerver). A tcp/udp kapcsolat hasonló érvek miatt nem biztos, hogy jó ráadásul nem szabványos (a tcp/udp az szabvány, de a rajta folyó kommunikáció/protokoll mindenképpen valami házi megoldás lesz, ami csak adott szolgáltatás/ügyfél specifikus)
Persze, ezt hozzá kell tenni, nem ismerem a pontos feladat specifikációt.
Köszi
Először is szeretném megköszönni a válaszodat.
Mint azt írtam jelenleg is a webservice-es megoldást használjuk, tehát a kliensek közlik az általuk végzett utolsó szinkron időpontját, és ahhoz képest adjuk a változást.
Mivel kizárólag magyarországi klienseket szolgálunk ki, így az említett időeltolódásos probléma nem lép fel, bár nemzetközi viszonylatban jogos.
Jelenleg olyan helyzetben vagyunk, hogy meghatározhatjuk a kommunikáció mikéntjét, viszont nem szeretnék ezzel visszaélni és ezért is kérem nagyobb társaság véleményét.
A feladat onnan indult, hogy magasabb körökben eldőlt, hogy lehetőséget kell teremteni arra, hogy a kliensek értesüljenek a módosításról, annak bekövetkeztekor.
Jelenleg az a megoldás a legszimpatikusabb, hogy amennyiben adatváltozás történik, úgy TCP-n és/vagy UDP-n küldünk egy csomagot (tk a tartalom annyira nem is fontos, inkább egy távoli esemény kiváltásról van szó [esetleg néhány paramétert átküldünk a csomagban]), ami után a kliens a webservice-n keresztül elkéri, hogy mi és hogyan változott...
Azt sem kell garantálnunk, hogy a csomag odaér (tehát jelenleg handshake-ben nem gondolkozunk), mert óránként küldenénk a változás tényét, amennyiben nem kérte el a frissített adatot a ws-től.
Szóval egy olyan megoldást keresek, ahol nem a kommunikáció alapját jelenti ez az "esemény" kiváltás (ugyanis éjszaka kötelező szinkron van), hanem egy plusz szolgáltatás a kliens felé, ha kvázi "real-time" adatbázist szeretne, akkor legyen erre lehetősége, anélkül, hogy mondjuk óránként a ws-t szólongatná, mivel így csak akkor történik adatátvitel, amikor arra ténylegesen szükség van.
húú, én is érzem, hogy kicsit csapongtam, de millió felé jár az agyam.
köszi,
Halee
nos :)