Moja własna szyna
Zgodnie z obietnicą złożoną w poprzedniej notce, rozpocząłem pracę na moją własną szyną komunikatów. Dziś chciałbym podzielić się z Wami moją motywacją (w nawiązaniu do “not invented here”) oraz opowiedzieć nieco o celach, jakie sobie postawiłem.
Motywacja
Są dwie. Pierwsza to szkolenie z asynchronicznego podejścia do SOA, które to szkolenie mam zamiar przeprowadzić w mojej firmie. Inspiracją dla mnie jest nie kto inny, jak Udi Dahan i jego prezentacja, którą miałem przyjemność oglądać na zeszłorocznym TechEd-zie. Niestety jestem przekonany, że nie udałoby mi się zmusić ludzi do poświęcenia półtorej godziny na oglądanie filmu z konferencji (nota bene po angielsku oczywiście). Dlatego postanowiłem
- wyciągnąć z sesji Udiego najważniejsze fakty i przedstawić je w skondensowanej formie menedżerom
- zorganizować warsztaty dla pracowników technicznych i pokazać im naocznie to, o czym Udi tylko opowiadał
Czyli w skrócie – dla każdego coś miłego. Do tej drugiej części potrzebne mi było narzędzie – szyna komunikatów. Pomyślałem o nServiceBus, ale po przejrzeniu kodu natychmiast zrezygnowałem. Kilkadziesiąt projektów, z których duża część istnieje tylko po to, aby zdefiniować API, aby jakiś inny projekt mógł dookreślić to API, a jeszcze inny je zaimplementować. Takie coś na pewno odciągnęłoby moją audiencję od sedna sprawy i warsztaty sprowadziłyby się do tego, jak poprawnie podłączyć wszystkie wtyczki nServiceBus.
Potrzebowałem czegoś prostego (nawiązując do komentarza Arka: czegoś o 8 klasach, a nie 200).
Drugi powód to chęć poznania bliżej technologii SQLServer Service Broker. Jest to chyba jeden z mniej znanych (i wykorzystywanych) ficzerów SQLServera. Dla tych, którzy nie kojarzą, co to takiego, w telegraficznym skrócie – Service Broker to infrastruktura kolejkowa (jak MSMQ), ale wbudowana w silnik bazy danych. Ma to jedną ogromną zaletę, a mianowicie pozwala na transakcyjne korzystanie z kolejek i z silnika bazy danych wykorzystując jedynie transakcje lokalne SQLServer (a nie transakcje rozproszone).
Cele
Skoro już wiecie, jakie są powody mojej brawurowej decyzji, poznajcie teraz moje cele. Jest właściwie jeden: zrobić to, co mam zrobić, ale inaczej. Nie widzę sensu w kopiowaniu rozwiązań Udiego lub Ayende (mimo, że uważam oba za bardzo dobre). Robiąc coś zupełnie inaczej być może dokonam czegoś ciekawego. Zasługującego przynajmniej na kilka notek na Zine-ie;)
W wypadku szyny komunikatów “zrobić coś inaczej” oznacza:
- Zdefiniowanie abstrakcyjnego API dla mechanizmu wymiany komunikatów pozwalającego na wykorzystanie różnych implementacji zamiast tworzenia frameworku z tysiącem wtyczek do zaimplementowania
- Dobra integracja z innymi abstrakcyjnymi API
- dostępu do danych
- logowania
- konfiguracji
- Maksymalne wykorzystanie infrastruktury dzięki możliwości implementowania całości szyny (API szyny) z użyciem konkretnego mechanizmu kolejkowania
- wykorzystanie transakcji lokalnych
- MARS
- Udostępnienie minimalnego bezpiecznego interfejsu zamiast interfejsu ogólnego, w przypadku którego użytkownik musi się zastanawiać nad konsekwencjami (błędy?) wykonania każdej operacji.
- obsługa naraz tylko pojedynczego komunikatu
- bezwzględne zapewnienie transakcyjności
Na koniec pozostaje mi jedna do Was prośba: wish me luck!
