Analýza existujících implementací a přístupů

Analýza existujících implementací a přístupů

Analýza existujících implementací a přístupů - NServiceBus
1.0, Soběslav Benda
Úvod:
- NServiceBus [http://www.nservicebus.com/] je .NET open source implementace
založená na architektonickém stylu sběrnice (nikoliv na architektonickém stylu broker,
jako např. BizTalk, nebo plánovaný XRouter ☺)
- NServiceBus není jedna fyzická entita, ale mnohem více se podobá technologii WCF a
to v tom, že při používání WCF není jeden bod v síťové topologii, ale WCF je části
infrastruktury, která běží v různých procesech společně s aplikačním kódem
- NServiceBus tedy nabízí framework jehož objekty mohou běžet v různých procesech
společně s aplikačním kódem a zmíněné objekty umožňují spolu síťově komunikovat
a vytvářet peer-to-peer síťové topologie
- Pro lepší demonstraci ještě obrázek, kde uvedené aplikace mohou běžet na různých
strojích a komunikace je tak řešena na úrovni frameworku NServiceBus podpořeného
konfigurací jednotlivých aplikací:
-
-
s frameworkem je dodáváno několik samostatných procesů (např. proxy), které nic
nemění na uvedeném modelu
NServiceBus je založeno na queued messaging, resp. instance komunikačních
komponent si vyměňují zprávy prostřednictvím MSMQ
o běžný messaging mezi klientem a serverem vyžaduje, aby byly při komunikaci
obě strany k dispozici (tedy jako běžící procesy), takže pokud není server
k dispozici, pak není komunikace provedena (toto odpovídá např. používání
RPC WCF)
o při použití NServiceBus může být server vypnutý a klient zařadí zprávu do
lokální fronty (konkrétně někam na hard disk), kde zpráva vyčkává, až je
cílový příjemce k dispozici, potom je zpráva příjemci předána a z disku je
smazána
o takový messaging je označovaný jako durable (odolný)
zprávy se v NServiceBus definují kódově, obdobně jako ve WCF
stejně tak kódově se dá nastavit, jestli má být zpráva ukládána na disk, timeout
doručení zprávy apod.
příjemci se definují v konfiguraci u každé služby, konfigurace je prováděna přes XML
Výhody:
1. eliminace poškození celého komunikačního prostředí odstávkou jedné z komponent
(komunikace neprochází přes nějaký centrální broker)
2. spolehlivost = komunikace je založena na asychronním messagingu s persistencí zpráv
(souvisí s bodem 1)
3. efektivita (souvisí s bodem 1)
Nevýhody:
1. nutno stavět komunikační prostředí na zelené louce (to rozhodně nechceme, my
chceme podporovat i existující aplikace, na druhou stranu je možno zřejmě využít
další procesy dodávané s NServiceBus, např. proxy), mnohem spíš se tato technologie
podobá WCF a s ní je možno srovnávat
2. architektura je v podstatě založena na peer-to-peer, takže počet spojení mezi
aplikacemi může být stále obrovský, není však zadrátováno v kódu, ale je přeneseno
na konfiguraci => přidání komponenty => úprava konfigurace na několika místech IT
infrastruktury
3. Zprávy a i další vlastnosti vztahující se k transportům je nutno definovat kódově.
Shrnutí:
Celkově nemá smysl podrobněji popisovat architekturu, detaily a další principy řešení
NServiceBus. Řešení je to určitě pěkné, zajímavé a použitelné. NServiceBus je však něco, co
rozhodně nechceme. Jedná se o framework, který může být úspěšně použit programátory
k vytváření komunikačního prostředí (obdobně jako je WCF).
Našim cílem je přenést tvorbu komunikačního prostředí mnohem spíš na administrátory a
analytiky s minimalizací manuální účasti programátorů a vytvořit spustitelný nástroj, který
bude založen na XML technologiích. Nicméně XRouter může být na NServiceBus napojen.