1. FABRIQ – архитектура за високопроизводителни разпределени изчисления, базирана на съобщения Светлин Наков www.devbg.org

2. Съдържание Web-услуги, WSE, SOA и Indigo Агентно-ориентирани архитектури Мрежи от опашки Продуктът FABRIQ Съобщения Обработчици на съобщения Поточни линии (pipelines) Действия и договори Адресация Хостинг на възлите Сигурност Архитектурни перспективи пред FABRIQ

3. Какво е услуга? В реалния свят услугата е: единица работа, извършвана от доставчик на услуги предоставя някакъв желан резултат на клиента (консуматор на услуги) с ясно дефинирани входни параметри и изходни резултати лесна за използване винаги достъпна има характеристики за качество (цена, време за извършване, ефективност и т.н.)

4. Web- услуги Web- услугите моделират услугите от реалния свят програмни компоненти, достъпни отдалечено през Web модел за изпълнение “заявка-отговор” клиентът поръчва, услугата изпълнява поръчката и връща резултат използват отворени стандарти за комуникация – HTTP, XML и SOAP сами описват интерфейса си за достъп чрез езика WSDL могат да бъдат търсени чрез UDDI

5. Web- услуги Web- услугите моделират услугите от реалния свят работят на принципа на обмяна на SOAP съобщения съобщенията съдържат структурирана информация – данни + метаданни (описание на данните) независими от операционната система, платформата и езика за програмиране функционално-независими , слабо-обвързани с клиента

6. WSE WSE = Web Services Enhancements = разширения на Web- услугите WS -* спецификациите са разширенията на стандартите за Web- услуги отворени стандарти дефинирани от организациите OASIS и W3C WSE е имплементация на WS-* стандартите за .NET Framework WS-Addressing – стандарт за адресация на услуги и съобщения WS-Security – осигурява сигурност при Web -услугите (автентикация, кодиране, подписване) WS-Policy – позволява задаване на изисквания при обмяната на съобщения

7. SOA SOA = Service Oriented Architecture = архитектура, базирана на услуги Подход за реализация на разпределени приложения, при който софтуерните компоненти са достъпни като услуги компонентите (услугите) комуникират чрез стандартни протоколи услугите са слабо-свързани (имат минимално количество взаимовръзки) услугите могат да бъдат използвани в контекст, неизвестен по време на дизайна

8. SOA При архитектурата, базирана на услуги услугите имат стандартизиран интерфейс за достъп услугите се използват от крайни потребители или от други услуги услугите участват в организацията и изпълнението на бизнес процесите нови услуги могат да се базират на комбинация от съществуващи Web- услугите, заедно с WSE, са много подходящи за реализация на SOA

9. Indigo Продуктът с кодово название " Indigo " e имплементация на концепциите на архитектурата, базирана на услуги ( SOA) application сървър – изпълнява и управлява приложения и услуги middleware продукт, ориентиран към управление и интеграция на услуги поддържа архитектура за разпределени приложения, базирани на съобщения използва отворени стандарти ( XML , Web services, …) Ще бъде част от Windows Longhorn

10. Агентно-ориентирани архитектури Софтуерните агенти са: автономни имат контрол над собствените си действия и вътрешните си състояния могат да работят самостоятелно без външна намеса специализирани – имат ясно зададена цел (задача) знаят какво да правят и как да го правят взаимодействат с други агенти за да изпълняват целта си имат ясно дефинирани интерфейси за комуникация

11. Агентно-ориентирани архитектури Софтуерните агенти са: разположени в специфична среда възприемат средата си чрез сензори и я променят чрез ефектори Агентно-ориентираните софтуерни архитектури се базират на агенти и взаимодействия между тях Позволяват изграждане на децентрализирани разпределени приложения

12. Мрежи от опашки Мрежите от опашки ( Queuing Networks ) описват децентрализиран модел за разпределени изчисления Имат следната структура: Състоят се от обработващи единици ( Processing Units ) с връзки между тях мрежата управлява потока на информацията (information workflow) Обработващите единици се състоят от верига примитивни обработчици ( primitive handlers) Примитивните обработчици са най-малките обработващи единици

13. Примитивни обработчици Примитивните обработчици са елементарни обработващи единици преизползваеми ( r eusable) извършват малки прости задачки върху съобщенията обработват само съобщения, които разпознават биват два вида общи – осигуряват кодиране / декодиране, маршрутизация, трансформация, log- ване специфични – реализират елементи от работния процес

14. Обработващи единици Обработващите единици са преизползваеми ( r eusable) изпълняват отделни стъпки от динамични бизнес процеси не са обвързани с местоположението си възможности за физическа мобилност скалируемост и устойчивост на сривове предоставят автономни услуги подходящи за автономно-ориентирани изчисления подходящи за агентно-ориентирани изчисления

15. Обработващи единици Обработващите единици се състоят от примитивни обработчици (примитиви) Примитивите се подреждат последователно в "поточни линии" Съобщенията се обработват чрез преминаване през поточните линии Примитивите могат да променят, създават и унищожават съобщения / net/node1 вход изход примитива примитива примитива

16. Мрежи от опашки "Мрежите" са множество свързани една с друга поточни линии Всяко съобщение пътува по някакъв път в мрежата Пътят зависи от самото съобщение – определя се динамично чрез правила за маршрутизация Пътят е поточна линия, съставена от обработващи единици (възли) Инфраструктурата прилича на фабрика: Изделието преминава през поточните линии на отделните цехове (възли)

17. Мрежи от опашки Network Gateway Transform /net/node1 Preproc. Balance /net/node2 Match /net/node3 Augment /net/node4 Match /net/node3

18. Какво е FABRIQ? FABRIQ е архитектура за разпределени приложения базирана на модела "мрежи от опашки" високопроизводителна силно скалируема Нейната цел да илюстрира асинхронния изчислителен модел, базиран на съобщения, който ще е част от продукта Indigo да помогне на разработчици и софтуерни архитекти да възприемат този модел

19. Какво е FABRIQ? Реализиран с технологиите .NET Framework и C# Web- услуги WSE ( Web Services Enhancements) Framework с отворен код добре документиран дизайн и архитектура разработен от newtelligence AG , заедно със специалисти от Microsoft не е продукт на Microsoft Тестван в реални условия

20. Съобщения Съобщенията пренасят данни за приложението Форматът зависи от самото приложение Съобщенията пренасят управляваща информация параметри за адресация настройки за сигурност и надеждност Инфраструктурата на FABRIQ обработва повечето управляваща информация хедъри : постоянна управляваща информация свойства: временна информация в паметта Приложенията обработват главно данните Изключение: кодиране / декодиране

21. Парсване на съобщенията Message <soap:Envelope xmlns:soap=&quot;...&quot;> <soap:Header> <wsu:Timestamp /> <wsa:From /> <wsa:To /> <wsa:ReplyTo /> <wsse:Confidentiality/> <wsse:Integrity /> </soap:Header> <soap:Body> <m:MyData> BE56239CE3E78AC56 717EA08B1EF9... NetworkStream TextReader XmlReader Header Collection Timestamp From To ReplyTo Confidentiality Integrity Body Properties Конструкторът на съобщението парсва хедърите в колекция от хедъри Парсването спира при достигане на тялото на съобщението. Свойството &quot; Body &quot; съдържа XmlReader на позицията на тялото.

22. Обработчици на съобщения Обработчиците на съобщения имплементират примитиви MyMessageHandler newMsg = this.HandleMessage(msg) Next.ProcessMessage(newMsg) IMessageHandler ProcessMessage(Message msg) IMessageHandler IMessageHandler ProcessMessage(Message msg) IChainableMessageHandler Next

23. Поточни линии ( pipelines) Head IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) Tail IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) MyMessageHandler IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) Pipeline IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) IMessageHandler ProcessMessage(Message msg) IMessageHandler

24. Поточни линии – композиция Head IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) Tail IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) Pipeline IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) IMessageHandler ProcessMessage(Message msg) Head IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) Tail IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) MyMessageHandler IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg) Pipeline IMessageHandler IChainableMessageHandler Next ProcessMessage(Message msg)

25. Управление на сривовете Съединяването на примитиви е добро ... ... докато нещо не се повреди някъде ... Управлението на сривове в поточните линии е тежка задача Действие 1, Преобразуване на съобщението Действие 2, Уведомяване на вътрешна услуга Действие 3, Записване в базата данни /net/node1 Начало Край Примитив Примитив Примитив

26. Решението: транзакции Всеки обработчик включва своя изпълнител (worker) в &quot;лека транзакция&quot; (WorkSet) Изпълнителят държи състоянието на съобщението и изпълнява commit() или abort() Използва се алгоритъм &quot; 2-Phase-Commit &quot; /net/node1 Начало Край Примитив Примитив Примитив WorkSet Worker Worker Worker Леки транзакции Prepare() Commit() Abort()

27. Действия и договори Действия уникално идентифицируеми състоят се от поточна линия от примитиви свързани с едно или повече входни съобщения аналогично на &quot;метод&quot; от ООП Договори съглашения за данните прецизно дефинират какви данни очаква дадено действие прецизно дефинират какви данни произвежда като резултат дадено действие

28. Възли и инстанции на възли Един &quot;възел&quot; от мрежата представлява една обработваща единица ( processing unit ) има уникална идентификация с URI свързан с логическо име на машина (host) може да съответства на няколко физически машини изпълнява се в отделен &quot; A pplication domain &quot; може да се спира / пуска независимо Възелът е еднопосочна асинхронна услуга Може да пренася съобщения и да им отговаря ( forward и reply-to ) не се поддържа отговор към източника &quot;Инстанция на възел&quot; е възел по време на работа ( runtime )

29. Адресация Всеки възел има уникален URI адрес и един или няколко URL адреса: Логически адрес : fabriq://network/node Транспортно-зависим адрес: http://machine/network/node msmq://machine/network/node Логически : използва се за абстрактно конфигуриране на мрежите Транспортно-зависим: използва се за маршрутизация по време на работа Адресирането използва WS-Addressing

30. WS-Addressing <wsa:To>uri:ServiceB</wsa:To> <wsa:Recipient> <wsa:Address> uri:Client </wsa:Address> <wsp:Policy /> </wsa:Recipient> <wsa:ReplyTo> <wsa:Address> uri:Client </wsa:Address> <wsp:Policy /> </wsa:ReplyTo> <wsa:Recipient> <wsa:Address> uri:Client </wsa:Address> <wsp:Policy /> </wsa:Recipient> <wsa:FaultTo> <wsa:Address> uri:ServiceB </wsa:Address> <wsp:Policy /> </wsa:FaultTo> To To To ReplyTo FaultTo Recipient FaultTo WS-Addressing WS-Policy ServiceA Client ServiceB Gateway Gateway ServiceC Dyn. Router

31. Адресация във FABRIQ Всеки възел може да има изходно съобщение Ако няма, той е крайна точка ( endpoint) Изходните съобщения се маршрутизират към следващия възел Използва се &quot;действието&quot; на изходното съобщение (wsa:Action) и/или логическия получател (wsa:To) Много маршрути могат да са подходящи Съобщението се изпраща към всеки от тях Маршрути и получатели Получателите са приоритетизирани Инфраструктурата опитва да изпрати съобщенията към получателите им според приоритета ( &quot; p rimary&quot; и &quot;backup&quot; ) .

32. Адресация във FABRIQ to: /net/node2 Маршрути to: /net/node3 action: actionA action: actionB to: /net/node4 http://.. msmq: //... Получатели /net/node1

33. В един FABRIQ възел /net/node1 Начало Край Примитив Примитив Pipeline Gate- keeper Router Sender Port Queue Listener Проверка на сигурността Избор на маршрут Изпращане

34. Хостинг на възлите Config Manager MSMQ Listener Enterprise Services Runtime (dllhost.exe) Process Initializer / Process Controller TCP Listener Enterprise Services Port Thread Pool Request Queue Process Listeners /net/node1 Начало Край Примитив Примитив Pipeline Gate- keeper Router Sender Port AppDomain /net/node2 Начало Край Handler Примитив Pipeline Gate- keeper Router Sender Port AppDomain

35. Модел на процесите FABRIQ се хоства в Enterprise Services Надежден модел на процесите Start/Stop, Pause/Resume Пулинг, рециклиране Стартиране при начално зареждане, стартиране като услуга Може да се настройва потребителят, под който се изпълнява процеса Интеграция с транспортните услуги от Enterprise Services Не е необходим Internet Information Server

36. Сигурността във FABRIQ Използва се инфраструктурата за сигурност на WSE 2.0 Microsoft Web Service Enhancements Използва се OASIS WS-Security, WS-Policy Ограничения на WSE 2.0 Не се поддържат динамични политики Политиките се описват във файлове Конфигурация за всеки AppDomain

37. Политики и договори <soap:Envelope> <soap:Header> … </soap:Header> <soap:Body> … </soap:Body> </soap:Envelope> Договор за услугата Договор за съобщението управлява управлява Политика – правила за услугите : - Изисквания : &quot; Ти трябва ... &quot; - Възможности : &quot; Аз мога … &quot; - Предпочитания : &quot; Предпочитам ... &quot; WS-Policy WS-PolicyAssertions WS-PolicyAttachment Договор – съдържание и функция на съобщенията : - Схеми : дефинират типовете - WSDL: дефинира действията W3C XML Schema WSDL 1.1 / 1.2 Край ( endpoint) XML схема WSDL политика

38. WS-Security Trusted Trusted Transitive Trust WS-Trust WS-Trust WS-Trust WS-Federation WS-Trust Trusted WS-Trust WS-Trust WS-Trust Identity Provider Secure Token Service IP/STS IP/STS IP/STS WS-SecureConversation Message WS-Security WS-SecureConversation Message WS-Security Resource Requestor Resource

39. Сигурността във FABRIQ AppDomain Config Output Policy Input Policy /net/node1 Начало Край Примитив Примитив Pipeline Gate- keeper Router Sender Port AppDomain Понякога WSE не се ползва за по-добра производителност Destination has Policy? Yes Send Message No Build Message Output Policy WSE Pipeline Input Policy WSE Pipeline Message has Security elements? Node has defined Policy? Yes Pipeline No OR

40. Мрежите на FABRIQ Възлите се свързват с логически или физически имена на машини Адресацията се базира на тези имена Конфигурирането на FABRIQ клъстер става със специално съобщение Конфигурирането е функция на самата мрежа Всяка машина хоства няколко възела от мрежата, описани в конфигурацията Кодът може да се зарежда динамично

41. Архитектурни перспективи Архитектурно FABRIQ много прилича на &quot;Indigo&quot; : подобен модел на съобщенията подобен модел на поточните линии ( pipelines) адресиране, базирано на WS-Addressing сигурност, базирана на WS-Policy Архитектурна стратегия : синхронизиране с новостите и промените от &quot; Indigo Beta &quot; (когато излезе) заместване на FABRIQ инфраструктурата с Indigo миграция на FABRIQ приложенията към Indigo

42. Ресурси за FABRIQ Страницата на проекта в GotDotNet: http://workspaces.gotdotnet.com/fabriq Личният дневник (blog) на Clemens Vasters: http://staff.newtelligence.net/clemensv Личният дневник (blog) на Arvindra Sehmi: http://www.thearchitectexchange.com/asehmi

43. FABRIQ Въпроси?