Обзор принципов построения распределенных сервис-ориентированных систем.

Актуальной проблемой в области информационных технологий является децентрализация архитектуры системы путем перехода к распределенным системам проектирования, построенным на основе Интернет-технологий, реализующих задачи коммуникации и информационного обмена между приложениями. Такие независимо управляемые приложения являются автономными и могут взаимодействовать друг с другом в процессе выполнения общей задачи. Протоколы Интернет-технологий представляют надежную базу для связывания подсистем и не требуют согласованного использования ресурсов, находящихся в разных узлах сети, что существенно упрощает процесс построения и эксплуатации распределенной САПР. Основным требованием для возможности реализации такой распределенной системы является согласованность интерфейсов, посредством которых связаны отдельные подсистемы. При выполнении этого требования отдельные компоненты распределенной САПР могут создаваться различными разработчиками и поддерживаться на различных сайтах, откуда они будут поставляться (возможно, на коммерческой основе) потребителям. Самым эффективным методом объединения подсистем в распределенное приложение следует считать организацию удаленного вызова процедур на базе сервис-ориентированной архитектуры с использованием веб-сервисов.

 

Сервис-ориентированная архитектура (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.

Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST).

Интерфейсы компонентов в сервис-ориентированной архитектуре инкапсулируют детали реализации (операционную систему, платформу, язык программирования) от остальных компонентов, таким образом обеспечивая комбинирование и многократное использование компонентов для построения сложных распределённых программных комплексов, обеспечивая независимость от используемых платформ и инструментов разработки, способствуя масштабируемости и управляемости создаваемых систем.

 

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

 

К разработке и реализации SOA предъявляются огромные требования. Если архитектура SOA складывается не только из продуктов и стандартов, помогающих ее реализовать (к примеру, через Web-сервисы), то какие дополнительные элементы необходимы для ее реализации? Сервис-ориентированное моделирование требует проведения дополнительных мероприятий и наличия артефактов, которые не присутствуют в традиционном Объектно-Ориентированном Анализе и Проектировании (object-oriented analysis and design - OOAD).

 

Как бы то ни было, существуют дополнительные, важные суждения, которые следует принимать во внимание. Во-первых: текущие методы OOAD не обращаются к трем ключевым элементам SOA – сервисам, потокам и компонентам, реализующим сервисы. Вам необходимо также иметь возможность напрямую обращаться к методикам и процессам, необходимым для идентификации, определения и реализации сервисов, их потоков и композиции. Кроме этого, необходимо реализовывать компоненты масштаба предприятия и быть уверенным в обеспечении требуемого качества обслуживания.

Во-вторых: необходимо провести изменение взглядов и принципов для соответствия отдельным требованиям двух ключевых ролей в SOA – поставщика и потребителя сервиса. В третьих: необходимо стремиться использовать предполагаемые приложения для одного предприятия или направления бизнеса в канале поставок, и раскрывать их для бизнес-партнеров, которые смогут компоновать, комбинировать и инкапсулировать их в новые приложения.

 

Все это является незначительным шагом от использования обычных "распределенных объектов". Речь идет о выгоде использования сетевых средств: к примеру, когда стороны используют комбинацию поисковых сервисов Amazon.com и Google, и совмещают их с сервисами eBay для построения собственных гибридных решений. Или, к примеру, когда агентство путешествий использует систему бронирования авиабилетов, координирует ее с информацией о ренте автомобилей и бронированием номеров в отеле, обновляет свои записи и отправляет планируемую карту маршрута в ваш органайзер. Независимо от приложения, для успешного создания SOA вам необходимы не просто хорошие инструменты и стандартны, а нечто большее. Вам необходимы некие перспективные шаги для поддержания жизненного цикла вашей SOA – методики для анализа, проектирования и реализации сервисов, потоков и компонентов. Таким образом, всем, заинтересованным в разработке корпоративного приложения, необходимо четко понимать все подробные шаги в сервис-ориентированном моделировании и архитектуре.

 

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

 

В последнее время сервисно-ориентированные архитектуры де-факто становятся критериями интеграции приложений, основанных на веб- технологиях. Применение веб-сервисов W3C происходит все чаще, поскольку растет потребность в связи между приложениями и работоспособностью. Организации могут извлечь пользу из сервис-ориентированных архитектур, объединив службы, разработанные внутри компании и вне ее, наряду с обеспечением стандартных способов взаимодействия между различными программными приложениями, работающими на разнообразных гетерогенных платформах через Интернет.

 

1. Сервис-ориентированная архитектура распределенной системы автоматизированного проектирования. Сервис-ориентированная архитектура (SOA) основана на модульном подходе к построению программного обеспечения, со стандартными интерфейсами. SOA использует принципы унификации типовых процессов, неоднократного использования элементов, и организацию на базе выбранной платформы. Компоненты программного обеспечения можно распределять по различным узлам, и они предлагаются для применения как слабо связанные, независимые приложения. Хотя архитектура SOA не привязывается к какой-либо одной технологии удаленного вызова методов (COM, DCOM, COM+,.NET REMOTING, Java RMI, CORBA), программные комплексы, построенные согласно SOA, как правило, реализуются как некоторая совокупность веб-сервисов, которые интегрированы согласно с известными стандартными протоколами (WSDL, SOAP). Веб-сервис описывает некоторый набор методов, каждый из которых может быть вызван в сети через стандартизированные XML-сообщения. На основании таких сообщений можно описать требуемые данные способом, не зависящим от платформы, и реализовать обмен информацией между приложениями, что обеспечивает слабосвязанность приложений.

· Работающие на одной платформе SOA-приложения, могут вызывать стандартным способом сервисы, функционирующие на иных платформах, Важно отметить, что сервисы не располагают информацией о вызывающем их приложении, а клиентские приложения не имеет информации, о способе, которым сервисы выполняют свои задачи. SOA-программы предоставляет инкапсуляцию всех деталей реализации каждого приложения от иных компонентов, предоставляя гибкий способ неоднократного использования и комбинирования приложений для построения распределённых информационных систем.

· Системы на основе сервис-ориентированной архитектуры относятся к классу мультиагентных систем (МАС), которые образованы несколькими взаимодействующими интеллектуальными агентами, обеспечивающими автономность, ограниченность представления и децентрализацию отдельных подсистем распределенной информационно-вычислительной системы.

 

 

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

Поскольку веб-сервисы функционируют на достаточно высоком уровне абстракции, динамически обрабатывая и анализируя все типы данных, то отдельным компонентам системы предоставляется возможность взаимодействовать с другими приложениями более открыто. При использовании таких универсальных интерфейсов появляется возможность использовать программные компоненты повторно, что позволяет снизить трудоемкость разработки распределенных систем автоматизированного проектирования. Учитывая высокую стоимость программного обеспечения современных САПР, указанная возможность имеет большое экономическое значение. Важно отметить, что услуга веб-сервиса, в отличие от любой услуги, оказываемой клиенту-пользователю через связанный с ним броузер, предоставляется клиентской программе.

При построении веб-сервисов применяется ряд спецификаций, основанных на открытых стандартах, при этом текст протоколов выполняется в следующей последовательности: поиск веб-сервиса при помощи протокола UDD, описание веб-сервиса на основе WSDL, вызов веб-сервиса через протокол SOAP, кодирование данных (XML), транспортировка (HTTP).

 

Основным стандартом технологии веб-сервисов является протокол WSDL. Этот протокол используется для создания описания интерфейса веб-сервиса при этом WSDL-документ описывает информационные блоки сервиса и имеет информацию об интерфейсе и методах, доступных для общего пользования, дает описание типов данных, использующихся при передаче в запросах и ответах по соответствующему протоколу, а также информацию о транспортном протоколе, который используется для работы с сервисом и адресную информацию о расположении описываемого сервиса. Следует заметить, что стандарт документа WSDL является независящим от какого-либо определенного протокола обмена XML-данными, но содержит встроенные средства поддержки SOAP.

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

Транспортный протокол HTTP применяется для осуществления обмена информацией с веб-сервисом через SOAP-сообщения. Возможно также в качестве транспортного протокола использование стандарта SMTP.

 

 

3. Взаимодействие протоколов веб-сервисов. Взаимодействие протоколов UDDI, WSDL, SOAP, HTTP при использовании веб-сервисов иллюстрируется приведенной на рис. 1 структурой, где сверху изображены процессы регистрации службы и получения ее описания WSDL, а в нижний части – процессы вызова метода службы и возвращения на клиентскую сторону результатов работы сервера.

Рис 1. Взаимдействие протоколов UDDI, WSDL, SOAP, HTTP при использовании веб-сервисов

Обращение к реестру UDDI осуществляется единственный раз и после получения адреса веб-сервиса повторно обычно не выполняется. Единственный раз выполняется также и процесс получения WSDL-документа. Если URL адрес веб-сервиса известен, то обращение к реестру выполнять не обязательно, так как файл WSDL можно вызвать непосредственно из веб-сервиса. Поскольку в реальных условиях работы с распределенными системами на основе веб-сервисов их URL-адреса, как правило, известны, обращение к UDDI осуществляется сравнительно редко.

Вызов метода веб-службы в распределенной системе осуществляется из клиентского приложения через прокси-класс, объект которого реализует требуемую заглушку (stub). Прокси-класс осуществляет преобразование передаваемых методу аргументов в SOAP-сообщение и направляет это сообщение веб-сервису. После выполнения сервисом вызываемого метода, прокси-класс получает соответствующий SOAP-ответ и преобразует его в соответствующие типы данных, что позволяет клиентскому приложению отобразить результаты выполнения метода веб-сервиса.