По истории информатики на тему (стр. 2 из 4)
Основными тактическими преимуществами cервис-ориентированной архитектуры являются:
· Более простые разработка и внедрение приложений.
· Использование текущих инвестиций.
· Уменьшение риска, связанного с внедрением проектов в области автоматизацией услуг и процессов.
· Возможность непрерывного улучшения предоставляемой услуги.
· Сокращение числа обращений за технической поддержкой.
· Повышение показателя возврата инвестиций ROI (англ., ROI - Return Of Investments).
Таким образом сервис-ориентированная архитектура – это не только программная архитектура, но и стратегия бизнеса, которая помогает компании многократно использовать существующие технологии в соответствии с текущими бизнес-целями, улучшая, в результате, свою эффективность, повышая оперативность и сокращая затраты.
При правильном внедрении 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-сервис – это программная система, идентифицируемая строкой URI, чей общедоступный интерфейс определен на языке XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов.
Бурбек первым предложил не только название, но и трехзвенную схему, ставшую в последующем классикой сервис-ориентированной архитектуры. Схема эта состоит из поставщика услуг, брокера-посредника и получателя услуг (рис. 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 имеют существенные ограничения по поддержке действительно распределенных систем, их протоколы взаимодействия объектов слишком сложны для организации производительной связи сервисов, реализованных на разных машинах.