Windows Azure lépésről lépésre, 13. fejezet – interjú és részlet

A tervek szerint március 12-én megjelenik a „Windows Azure lépésről lépésre”, az első magyar nyelvű szakkönyv a Microsoft felhőplatformjáról. Mostantól kezdve egészen a megjelenés napjáig minden munkanapon foglalkozunk a könyvvel: rövid interjúkat készítünk az egyes fejezetek szerzőivel, és egy-egy részletet is közzéteszünk a könyvből.

Ezúttal Érsek Attilával beszélgetünk munkájáról, az Azure-ral való kapcsolatáról és a könyvben vállalt szerepéről.

 

Ne feledkezzetek el nyereményjátékunkról:
Ossz meg egy fejezetet, hívd meg a főnöködet, nyerj Azure-könyvet!

Az előző bejegyzések:

Kérlek, mesélj magadról néhány mondatot, mivel foglalkozol és hol?

Több éve már, hogy az SDA Stúdió Kft. szoftver architectjeként dolgozom, ahol a legkülönfélébb partnerek számára tervezünk és szállítunk változatos problémákra megoldásokat. Bár Delphi, ANSI C és Java háttérrel indultam, ma már elkötelezett .NET szakértőként dolgozom, persze követve a modern idők JavaScript őrületét is. Amellett, hogy szeretem a hosszú távon is fenntartható, tartós szoftvereket, szinte megszállottan követem a szakmai trendeket, újításokat. Kollégáim nagy örömére, ugyanis így időről-időre sikerül előrukkolni valami még bonyolultabb megoldással.

Mi a kapcsolatod a Windows Azure-ral?

Igazán lelkesen az Azure magyarországi bejelentése óta foglalkozom felhő alapú megoldásokkal, és magával az Azure platformmal. Talán ennek is az eredménye, hogy az elsők között sikerült komoly (díjjal is kitüntetett) felhős alkalmazást készítenünk. Érdekes, hogy a kezdetekben a PaaS-ből engem nem a skálázhatóság, hanem az egységes és biztos alapokra épített platform fogott meg. Mára viszont teljesen magával ragadott az eventsourcing és a CQRS, így az extrém skálázhatóság nyújtotta lehetőség, és változásokra történő gyors reagálás lett magasabb prioritású. A számítási felhő és a NoSQL mozgalom megjelnésével lehetőségek tárháza nyílt szoftvertervezés és fejlesztés terén.

Mivel ismerteti meg az általad írt fejezet az olvasót?

A Service Bus szolgáltatás alapismereteit próbáltam összefoglalni. Ez egy, akár nagyvállalati környezetben is jól alkalmazható, szolgáltatási és üzenetszórási megoldás, és mint ilyen, meglehetősen bonyolult is tud lenni. Leginkább szoftverek integrációjakor, vagy lazán kapcsolt modulokból felépülő robusztus alkalmazások fejlesztésekor érdemes hozzányúlni, de akkor viszont nagyon. Talán az egyik legkomolyabban kidolgozott Windows Azure szolgáltatás, ám egyúttal egy kicsit elhallgatott része is, mert szinte lehetetlen a használatára közérthető, “helló világ” bonyolultságú példákat hozni. Megvallom, a fejezet megírásakor nekem is a megadott oldalszámkeret tartása jelentette a legnagyobb kihívást.🙂

Milyen újdonságokat látsz a saját területeden?

Ha a Service Bus szolgáltatást értjük alatta, akkor a legjobb példa a folyamatos fejlődésre, hogy alig pár napja jelent meg a Service Bus 1.0 for Windows Server megoldás, mely egy az egyben megfelel a publikus felhőben futó párjának. Így ma már gondolkodás nélkül nyúlhatunk ehhez az eszközhöz alkalmazásainkban. Bár maga a szolgáltatás elég kerek, maga a “messaging” terület jóval nagyobb, így akár óriási változások is jöhetnek.

Ha pedig szoftver architectként érdekes a kérdés, csak elég szétnézni a Domain Driven Design és CQRS körökben, mekkora változásokat és pörgést okoztak a számítási felhők nyújtotta lehetőségek.

Részlet a 13. fejezetből:

Service Bus Messaging

A Service Bus Relay szolgáltatása egy teljes értékű ISB megvalósítás, ha szolgáltatások és kliensek közötti üzenetek továbbítását kell megvalósítani interneten és felhőn keresztül, de nem ad választ a kommunikáló felek ideiglenes szétkapcsolására, üzenetszórásra és terhelés megosztásra. Ezért a Service Bus 1.5-ös verziójától elérhető a tartós üzenetsorok és feliratkozások kezelésének megvalósítása. A továbbított üzenetekkel (relayed messages) szemben a közvetített üzenetek (brokered messages) aszinkron, ideiglenesen szétkapcsolt kommunikációt valósítanak meg. A Service Bus megbízhatóan és tartósan tárolja az üzeneteket, amíg azok feldolgozásra nem kerülnek. A szolgáltatásokat üzenetfogyasztóként (message consumer), a klienseket pedig üzenetgyártóként (message producer) definiálja. A két fél között a Service Bus üzenetközvetítőként (message broker) üzenetsorokat (queues) és üzenet témákat (topics) biztosít.

A csatolásmentes (decoupled) kommunikációnak rengeteg előnye van, például a szolgáltatásoknak elegendő csak akkor a következő üzenetért fordulniuk, ha már készen állnak annak feldolgozására. Közvetlenül továbbított üzenetek esetén a kommunikációt a küldő fél kezdeményezi, közvetlen nyomást helyezve a fogadóra. A fogadó félnek készen kell állnia az üzenet fogadására és feldolgozására a kontraktusok által előírt időtúllépési értéken belül. Közvetített üzenetek esetén a küldő üzenetét az üzenetközvetítő fogadja és tárolja, amíg az üzenet fogyasztója készen nem áll a következő üzenet feldolgozására.

Üzenetsorokat az Azure Queue Storage is biztosít számodra, de milyen esetekben érdemes mégis a Service Bus megvalósítást választanod? Akkor, ha az alábbi fejlett szolgáltatások valamelyike szükséges:

  • Hibás és elévült üzenetek automatikus kezelése
  • Duplikált üzenetek detektálása
  • Biztonságos azonosítás az Access Control szolgáltatáson keresztül, és eltérő jogosultsági szintek biztosítása
  • Tranzakciók kezelése, több üzenet küldése és fogadása egy atomi műveletben
  • Fontos az üzenetek garantált First-In-First-Out (FIFO) sorrendben való feldolgozása
  • WCF és WF támogatás

Abban az esetben, ha két Windows Azure szerepkör közötti egyszerű kommunikációt kell megvalósítanod, és nincs szükséged az itt felsorolt képességek valamelyikére, akkor az Azure Storage megvalósítás elegendő.
A két Queue megvalósítás alapos összehasonlítását megtalálod a http://msdn.microsoft.com/en-us/library/windowsazure/hh767287.aspx címen

A közvetített üzenet használatához először egy Service Bus szolgáltatás névtér létrehozására lesz szükséged – a már megismert módon. A menedzsment feladatok – mint például üzenetsor létrehozása vagy törlése – elvégzéséhez nevesítened kell a Service Bus végpont címét és az azonosítási adatokat. Ezeket az információkat tartalmazó kapcsolódási karakterlánc felépítése az alábbi:

Endpoint=sb://[namespace].servicebus.windows.net/;SharedSecretIssuer=[issueed];SharedSecretValue=[key]

Ezt a kapcsolódási karakterláncot elhelyezheted a .NET alkalmazásod konfigurációs állományában (*.config) vagy az Azure szerepkör konfigurációjában (*.cscfg és *.csdef). A .NET konfigurációs rendszerének használatakor ezt a beállítást az bejegyzés alatt kell elhelyezned. Bármelyik megoldást is választod, a Microsoft.WindowsAzure névtér CloudConfigurationManager statikus osztálya segítségével éred el legegyszerűbben:

var connectionString =CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");

Bár a Microsoft.ServiceBus NuGet csomagból való telepítése esetén a Visual Studio a szükséges mintabejegyzést automatikusan elhelyezi számodra az alkalmazás konfigurációjában, Azure szerepkörök esetén helyesebben jársz el, ha ezt az információt a szerepkör konfigurációjában tárolod.

Az üzenetsorok és témák kezeléséhez szükséges műveleteket a Microsoft.ServiceBus névtér NamespaceManager osztály példányán keresztül érheted el. A szükséges példányt a kapcsolódási karakterlánc alapján legegyszerűbben az osztály statikus CreateFromConnectionString metódusával hozhatod létre, ahogy azt a példa is mutatja:

var namespaceManager = NamespaceManager.CreateFromConnectionString(connectionString);

Ha haladó beállításokra vagy a Shared Secret megoldástól eltérő azonosítási lehetőségre van szükséged, akkor az osztály valamely konstruktorát használd!

Holnap a 14.fejezettel folytatjuk!

3 thoughts on “Windows Azure lépésről lépésre, 13. fejezet – interjú és részlet

  1. Visszajelzés: Windows Azure lépésről lépésre, 15. fejezet – interjú és részlet | Felhők között

  2. Visszajelzés: Windows Azure lépésről lépésre, 16-17. fejezet – interjú és részlet | Felhők között

  3. Visszajelzés: Windows Azure lépésről lépésre, 17. fejezet – interjú és részlet | Felhők között

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s