Технологии InterSystems для разработки композитных приложений. Готовность к SOA . Олег Оленин

1. Технологии InterSystems для разработки композитных приложений. Готовность к SOA. Олег Оленин oleg.olenin@intersystems.ru

2. ... или как из трех букв сложить слово «счастье»

3. Задачи • Определить, что такое SOA • Показать, как продукты Intersystems могут быть использованы для построения сервис ориентированных решений • Определить, решения какого класса можно реализовывать с помощью линейки продуктов Intersystems • Определить к каким категориям модных продуктов можно отнести продукты Intersystems

4. План • Что такое SOA? • Сервисы и InterSystems Cache • ESB и InterSystems Ensemble • Исполняемые процессы и их реализация в Ensemble • Композитные приложения • Connected IT инфраструктура

5. Что такое SOA? • Обещания бизнесу полного счастья? • Навязчивое слово? • Подход к проектированию и реализации систем? • Новая инфраструктура и специализированные классы систем? • Типы проектов, которые принято ассоциировать с SOA? • Опыт о том, как не надо делать? • Новый способ управления IT подразделениями? • В SOA главное совсем и не продукт?

6. Определения SOA • Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains OASIS Reference Model for Service Oriented Architecture 1.0 • SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. http://www.xml.com/pub/a/ws/2003/09/30/soa.html

7. Прагматичный подход к определению • SOA - любой набор лучших практик для построения распределенных систем, которые взаимодействуют между собой • Фундаментальная основа SOA • Использование формально описанных взаимодействий между системами • Переход к открытым стандартам • XML, HTTP, SOAP, XSD, WSDL • Взаимодействие зависит от внешних интерфейсов и не зависит от внутренней реализации

8. Немного о стандартах Хаос стандартов

9. Distributed & Loosly Coupled • Сервис ничего не знает о его потребителях • Для потребителя вся информация о том, как взаимодействовать с сервисом содержится в контракте (WSDL). Но не все. • Потребители ничего не знают о других потребителях • Потребители и сервисы могут работать на разных платформах • Все необходимое для выполнения бизнес операции сервисом содержится в сообщении и в ответе на него • Обмен документами • Семантика документов ясна всем сторонам

10. Типовой сценарий • В ходе автоматизации бизнес процесса декомпозировали функциональность системы на операции. • Операции определили в WSDL описании интерфейсов • Структуру сообщений в XSD • Создали сервис. Проверили, что он соответствует WS-I • Обеспечили его доступность. Опубликовали его описание в реестре • Нашли сервис в реестре, сделали клиента • При обращении клиента к сервису определяем местонахождение через реестр

11. Сервисы и Cache 2008.2 • Подход bottom-up. SOAP Client Wizard. • Подход top-down. Возможность кастомизировать сгенеренный WSDL. • Поддерживаются SOAP 1.1 , 1.2, WSDL 1.1., HTTP 1.1 • Реализована работа с UDDI version 1.0 • Поддержка .Net DataSet

12. WS-* и не только. Различные сценарии взаимодействия. • Безопасность • SSL (HTTPS)‏ • WS-Security. HTTP Auth. • Асинхронное взаимодействие, корреляция. • WS-Addressing. • Производительность • Транспорты, отличные от HTTP • Caché binary SOAP format. • Передача бинарных данных • MTOM 1.0, SOAP With Attachments • Службы с состояниями. Session support. • Проверка на совместимость. WS-Inspection.

13. SOA Maturity Model, Level I

14. Определяются операции

15. Стандартизируются службы

16. Используются WS-*

17. Просто сервисы: нерешенные вопросы Проблема сокращения количества связей не решена: • Каждый из провайдеров сервисов сам обеспечивает инфраструктуру его функционирования • Управление затруднено • Нет общего реестра сервисов

18. Предлагаемое решение - ESB

19. Enterprise Service Bus Сейчас на рынке более 50 продуктов, называемых ESB. Главное знать, что они должны делать в рамках реализации архитектурного подхода: • Сервисы не зависят от технологии доступа к ним. Слабая связность в плане протоколов доступа • Mediation. Маршрутизация, трансформация сообщений • Канонический формат. Enrichment. • Общая инфраструктура - безопасность, логгирование, управление, non-blocking вызовы, масштабирование • В концептуальном плане предполагается работа без состояний

20. Типичные возможности ESB • Invocation. Synchronous and asynchronous transport protocols, service mapping • Routing Addressability. Static/deterministic routing, content-based routing, rules-based routing, policy-based routing • Mediation Adapters • Messaging processing, transformation and enhancement • Complex Event Processing • Quality of Service. Security, reliable delivery, transaction management • Management. Monitoring, audit, logging, metering, admin console, BAM

21. Реализация ESB в Ensemble Нет продукта InterSystems ESB. Есть лучше - EnSemBle: • Интеграция • Что можем слушать: EDI, POP3, File, FTP,HL7, HTTP, IWay, MQ Series,MSMQ, Pipe, SOAP, SQL, TCP, Java, JMS • Куда можем говорить: EDI, SMTP, File, FTP, HL7, HTTP, IWay, LDAP,MQSeries,MSMQ,Pipe,SAP,Siebel,SOAP,SQL,TCP,Telnet,TN3270, Java,JMS • Маршрутизация сообщений. EnsLib.MsgRouter.RoutingEngine, BPL. • Трансформация. Data Transformation Language, XSLT • Канонизация. Трансформация сообщения в объект класса. • Business Alarm Monitoring • Ensemble Management Portal

22. Реализация ESB в Ensemble

23. SOA Maturity Model, Level II • С высокоуровневой точки зрения в ESB происходит работа без состояний • Как реализовывать “долгие процессы”? • Как делать более “крупные” сервисы? • Как реализовывать сценарии взаимодействия с участием пользователей?

24. SOA Maturity Model, Level III

25. Исполняемые процессы • Слово одно, характеристики разные: • Workflow-процессы • Оркестровка веб служб • Интеграционные процессы • Сервера бизнес процессов, два типа: • BPEL4WS • XPDL

26. Бизнес процессы и Ensemble • Разработчику проще работать с BPL, чем с BPEL • XML используется там, где надо • Более удобные активности, сокращающие код • <branch/> и <label/> • Проще изменять и тестировать • Всегда есть возможность унаследовать Ens.BusinessProcess и сделать свой собственный процесс: • Это важно • Не нужно начинать с 0. Используем инфраструктуру Ensemble и работаем в привычном окружении

27. BPMS. Развитие темы. • BPM – методология управления бизнеса, основанная на измерении его в процессах • BPMS решения - исполняемый BPM • Исполняемые процессы • Измеряемые критерии • Оптимизация на базе собранных показателей • Замкнутый цикл • Технологическая платформа для моделирования, автоматизации, мониторинга, управления и оптимизации процессов • BPM + SOA = BPMS

28. Типовой состав BPMS • Инструменты BPM • Аналитическая модель • Исполняемая модель • Human activities. Roles, Tasks, UI, Deadlines • Automated steps. Component, Process data, Events, Exceptions • Движок процессов • Business Rules • Application Integration • Performance Management • Human interaction

29. BPM + Ensemble = BPMS

30. SOA Maturity Model, Level IV

31. Современная IT инфраструктура предприятия. Connected Enterprise

32. Современная IT инфраструктура предприятия на основе Ensemble Достоинства каждого из подходов объединены в Ensemble: • BPM • Прозрачность логики исполнения процесса • Объединение пользователей и приложений • Мониторинг исполнения процессов • SOA • Разделение ответственности • Слабая связность компонентов взаимодействия • Повторное использование компонентов • EAI • Связность с приложениями • Готовые средства для разработки

33. Почему Ensemble?

34. Cпасибо! Вопросы? Пишите письма: oleg.olenin@intersystems.com http://writeimagejournal.com/