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:


while (!cancellationToken.IsCancellationRequested)
{
 BrokeredMessage message;
 try
 {
 message = queueClient.Receive(TimeSpan.FromMilliseconds(500));
 }
 catch (MessagingException exception)
 {
 if (!exception.IsTransient)
 {
 Trace.TraceError(exception.Message);
 throw;
 }
 Trace.TraceWarning(exception.Message);
 continue;
 }
 if (message != null) //volt üzenet
 {
 Trace.WriteLine(String.Format("Processing: {0}", message.SequenceNumber.ToString()));
 message.Complete();
 }
}

Egy üzenet feldolgozó ciklus esetén a te megvalósításodtól függ az üzenetek kiolvasásának időzítése, a kommunikáció során bekövetkező hibák kezelése, és a párhuzamos feldolgozás megvalósítása. Ebben van segítségedre az új programozási modell, mely a fentebbi feladatok nagy részét megvalósítja helyetted.

Mielőtt áttekintenénk a részleteket, nézzünk egy példát az eseményvezérelt üzenet feldolgozásra:


var onMessageOptions = new OnMessageOptions()
 {
 AutoComplete = true,
 MaxConcurrentCalls = 5,
 };

onMessageOptions.ExceptionReceived +=
 (sender, eventArgs) =>
 {
 Trace.TraceError(eventArgs.Exception.Message);
 };

queueClient.OnMessage(
 message =>
 {
 Trace.WriteLine(String.Format("Processing: {0}", message.SequenceNumber.ToString()));
 },
 onMessageOptions);

Hogy megértsd a működését, vegyük sorra a példa sorait! A „message pump” megvalósítás működését az OnMessageOptions osztály egy példányával szabályozhatod, amely az alábbi beállításokat teszi lehetővé:

  • AutoComplete: Engedélyezett esetben a PeekLock módban létrehozott üzenetsorok esetén az üzenet sikeres feldolgozása után automatikusan meghívja az üzenet Complete() metódusát. Alapértelmezetten true értékkel rendelkezik
  • MaxConcurrentCalls: Azt szabályozza, hogy hány konkurens szálon hívható meg az üzenet feldolgozó művelet. Alapértelmezett értéke: 1.
  • ExceptionReceived: Esemény, melyre feliratkozva értesítést kaphatsz az üzenetek fogadása közben bekövetkező kommunikációs hibákról. Ilyen hibák lehetnek az átmeneti kommunikációs, és a jogosultságokkal kapcsolatos kivételek.

Az onMessageOptions változó beállítása után egyszerűen csak meg kell hívni az OnMessage metódust, mely paraméterként várja az Action<BroekredMessage> típusú függvényt, és az előbb létrehozott paraméter példányt.

Az AutoComplete tulajdonság használata esetén fontos, hogy ne „nyeld” le a feldolgozás során bekövetkező kivételeket, mert az API így értesül róla, hogy ne hívja meg az üzenet Complete metódusát. Természetesen az így bekövetkezett kivétel a háttérben kezelésre kerül, és az üzenet fogadása folytatódik tovább. A MaxConcurrentCalls tulajdonság 5-re állítása engedélyezte, hogy akár 5 üzenet párhuzamos feldolgozása is megtörténjen. Ez a minimális erőfeszítés elegendő volt, hogy a párhuzamosítással nagymértékben növeljük az üzenetek feldolgozási sebességét. Természetesen a feldolgozás szálbiztonságát neked kell garantálnod.

Az üzenetek fogadását a MessageClientEntity osztályt megvalósító üzenetsor vagy feliratkozás kliensének Close metódusának meghívásával állíthatod le:

queueClient.Close();

Ezzel az új programozási modellel hatékonyabb és áttekinthetőbb kód írható, mely lehetővé teszi számodra, hogy az infrastrukturális kérdések helyett a számodra fontos megoldandó problémára koncentrálj.

Task-alapú aszinkron API

Ez a viszonylag kisebb változtatás, amely az új async/await programozási modell támogatásával az aszinkron kódokat egyszerűsíti és teszi olvashatóbbá. Minden metódus, amelynek volt egy Begin/End kezdetű aszinkron párja, most már rendelkezik egy Async végű verzióval is. Ezek a verziók System.Threading.Tasks.Task típusú visszatérési értékkel rendelkeznek.

Az aszinkron programozási modell (minden Begin/End kezdetű metódus), hogy a paraméterek ellenőrzése a Begin metódusban történik, míg a feldolgozás során bekövetkező hibák az End metódusban jelentkeznek. Így mindkét helyen szükséges a lehetséges kivételek kezelése:

try
{
queueClient.BeginSend(message, EndMessageSend, queueClient);
}
catch (ArgumentException)
{
}

//...

static void EndMessageSend(IAsyncResult result)
{
 var queueClient = (QueueClient)result.AsyncState;
 try
 {
 queueClient.EndSend(result);
 }
 catch (OperationCanceledException)
 {
 }
}

A fenti kódrészlet async/await modell szerinti megvalósítása így néz ki:


try
{
 await queueClient.SendAsync(message);
}
catch (ArgumentException)
{
}
catch (OperationCanceledException)
{
}

Miközben az alkalmazásod vár a hálózati kommunikáció befejezetésére, lehetőséged van párhuzamos műveletek elvégzésére. Az így egyszerűsödő aszinkron megoldások alkalmazásával nagyban hozzájárulhatsz a felhasználói elégedettség növeléséhez úgy, hogy közben a kód bonyolultsága minimálisan növekszik.

Ezeket az újdonságokat Te is kipróbálhatod! Regisztrálj az ingyenes, 90 napos Azure előfizetésre!

Holnap folytatjuk!

2 thoughts on “Windows Azure újdonságok – Service Bus II.

  1. Visszajelzés: Windows Azure újdonságok – Service Bus III. | Felhők között

  2. Visszajelzés: Windows Azure újdonságok – Service Bus IV. | 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