WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 |
CЕРВИС-ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА: НОВЫЕ ВОЗМОЖНОСТИ В СВЕТЕ РАЗВИТИЯ GRID ТЕХНОЛОГИЙ А.В. Богданов, Е.Н. Станкова, В.В. Мареев Автономная некоммерческая организация «Институт высокопроизводительных вычислений и интегрированных систем» 191119, г. Санкт-Петербург, ул. Коломенская, д. 35-37, литер А, помещение 6Н Аннотация. Cервис-ориентированная архитектура (SOA) - это такая архитектура приложения, в которой компоненты или «сервисы», имея согласованные общие интерфейсы, используют единые правила (контракты) для определения того, как вызывать сервисы и как они будут взаимодействовать друг с другом. В настоящее время эта технология получает все большее распространение во многих областях ИТ индустрии благодаря своему главному преимуществу: способности предложить эффективный подход к решению одной из самых сложных и насущных проблем — проблемы интеграции информационный ресурсов. Соединение преимуществ SOA c возможностями Grid технологий позволит осуществить интеграцию не только локальных, но и географически распределенных информационных ресурсов.

Annotation. Service-oriented architecture (SOA) is application architecture in which components or "services", having unified common interfaces, use joint rules (contracts) for definition of how they will access the services and how they will interact with each other.

Nowadays this technology is becoming more and more widespread in many fields of IT industry due to the main advantage: capacity to offer effective approach to the solution of one of the most complicated and actual problems – problem of integration of the information resources. Joining the advantages of SOA with the capacities of Grid technology allows providing integration not only of local but of geographically remote information resources.

1 Введение В настоящее время под давлением рынка быстро возрастает сложность разрабатываемого программного обеспечения. Современные приложения уже не являются неизменяемымы, цельными образованиями, как это было в прошлом. Это не монолитные ядра, работающие на крупной компьютерной платформе, а скорее набор динамически изменяемых модулей. Приложения создаются несколькими командами разработчиков с помощью различных языков программирования, с применением множества данных, которые могут поступать "он лайн" из нескольких, как правило, географически распределнных источников. В итоге возникает потребность в создании нового стиля разработки приложений, основой которого будут программные службы (software services). Такой стиль позволит программистам не начинать работу с нуля, а создавать новые приложения, используя уже готовые службы, доступные в так называемой экосистеме служб. Экосистема – это набор соединений между различными службами, функциональное назначение которых состоит в выполнении определенных запросов клиента. Между службами существует определенная иерархия, служба обрабатывающая сложный запрос, разбивает его на более простые, которые, в свою очередь обрабатываются другими службами. При этом образуются ассоциативные связи. Такая концепция легко сравнима с хорошо известной Web-концепцией.

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

В течение последних нескольких лет значительный интерес привлекли концепции "сервисно-ориентированный компьютинг" (Service Oriented Computing – SOC) и "сервисно-ориентированная архитектура" (Service Oriented Architecture – SOA).

При рассмотрении термина "сервисно-ориентированная архитектура", полезно предварительно определить ключевые термины:

Архитектура – это формальное описание системы, определяющее е цели, функции, внешне видимые свойства, и интерфейсы. Она также включает описание внутренних компонентов системы, и их отношений, наряду с принципами, управляющими ее дизайном, функционированием и возможной последующей эволюцией.

Сервис (служба) – программный компонент, к которому можно удалнно обратиться посредством компьютерной сети, и предоставляющая некоторые функциональные возможности запрашивающей стороне.

Основная идея SOA и SOC состоит в том, чтобы инкапсулировать функциональности крупномодульных приложений в службах, которые распространяются по сети. Такие службы должны взаимодействовать и сами договариваться между собой с помощью стандартных интерфейсов, позволяющих им прозрачно работать на поле разнообразных платформ и между границами организаций, что открывает возможность создания динамичных виртуальных организаций. Можно определить архитектуру SOA как слабосвязанную архитектуру с набором компонент, достаточно "гранулированных" для использования клиентами. Доступ к компонентам осуществляется через сеть в соответствии с политикой, точно определнной этими компонентами. Хотя большинство определений SOA предписывают при е реализации использование именно Web-служб, тем не менее, SOA можно реализовать, используя любую основанную на службах технологию.

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



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

Разработка подобных архитектур стала закономерным результатом эволюционного процесса, начавшегося в 80-е годы с первых попыток построения распределнных систем на основе объектно-ориентированных моделей. Некоторое время назад появились распределнные системы следующего поколения, базирующиеся на двухкомпонентных моделях.Net и J2EE. Они суммировали унаследованные от предшественников свойства, а их гранулярность увеличилась в связи с добавлением объектов, названных «компонентами». Таким образом, распределнные системы стали более гибкими, и была обеспечена возможность выполнения транзакционных операций.

Компонентная распределнная модель заняла надлежащее место во внутренних сетях предприятий, обеспечив взаимодействие гомогенных приложений. Но на следующем витке развития технологий, вызванном появлением Internet, обнаружились ее ограничения. Во-первых, в каждой из моделей задействуется свой коммуникационный протокол (RMI для J2EE,.Net Remoting для.Net), и, хотя их совместное использование возможно, оно неэффективно. Во-вторых, слишком сложна схема адресации; е применению в среде Internet мешает необходимость централизованного присвоения адресов компонентам. В-третьих, структура сообщений является низкоуровневой. По сути, она соответствует структуре, используемой в языках программирования: те же целые числа, символьные переменные, числа с плавающей точкой. При этом не обеспечиваются должная гибкость, возможности добавления новых параметров и самоописания объектов. В-четвертых, можно отметить недостаточную наджность. Протоколы, по существу, синхронны и сильно связаны, что противоречит требованиям больших структур.

Возникла потребность в новом, более простом коммуникационном протоколе, и в ответ на не был создан независимый протокол SOAP (Simple Object Access Protocol ).

В нм используются стандартная схема адресации с применением URL для идентификации объектов, транспортный протокол HTTP, данные в формате ASCII и язык XML, открывающий возможность самоописания объектов.

SOA поддерживается языком WSDL (Web Services Description Language), в котором описание сервисов делится на интерфейс и оболочку. Интерфейс описывает, что должен содержать запрос, а оболочка определяет протоколы транспорта и данных.

На самом деле попытки реализовать архитектуру приложений, в которой распределнные прикладные модули представлены как объекты, взаимодействующие посредством чтко описанных интерфейсов, предпринимаются уже довольно давно и с определнным успехом (модели построения компонентных приложений Common Object Request Broker Architecture (CORBA) и Microsoft Distributed Component Object Model (DCOM)). Внешне они действительно похожи на SOA, но более детальный анализ показывает, что в этих ранних подходах к сервисной ориентации программных систем не выполняются или выполняются с определенными ограничениями базовые принципы SOA. Так, в CORBA и DCOM взаимодействующие объекты являются сильносвязанными, и внесение изменений в реализацию программных компонентов, предоставляющих и использующих определенный сервис, должны быть скоординированы между собой. Запросы к объектам (сервисам) в этих архитектурах, как правило, содержат небольшой объем информации, учитывающей специфику реализации сервисов ("мелкозернистая" — fine-grained — структура сервисов), и потому порождают значительный сетевой трафик между поставщиком и потребителем сервиса. В DCOM взаимодействие программных компонентов основано на закрытых интерфейсах Microsoft. CORBA не принадлежит частной компании, эта архитектура — плод усилий международного консорциума OMG, который ставил своей целью создание универсальной платформы интеграции разнородных программных компонентов на базе стандартного языка описания интерфейсов. Однако реализации спецификаций CORBA сильно варьируются в продуктах разных производителей, что ограничивает интероперабельность систем на базе CORBA. Кроме того, и CORBA, и DCOM имеют существенные ограничения по поддержке действительно распределенных систем, их протоколы взаимодействия объектов слишком сложны для организации производительной связи сервисов, реализованных на разных машинах.

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

Работа GRID-систем опирается на программное обеспечение промежуточного уровня: программные компоненты и протоколы, которые обеспечивают требуемый контролируемый доступ к ресурсам. На первом этапе своего существования GRIDсистемы строились или на основе специально разработанных общедоступных компонент или на основе закрытых технологий. Хотя различные общественные и коммерческие решения были успешны в своих областях применения GRID, каждое со своими сильными и слабыми сторонами, они имели ограниченный потенциал как основы для GRID нового поколения. Этот потенциал должен быть масштабируемым и интероперабельным для удовлетворения потребностям широкомасштабных научных и производственных проектов. Достижению такого рода целей должна способствовать интеграция технологий GRID и SOA.





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

Цели SOA- для крупных информационных систем, уровня предприятия, и выше:

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

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

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

"Крупнозернистая" структура сервисов. Сервисы в SOA представляют собой модули бизнес-логики достаточно высокого уровня, благодаря чему взаимодействие между ними сводится к ограниченному числу сообщений по содержанию бизнеслогики вместо множества низкоуровневых вызовов, учитывающих детали реализации сервисов. Такой подход снижает нагрузку на сеть и способствует более высокой производительности системы. На практике переход к SOA может начинаться с представления в виде сервисов бизнес- или системных функций низкого уровня, которые затем благодаря еще одному свойству сервисов — модульности будут компоноваться в высокоуровневые сервисы, реализующие определенные этапы бизнес- или вычислительного процесса или весь процесс целиком. Важно, что с точки зрения архитектуры сервис, независимо от внутренней структуры и языка реализации, выглядит как единое целое.

Реализация слабой связности может основываться на сочетании различных средств и методов:

1. Контракты. Понятие контракта в SOA трактуется несколько шире, чем обычно. Контракт определяет условия предоставления и потребления сервисов, включая функциональные, технические (не только протокол, но и, например, способ авторизации) и прочие (стоимость, гарантии) параметры и служит основой соглашения между потребителем и провайдером сервиса на всех этапах его жизненного цикла. Не даром одно из распространенных определений провайдера и потребителя сервисов базируется на том, кто из них контракт предоставляет (провайдер), а кто принимает (потребитель).

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

Контракты не только ослабляют связи между элементами архитектуры, но, что не менее важно, делают их явными, овеществленными объектами управления.

Постоянное изменение различных участков SOA, таким образом, становится возможно именно благодаря контрактам.

2. Композиция. Основным преимуществом композиции, вполне самостоятельной черты SOA, считается обеспечение возможности многократного использования ранее реализованной функциональности. Однако композиция способствует и адаптивности, т.к. позволяет быстрее проводить многие изменения путем перестыковки связей между сервисами. Такие изменения осуществлять гораздо легче, чем менять весь сервис в целом.

Pages:     || 2 | 3 | 4 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.