Сервис-ориентированная архитектура: новые возможности в свете развития Grid технологий

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). При

рассмотрении

термина

"сервисно-ориентированная

предварительно определить ключевые термины:

2

архитектура",

полезно

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

посредством

компьютерной

сети,

и

предоставляющая

некоторые

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

крупномодульных

приложений

в

службах,

которые

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

3

Разработка

подобных

архитектур

стала

закономерным

результатом

эволюционного процесса, начавшегося в 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), в котором описание сервисов делится на интерфейс и оболочку. Интерфейс описывает, что должен содержать запрос, а оболочка определяет протоколы транспорта и данных.

4

На самом деле попытки реализовать архитектуру приложений, в которой распределѐнные прикладные модули представлены как объекты, взаимодействующие посредством чѐтко описанных интерфейсов, предпринимаются уже довольно давно и с определѐнным успехом (модели построения компонентных приложений 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 основывается на хорошо прописанных стандартах и сервисах, представленных так, что они могут быть обнаружены и задействованы конечным пользователем или приложением.

5

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

6

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

сокращение

издержек

при

разработке

приложений,

за

счѐт

упорядочивания процесса разработки, 

расширение повторного использования кода,



независимость от используемых платформ, инструментов, языков разработки,



повышение масштабируемости создаваемых систем,



улучшение управляемости создаваемых систем.

Принципы SOA 

Архитектура, как таковая, не привязана к какой-то определѐнной технологии,



Независимость

организации

системы

от

используемой

вычислительной платформы (платформ), 

Независимость

организации

системы

от

применяемых

языков

программирования, 

Использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним,

7



Организация

сервисов

как

слабо-связанных

компонентов

для

построения систем Сервис-ориентированная

архитектура

основана

на

следующих

базовых

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

8

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

не

столько

программного

компонента,

сколько

бизнес

или

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

Композиция.

Основным

преимуществом

композиции,

вполне

самостоятельной черты SOA, считается обеспечение возможности многократного использования

ранее

реализованной

функциональности.

Однако

композиция

способствует и адаптивности, т.к. позволяет быстрее проводить многие изменения путем перестыковки связей между сервисами. Такие изменения осуществлять гораздо легче, чем менять весь сервис в целом. 3. Динамическое связывание. Опираясь на стабильность контракта потребитель может находить необходимые экземпляры сервисов, не прерывая работы. Это означает, что система устойчива к изменениям не только в адресации доступных сервисов (переезд на другой сервер), но и в их составе, который может измениться за время эксплуатации. Например, могут появиться новые партнеры, или ответственность за предоставление требуемой бизнес-функции может перейти к другому провайдеру, в том

числе

внешнему,

однако

это

не

повлияет

на

работу

потребителя.

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

9

сервисов, информацию об их провайдерах и иногда также об их потребителях. Все это вместе, помимо прочих не менее важных функций, служит также и конфигурацией SOA, определяющей параметры времени исполнения используемых сервисов для потребителей сервисов (вследствие композиции зачастую являющихся также их провайдерами). SOA - не догма, а набор взаимно совместимых принципов проектирования, и динамическое связывание часто относят к наиболее специфическим из них. Его преимущества особенно ощутимы при работе больших или децентрализованных ITслужб, или когда во взаимодействие включается ряд сторон, работаещих по идентичному или по очень похожему контракту. Это могут быть собственные филиалы компании (например, розничные отделения - магазинов, банков и т.д.), но чаще это партнеры - поставщики, курьеры, агенты, дилеры/дистрибьюторы и т.п. 4. Масштабируемость интерфейсов. При всей типизированности интерфейсов, хорошей практикой считается оставлять возможность для добавления заранее непредусмотренных элементов данных в передаваемые сообщения. Таким образом, контракт заранее допускает некоторую гибкость, если она возможна/необходима в конкретной ситуации. 5. Перестраивание. Масштабируемость – качество хорошее, но недостаточное. Интерфейс

всегда

должен

максимально

полно

отражать

существующие

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

, не последний из

которых - баланс логичности /интуитивности в стиле принятия решений

. Для более

стабильных организаций характерна бо́льшая регламентация процесса изменений , для более гибких - меньшая.

10

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

на

изменения

в

бизнес-процессах

динамично

и

без

сложных

трансформаций на интеграционном уровне. Другим важным компонентом хорошо спланированной архитектуры SOA является централизованный репозиторий, который содержит справочник всех сервисов, доступных на вашем предприятии. Здесь подойдет любая их классификация, наилучшим образом соответствующая вашей организации. Она должна обеспечивать группирование сервисов по бизнес-функциям, подразделениям, источникам данных или даже по версии исходного кода. Указанную функциональность в SOA обеспечивает реестр, основанный на стандарте UDDI (Universal Description, Discovery and Integration), который можно рассматривать как справочник "желтые страницы" Web-сервисов. В нем перечислены компании и связанные с ними сервисы. Данные механизмы позволяют организовать доступ партнеров по бизнесу к реестру, тем самым обеспечивая возможность быстрой интеграции приложений. Одним из важных вопросов построения архитектуры SOA являются ее администрирование и обеспечение безопасности. При наличии сотен сервисов, готовых к применению, у пользователя возникает потребность в централизованной системе администрирования, с помощью которой можно было бы осуществлять их мониторинг и защиту.

11

Существует множество систем администрирования SOA (на базе агентов и без них). Продукты SOAPStation компании Actional, Management Foundation, Service-Level Manager и Exception Manager фирмы AmberPoint, Gateway от Reactivity и Service Manager компании SOA Software являются наиболее популярными средствами, предназначенными для администрирования сервисов в рамках всего предприятия. Компании Computer Associates и Hewlett-Packard со своими продуктами Unicenter и OpenView соответственно также предлагают программные средства для оперативного администрирования и мониторинга SOA. Администрирование

архитектуры

SOA

означает

как

мониторинг

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

автоматически

отслеживая

ненадежные

соединения

и

проблемы

взаимодействия корпоративных сетей с помощью средств захвата сообщений, по своим возможностям

намного

превосходящие

традиционные

анализаторы

сетевых

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

определенную

бизнес

(вычислительную)

-логику,

бизнес

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

для

расширения

возможностей

уже

существующих,

вместо

повторного

программирования одних и тех же функций. Возможности сервисов описываются с использованием таких языков, как Язык Описания Web-сервисов (Web Services Description Language, WSDL).

12

Архитектура WSA использует механизмы обнаружения служб, "хореографию" рабочих потоков и управление транзакциями/состоянием, которые основываются на возможностях XML и спецификациях нижних уровней этой архитектуры. Термин

ориентированная

на

службы

инфраструктура

характеризует

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

бы

диспетчеру

рабочей

нагрузки

унифицировано

распределять,

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

быть

самоопределяющимися.

Динамическая

композиция

служб

и

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

13

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

14

3. Общая схема SOA Архитектура SOA , имеет следующие характерные особенности: 

Архитектура является распределенной. Функциональные модули приложение (системы) могут быть распределены по множеству вычислительных

систем

и

способны

к

взаимодействию

с

использованием локальных или глобальных сетей. 

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



Возможен

динамический

поиск

и

подключение

нужных

функциональных модулей. 

Архитектура базируется на общепринятых отраслевых стандартах.

Рисунок 1. Схема взаимодействия поставщика сервиса, потребителя сервиса и реестра сервисов

15

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

публикация сервиса;



поиск сервиса;



подключение и использование.

Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XMLдокументами, которые соответствуют XML-схеме. Любой разговор о SOA невольно переходит на рассуждение о роли и месте Webсервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA. Так, Джерими Уэстерман отмечает, что использование XML и Web-сервисов "поднимает SOA на более высокий уровень". Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты

16

реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость. Архитектура Web-служб (Web Services Architecture, WSA) дает возможность определить

SOA,

в

которой

службы

взаимодействуют,

обмениваясь

XML-

сообщениями. Технологии создания Web-служб в настоящее время уже достаточно продуманы, и многие компании предлагают хорошие коммерческие стеки Web-служб, а Apache поддерживает надѐжный свободно распространяемый стек. Тем не менее, важно понимать, что эти системы могут делать и чего не могут. Они действительно предоставляют инструментарий для разработки Web-служб, как правило, на языках Java или C#, и контейнеры для хостинга этих служб. Вместе с тем большинство из них не решает вопрос о том, как обеспечить универсальный набор абстракций и интерфейсов для эффективного использования ИТ-ресурсов – что является ключевым требованием

к

инструментарию

для

реализации

горизонтальной

интеграции.

Разработка таких абстракций и интерфейсов ведѐтся интенсивно, но пока ещѐ полностью

не

завершена.

Web-службы

определяются

базовым

комплектом

технологических спецификаций, предоставляющих механизмы для описания набора сообщений (то есть интерфейсов), которые могут использоваться для взаимодействия со службой (WSDL) и кодирования сообщений между службами (SOAP). Другие спецификации определяют правила, касающиеся безопасного доступа к службам (WSSecurity), адресации служб (WS-Addressing), управления состоянием (WS-Resource Framework), распространения уведомлений (WS-Notification) и т.д. Использование языка XML для описания интерфейсов служб и кодирования сообщений облегчает интеграцию приложений и распределѐнных систем из независимо определѐнных и слабо связанных служб.

Перечислим основные характеристики архитектуры Web-

служб: WSA базируется на XML-технологиях, таких как Информационная модель XML (XML Information Model) База данных XML (XML Base) и схема XML (XML Schema). WSA является независимой от транспортных протоколов нижележащего уровня (например, HTTP [HyperText Transfer Protocol] или SMTP [Simple Mail Transfer

17

Protocol]), и способ передачи данных определяется с помощью механизма связывания времени исполнения. Архитектура использует XML-шаблон обмена сообщениями, обеспечивая в то же время расширяемость модели для этого шаблона в целях адаптации к различным требованиям, предъявляемым к обмену сообщениями (например для обеспечения безопасности, надежности, координации и секретности). Такие интероперабельные сообщения создаются с использованием Простого Протокола Доступа к Объектам (Simple Object Access Protocol, SOAP) и расширений SOAP. Механизмы SOAPрасширений и информационные модели XML используются для создания расширений Web-служб.

18

4. SOA Grid Модель То,

что

теперь

понимают

под

термином

Grid,

представляет

собой

инфраструктуру, построенную на основе Интернета и Всемирной паутины (World Wide Web), которая обеспечивает масштабируемые, безопасные и быстродействующие механизмы

для

обнаружения

и

доступа

к

удаленным

вычислительным

и

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

неисправности

подразумевает

потребность

в

автоматическом

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

19

концепция системы автономных вычислений содержит следующие требования для вычислительной системы: 

нуждается в детальной информации о своих компонентах и их состояниях;



должна конфигурировать и реконфигурировать себя динамически;



стремится оптимизировать свое поведение, чтобы достичь своей цели;



способна восстанавливаться после неисправности;



защищает себя от атак;



должна знать свою среду;



реализует открытые стандарты;



оптимизирует использование ресурсов.

Разрабатываемые ныне системы Grid уже начинают выявлять многие из этих свойств. Grid реализованы при помощи Grid middleware - промежуточного программного обеспечения, осуществлющего необходимый доступ ресурсам. До настоящего времени, Grid были построены, используя, по большей части, или специальные компоненты открытого доступа или составляющие собственность компаний технологии. В то время как различные открытые и коммерческие решения были успешны в своих областях применения, у каждого есть сильные стороны и ограничения, и они создали потенциал для Grid будущего поколения, которые должны будут быть очень масштабируемыми и прозрачными, чтобы отвечать потребностям глобальных предприятий. В последние годы, однако, стало ясно, что есть значительное пересечение между целями вычислительных Grid и сервисами, основанными на Веб-службах; быстрые достижения в технологии Веб-служб и стандартах таким образом обеспечили эволюционный

путь

от

архитектуры

"шины"

используемых

сейчас

Grid

к

стандартизированному Grid класса предприятия будущего. Чтобы показывать, как Service-Oriented (сервисно-ориентированная) Grid могла бы быть построена, на рисунке 2 показана простая Grid, в которой сервис доступа к обычным и к виртуальным ресурсам обеспечивается через службы Grid.

20

Рисунок 2. В сервисно – ориентированной Grid Веб-службы виртуализируют ресурсы и обеспечивают другие функции С недавних пор свои услуги пользователям стали предлагать отдельные программные системы промежуточного уровня и приложения, опирающиеся на идеи Grid, например, порталы, механизмы поиска, сети распределенных данных и службы авторизации. Однако все эти службы автономны и не являются интероперабельными. Потребность в интеграции и интероперабельности все большего числа приложений заставляет развивать технологии Grid в направлении открытой архитектуры, предлагающей обширный набор служб, которые виртуальные организации могли бы объединять в различных комбинациях в соответствии со своими специфическими потребностями. Каркас открытой архитектуры сервисов Grid - Open Grid Sevice Architecture (OGSA-) — это совместный взгляд Globus и IBM на процесс слияния Web-сервисов и вычислений Grid. OGSA направлена на создание, ведение и применение наборов сервисов, поддерживаемых виртуальными организациями. Сервис определяется как объект в сети, который обеспечивает возможности вычислительных ресурсов, ресурсов памяти хранения, сетей, программ и баз данных. Это позволяет подходу Web-сервисов

21

удовлетворять

некоторым

требованиям

Grid.

Таковыми

являются,

например,

стандартные интерфейсы, определенные в OGSA: 

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



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



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



уведомления: динамические распределенные сервисы должны уметь асинхронно уведомлять друг друга относительно тех изменений, которые происходят с их состояниями;



управляемость: должны обеспечиваться действия по администрированию и контролю большого количества сервисов Grid;



простая среда пребывания (hosting) — набор ресурсов, находящийся в одном административном домене и поддерживающий первичные средства для обслуживания пользователя, например сервер приложений J2EE, система Microsoft.NET или кластер Linux. Больше всего архитектура OGSA повлияла на такие части Globus, как протокол

распределения и управления ресурсами Grid (GRAM), сервис метакаталогов (MDS-2), используемый для обнаружения информации, регистрации, моделирования данных и локального системного реестра, и инфраструктуру безопасности Grid (GSI), которая поддерживает условия одиночного входа, ограниченного делегирования и отображения мандатов. Ожидается, что будущие реализации инструментария Globus будут основаны на архитектуре OGSA. С этой целью в OGSA вводится концепция Grid-службы, опирающаяся на принципы и технологии, предложенные как сообществом Grid, так и сообществом Web-служб. Web-службы описывают программные компоненты, к которым можно получить доступ, методы для доступа к этим компонентам и методы, которые дают

22

пользователям и приложениям возможность выбирать подходящих провайдеров служб Web-службы не зависят от языков программирования и системного программного обеспечения. Консорциум W3C и другие организации устанавливают стандарты Webслужб, опробованные в рамках крупных отраслевых инициатив, таких как Sun ONE, Microsoft .Net и IBM Dynamic e-Business. Модель OGSA включает в себя три стандарта Web-служб: SOAP; WSDL; WS-Inspection. Цель

Web-служб

и

OGSA

заключается

в

том,

чтобы

обеспечить

интероперабельность между слабо связанными службами, вне зависимости от их реализации,

местонахождения

и

платформы.

OGSA

определяет

стандартные

механизмы для создания, именования и обнаружения постоянных и временных экземпляров Web-служб; обеспечивает прозрачность местонахождения и связывания по различным протоколам для экземпляров служб; поддерживает интеграцию с базовыми службами исходной платформы. С этой целью OGSA определяет набор расширений WSDL с помощью элементов расширения, допускаемых WSDL, и конвенции на использование Web-служб для Grid-вычислений. OGSA призвана предложить общую модель ресурсов, которая представляет собой абстрактное представление как физических ресурсов (таких как процессоры, процессы, диски и файловые системы), так и логических. Она предоставляет некоторые общие операции и поддерживает базовые

модели,

представляющие

ресурсы

как

экземпляры

служб.

В OGSA каждой службе соответствует некоторый интерфейс Grid-служб и поведение, определенное в терминах интерфейсов WSDL, а также конвенции и механизмы для создания и композиции сложных распределенных систем. Связанные службы могут поддерживать надежный вызов, аутентификацию, предоставление и делегирование прав. OGSA определяет Grid-службу как Web-службу, которая предоставляет набор корректно определенных интерфейсов и следует специфическим конвенциям. Интерфейсы касаются вопросов обнаружения, динамического создания службы, управления

жизненным

циклом,

уведомления,

управляемости.

Конвенции определяют именование и возможность модернизации. Конвенции позволяют пользователям Grid определять, когда меняется служба и когда эти изменения обратно совместимы по интерфейсу и семантике, но необязательно по сетевому протоколу. OGSA также определяет механизмы обновления «знаний» клиента

23

о службе, в том числе, о поддерживаемых ею операциях и сетевых протоколах, которые клиент

может

использовать

для

связи

с

этой

службой.

Также Grid-службы отвечают за авторизацию и контроль параллельной обработки. Базовый набор согласованных интерфейсов может использоваться для реализации всех Web-служб, способствуя созданию иерархических служб более высокого порядка, которые могут единообразно трактоваться на различных уровнях абстракции. В отличие от традиционных Web-служб, которые позволяют обнаруживать и инициировать только постоянные (persistent) службы, OGSA также предусматривает поддержку временных (transient) экземпляров служб, инициируемых и завершаемых динамически. Таким образом, Grid-служба — это потенциально временная служба на базе протоколов Grid, описанная посредством WSDL. Web-сервисы

обеспечивают

средства

интероперабельности,

являющиеся

ключевыми для вычислений на Grid, и поэтому OGSA является существенным элементом стратегии, которое адаптирует Web-сервисы к Grid и приближает потребность в приложениях Grid. Однако сами Web-сервисы не дают новых решений для главных проблем крупномасштабных распределенных систем, они даже не обеспечивают новых методов их разработки. Поэтому следует рассмотреть другие сервисно-ориентированные модели, основанные на агентах вычисления, которые являются существенным дополнением сервисно-ориентированной модели Grid. Парадигма агентных вычислений представляет перспективу программных систем в использовании объектов, которые обычно имеют следующие свойства, обозначаемые как слабые агенты : 

автономность — агенты функционируют без вмешательства извне и имеют некоторый контроль над своими действиями и внутренним состоянием;



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



реактивность — агенты воспринимают и реагируют на их среду;



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

среды, где их автономность дает возможность адаптироваться к изменяющимся

24

обстоятельствам. Это характерное свойство для нового поколения Grid. Один из методов для достижения этого свойства — переговоры между компонентами, и имеется существенный задел в исследованиях техники переговорных механизмов. В частности, методы, основанные на рыночных механизмах, имеют весомое значение для вычислительной экономики, которая возникает в приложениях Grid. Следовательно, можно рассматривать Grid как ряд взаимодействующих компонентов и информацию, которая передается в этих взаимодействиях. Последнюю можно отнести к нескольким категориям. Одна из них — информация контекста предметной области. Другие типы включают следующую информацию: о компонентах и их функциональных возможностях в пределах предметной области; о связях с компонентами; об общем потоке работ и конкретных потоках как частей общего. Компоненты должны быть связаны стандартным способом для обеспечения интероперабельности между ними на основе согласованных общих словарей. В языках взаимодействия агентов (ACL) эти вопросы рассматриваются на формальной основе. В частности,

Организация

по

вопросам

интеллектуальных

физических

агентов

(Foundation for Intelligent Physical Agents — FIPA) разрабатывает подходы к определению семантики для этой информации на основе интероперабельности, а также стандарты на программное обеспечение для разнородных и взаимодействующих агентов и агентно-ориентированных систем, включая обширные спецификации. В абстрактной архитектуре FIPA агенты взаимодействуют, обмениваясь сообщениями, которые

представляют

собой

речевые

акты,

закодированные

в

языке

их

взаимодействия; сервисы предоставляют услуги агентам (включая службы каталогов и передачи сообщений) и могут быть реализованы или как агенты, или как вызываемое программное обеспечение, к которому обращаются с использованием программного интерфейса (например, в Java, C++ или IDL). Таким образом, можно идентифицировать обмен информацией между агентами и

обращения

к

каталогам

как

форматы

информации,

распознаваемые

на

инфраструктурном уровне. Новой

парадигмой

обслуживания

инфраструктуры

Grid

и

разработки

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

25

Концепция ориентированной на службы утилиты знаний: 

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



базируется на существующих промышленных практиках, тенденциях и развивающихся технологиях;



обеспечивает правила и методы для объединения служб в экосистему, которая поддерживает сотрудничество и самоорганизацию;



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

объединении

концепций

Web-служб,

грид-технологий,

семантического

Web'а,

распределенных аналитических и самоорганизующихся систем, которые достаточно широко приняты международной промышленностью. Следующие три ключевых понятия отражают суть видения SOKU: 

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

чего

структура,

поведение

и

расположение

программного

обеспечения изменяются во время выполнения; 

знания – службы согласно видению SOKU сопровождаются описаниями их семантики

(знаниями

формирование и

о

службах),

чтобы

облегчить

автоматическое

усовершенствование функциональности; аспект знаний

усиливается акцентом на предоставлении пользователю служб высокого уровня; 

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

состоит в переходе от уже сложившегося уровневого представления к представлению в виде многомерной семантической сети (a multi-dimensional mesh of concepts), с использованием в каждом из измерений этой сети тех же самых механизмов на всей структуре традиционных уровней. Видение ориентировано, прежде всего, на раскрытие

26

концепций

именно

пользовательского

уровня,

и

возможности

использования

предоставляемых служб с той же степенью надѐжности, безопасности, легкости и повсеместности, какие присущи таким обычным утилитам, как электроснабжение или водоснабжение. Службы SOKU отличаются от служб типичной SOA (например, таких как Webслужбы), поскольку они описываются явно заданными знаниями, пригодными для восприятия компьютером, а также оперируют с подобными представлениями знаний: Службы SOKU сопровождаются семантическими описаниями (semantically described), то есть, аннотируются машинно-читаемыми метаданными, что облегчает их автоматическое использование. Это позволяет динамически составлять из них композиции, а также автоматически их адаптировать, конфигурировать, обеспечивая самоуправление и автономное поведение. Служба SOKU может состоять из набора служб, статически или динамически оркеструемых. Службы SOKU также работают с семантически описанным контентом и семантическими описаниями, то есть они обрабатывают знания (process knowledge) – при этом они могут содержать и использовать знания, потреблять или воспроизводить их. Это ведет к более настраиваемому набору служб, которые с помощью явных представлений соответствующих словарей, схем или онтологий конфигурируются применительно к рассматриваемой задаче. В

многоуровневой

архитектуре

уровни

промежуточного

программного

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

27

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

удовлетворять

вычислительные

потребности

через

локальные

вычислительные платформы и инфраструктуры ограниченного характера, т.е. персональные компьютеры и локальные сети, то сегодня ситуация меняется. Это связано,

среди

прочих

факторов,

с

увеличением

количества

пользователей

компьютеров и сетевых компонентов, появлением более быстрых и развитых аппаратных средств и все более сложного программного обеспечения. Следствием таких

изменений

стала

возможность

эффективного

использования

широко

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

28

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

29

Список использованных источников 1. «Эволюция архитектуры грид-компьютинга и модели адаптации грида .» Дж. Джозеф, М. Эрнест, К. Фелленштейн . Грид-компьютинг, журнал IBM, Том 43, N 4, 2004 , www.gridclub.ru. 2. «Перспективы грид: грид-компьютинг – следующее поколение распределѐнного компьютинга . В чѐм различие между грид-компьютингом и Р2Р, CORBA, кластеркомпьютингом и DCE.» Матт Хайнос, www.gridclub.ru. 3. «Grid-технологию в жизнь!» Елена Гореткина, PC Week (371)5`2003. 4. «Будущее европейских гридов:гриды и ориентированные на службы утилиты знаний Видение и направления исследований на период до 2010 года и далее . Третий Отчѐт Экспертной Группы по гридам следующего поколения », www.gridclub.ru. 5. «Введение в технологию Грид». Составлено А.К. Кирьяновым и Ю.Ф. Рябовым (Петербургский институт ядерной физики им. Б.П. Константинова РАН) . 6. «На пути к SOA» Наталья Дубова, CIO.RU 29/08/2005 №08. 7. «Архитектура

SOA

как

она

есть»,

Лори

Маквитти

http://www.ccc.ru/magazine/depot/06_02/read.html?0104.htm. 8. «SOA и адаптивность» http://feygin.elashkin.com/2006/12/soa_12.html. 9. «SOA: просто для большинства, сложно для меньшинства.» Сергей Кузнецов, Обзор ноябрьского 2007 г. номера журнала Computer (IEEE Computer Society, V. 40, No 11, ноябрь, 2007). 10. «Описание слона: многоликость информационных технологий в форме службы» Ян Фостер Стивен Тьюке, www.gridclub.ru. 11. «Конвергенция виртуализации, grid и SOA» Ричард Вирт, «Открытые системы», №3 2008 12. Сервис-ориентированная архитектура, http://www.iso.ru/journal/articles/374.html. 13. «Middleware:

модель

сервисов

распределенных

систем»,

http://citforum.gatchina.net/database/kbd97/3.shtml. 14. «Связующее программное обеспечение: часть решения или часть проблемы?» http://www.iso.ru/journal/articles/399.html.

30

15. «Интеграция

приложений

на

платформе

Oracle

Fusion

Middleware.»

http://www.topsbi.ru/default.asp?artID=1382. 16. «Технология Grid Computing». Олег Таковицкий. Статья была опубликована в журнале BYTE http://www.bytemag.ru. 17. «SOA для сетей», Александр Александров, «Открытые Системы» №3 2007 18. http://www.soa.org/ 19. http://ru.wikipedia.org/wiki/SOA 20. http://www.ibm.com/developerworks/ru/webservices/newto/ 21. http://www.infoq.com/news/2008/04/soa-generations 22. MATT WELSH , Running Linux, 3rd Edition. 23. http://msdn.microsoft.com/en-us/architecture/aa948857.aspx 24. http://www.bookrags.com/wiki/Service-oriented_architecture 25. http://webservices.xml.com/pub/a/ws/2003/09/30/soa.html 26. http://www.service-architecture.com/web-services/articles/serviceoriented_architecture_soa_definition.html 27. http://www.service-architecture.com/ 28. http://en.wikipedia.org/wiki/OASIS_SOA_Reference_Model 29. http://www.ibm.com/developerworks/ru/library/ar-soasec1/index.html 30. http://c-reaction.net/content/view/35/49/lang,ru/ 31. http://www.osp.ru/os/2004/06/184450/ 32. http://www.bytemag.ru/articles/detail.php?ID=6503 33. http://citforum.ncstu.ru/seminars/cbd2006/sonic/ 34. http://www.iso.ru/journal/articles/374.html 35. http://www-306.ibm.com/software/info/ecatalog/ru_RU/soa/launch/ 36. http://www.citforum.ru/internet/webservice/soa/ 37. http://www.ibm.com/ru/services/gts/its/solutions/soa_infrastructure/ 38. http://www.citcity.ru/11532/ 39. http://www.microsoft.com/technet/prodtechnol/sql/2005/sqlsoda.mspx 40. http://www.grid.org.il/?CategoryID=242 41. http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s01.html 42. http://grid.jinr.ru/materials/education/grid_computing-technology.htm

31

43. http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s02.html 44. http://www.cmcons.com/articles/soa_i_web-servisy/page-4/ 45. http://java.sun.com/developer/technicalArticles/WebServices/soa/ 46. http://www.whatissoa.com/p12.asp 47. http://www.digerateur.com/articles/whatIsAService.jsp 48. http://www.inln.ru/vng/Publ/Soa.aspx 49. http://www.bytemag.ru/articles/detail.php?ID=8725 50. http://www.interface.ru/fset.asp?Url=/borland/vvod.htm 51. http://www.ibm.com/developerworks/ru/library/ws-uddisecure/index.html 52. http://www.osp.ru/os/2008/02/4923475/ 53. http://miedlar.com/learning/jsoa/Architecture.aspx 54. http://pda.erpnews.ru/doc2720.html 55. http://www.globus.org/alliance/publications/papers/ogsa.pdf 56. http://www.gridforum.org/documents/GWD-I-E/GFD-I.030.pdf 57. http://www.gridforum.org/documents/GWD-I-E/GFD-I.029v2.pdf

32