Лекция №6
Архитектура подсистемы обеспечения юридической значимости электронного документооборота (ПОЮЗД), взаимодействие с прикладными системами, сервисы ПОЮЗД
Часть 6.1.
Типовая сервис-ориентированная архитектура ИС.
Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture)
— модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
Программные комплексы, разработанные в соответствии с сервисориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например,
на базе jini, CORBA, на основе REST).
Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют
(Инкапсуля́ция (лат. in capsula) — размещение в оболочке, изоляция, закрытие чего-либо инородного с целью исключения влияния на окружающее. В информатике, программировании — обеспечение доступности главного, выделение основного содержания путём помещения всего мешающего, второстепенного в некую условную капсулу (чёрный ящик). Инкапсуляция (англ. encapsulation) — это фундаментальная объектно-ориентированная концепция, позволяющая упаковывать данные и поведение в единый компонент с разделением его на обособленные части — интерфейс и реализацию. Последнее осуществляется благодаря принципу изоляции решений разработки в ПО, известному как сокрытие информации (англ. information hiding). Инкапсуляция, наследование и полиморфизм (в форме ad hoc полиморфизма или полиморфизма подтипов) являются тремя столпами объектно-ориентированного программирования, реализуя в нём принцип абстракции данных (не путать с абстрактными типами данных, реализации которых предоставляют возможность инкапсуляции, но имеют иную природу) детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых
платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем.
Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать дополнительно механизм файловой системы для обмена данными.
Главное, что отличает SOA — это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу.
Элементы сервис-ориентированной архитектуры, по: Dirk Krafzig, Karl Banke, and Dirk Slama. Enterprise SOA. Prentice Hall, 2005
SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса.
Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т.д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на
платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.
SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов.
Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.
Использование компонентной архитектуры (SCA) для реализации SOA — это область текущих исследований.
Интеграция разнородных и распределенных данных не в состоянии разрешить все вопросы управления предприятием. В соответствии с процессным подходом наибольшую ценность представляют не сами по себе данные, а использование информации в тех или иных бизнес-процессах компании. В самых современных ИС принято рассматривать как "атомарную" единицу не данные в "чистом" виде, а некоторый сервис, соответствующий какому-то элементарному бизнеспроцессу. В частности, такой сервис может просто выдавать какие-то данные, являясь аналогом "атомарной" единицы классических ИС.
В настоящее время при формировании информационной инфраструктуры предприятия, при проектировании и реализации КИС все чаще применяется сервис-
ориентированная архитектура (Service-Oriented Architecture - SOA). Это такая
архитектура ИС, в которой система строится из набора гетерогенных слабосвязанных компонентов (сервисов). SOA понимается как парадигма организации и использования распределенного множества функций, которые могут контролироваться различными владельцами. Базовыми понятиями в такой архитектуре являются "информационная услуга" и "композитное приложение".
Информационная услуга (сервис) - это атомарная прикладная функция автоматизированной системы, которая пригодна для использования при разработке приложений, реализующих прикладную логику автоматизируемых процессов как в самой системе, так и для использования в приложениях других автоматизированных систем.
Сервис обычно характеризуется следующими свойствами:
возможность многократного применения;
услуга может быть определена одним или несколькими технологически независимыми интерфейсами;
выделенные услуги слабо связаны между собой, и каждая из них может быть вызвана посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия услуг между собой.
Композитное (составное) приложение - программное решение для конкретной прикладной проблемы, которое связывает прикладную логику процесса с источниками данных и информационных услуг, хранящихся на гетерогенном множестве базовых информационных систем. Обычно композитные приложения ассоциированы с процессами деятельности и могут объединять различные этапы процессов, представляя их пользователю через единый интерфейс.
Использование такого подхода при построении архитектуры сложных интегрированных информационных систем позволяет:
создать систему корпоративных композитных приложений, основанных на системе корпоративных Web-сервисов;
организовать интеграцию приложений, бизнес-процессов, с автоматизацией бизнес-процессов, включая Human Workflow;
использовать различные транспортные протоколы и стандарты форматирования сообщений, средства обеспечения безопасности, надежной и своевременной доставки сообщений;
существенно повысить скорость разработки прикладных приложений и снизить затраты на эти цели.
Благодаря упрощению среды управления и взаимодействия снижается потребность
вкодировании новых программ; повторное использование сервисов сокращает затраты времени на разработку; рационализация унаследованных процессов помогает уменьшить общее число процессов, требующих эксклюзивных методов управления; благодаря использованию простых протоколов значительно сокращаются трудозатраты на поддержку приложений.
Обязательным условием построения и внедрения архитектуры системы на основе SOA является использование единой инфраструктуры описания сервисов (репозитория сервисов), разрешенных протоколов доступа и обмена сообщениями, форматов сообщений.
Упомянутая инфраструктура образует так называемую интеграционную шину
(ИШ) (Enterprise Service Bus - ESB), являющуюся одним из центральных компонентов системы. Она устанавливает единые правила публикации сервисов, управления и
информационного взаимодействия между приложениями различных систем, входящих в состав интегрированной системы. Это упрощает управление приложениями и их поддержку, а также снижает риск фрагментации приложений и процессов.
Каждая из служб взаимодействует не с остальными службами напрямую, а только с шиной. ИШ образует однородную среду информационного взаимодействия и является фундаментом для интеграции информационных систем, функционирующих в различных учреждениях и ведомствах. ИШ определяет, кем, где, каким образом и в каком порядке должны обрабатываться запросы.
Если сервис (информационный ресурс) не поддерживает эти правила, необходимо создавать промежуточный модуль-адаптер, который предоставляет системе необходимый интерфейс и обеспечивает взаимодействие с ресурсом.
По данным Gartner Group ("Predicts 2007: SOA Advances", 17 ноября 2006 года): "К 2008 году SOA станет господствующей архитектурой построения ИТ-систем, что приведет к окончанию 40-летней эры господства архитектуры монолитных приложений".
Рис. 7.2. Структура построения ESB и компоненты концепции SOA
Изменение и совершенствование бизнес-процессов в компаниях занимает годы. По данным Gartner Group, 80% ИТ-бюджета – это расходы на сопровождение систем, из них 35% - затраты на интеграцию приложений, 60% стоимости внедрения корпоративной ИС составляют расходы на интеграцию, 50% ИТ-бюджета потрачено на обеспечение интерфейсов систем. Использование SOA-архитектуры позволяет эффективно организовать оперативную адаптацию ИТ-систем под требования бизнеса, что дает стратегическое преимущество компании, заключающееся в:
повышении скорости адаптации бизнеса к быстро меняющимся требованиям рынка (Agility);
расширении взаимодействия гетерогенных корпоративных информационных систем при сохранении сделанных в них инвестиций;
сокращении расходов на ИТ-системы на основе повторного использования их функциональных компонентов;
повышении производительности труда клиентов, партнеров и сотрудников (на основе архитектуры Web 2.0).
С точки зрения бизнеса SOA можно представить как набор гибких служб и процессов, которые бизнес предлагает своим заказчикам, партнерам или внутри своей собственной организации. В данном контексте эти же службы можно по-разному комбинировать и оснащать, поддерживая изменения или развитие бизнес-требований и моделей с течением времени.
Основные бизнес-цели внедрения SOA-решений состоят в ликвидации:
фрагментированности и дублирования данных;
дублирования реализаций бизнес-функций, процедур, процессов;
негибкой архитектуры.
Становление и развитие SOA происходило на базе практических требований бизнеса, заключавшихся прежде всего в разумной экономии программных и технологических средств и затрат на реализацию и сопровождение информационной инфраструктуры:
обеспечивать преемственность инвестиций в IT, сохранение существующих информационных систем и их совместное эффективное использование для повышения ROI от IT-вложений;
обеспечивать реализацию различных типов интеграции:
oпользовательская интеграция (User Integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;
oинтеграция приложений (Application Connectivity) - обеспечение взаимодействия приложений;
oинтеграция процессов (Process Integration) - интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;
oинформационная интеграция (Information Integration) - интеграция с целью обеспечения доступности информации и данных;
oинтеграция новых приложений (Build to Integrate) - интеграция новых приложений и сервисов в существующие информационные системы.
обеспечивать поэтапность внедрения вновь созданных и миграции
существующих информационных систем;
иметь стандартизованную технологическую обеспеченность реализации и инструментарий разработки, совокупно предоставляющие наилучшие возможности повторного использования приложений, внедрения новых и миграции существующих информационных систем;
позволять реализацию различных моделей построения информационных систем, в особенности, таких как портальные решения, grid-системы и on-demand- системы.
Сегодняшний уровень развития SOA позволяет утверждать, что все указанные требования в той или иной мере выполняются.
Архитектура, управляемая моделями (MDA - Model-driven architecture)
MDA– это другая концепция создания ИС. Предложена консорциумом OMG (Object Management Group), является обобщением идей SOA и повторно используемых программных компонент (шаблонов, паттернов).
MDA по определению является открытой и "нейтральной" по отношению к используемым технологиям интеграции. Она основана на четырех принципах:
основой для разработки приложений масштаба предприятия являются детальные модели с общепринятой нотацией;
для построения систем используется рамочная система моделей, позволяющая отделить бизнес-логику приложений от конкретной реализации. Исходной является так называемая независимая модель вычислений (Computational Independent Model), которая использует платформо-независимые (PIM) и специфичные модели (PSM). Она позволяет почти автоматически генерировать исполняемый код и соответствующие структуры данных;
существуют формальные модели для распределенных вычислений, транзакций, операции в реальном времени и т.п.;
основан на использовании открытых промышленных стандартов и поддержке производителей средств разработки.
Сервис - ориентированная архитектура (soa) и архитектура, управляемая моделями
(mda)
SOA представляет собой модель взаимодействия, которая связывает различные функциональные модули приложений (сервисы) между собой с помощью четко определяемых интерфейсов. Интерфейсы не зависят от используемых аппаратных платформ, операционных систем и языков программирования. Это позволяет отдельным сервисам взаимодействовать между собой одним и тем же стандартным и универсальным
способом (модель "слабой связи"). Преимущество - повышенная гибкость и адаптируемость.
Комбинация процессно-ориентированной модели предприятия с концепцией сервис-ориентированной архитектуры информационных технологий позволяет лучше увязать процесс разработки компонент информационных систем с миссией, основными задачами и функциями организаций (бизнес-процессы как готовые сервисы).
С помощью SOA организации имеют потенциальную возможность разрабатывать набор реализаций различных бизнес-процессов, которые могут быть многократно использованы предприятием как готовые сервисы.
Принципы SOA:
явное отделение бизнес-логики прикладной системы от логики презентации
информации;
реализация бизнес-логики прикладной системы в виде некоторого количества программных модулей (сервисов), которые доступны извне (пользователям и другим модулям), чаще всего в режиме "запрос-ответ", через четко определенные формальные интерфейсы доступа;
при этом "потребитель услуги", который может быть прикладной системой или другим сервисом, имеет возможность вызвать сервис через интерфейсы, используя соответствующие коммуникационные механизмы.
Понятие сервиса Сервис - это программный компонент, реализующий законченную функцию
предоставления или обработки данных. Основным отличием сервиса от обычного компонента является стандартный и платформенно-независимый интерфейс. Клиент, обращающийся к сервису, не обязан ничего знать о подробностях реализации сервиса: на каком языке и в какой модели программирования он создан, на каких аппаратных средствах, в какой операционной среде, на какой платформе промежуточного программного обеспечения он выполняется. Сервисно-ориентированная архитектура позволяет компоновать бизнес-процессы из компонентов, выполняющихся на разных платформах (например, Microsoft .NET и Java 2 Enterprise Edition (J2EE)), представлять их
ввиде сервисов и повторно использовать в новых бизнес-процессах.
Современные подходы к SOA охватывают не только технологический уровень обмена данными, но и уровень бизнес - операций. Для описания бизнес-процессов и их взаимодействия разработан для языка BPEL (Business Process Execution Language for Web Services), который расширяет модель взаимодействия веб-служб и включает в неё поддержку транзакций. Для задач электронного бизнеса соответствующая
функциональность SOA реализуется на уровне web-сервисов (служб). В общем случае принципы SOA создания информационных систем не обязательно предполагают использование технологий web-сервисов (можно и на других платформах). Использование web-сервисов как технологических спецификаций позволяет перейти к "расширенному предприятию" и бизнесу "реального времени" объединяющему предприятие, поставщиков, партнеров, клиентов в единую систему. Web-сервисы. Под web-сервисами понимаются программные системы, которые используют XML в качестве формата данных, стандарты Web Services Description Language (WSDL), Universal Description, Discovery and Integration (UDDI) и Simple Object Access Protocol (SOAP). WSDL -
определяет месторасположение сервиса и отображаемые им операции (или методы), позволяющие обращаться к этому сервису.
SOAP - это простой основанный на XML протокол для описания формата принимаемых и посылаемых сообщений. Он позволяет приложениям обмениваться информацией по транспортным протоколам, таким как HTTP. Стандарт UDDI - для создания каталогов доступных сервисов. Ссылочная модель сервис – ориентированной архитектуры предприятия. Она использует единый подход для описания бизнеса и ИТ и состоит из следующих компонент:
презентационный уровень описывает интерфейсы для взаимодействия пользователей с информационной системой (корпоративные и публичные порталы, доступ с мобильных устройств, преобразования информации при взаимодействии с внешними системами и устройствами);
на уровне бизнес-сервисов формируются модели и осуществляется управление выполнением бизнес-процессов (с использованием BPEL), а также координация автоматизированных и "ручных" операций;
интеграционные сервисы обеспечивают взаимодействие между приложениями, которое может быть реализовано с помощью средств обмена сообщениями или в рамках единой среды исполнения, такой как сервер приложений J2EE;
сервисы уровня данных обеспечивают извлечение и повторное использование данных из СУБД и приложений. Этот уровень позволяет изолировать вышестоящие компоненты архитектуры от изменений в технологиях (например, версии продукта), и обеспечить единый унифицированный подход к выполнению операций с данными;
уровень инфраструктуры, приложений и СУБД является основой для всей структуры (основные инвестиции в ИТ).
Комплексная ссылочная модель SOA предприятия
Сервис-ориентированная платформа должна соответствовать следующим требованиям:
обеспечивать спецификации интерфейса, которые были бы приняты, если не всеми, то большинством разработчиков компонентов;
использовать общепринятые протоколы для взаимодействия сервисов и
клиентов;
не использовать в интерфейсе какие-либо сложные и/или закрытые форматы представления информации;
не требовать для своей поддержки дорогостоящего или ресурсоемкого программного обеспечения.
Базовая архитектура SOA:
1.Провайдер сервисов - предоставляет сервисы, контракт по активизации которых и месторасположение опубликованы (WSDL-документ).
2.Потребитель сервисов - потребляет нужные, обнаруженные в каталоге
сервисы.
3.Каталог сервисов (необязательно) - служит для публикации и ведения списка сервисов, доступных для потребителей (извлекается посредством UDDI).
Состав необходимых сервисов для работы с усиленной квалифицированной ЭП: Сервис создания ЭП;
Сервис создания электронной подписи предназначен для централизованного: 1. Создания и хранения ключей электронной подписи Пользователей
Удостоверяющего центра.