Geum.ru

Реферат По истории информатики на тему " История развития сервис-ориентированной архитектуры."

Вид материалаРеферат
Подобный материал:

Санкт Петербургский государственный университет информационных технологий механики и оптики


Реферат

По истории информатики на тему

“История развития сервис-ориентированной архитектуры.”



Аспирант:
Войтюк Т. Е.

Кафедра:

ИПМ

Специальность:

05.13.12



Санкт-Петербург

2009 г.

Оглавление


Введение 3

1. Определение и сущность сервис-ориентированной архитектуры. 5

2. История развития SOA. 9

3. Основные причины возникновения SOA. 14

4. Перспективы развития SOA. 16

Заключение 17

Список литературы 18


Введение


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

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

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

1. Определение и сущность сервис-ориентированной архитектуры.

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

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

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

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

Сервис-ориентированная архитектура основана на следующих базовых принципах, позволяющих снять наиболее острые проблемы интеграции приложений:
  • Слабая связанность (англ., Loosely coupled). С точки зрения реализации сервисы в SOA независимы друг от друга: они выполняют определенные действия по запросам, полученным от других сервисов, и возвращают результаты. Все детали этого выполнения полностью скрыты: в концепции SOA сервисы — это «черные ящики». Отсюда следует, что изменения в реализации сервиса никак не повлияют на прикладной компонент, который этот сервис использует, и наоборот. Слабая связанность обеспечивает простую и быструю адаптацию системы к изменениям в структуре и принципах реализации сервисов.
  • «Крупнозернистая» (англ., coarse-grained) структура сервисов. Сервисы в SOA представляют собой модули бизнес-логики достаточно высокого уровня, благодаря чему взаимодействие между ними сводится к ограниченному числу сообщений по содержанию бизнес-логики вместо множества низкоуровневых вызовов, учитывающих детали реализации сервисов. Такой подход снижает нагрузку на сеть и способствует более высокой производительности системы. На практике переход к сервис-ориентированной архитектуре может начинаться с представления в виде сервисов бизнес- или системных функций низкого уровня, которые затем благодаря еще одному свойству сервисов — модульности будут компоноваться в высокоуровневые сервисы, реализующие определенные этапы бизнес-процесса или весь процесс целиком. Важно, что с точки зрения архитектуры сервис, независимо от внутренней структуры и языка реализации, выглядит как единое целое.

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

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

Основная стратегическая ценность cервис-ориентированной архитектуры состоит в:
  • Сокращении времени реализации проектов, или "времени выхода на рынок".
  • Повышении производительности.
  • Более быстрой и менее дорогой интеграции приложений и интеграция B2B (англ., B2B - business-to-business).

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

Основными тактическими преимуществами cервис-ориентированной архитектуры являются:
  • Более простые разработка и внедрение приложений.
  • Использование текущих инвестиций.
  • Уменьшение риска, связанного с внедрением проектов в области автоматизацией услуг и процессов.
  • Возможность непрерывного улучшения предоставляемой услуги.
  • Сокращение числа обращений за технической поддержкой.
  • Повышение показателя возврата инвестиций ROI (англ., ROI - Return Of Investments).

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

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

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

2. История развития SOA.


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

Изменяющиеся потребности бизнеса и, в соответствии с ним, развивающаяся ИТ отрасль, способствуют появлению новых технологий. Появление сервис-ориентированной архитектуры не стало исключением.

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

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

В 90-х гг. началось повышение интереса заказчиков к комплексным ERP-решениям (англ., ERP - Enterprise Resource Planning), рассматривавшимся как альтернатива огромного количества бизнес-приложений, которые появились в результате фрагментарной автоматизации подразделений, и которые теперь нужно было увязывать в единую корпоративную систему. Однако уже в начале нынешнего десятилетия стало понятно, что потенциал подобных монолитных программных комплексов с точки зрения бизнеса в значительной степени исчерпан. Тому было несколько причин. Во-первых, такая схема затрудняла развитие и модификацию ИТ-систем в условиях быстрого изменения бизнес -потребностей заказчиков. Во-вторых, задачи автоматизации предприятия быстро выходили за пределы круга задач ERP, появлялась потребность в функциях CRM (англ., Customer Relationship Management - системы управления взаимосвязями с клиентами и партнерами), BI (англ., business intelligence - система анализа деловых данных), ECM (англ., enterprise content management - управление информационными ресурсами предприятия). Создать единое комплексное решение, обладающее всеми нужными функциями, стало уже фактически неразрешимой технической проблемой. В результате маятник ИТ-прогресса начал очередное движение в сторону композитных систем.

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

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



Рис. 1. Эволюция парадигм программирования.


Развитие идеи сервис-ориентированной архитектуры начинается ещё в 70-х годах XX века, тогда, американский учёный в области теории вычислительных систем - Алан Кэй, принялся развивать объектные технологии, используя объекты в качестве переносчиков семантики, а не простых данных. Его последователем, разработчиком среды для объектно-ориентированного языка Smalltalk на IBM PC был Стив Бурбек. Он развивал объектные технологии в собственном направлении.

Конец XX века охарактеризовался массовым увлечением так называемым «электронным бизнесом», взаимодействием между бизнесами (business-to-business, B2B) и другими возможностями, открывшимися в связи с ростом популярности глобальной сети. Развивая эту идею, Бурбек высказал предположение, что для гибкой организации взаимных услуг между отдельными бизнесами может быть выстроена архитектура, названная им Service-Oriented Architecture (SOA), основанная на Web-сервисах. Web-сервис – это программная система, идентифицируемая строкой ссылка скрыта, чей общедоступный ссылка скрыта определен на языке ссылка скрыта. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на ссылка скрыта, и передаваемых с помощью ссылка скрыта.

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



Рис. 2. Архитектура, ориентированная на сервисы.


Но основная ошибка Бурбека заключалась в том, что он представлял, как и многие ИТ-специалисты, глобальную информационную систему с распространяющимися на все пространство Internet репозиториями сервисов и подобными гигантскими механизмами. Не смотря на абсурдность этой идеи, на сегодняшний день, в рамках работы над сервис-ориентированной архитектурой в 2007 г. Бурбек опубликовал работу «Сложность и эволюция компьютерных систем, биологические принципы для управления эволюционирующими системами» (Complexity and the Evolution of Computing, Biological Principles for Managing Evolving Systems). В работе он проводит аналогию с переходом от одноклеточных организмов к многоклеточным, случившимся в природе сотни миллионов лет назад, не только в связи с SOA, но и в связи с появлением многоядерных процессоров, кластеров из лезвий, тем самым показывая, что сервис-ориентированная архитектура — отнюдь не случайность, а вполне закономерный этап процесса эволюции.

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

Основным перспективные направлением 90-х годов, стало использование распределенных объектных технологий, таких как CORBA (англ., Common Object Request Broker Architecture - общая архитектура брокера/посредника запросов к объектам), DCOM (англ., Microsoft Distributed Component Object Model - объектная модель распределённых компонент) и Java RMI (англ., Remote Method Invocation). Внешне они действительно похожи на SOA, но более детальный анализ показывает, что в этих ранних подходах к сервисной ориентации программных систем не выполняются или выполняются с определенными ограничениями базовые принципы сервис-ориентированной архитектуры. Так, в CORBA и DCOM взаимодействующие объекты являются сильносвязанными, и внесение изменений в реализацию программных компонентов, предоставляющих и использующих определенный сервис, должны быть скоординированы между собой. Запросы к объектам (сервисам) в этих архитектурах, как правило, содержат небольшой объем информации, учитывающей специфику реализации сервисов («мелкозернистая» — англ., fine-grained — структура сервисов), и потому порождают значительный сетевой трафик между поставщиком и потребителем сервиса. В DCOM взаимодействие программных компонентов основано на закрытых интерфейсах Microsoft. CORBA не принадлежит частной компании, эта архитектура — плод усилий международного консорциума OMG (англ., Object Management Group - группа по управлению объектами консорциум по технологии манипулирования объектами (Windows, сети), включающий 120 компаний, в том числе многих распространителей продукции под Unix), который ставил своей целью создание универсальной платформы интеграции разнородных программных компонентов на базе стандартного языка описания интерфейсов. Однако реализации спецификаций CORBA сильно варьируются в продуктах разных производителей, что ограничивает интероперабельность систем на базе CORBA. Кроме того, и CORBA, и DCOM имеют существенные ограничения по поддержке действительно распределенных систем, их протоколы взаимодействия объектов слишком сложны для организации производительной связи сервисов, реализованных на разных машинах.

С появлением XML (англ., Extensible Markup Language - расширяемый язык разметки) открылся путь к созданию интерфейсов, нейтральных к платформе реализации. Основанный на XML язык описания Web-сервисов WSDL (англ., Web Services Description Language) и использование XML для обмена сообщениями между сервисами обеспечивают тот универсальный механизм взаимодействия разнородных компонентов, без которого невозможна сервис-ориентированная архитектура. Стандартный протокол SOAP обеспечивает простую связь между сервисами по сети. Реестр сервисов, построенный по стандарту UDDI, позволяет компонентам системы получить информацию о доступных сервисах. Таким образом, Web-сервисы обеспечивают базовые технологии для создания приложений по принципам архитектуры SOA. Эти технологии будут эволюционировать и в перспективе могут оказаться вытесненными другими, более прогрессивными решениями, что не изменит общей сущности SOA, хотя, возможно, внесет коррективы в подходы к реализации этой архитектуры.

3. Основные причины возникновения SOA.


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

Неудовлетворенный спрос потребителей стал основной причиной появления сервис - ориентированной архитектуры и ускорил её развитие. По мнению многих аналитиков SOA, - это закономерный этап развития веб-сервисов, логическое продолжение идей. Даже более того SOA - это закономерный этап развития корпоративных систем вообще. Развитие в сторону сервис - ориентированной архитектуры и отход от простых Web-сервисов показывают, что для устранения сложности систем требуется что-то более существенное. Развитие интернета принесло нам стандарты для Web-сервисов и XML. Теперь новые инструменты позволят реализовать накопленный за многие годы опыт.

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

Большинство специалистов считают, что основная ценность SOA состоит в способности связывать и интегрировать корпоративные системы. Однако это довольно узкое представление. Сервис-ориентированная архитектуры обретает большую значимость, когда интеграцию рассматривают на дальнюю перспективу и учитывают повышение эффективности за счет связи с унаследованным программным обеспечением, тем самым обеспечивая взаимодействие всех частей информационной системы. Хотя большинство бизнес-процессов связано только со специальными корпоративными системами, в действительности для выполнения ежедневных операций, которые являются частью бизнес-процессов, мы используем большинство программных артефактов. Любая компания имеет дело с электронными таблицами, почтой, программами-календарями, ERP, CRM и многими другими системами, у каждой из которых есть как минимум свой программный интерфейс. Трудность заключается в том, что процессы, присущие предприятию и традиционному программному обеспечению автоматизации, очень разобщены, поэтому стоит больших усилий представить их как часть общего бизнес-процесса. Сервис-ориентированная архитектура показывает, как можно гибко и логически последовательно связать эти программные артефакты. Цель сервис-ориентированной архитектуры - создать более производительную программную платформу, которая свяжет вместе отдельные функции и потоки, повысив производительность и гибкость.

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

4. Перспективы развития SOA.


Сервис-ориентированная архитектура –перспективная технология. Сотрудники Gartner уверенно заявили о том, что в 2009 году преобладающей практикой проектирования и разработки компьютерных программ станет именно сервис-ориентированная архитектура (с вероятностью 0,7). Аналитики компании ZapThink, специализирующейся на вопросах развития и применения сервис-ориентированно1 архитектуры, выяснили, что в 2005 году компании переходили от пилотных проектов к реальным внедрениям в рамках своих отделов. Так, целый ряд организаций из различных сегментов экономики, включая финансовые услуги, страхование, аэрокосмическую отрасль, здравоохранение, фармацевтику, розничную торговлю, государственный сектор и промышленность, "подняли" Web-сервисы до уровня SOA. В настоящий момент эти организации расширяют рамки этих проектов - они внедряют их не только на уровне различных отделов и подразделений, но и во всей компании.

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

Заключение


Каждый предшествующий век начинался с очередной технической революции: XIX век — с появления паровых машин, XX-й — с электричества и двигателей внутреннего сгорания. Лет через пятьдесят потомки скажут с какой революции начался XXI век. Пока же можно предположить, что среди претендентов на первенство есть еще не нашедшие своего точного названия системные изменения в компьютинге. Возможно, в этом ряду могут оказаться и архитектуры, ориентированные на сервис.

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

Хотя идея сервис-ориентированной архитектуры не нова, однако она отличается от предшественников тем, что открывает новую эру "синтезируемых" вычислений. И синтез основан на роли XML как общего звена во всех областях вычислений, включая обмен сообщениями, хранение данных и новое поколение компьютерных языков и спецификаций.

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

Список литературы


  1. М. Македонский. Сервисно-ориентированная архитектура (SOA). Опрос экспертов. a.ru/publications_164.htm.
  2. А. Колесов. Многие современные ИС уже являются SOA-совместимыми. k.ru/themes/detail.php?ID=110761.
  3. Сервисно-ориентированная архитектура. ссылка скрыта.
  4. Д. Гулько. Единая система НСИ – основа сервисно-ориентированной архитектуры. ссылка скрыта.
  5. Лори Маквитти. Архитектура SOA как она есть. ссылка скрыта.
  6. ссылка скрыта. Архитектуры, ориентированные на сервисы. ссылка скрыта.
  7. К. Фильчагин. SOA-архитектура – современная вершина Эволюции. ссылка скрыта.
  8. А. Колесов. SOA: переход от теории к практике ссылка скрыта.
  9. Л. Черняк. SOA — шаг за горизонт. ссылка скрыта.
  10. Ash Parikh, Murty Gurajada. SOA в реальности. ссылка скрыта.
  11. С. Борзов 11 мифов SOA. ссылка скрыта.
  12. Jon Brodkin. 6 острых вопросов к SOA. ссылка скрыта.
  13. С. БОРЗОВ. SOA 2008. u/doc2980.php.