Windows Azure újdonságok – Service Bus IV.

Ahogy korábban olvasóinknak ígértük, igyekszünk folyamatosan frissíteni a blogot a könyv megjelenése után bejelentett Azure frissítésekkel és új szolgáltatásokkal, amik bizonyos időközönként bekerülnek majd a könyv elektronikus kiadásaiba is. Ezúttal a Service Bus újdonságokat mutatjuk be egy több részes sorozatban:

Az előző bejegyzések:

A Windows Azure SDK 2.0-s változata több újdonságot is hozott a közvetített üzenetek továbbítását megvalósító üzenetsorok és feliratkozások kezelésében, és egyúttal bemutatkozott az esemény-vezérelt programozási modell is. A főbb újdonságok az alábbi témakörökbe csoportosíthatóak:

  • Újdonságok az üzenetsorok és feliratkozások kezelésében
  • Eseményvezérelt programozási modell
  • Task alapú aszinkron API
  • Shared Access Signature (SAS) autentikáció

SAS szabályok az üzenetküldő entitásokon

Szerencsére a sorokon és témákon már a Service Bus API segítségével is szerkesztheted a SAS szabályokat, az entitásokhoz tartozó QueueDescription és TopicDescription osztályok AuthorizationRules tulajdonságán keresztül. Nézzük meg rá a példát!

olvasásának folytatása

Reklámok

Windows Azure újdonságok – Service Bus III.

Ahogy korábban olvasóinknak ígértük, igyekszünk folyamatosan frissíteni a blogot a könyv megjelenése után bejelentett Azure frissítésekkel és új szolgáltatásokkal, amik bizonyos időközönként bekerülnek majd a könyv elektronikus kiadásaiba is. Ezúttal a Service Bus újdonságokat mutatjuk be egy több részes sorozatban:

Az előző bejegyzések:

A Windows Azure SDK 2.0-s változata több újdonságot is hozott a közvetített üzenetek továbbítását megvalósító üzenetsorok és feliratkozások kezelésében, és egyúttal bemutatkozott az esemény-vezérelt programozási modell is. A főbb újdonságok az alábbi témakörökbe csoportosíthatóak:

  • Újdonságok az üzenetsorok és feliratkozások kezelésében
  • Eseményvezérelt programozási modell
  • Task alapú aszinkron API
  • Shared Access Signature (SAS) autentikáció

Shared Access Signature (SAS) autentikáció

A Windows Azure csapat valószínűleg érezte, hogy a Service Bus hozzáférések korlátozására az Access Control Service szolgáltatás (új nevén: Windows Azure Active Directory Access Control) használata az esetek jelentős részében túlzott bonyolultságot jelentett mind fejlesztési mind üzemeltetési oldalról, és sok alkalmazásnál nem megengedhető, hogy a teljes értékű adminisztratív hozzáférési kulcs beágyazása.

olvasásának folytatása

Windows Azure újdonságok – Service Bus II.

Ahogy korábban olvasóinknak ígértük, igyekszünk folyamatosan frissíteni a blogot a könyv megjelenése után bejelentett Azure frissítésekkel és új szolgáltatásokkal, amik bizonyos időközönként bekerülnek majd a könyv elektronikus kiadásaiba is. Ezúttal a Service Bus újdonságokat mutatjuk be egy több részes sorozatban:

Az előző bejegyzések:

A Windows Azure SDK 2.0-s változata több újdonságot is hozott a közvetített üzenetek továbbítását megvalósító üzenetsorok és feliratkozások kezelésében, és egyúttal bemutatkozott az esemény-vezérelt programozási modell is. A főbb újdonságok az alábbi témakörökbe csoportosíthatóak:

  • Újdonságok az üzenetsorok és feliratkozások kezelésében
  • Eseményvezérelt programozási modell
  • Task alapú aszinkron API
  • Shared Access Signature (SAS) autentikáció

Eseményvezérelt programozási modell

Üzenetsor kiolvasó és feldolgozó ciklusokat nem könnyű megtervezni és megírni. Minden ilyen („végtelen”) ciklusban kihívás definiálni, hogy mikor érjenek véget, hogyan kezeljék az átmeneti és feldolgozási hibákat, és komoly erőlátást igényel a ciklus feldolgozási sebességének megtervezése. Ebben van segítségedre a 2.0 SDK-ban megjelent eseményvezérelt, azaz „push”, programozási modell, amely a feldolgozó ciklusok alternatívája. Hogy könnyebben meglásd a különbséget, először nézzük egy egyszerűsített példát a feldolgozó ciklus megvalósítására:

olvasásának folytatása

Windows Azure újdonságok – Service Bus I.

Ahogy korábban olvasóinknak ígértük, igyekszünk folyamatosan frissíteni a blogot a könyv megjelenése után bejelentett Azure frissítésekkel és új szolgáltatásokkal, amik bizonyos időközönként bekerülnek majd a könyv elektronikus kiadásaiba is. Ezúttal a Service Bus újdonságokat mutatjuk be egy több részes sorozatban:

A Windows Azure SDK 2.0-s változata több újdonságot is hozott a közvetített üzenetek továbbítását megvalósító üzenetsorok és feliratkozások kezelésében, és egyúttal bemutatkozott az esemény-vezérelt programozási modell is. A főbb újdonságok az alábbi témakörökbe csoportosíthatóak:

  • Újdonságok az üzenetsorok és feliratkozások kezelésében
  • Eseményvezérelt programozási modell
  • Task alapú aszinkron API
  • Shared Access Signature (SAS) autentikáció

Üzenettovábbító entitások lekérdezése

A szolgáltatás névtérben létrehozott üzenetsorok és feliratkozások végpontjait együttesen üzenettovábbító entitásoknak (Messaging Entities) nevezzük. Adott névtérben az általad létrehozott entitásoknak egyedi útvonallal kell rendelkezniük. Komplex megoldások esetén könnyen előfordulhat, hogy már nem olyan egyszerű ezek követése, nyilvántartása. Már az Azure SDK 2012 októberi változatában elérhetővé vált számodra, hogy szabványos, ODATA protokollnak megfelelő formátumban, lekérdezd a témákat, üzenetsorokat és feliratkozásokat.

olvasásának folytatása

Windows Azure hírek: Egyszerűsített regisztráció, előfizetés-kezelés és számlázás

Sziasztok!

A hétvégén egy levelet kaptam a Windows Azure Platform Team-től, melyet a fontossága miatt osztanék meg veletek (változatlan formában). Azok akik nem kaptak ilyet, vagy lemaradtak róla, így szintén értesülhetnek a klub alkalmával többször is felmerült igényekre adott válaszról.

Tehát a levél:

“A  visszajelzések alapján számos fejlesztést hajtunk végre a Windows Azure élmény  fokozása érdekében.   Szeretnénk  kihasználni a lehetőséget, hogy tájékoztassuk a várható változásokról.

Főbb  pontok:

  • Egyszerűsített  regisztrációs folyamat:
    • Hozzon  létre új előfizetéseket 3 egyszerű lépésben
    • Használja  ki az új költségkorlátozás  lehetőségét, amely az új, 90 napos ingyenes  próbaverzióban és az új, MSDN előfizetésekben érhető el többletfelhasználási  díjak nélkül.
  • Rugalmas  előfizetés-kezelés:
    • Vegye fel  vagy frissítse előfizetéseit gyorsan
    • Váltson a  konstrukciók között egyszerűbben
    • Mondja le a  szükségtelen előfizetéseket közvetlenül a Windows Azure Management portálból
  • Fejlett  számlázási lehetőségek:
    • Valós idejű  hozzáférés a használattal és számlázással kapcsolatos adatokhoz közvetlenül a  Windows Azure Management portálból
    • A számlázás  minden hónapban ugyanakkor történik, az előfizetések számától függetlenül
    • Egyszerűbb,  összesített számla

A Windows  Azure használatát segítő ezen új lehetőségek (pl. költségplafon, valós idejű  hozzáférés a használati és terhelési adatokhoz) bevezetésével egy időben megszüntetjük  a havi értesítéseket a konstrukcióban foglalt számítási órák 75, 100 és 125  százalékának (vagy a 3 hónapos összesített átlag azon ajánlatok esetében,  amelyekben nincsenek számítási órák) elérésével kapcsolatban.

A bevezetés  közeledtével meg fogjuk adni a frissítések pontos időpontját, valamint közöljük  majd a további részleteket.  A tervezett  frissítés során a számlázási rendszer rövid ideig nem lesz elérhető egy hétvégi időpontban – ez kevesebb  mint 24 órát igényel majd a kezdéstől a befejezésig. A frissítési folyamat  során nem tud majd új előfizetéseket felvenni, ám a folyamat nem érinti a  futtatott Windows Azure alkalmazásokat.

Örömmel vezetjük be ezeket a  fejlesztéseket azon elkötelezettségünk részeként, amelynek keretében szeretnénk  Önnek rugalmas, könnyen használható felhő alapú platformot biztosítani. Lépjen velünk kapcsolatba, ha bármilyen kérdése van a  frissítésre vonatkozóan.

A Windows Azure csapata Microsoft Corporation”

Szerintem a pontok magukért beszélnek, a költségkorlátozás és az egyszerűsített előfizetés menedzsment pedig minden fejlesztő álma!

Command-Query Responsibility Segregation – Egy érv az Azure Table Storage mellett?

A június 15.-i azure klub keretében előkerült a SQL Azure vs Table Storage kérdés, a kettő között felállítható párhuzam (ha létezik egyáltalán ilyen), valamint egyáltalán a NoSQL megoldások létjogosultságának és használhatóságának kérdése. Akik ott voltak a találkozón emlékezhetnek, hogy valódi érveket nehezen sikerült felhoznunk a Table Storage mellett, inkább csak megérzéseket: ha a megoldásunk nem igényli a relációs adatbázisok által nyújtott szolgáltatásokat, ám szükség van valamilyen perzisztálásra. E gondolat mentén elindulva jutottam el a „Command-Query Responsibility Segregation (CQRS)”-ig, még inkább a témával foglalkozó blog oldalakig.

Ezen oldalakról összeszedett gondolatokat rendszereztem kicsit, melyek teljes megértéshez mindenképpen szükséges a CQRS legalább átfogó ismerete, amiről innen kiindulva itt olvashattok, ám ezen ismeretek nélkül is értelmezhető.

A CQRS mögötti legegyszerűbben megfogható szándék, hogy szeparáljuk az adatok megváltoztatását (command) az adatok lekérdezésétől (queries). Ezen egyszerű döntés a klasszikus alkalmazás architektúrákra nézve magával hoz pár változtatást és lehetőséget. Melyek eredményeképp a CQRS kultusz valójában fejlesztési elvek, minták és ajánlások együttese, mellyel extrémen skálázható és robosztus, magas üzleti értékkel rendelkező alkalmazásokat tervezhetünk.

Elévült adatok

Általános, hogy alkalmazásainkban több szereplő (konkrét felhasználó, vagy automatizált folyamat) párhuzamosan fér hozzá írásra/olvasásra adatok ugyanazon köréhez. Elévült adatról (Stale Data) beszélünk akkor, ha miután az egyik szereplőnek megmutattunk egy információt, a lekérdezést követő pillanatban egy másik szereplő ezt információt megváltoztatta. Így tehát nem feltétlenül bízhatunk az első szereplő döntéseiben (módosításaiban), hiszen azokat olyan információkra alapozta melyek közben elévültek.

Standard architektúráinkban e problémát legtöbbször explicit nem is kezeljük, helyette relációs adatbázisba pakoljuk adatainkat, és rá bízzuk a konkurenciakezelést. A CQRS ezzel szemben azt állítja, hogy az adatoknak mindig aktuálisnak (staleness) kell lennie (legalábbis közel aktuálisnak), így explicit módon szükséges kezelni a konkurencia kérdését. Akkor miért is van szükségünk tranzakciós adatbázisra?

Lekérdezések (Queries)

Adatainkat a relációs adatbázisokban n.-ik (n>=2) normálformában tároljuk, majd ezeket képezzük le az üzleti modellünkre. Az adatokon kívül másra nincs szükségünk, így felesleges a relációs adatbázisok minden megszorítása és tárolási szabálya. Majd ezen üzleti modellt tovább transzformáljuk DTO-kra (Data Transfer Objects), hogy hálózaton keresztül továbbíthatóak legyenek. Elég csak a WCF DataContract-jaira gondolnunk. Az MVC minta elterjedésével pedig modellünket végül leképezzük a „view model” objektumaira. Rengeteg (felesleges?) munka, mindez az újrahasználhatóság jegyében!

Készítsünk helyette egy extra adattárat, elvégre az adataink úgyis mindig aktuálisak! Miért ne lehetne eleve a view model reprezentálva ebben a tárban? Egy tábla minden view-hoz. Alkalmazásaink egy egyszerű „select * from myviewtable” lekérdezéssel megjeleníthetnék aktuális felületüket. Gondoljunk ebbe bele egy kicsit! Nincsenek relációk az egyes view model-ek között, a kapcsolatot maximum egy „where” feltételben megfogalmazott elsődleges kulcs jelenti, azaz nincs szükségünk a relációkra az adattárolás oldalán sem! Sőt, semmi akadálya, hogy akár több tárunk is legyen a lekérdezések számára, megteremtve az extrém skálázhatóság egy újabb eszközét!

Módosítások (Commands)

A CQRS egyik legfontosabb pontja a felhasználói felületek újragondolása. Módosításainkat parancsokba szervezve, a modellen történő közvetlen módosítás helyett, újra kell gondolnunk, hogy mely párhuzamos műveleteket engedjük meg és melyeket utasítjuk vissza. Példaként egy partner nevének, vagy címének módosítása minden további nélkül megtörténhet párhuzamosan, sőt ugyanazon partner státuszát is bátran módosíthatjuk. Minden parancs esetén explicit módon szabályozva döntünk arról, hogy mely további parancsok feldolgozását engedjük. Minél nagyobbak entitásaink, minél több attribútummal rendelkeznek, annál nagyobb az esélye, hogy a standard architektúrákban ütközésre kerül sor, ezáltal frissítésre és a művelet megismétlésére kényszerítve a felhasználót. A módosítások „command”-okba szervezésével akár azt is megtehetjük, hogy ugyanazon szereplő újabb módosítást kérjen mielőtt az előző sikerességét egyáltalán visszajeleztük. Egy módosítás sikertelensége esetén pedig egyszerűen értesítjük a felhasználót az adott parancs sikertelenségéről, és ő dönthet a szükséges lépésekről.

Mint láthattuk a parancsainkat nem szükséges azonnal feldolgozni, várakozási sorba (Queue) pakolhatóak. A feldolgozás sebessége innentől nem architektúrális, hanem „SLA” kérdése. Mi több, parancsainkat kategorizálva külön-külön várakozási sorok alakíthatóak ki. Nagyobb terheltség esetén csak a szükséges parancsfeldolgozók számának növelésére van szükség.

Mivel módosításainkat ilyen módon külön tároljuk a lekérdezésektől és a modelltől, több lehetőség is megnyílik előttünk. Tárunkhoz való hozzáférés optimalizálását explicit módon szabályoztuk, csökkentve a rendszer érzékenységét a tár hibáira, a felhasználónak nem is kell értesülnie a felmerülő problémákról. Nincs is szükségünk a relációs adatbázisoktól megszokott tranzakcionalitásra, deadlock kezelésre.

Az üzleti modell

A CQRS elvei nagy hatással vannak alkalmazásaink üzleti modelljére is. Semmi sem követeli meg tőlünk, hogy különböző parancsainkat ugyanazon üzleti modellen értelmezzük. A másik oldal pedig, hogy immár nem az üzleti modellünkön fogalmazzuk meg a lekérdezéseket, így nincs szükség az egyes entitások közötti relációk nagy számosságára. Modellünk szeparálhatóvá válik, az egyes részek akár eltérő implementációval is megadhatók. A modellünkön értelmezett ilyen
egyszerűsítések bevezetésével az „aggregate root” entitások relációi akár meg is szüntethetőek. Senki sem fogja a modellünkön lekérdezni egy partner rendeléseit (Partner 1 – * Orders), a kapcsolatok egyszerű ID kapcsolatokra vezethetők vissza, melyek szükség esetén feltölthetőek, hisz a felhasználói felület megjelenését nem lassítják. Ezt az ID-t pedig a parancsaink hordozzák.

Ilyen formában parancsaink egyetlen entitáson értelmezhetőek lesznek, a relációs adatbázisok tábla
szerkezete is fölöslegessé válhat, valós alternatívává téve számunkra a felhő platformok kulcs-érték típusú table storage megoldásait.

Felhő plattform

Alkalmazásaink újragondolásával és a CQRS alkalmazásával a választott technológiáktól sokkal függetlenebbül
koncentrálhatunk tisztán az üzleti igényekre, úgy hogy élvezzük az alábbi előnyöket:

  • Közel végtelen skálázhatóság
  • Komplex problémák is modellezhetőek a fejlesztési komplexitás növekedése nélkül
  • Más rendszerekkel való integráció jóval szabadabb foka
  • Robosztus, hibatűrő és tervezetten konkurens alkalmazás
  • Kiaknázhatjuk a felhő platform nyújtotta szolgáltatások előnyeit

Egy lehetséges referencia cloud platformra szánt architektúra az alábbiakból építkezhet:

  • CQRS
  • DDD
  • Üzenet alapú architektúra, Message Queuing
  • Service Bus és Event Sourcing
  • NoSQL tárolás, Azure Storage

Természetesen ez nem jelenti azt, hogy felhőre minden alkalmazást így éri meg elkészíteni, mindig az aktuális követelmények határozzák meg a szükséges architektúrát és implementációs technológiát, ám remélem a lehetőségek egy újabb halmazát sikerült ezzel a kis gondolatébresztővel számotokra megvilágítani.

Forrásanyagok:

Ha valakinek akár a CQRS-el kapcsolatban, akár a CQRS és a felhő platformok lehetséges előnyeivel és hátrányaival kapcsolatban kérdése van, esetleg érdekelné példa architektúra és implementáció az írjon bátran a megjegyzések közé, vagy keressen email-ben az ersek.attila@hotmail.com címen.