Содержание к диссертации
Введение
ГЛАВА 1 Задачи и проблемы организации взаимодействия информационных систем 12
1.1 Интеграция информационных систем 12
1.1.1 Основная задача и предпосылки интеграции 13
1.1.2 Сервис-ориентированный подход и слабое связывание 15
1.1.3 Эталонная модель сервис-ориентированной архитектуры 18
1.1.4 Композиция веб-сервисов, оркестровка и хореография 20
1.2 Анализ проблем организации взаимодействия веб-сервисов 22
1.2.1 Проблема поиска и распознавания подобных веб-сервиса 23
1.2.2 Языки и архитектурные стили описания веб-сервисов 25
1.2.3 Спецификации и протоколы организации взаимодействия 28
1.2.4 Проблема надежности взаимодействия веб-сервисов 30
1.3 Постановка задачи 34
1.4 Выводы 36
ГЛАВА 2 Разработка концептуальной модели интеграции веб-сервисов 37
2.1 Термины и определения качества веб-сервисов 37
2.1.1 Характеристики качества веб-сервисов 37
2.1.2 Комплексные показатели качества веб-сервисов 40
2.1.3 Показатели качества обслуживания веб-сервисов 42
2.2 Концепция функционального резерва веб-сервисов 45
2.2.1 Понятие универсума веб-сервисов 47
2.2.2 Расширение функционального описания веб-сервисов 48
2.3 Концептуальная модель программной инфраструктуры 51
2.3.1 Компоненты программной инфраструктуры 52
2.3.2 Компоненты интеграционного программного обеспечения 54
2.3.3 Порядок взаимодействия компонентов 54
2.4 Выводы 61
ГЛАВА З Разработка адаптивной стратегии отказоустойчивости 62
3.1 Мотивация разработки стратегии отказоустойчивости 62
3.1.1 Исследование показателей надежности веб-сервисов 64
3.1.2 Анализ проблем прогнозирования показателей 68
3.1.3 Наличие функционально подобных веб-сервисов 71
3.2 Вычисление показателей стратегии отказоустойчивости 73
3.3 Параметрическая модель стратегии отказоустойчивости 80
3.3.1 Требования и ограничения пользователя 80
3.3.2 Интегральный показатель эффективности стратегии 82
3.4 Метод дискретного представления показателей 84
3.5 Адаптивный алгоритм стратегии отказоустойчивости 86
3.6 Экспериментальная оценка стратегий отказоустойчивости 89
3.7 Выводы 94
ГЛАВА 4 Реализация программной инфраструктуры интеграции веб-сервисов 95
4.1 Архитектура разработанных программных компонентов 95
4.1.1 Концепция расслоения программных систем 95
4.1.2 Модели и схемы расслоения программных системы 98
4.1.3 Архитектурные слои программной реализации 100
4.2 Реализация компонентов анализа данных QoWS 106
4.2.1 Компонент агрегирования распределенных данных QoWS 107
4.2.2 Экспериментальная реализация функции агрегирования 110
4.2.3 Компонент прогнозирования показателей QoWS 115
4.3 Выводы 116
Заключение 118
Список сокращений и условных обозначений 120
Библиографический список 121
- Композиция веб-сервисов, оркестровка и хореография
- Показатели качества обслуживания веб-сервисов
- Анализ проблем прогнозирования показателей
- Модели и схемы расслоения программных системы
Композиция веб-сервисов, оркестровка и хореография
Информационные технологии являются важной составляющей процесса интеграции информационных ресурсов человеческого общества. К настоящему времени информационные технологии прошли несколько этапов эволюции, смена которых сопровождалась появлением новых технических, технологических и программных средств поиска и обработки данных, что в свою очередь привело к развитию информационно-вычислительных систем различного назначения.
В общем случае информационную систему можно определить как взаимосвязанную совокупность концепций, методов, технологий, технических и программных средств, используемых для сбора, обработки, хранения и выдачи информации потребителю в интересах достижения поставленной цели. Современная информационная система предполагает использование компьютера в качестве основного технического средства обработки информации. Компьютеры, оснащенные программными средствами, являются инструментом обработки и интерфейсом доступа к функциональным возможностям информационных систем. Разработка любой информационной системы начинается определения ее миссии, задач, архитектуры, инфраструктуры, конфигурации, средств телекоммуникаций и круга пользователей, взаимодействующих зачастую с несколькими информационными системами посредством компьютера.
Организация среды взаимодействия является важнейшим фактором успешного развития информационных систем и с развитием среды Интернет стала немыслима в отрыве от интернет-технологий, в частности - технологии веб-сервисов, основу которой составляет сервис-ориентированный подход к организации взаимодействия и сервис-ориентированная архитектура.
Информационно-вычислительная инфраструктура современного предприятия насчитывает сотни программных приложений, реализующих бизнес-процессы, протекающие как внутри отдельной компании, так и связывающие отдельные цепочки бизнес-процессов различных компаний или их филиалов в единый сквозной бизнес-процесс. Все эти приложения разработаны разное время разными поколениями программистов внутреннего отдела информатизации предприятия, либо приобретены у стороннего поставщика. Естественно, что архитектура, язык программирования и программная среда выполнения каждого из приложений различны, о существенно затрудняет интеграцию программных приложений информационных систем предприятий единую информационно-вычислительную среду.
Термин интеграция может иметь достаточно широкое определение и означать объединение компьютерных систем, компаний и людей [23], [85]. В общем случае можно сказать, что интеграция подразумевает обеспечение взаимодействия между множеством программ программных систем, выполняющихся од управлением различных программно-аппаратных платформ, расположенных в территориально удаленных местах. Со временем предприятия развиваются, расширяется спектр их услуг, увеличивается число партнеров, что влечет появление новых целей и задач, и, как следствие, разработку, либо закупку необходимых программных приложений. Основная задача интеграции состоит в налаживании функциональных связей [42] между приложениями различных информационных систем.
Предпосылкой интеграции может явиться необходимость создания корпоративных информационных порталов, репликации данных, реализации распределенных бизнес-процессов бизнес-функций совместного использования в масштабах виртуального предприятия [47], [79], [80]. В полупроводниковой индустрии примером может служить разработка и поставка виртуальных электронных компонентов (Semiconductor Intellectual Property Core, SIP-компонент) в виде кода на языках описания аппаратных средств Verilog или VHDL, либо готовой топологии в формате GDSII [84]. Разработка SIP-компонентов, номенклатура и сложность которых постоянно увеличиваются, ведется множеством крупных и малых фирм. В настоящее время доступ к библиотекам SIP-компонентов предоставляют такие ведущие поставщики CAD/CAM/CAE-систем, как AutoCAD, SolidWorks, Synopsys, Mentor Graphics, Cadence, и разработчики SIP-компонентов "на продажу", такие как ARM, Dolphin, Verisilicon и другие. На рисунке 1 представлена типовая структура процессора мобильных приложений с различными типами используемых в нем SIP-компонентов, которые могут быть поставлены несколькими компаниями-разработчиками [16].
Показатели качества обслуживания веб-сервисов
Наиболее популярным подходом области интеграции является создание слабосвязанных систем. Термин слабое связывание, как и его преимущества по отношению к созданию сильно связанных систем, известен уже давно. Основным принципом слабого связывания является минимизация числа допущений, которые делают разработчики компонентов и приложений взаимодействующих сторон. Безусловно, наличие детальной информации о протоколах форматах данных позволяет повысить эффективность взаимодействия, но получаемое при этом сильно связанное интеграционное решение крайне чувствительно к изменениям.
С появлением сервис-ориентированной архитектуры (англ. Service-Oriented Architecture, SOA), технологии веб-сервисов и стремительным развитием Интернет перспектива создания глобально-распределенных слабосвязанных систем превратилась в реальность [60], [85]. В основе данной архитектуры лежат принципы многократного использования программных компонентов, позволяющие исключить дублирование функциональности программного обеспечения.
С точки зрения разработки и интеграции информационных систем сервис-ориентированная архитектура является парадигмой организации и использования бизнес-процессов и ресурсов, принадлежащих различным областям производственной и экономической деятельности. Она позволяет структурировать развертывание и организацию информационной технологии в рамках конкретного предприятия или консорциума предприятий, которым необходимо взаимодействовать друг с другом. Тем не менее, основные концепции сервис-ориентированного подхода, как правило, реализуются для предоставления электронных слуг посредством веб-сервисов, которые взаимодействуют друг с другом через Интернет, в отличие от бизнес-услуг, которые могут быть выполнены вручную. В связи с этим, SOA также можно рассматривать как принцип дл разработки архитектуры программного обеспечения, торый строится вокруг понятия веб-сервиса самодостаточного, автономного, повторно используемого программного компонента с инкапсулированной функциональностью, доступного через Интернет. Программные системы, разработанные в соответствии с SOA, реализуются как набор веб-сервисов, интегрированных при помощи стандартных протоколов (UDDI, SOAP, WSDL) [72], [89], [90], [91] (рисунок 2).
Организованные на основе SOA слабосвязанные распределенные системы состоят из в заимодействующих агентов поставщиков и потребителей сервисов, выполняющих определенные задачи [41]. Агенты распределенной системы не работают в одной и той же среде выполнения и связываются друг с другом с помощью протоколов че рез сеть. В распределенных системах скорость выполнения задач зависит от скорости удаленного доступа к агентам, а надежность – от ошибок коммуникации между агентами.
SOA характеризуется следующими свойствами, отражающими особенности сервис-ориентированного подхода: логическое представление сервиса, сообщения, описание, степень детализации, передача по сети и кроссплатформенность. Сервис определяется в терминах сообщений, участвующих обмене между агентами поставщиков и потребителей сервисов. SOA не определяет внутреннюю структуру агентов, х реализацию, тем самым обеспечивая совместимость между любыми программными компонентами, удовлетворяющими требованиям обмена сообщениями в определении сервиса. Сервисы используют небольшой набор операций с большим набором сообщений, определяющих степень детализации описания сервиса. Сообщения, участвующие обмене сервисами, имеют стандартизованный кроссплатформенный XML-формат [104]. Взаимодействие с сервисами может осуществляться с помощью сетевого соединения.
Эталонная модель сервис-ориентированной архитектуры (англ. Reference Model for Service Oriented Architecture, SOA-RM) предложена OASIS с целью уточнения основных понятий в области SOA. Технический комитет OASIS-РМ был создан в 2003 году для разработки модели, которая демонстрировала бы преимущества сервис-ориентированного подхода и содействовала созданию конкретных сервис-ориентированных архитектур. В результате эталонная модель была стандартизована в 2006 году.
SOA-RM является абстрактной моделью, определяющей правила взаимодействия между субъектами в составе сервис-ориентированной архитектуры. Она состоит из минимального набора объединяющих концепций, аксиом и отношений и не зависит от конкретных технологий и конкретных деталей реализации. В соответствии с эталонной моделью SOA является парадигмой для организации и использования распределенных возможностей, которые могут быть подконтрольны различным доменам. Таким образом, SOA-RM обеспечивает механизм для согласования потребностей потребителя сервиса с возможностями, предлагаемыми поставщиком сервиса. Центром SOA-RM является сервис, который определяется как механизм, для обеспечения доступа к одной или нескольким возможностям, используя заданный интерфейс, соответствии с ограничениями политиками, указанными в описании сервиса. Вокруг этого понятия в SOA-RM существует три динамические концепции:
1. Видимость. Нужно убедиться, что поставщик сервиса и пользователь могут видеть друг друга. Это верно для любого вида отношений между поставщиком сервиса и пользователем, независимо от конкретного типа их представления (программное приложение или человек). Видимость зависит от трех факторов: осведомленность, готовность и достижимость. Пользователь сервиса должен быть в курсе о существовании поставщика услуг; оба должны быть готовы взаимодействовать друг с другом и поставщик сервиса должен быть достижим для пользователя сервиса.
2. Взаимодействие. Взаимодействие зависит от видимости, потому что пользователь сервиса и поставщик не могут взаимодействовать, если они не видят друг друга. Для того чтобы понять, что необходимо для взаимодействия с сервисом, описание должно охватывать информационную модель модель поведения. Первая модель детализирует информацию, оторой удут обмениваться ри взаимодействии с сервисом, о время ак последняя модель показывает действия, которые могут быть вызваны с помощью сервиса.
3. Эффект реального мира. Результатом любого взаимодействия является эффект реального мира, оторый может оздать собственный экземпляр ачестве информации, возвращаемой сервисом или изменением состояния сущностей, участвующих во взаимодействии. Приведенные выше понятия учитывают динамические аспекты,
поскольку они касаются взаимодействия с сервисами. Кроме того, SOA-RM определяет три дополнительных аспекта, которые относятся к сервисам как таковым:
1. Описание сервиса. Описание сервиса содержит всю информацию, необходимую пользователю для того, чтобы решить, имеет ли сервис отношение к конкретному контексту. Кроме того, описание содержит информацию, которая необходима для того, чтобы фактически воспользоваться данным сервисом. Таким образом, описание сервисов упрощает динамические аспекты, такие как видимость взаимодействие.
2. Контракт и политика. Контракт представляет собой официальное соглашение между двумя или более сторонами, в то время кк политика ограничивает использование, развертывание, или описание конкретной сущности в соответствии с определением своего владельца.
3. Контекст выполнения. Контекст выполнения включает в себя все технические и бизнес- элементы, которые ак или иначе имеют отношение взаимодействию между поставщиками сервиса пользователями, такими как элементы инфраструктуры. Таким образом, каждое взаимодействие имеет определенный контекст выполнения.
SOA-RM также описывает понятие модели процесса. Соответственно модель процесса характеризует временные отношения и временные свойства действий и событий, связанных со взаимодействием с сервисом. Оркестровка множества услуг не рассматривается в эталонной модели, потому что в центре внимания находится моделирование того, что такое сервисы и какие ключевые отношения вовлечены в моделирование сервисов.
Анализ проблем прогнозирования показателей
Есть два архитектурных стиля, для описания веб-сервисов, а именно WS- и передача репрезентативного состояния (англ. Representational State Transfer, REST). Стиль WS- основывается на идее доступности услуги в одном и нескольких местах, каждое из которых описывается унифицированным идентификатором ресурса (англ. Uniform Resource Identifier, URI). Каждый сервис включает в себя несколько операций, выполняющих требуемую функцию [94], что в свою очередь означает, что каждая операция является сервис-зависимой. Сообщения, которыми обмениваются операции или сервисы, состоят из метаданных (заголовок) и тела сообщения (полезная нагрузка). Этот архитектурный стиль, как правило, реализуется с помощью WS- стандартов, используя простой протокол доступа к объектам (англ. Simple Object Access Protocol, SOAP) в качестве протокола обмена сообщениями. Однако могут быть использованы другие протоколы, такие как протокол передачи гипертекста (англ. HyperText Transfer Protocol, HTTP) или простой протокол передачи почты (англ. Simple Mail Transfer Protocol, SMTP). На самом деле WS- сервисы могут работать поверх различных протоколов, что позволяет предоставлять инфраструктурные сервисы, отвечающие за безопасность, обработку транзакций, маршрутизацию сообщений сложных интеграционных решениях и надежность сервис-ориентированных систем.
Технология REST является идиомой дизайна, построенной вокруг идеи использования сервисов в качестве ресурса, идентифицируемого URI, вместо того, чтобы использовать одиночные операции сервиса [93]. Состояние ресурса может изменяться командами HTTP протокола, такими как создание, чтение, обновление и удаление (HTTP PUT, GET, POST и DELETE). Данные, как правило, передаются с помощью расширяемого языка разметки (англ. eXtensible Markup Language, XML) по HTTP протоколу, который имеет преимущество универсальности и простоты использования (в отличие, например, от JavaScript Object Notation - JSON), но не предоставляет методы хорошего описания сервисных контрактов.
Язык описания веб-сервисов (англ. Web Services Description Language, WSDL) предоставляет средства для описания интерфейса веб-сервиса с помощью XML [91]. Спецификация продвигается W3C консорциумом и в настоящее время опубликована в качестве рекомендации версии 2.0. WSDL позволяет вызывать операции веб-сервиса независимо от его реализации. Вместо использования сервисов имен и каталогов, которые обычно встречаются промежуточном программном обеспечении, веб-сервисы работают в довольно децентрализованных средах. В WSDL местоположение каждого конкретного сервиса четко определено, чтобы другие сервисы или приложения могли вызывать операции сервиса.
Спецификация WSDL 2.0 обеспечивает возможность использования восьми различных моделей обмена сообщениями между сервисом и его пользователем. Четыре модели (In-Only, Out-Only, Robust-In-Only, Robust-Out-Only) основаны на отправке пользователем сообщения сервису или возврате от сервиса сообщения об ошибке. Еще четыре модели (In-Out, Out-In, In-Optional-Out, Out-Optional-In) основаны на отправке начального сообщения любой из сторон. Есть два общих подхода к разработке веб-сервисов: Code-First и Contract-First. Первый из них является нисходящим подходом, требующим разработку классов в объектно-ориентированном языке программирования, которые затем могут быть использованы для создания WSDL документа, описывающего функциональность, предлагаемую этими классами в качестве операций сервиса. Второй представляет собой восходящий подход, требующий разработать сначала WSDL документ, используемый для создания скелета необходимых классов, которые в последствии будут реализованы. Существующие платформы веб-программирования предлагают способы для контроля соответствия между WSDL и объектно-ориентированными языками. Для Java, например, могут быть использованы платформы с открытым исходным кодом, такие как Apache Axis 2 и Oracle Metro Stack. Альтернативой в среде разработки .NET является Windows Communication Foundation (WCF).
Несмотря на то, что WSDL предлагает независимое от языка описание структурных аспектов веб-сервиса, он все же является техническим языком, который ограничивает его применение только аудиторией специалистов в области информационных технологий. Кроме того, WSDL не предоставляет никаких возможностей для связывания операций сервисов с бизнес сущностями, такими ак процессы, объекты и возможности внутри предприятия. Также не предоставляется никаких средств для определения нефункциональных аспектов веб-сервисов, таких как цена и различные показатели уровня обслуживания (время ответа, доступность и т.д.).
Для ликвидации этих ограничений W3C консорциумом были разработаны рекомендации WS-Policy, предоставляющие механизм для расширения WSDL-артефактов политиками по различным аспектам использования сервисов, такими как соглашения о безопасности или об уровне обслуживания. Эти рекомендации также могут быть использованы пользователями для указания требований, которым должны соответствовать выбираемые ими сервисы. Однако, реализация WS-Policy слишком тесно связана со структурой WSDL документа и, как правило, распределена по нескольким WSDL документам, поэтому целостность картины о том, какая политика каким сервисам принадлежит, зачастую определить трудно.
SOAP - простой протокол доступа к объектам на основе XML для обмена сообщениями между веб-сервисами, которые используют различные транспортные протоколы, например, HTTP, TCP или SMTP [89]. Протокол SOAP можно рассматривать как асинхронный способ обмена сообщениями типа запрос-ответ между различными взаимодействующими сторонами. SOAP определяет формат сообщений, но не хранит состояния не предоставляет возможностей семантической интерпретации сообщений.
Заголовок SOAP сообщения содержит метаданные для работы инфраструктурных сервисов, обеспечивающих безопасность, обработку транзакций, маршрутизацию и надежность. Таким образом, он является расширяемым, но необязательным. Тело, которое является обязательным, содержит полезные данные сообщения - его смысловую нагрузку. Тело может быть интерпретировано целевым компонентом, т.е. пользователем веб-сервиса или его поставщиком. Кроме того, но может содержать необязательные элементы, которые содержат информацию об ошибке и статусе SOAP сообщения.
Модели и схемы расслоения программных системы
Выбор оптимальной стратегии отказоустойчивости для сервис-ориентированных систем зависит не только от показателей QoWS, но и от характеристик сервис-ориентированной системы в целом. Например, для систем реального времени оптимальным может быть в ыбор параллельной стратегии, обеспечивающей минимальное время ответа. Для систем с ограниченными вычислительными ресурсами (например – мобильные приложения) предпочтительным будет выбор последовательной стратегии. Автоматизировать определение характера чувствительности сервис-ориентированной системы (времени ответа, ограниченности ресурсов) на уровне промежуточного программного обеспечения интеграции веб-сервисом, не располагая требованиями пользователя, сложно. В тоже время требовать от пользователей предоставления излишне детальной технической информации для использования ее при выборе стратегии отказоустойчивости на практике не всегда возможно - пользователь может быть просто не знаком с особенностями обеспечения отказоустойчивости сервис-ориентированных систем. Для решения этой проблемы предлагается определить минимально необходимый для выбора стратегии отказоустойчивости и в тоже время понятный пользователю набор критериев (требований).
Пороговое время ожидания Т - максимальное время обработки запроса пользователя, которое допустимо для программного приложения, вызывающего веб-сервис. Если время ответа веб-сервиса больше, чем Т, то такой вызов рассматривается как отказ по времени ожидания. Пороговая вероятность отказа Р - максимальная вероятность отказа, допустимая для работы программного приложения пользователя. Если вероятность отказа веб-сервиса больше Р, то веб-сервис не может использоваться без применения стратегии отказоустойчивости. Ограничение ресурсов L - максимальное количество параллельных соединений, допускаемое программным приложением пользователя (позволяет приблизительно оценить потребление ресурсов, так как для параллельного соединение с большим количеством веб-сервисов необходимо больше вычислительных ресурсов). Ограничение стоимости С - максимальная стоимость вызова веб-сервиса, допускаемая пользователем. Тип стратегии S - последовательная или параллельная стратегия отказоустойчивости. Если тип стратегии на указан, то промежуточное программное обеспечение интеграции веб-сервисов будет само определять оптимальный тип стратегии отказоустойчивости.
Помимо субъективных требований (предпочтений) пользователей для определения оптимальной стратегии отказоустойчивости необходима объективная оценка каждого вызываемого веб-сервиса. В научной и технической литературе приводятся различные варианты классификации показателей QoWS и варианты решения этой задачи для атомарных веб-сервисов. Несмотря на изученность проблемы существует ряд вопросов, требующих решения в контексте поставленной задачи - динамический выбор отказоустойчивой композиции веб-сервисов.
Сложность получения информации о производительности вызываемых веб-сервисов. Пользователи сервисов не всегда вычисляют и сохраняют получаемые ими значения показателей QoWS, таких как вероятность отказа или время ответа сервиса. Большинство пользователей сервисов не желает делиться информацией, которую они получают.
Географическое местоположение пользователя по отношения к сервису влияет на значение показателей QoWS, собранных этим пользователем. Так производительность каналов связи, используемых одним пользователем, может существенно отличаться от производительности каналов связи, используемых другим пользователем, вследствие чего будут отличаться и значения времени ответа, полученные каждым пользователем. Например, пользователь может находиться в той же локальной сети, то веб-сервис. В этом случае показатели, характеризующие производительность веб-сервиса, могут дезинформировать пользователей, обладающих низкоскоростными Интернет-соединениями для доступа к тому же веб-сервису.
Отсутствие удобного механизма для получения пользователями информации о показателях QoWS. Основываясь на анализе характеристик и определенных ранее комплексных показателях вб-сервисов, можно выделить три основных показателя QoWS, необходимых для объективной оценки при выборе оптимальной стратегии отказоустойчивости: среднее время ответа (t или qt), вероятность отказа (р или q2). Участие пользователей в процессе накопления и использования наборов данных показателях QoWS должно осуществляться на обровольной взаимовыгодной основе. В случае сотрудничества пользователи получают возможность использовать коллективный опыт динамической оптимизации стратегии выбора отказоустойчивой композиции еб-сервисов. Не готовые обмену информацией о показателях QoWS пользователи могут отключить эту возможность промежуточного программного обеспечения, то понизит эффективность его работы. Такая тактика поощрения стремления пользователей к сотрудничеству аналогична тактике загрузки файлов с BitTorrent [31], где остановка отправки файлов другим пользователям снижает скорость загрузки.
Интегральный показатель эффективности є для каждой стратегии можно вычислить по следующей формуле: где ts - среднее время ответа стратегии, ps - вероятность отказа стратегии, cs - стоимость выполнения стратегии, /s - количество ресурсов, необходимое пользователю для использования данной стратегии, Т -ограничение пользователя по времени ожидания результата выполнения требуемой функции, Р - пороговое значение вероятности отказа, допустимое для функционирования приложения пользователя, L - ограничение вычислительных ресурсов, которыми располагает пользователь ля использования данной стратегии отказоустойчивости, at,ap,ac,ai - весовые коэффициенты, определяющие приоритеты пользователя по отношению к соответствующим показателям и задаваемым им параметрам (требования и ограничения пользователя) . Идея такого способа подсчета заключается в том, чтобы привести к единому способу представления показатели QoWS и требования пользователя, допускающему их интегральную оценку в виде безразмерной величины.
