Witaj na Zine.net online Zaloguj się | Rejestracja | Pomoc

Simon says...

Szymon Pobiega o architekturze i inżynierii oprogramowania
NServiceBus - przykład 2: publish/subscribe
Wracam po świąteczno-noworocznej przerwie z drugą częścią tutoriala NServiceBus.

Drugi z przykładów, które chciałbym z Wami omówić to demo subskrypcji. W katalogu z przykładami NServiceBus znajdziecie go pod nazwą „PubSub”. Solution składa się z 4 projektów.
MyMessages zawiera definicje wymienianych komunikatów. Zwróćcie uwagę, że są tam dwa elementy: interfejs IEvent oraz klasa EventMessage z niego dziedzicząca. Skąd to i po co? I dlaczego to wytłuszczenie? Otóż NServiceBus posiada unikalną własność — umożliwia definiowanie komunikatów jako interfejsów oraz obsługuje ich dziedziczenie  (zarówno między interfejsami, jak i między interfejsami i klasami). Jak to działa? Jeśli zdecydowałem się odbierać (czy to przez subskrypcje, czy też „klasycznie” – request/response) pewien typ komunikatu, to mój endpoint będzie odbierał także wszystkie komunikaty, których typy dziedziczą z podanego.

Ale skończymy to teoretyzowanie i popatrzmy na przykład. MySubscriber1 zawiera handler dla komunikatu typu EventMessage. NServiceBus automatycznie przy starcie wykrywa ten fakt, odnajduje w pliku konfiguracyjnym adres kolejki wejściowej instancji NSB publikującej ten komunikat i zgłasza się do niej jako subskrybent.

MySubscriber2 wykorzystuje możliwość własnej inicjalizacji instancji NSB i wymusza pominięcie automatycznej subskrypcji.

    1 public class EndpointConfig : IConfigureThisEndpoint, IWantCustomInitialization
    2  {
    3      public void Init()
    4      {
    5          NServiceBus.Configure.With()
    6              .CastleWindsorBuilder() // just to show we can mix and match containers
    7              .XmlSerializer()
    8              .MsmqTransport()
    9                  .IsTransactional(true)
   10              .UnicastBus()
   11                  .DoNotAutoSubscribe() //managed by the class Subscriber2Endpoint
   12                  .LoadMessageHandlers();
   13      }
   14  }

Jest ona zrealizowana „manualnie” w klasie Subscriber2Endpoint. MySubscriber2 zawiera handler dla komunikatów typu IEvent.

„Skomplikowana” logika zawarta w Publisherze

var eventMessage = publishIEvent ? Bus.CreateInstance<IEvent>() : new EventMessage();

sprawia, że co drugi raz wysyłany jest komunikat typu EventMessage, a co drugi — anonimowa (dynamicznie generowana) implementacja IEvent. Zastanówmy się wobec tego jak zachowają się subskrybenci. Subscriber2, któremu obojętne co przetwarza, pod warunkiem, że to „coś” stosuje się do kontraktu IEvent będzie reagował na każdy opublikowany komunikat. Subscriber1 jest selektywny — nie interesuje go „byle jaka” dynamiczna implementacja IEvent. On chce tylko EventMessage. Będzie więc reagował na co drugi komunikat. Prawda, że sprytne?

Co ważne, decyzja kto jest zainteresowany danym komunikatem następuje na poziomie publikującego, a nie subskrybującego. Publisher nie wysyła do MySubscriber1 anonimowych implementacji IEvent, gdyż wie, że ten sobie tego nie życzy.

Ostatnim elementem przykładu jest implementacja interfejsu IAuthorizeSubscribtions. Pozwala ona na określenie, na podstawie danych o nadawcy, czy pozwolić na realizację danego żądania subskrypcji. Mechanizm ten pozwala skutecznie ograniczyć zakres publikacji do wyłącznie zaufanych maszyn i/lub użytkowników.

Opublikowane 7 stycznia 2010 17:13 przez simon

Filed under:

Komentarze:

# re: NHibernate - przykład 2: publish/subscribe @ 7 stycznia 2010 19:09

Czy NServiceBus nadaje się do używania w shared hostingu? Czy są inne transporty niż msmq? Powiedzmy że mam aplikację na home.pl i prawdopodobnie nie mam dostępu do msmq co byś na to poradził?

Czy również wątek susbscribera może chodzić w kontekście aplikacji webowej? (mam na myśli cykl życia puli aplikacji IIS).

pawel

# re: NHibernate - przykład 2: publish/subscribe @ 7 stycznia 2010 19:12

btw w tytule powinno być NServiceBus .. chyba

pawel

# re: NServiceBus - przykład 2: publish/subscribe @ 7 stycznia 2010 19:22

@pawel Dzięki:)

simon

# re: NServiceBus - przykład 2: publish/subscribe @ 7 stycznia 2010 19:23

@pawel Nad pytaniami się muszę zastanowić -- odpiszę napewno, ale później:)

simon

# Simon says... : NServiceBus - przykład 2: publish/subscribe @ 7 stycznia 2010 20:08

Dziękujemy za publikację - Trackback z dotnetomaniak.pl

dotnetomaniak.pl

# re: NServiceBus - przykład 2: publish/subscribe @ 7 stycznia 2010 20:26

Wydaje mi się, że użycie NSB w wypadku shared hostingu nie jest najlepszym pomysłem - po prostu byłaby to raczej "armata na mrówki". Czy shared oznacza parial-trust? Jeśli tak, to z tego, co wiem, jest to niemożliwe.

Do NSB istnieje kilka alternatywnych transportów, na bazie m.in. czystego UDB, Apache Active MQ, kolejek Windows Azure i innych.

NSB może działać w kontekście aplikacji webowej hostowanej na ASP.NET, jest nawet na to odpowiedni sample, który postaram się w najbliższym czasie przedstawić.

simon

# re: NServiceBus - przykład 2: publish/subscribe @ 7 stycznia 2010 22:36

"Wydaje mi się, że użycie NSB w wypadku shared hostingu nie jest najlepszym pomysłem - po prostu byłaby to raczej "armata na mrówki"" -

W takim razie nie wiem czy dobrze rozumiem ideę.  Czy nsb nie nadaje się jako proxy dla dużej ilości jednostkowych zadań np. masowego mailingu, albo przyjęcia duże ilości danych z zewnątrz w krótkim czasie. Czy takie zastosowanie nie było intencją Udiego?

pawel

# re: NServiceBus - przykład 2: publish/subscribe @ 8 stycznia 2010 07:38

Hmmm wiesz co, musiałbyś mi chyba powiedzieć coś więcej na temat tego "hipotetycznego systemu";). Mówiąc o armacie na mrówki miałem na myśli, że jeśli aplikacja ma być hostowana na współdzielonym serwerze, to nie ma jakiś specjalnie wygórowanych wymagań wydajnościowych, których nie bylibyśmy w stanie zaspokoić "tradycyjnymi" metodami. Ale to tylko takie ogólne spostrzeżenie - jak zwykle w takich sprawach prawidłową odpowiedzią jest "it depends":)

simon

Komentarze anonimowe wyłączone