Часть 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-вложений;

• обеспечивать реализацию различных типов интеграции:

  • пользовательская интеграция (User Integration) - обеспечение взаимодействия информационной системы с конкретным персонифицированным пользователем;

  • интеграция приложений (Application Connectivity) - обеспечение взаимодействия приложений;

  • интеграция процессов (Process Integration) - интеграция процессов в соответствии с бизнес-логикой деятельности предприятия;

  • информационная интеграция (Information Integration) - интеграция с целью обеспечения доступности информации и данных;

  • интеграция новых приложений (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. Создания и хранения ключей электронной подписи Пользователей Удостоверяющего центра.

2. Создания и проверки электронной подписи электронных документов различного формата криптографических сообщений.

3. Взаимодействия Операторов и Пользователей с Удостоверяющим центром для получения и управления сертификатами ключей проверки электронной подписи.

Сервис проверки и усиления ЭП;

Усиленная неквалифицированная и усиленная квалифицированная электронные подписи получаются в результате криптографического преобразования информации с использованием ключа электронной подписи,

позволяют определить лицо, подписавшее электронный документ,

позволяют обнаружить факт внесения изменений в электронный документ после момента его подписания,

создаются с использованием средств электронной подписи.

Квалифицированная электронная подпись наравне с вышеуказанными признаками должна соответствовать следующим дополнительным признакам:

1. ключ проверки электронной подписи указан в квалифицированном сертификате;

2. для создания и проверки электронной подписи используются средства электронной подписи, получившие подтверждение соответствия требованиям, установленным в соответствии с Законом об электронной подписи.

При этом основное отличие квалифицированного сертификата ключа проверки электронной подписи заключается в том, что он должен быть выдан аккредитованным удостоверяющим центром или доверенным лицом аккредитованного удостоверяющего центра.

Сервис сбора CRL или OCSP-сервис;

Для технологии открытых ключей необходимо, чтобы пользователь открытого ключа был уверен, что этот ключ принадлежит именно тому удалённому субъекту (пользователю или системе), который будет использовать средства шифрования или цифровой подписи. Такую уверенность дают сертификаты открытых ключей, то есть структуры данных, которые связывают значения открытых ключей с субъектами. Эта связь достигается цифровой подписью доверенного CA (В криптографии центр сертификации или удостоверяющий центр (англ. Certification authority, CA) — сторона (отдел, организация), чья честность неоспорима, а открытый ключ широко известен. Задача центра сертификации — подтверждать подлинность ключей шифрования с помощью сертификатов электронной подписи.

Технически центр сертификации реализован как компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов) под каждым сертификатом. Сертификат имеет ограниченный срок действия, указанный в его подписанном содержании. Поскольку пользователь сертификата может самостоятельно проверить его подпись и срок действия, сертификаты могут распространяться через незащищённые каналы связи и серверные системы, а также храниться в кэш-памяти незащищённых пользовательских систем. Содержание сертификата должно быть одинаковым в пределах всего PKI (Инфраструктура открытых ключей (ИОК, англ. PKI - Public Key Infrastructure) — набор средств (технических, материальных, людских и т. д.), распределённых служб и компонентов, в совокупности используемых для поддержки криптозадач на основе закрытого и открытого ключей. В основе PKI лежит использование криптографической системы с открытым ключом и несколько основных принципов:

1. закрытый ключ (private key) известен только его владельцу;

2. удостоверяющий центр создает электронный документ — сертификат открытого ключа, таким образом удостоверяя факт того, что закрытый (секретный) ключ известен эксклюзивно владельцу этого сертификата, открытый ключ (public key) свободно передается в сертификате;

3. никто не доверяет друг другу, но все доверяют удостоверяющему центру;

4. удостоверяющий центр подтверждает или опровергает принадлежность открытого ключа заданному лицу, которое владеет соответствующим закрытым ключом).

CRL представляет собой список отозванных сертификатов с указанием времени. Он подписывается CA и свободно распространяется через общедоступный репозиторий. В списке CRL каждый отозванный сертификат опознается по своему серийному номеру. Когда у какой-то системы возникает необходимость в использовании сертификата (например, для проверки цифровой подписи удаленного пользователя), эта система не только проверяет подпись сертификата и срок его действия, но и просматривает последний из доступных списков CRL, проверяя, не отозван ли этот сертификат.

Полное наименование изделия: Программно-аппаратный комплекс "Службы УЦ. КриптоПро OCSP".

Сокращенное наименование изделия: ПАК "КриптоПро OCSP".