Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок. SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.
SOA - это всего лишь иной стиль построения современных корпоративных систем. Он ориентируется на сервисы, характеризуется распределенной архитектурой и слабосвязанными интерфейсами. Сервис в данном случае - это не что иное, как единица работ, выполняемая сервис-провайдером для обеспечения желаемого результата потребителю сервиса. Именно сервис, а не объект, как в ООП, является повторно используемым, и при этом он не зависит от технологий, языковых сред и других ресурсов. Интегрирующую роль между сервис-провайдером и потребителем берут на себя программные агенты. Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях.
Сами Web-сервисы не предполагают какого-либо архитектурного решения, в то время как именно архитектурой определяется стиль процессов взаимодействия. SOA не предписывает жесткой вертикальной методологии проектирования, внедрения или управления ИТ-инфраструктурой. Вместо этого, SOA ограничивается лишь рядом принципов, характеризующих каждый из этих процессов; поэтому ее иногда называют не архитектурой, а архитектурным стилем.
Отметим некоторые из этих принципов.
Распределенное проектирование. Решения относительно внутренних особенностей информационных систем принимаются различными группами людей, имеющими собственные организационные, политические и экономические мотивы.
Постоянство изменений. Отдельные участки архитектуры могут претерпевать изменения в любой момент времени.
Последовательное совершенствование. Локальное улучшение компонентов архитектуры должно приводить к совершенствованию всей архитектуры в целом - к росту суммарной полезности компонентов того же уровня, что и изменяемый, равно как и компонентов более низкого и более высокого уровня.
Рекурсивность. Однотипные решения имеют место на различных уровнях архитектуры.
Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александр показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.
Общая схема.
В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 2). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом). Отсутствие любого из этих элементов недопустимо, а добавление других составляющих на практике не только возможно, но и неизбежно. Среди таких элементов могут быть всевозможные программные средства промежуточного слоя, контролирующие порядок и контекст взаимодействия, осуществляющие мониторинг и управление сервисами, а также управление метаданными и другие вспомогательные процессы.
Рис. 2.
Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют XML-схеме.
Модель SOA не зависит от технологий, использующихся для реализации SOA, а основным методологически значимым ее компонентом является реестр сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и потребителя сервисов он выполняет функции посредника. Провайдер размещает информацию о своих сервисах в реестре, что дает возможность потребителю в любой момент найти необходимый ему сервис. На первый взгляд, кажется, что в этом нет ничего особенного, однако за этим процессом общения скрывается основное качество SOA -- слабая связанность. Благодаря этому свойству, сервисы обретают мобильность, способность перемещаться с одного сервера на другой, не требуя согласования и координации со всеми потребителями. Естественно, что потребители сервисов в ряде случаев не способны и не должны принимать во внимание регулярное перераспределение ресурсов, обеспечивающих функционирование сервисов.
Позднее связывание также позволяет отложить момент конечной сборки связей до времени исполнения, а не времени разработки программы, что характерно для традиционных монолитных систем. Можно также во время исполнения менять параметры связи (такие как адрес, протокол и канал взаимодействия). Это придает несколько измерений гибкости самой связке между провайдером и потребителем сервиса -- соответственно вызываемым и осуществляющим вызов объектами. В частности, провайдер и потребитель могут исполняться на сколь угодно физически удаленных инфраструктурах. Каждая из систем может иметь собственные параметры жизненного цикла, а любые изменения в них, не затрагивающие интерфейс сервиса, не требуют остановки ни одной из них.
В SOA сервисы рассматриваются как автономные объекты, управление которыми не централизовано. Это позволяет взаимодействующим посредством сервисов информационным системам развиваться в соответствии с потребностями бизнеса, которые потребителям сервисов, как правило, не только не известны, но и не интересны. Однако это было бы невозможно, если бы интерфейс сервиса не был прочно закреплен обоюдным соглашением провайдера и потребителя сервиса. Одной из отличительных черт SOA является наличие контрактов, описывающих интерфейсы сервисов. Такой контракт представляет собой документ, специфицирующий ожидания сервиса по отношению к его потребителям и наоборот. Контракты Web-сервисов описываются WSDL-документом, в нотации XML определяющим, как потребители должны обращаться к сервису. Использование XML на этом этапе имеет принципиальное значение, позволяя и провайдеру, и потребителю сервиса не зависеть от определенной платформы.
Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них -- отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных. Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.
Service Oriented Architecture (SOA) - это новая парадигма проектирования распределенных интегрированных систем. Согласно SOA любые части информационных систем имеющие функциональность рассматриваются как службы (service providers, провайдеры служб), которые предоставляют свою функциональность другим частям системы посредством вызовов их функций. Службы являются компонентами, которые могут быть найдены и вызваны через локальную сеть или Internet. При этом различные службы могут организовываться (orchestrate) для совместного выполнения определенной задачи. SOA обеспечивает концептуальные архитектурные шаблоны и платформы для таких систем. Обычно архитектура таких систем и потоки данных в них близки к структуре бизнес-подразделений, использующих их, и взаимодействий между ними. В некоторой степени происходит соединение информационных технологий и бизнес-процессов на концептуальном уровне. Такое слияние положительно влияет на понимание информационных систем представителями бизнеса (концепция службы более наглядна чем термины "репликация", или "удаленный вызов процедуры"), и на понимание бизнес-процессов разработчиками системы. В качестве платформы для SOA-приложений обычно используются web-службы. Однако, не все информационные системы, построенные на основе web-служб, соответствуют SOA, и SOA не обязательно должна базироваться на технологии web-служб. Концепция SOA впервые была описана в 1996 году, но только в последние годы на волне интереса к web-службам стала широко известной. К этой волне популярности приложило руку и Microsoft - в 1999 году Steve Ballmer озвучил концепцию "software as service", получившую свое воплощение в технологии.NET и web-службах. Поддержка web-служб встраивается во многие продукты Microsoft - BizTalk Server, MapPoint Server, SQL Server 2005 (Yukon), Office 2003.
Don Box - один из архитекторов новой инфраструктуры Microsoft для межпрограммного обмена сообщениями Indigo выделил 4 основных принципа SOA:
Явные границы служб . Для каждой части системы, для всех подсистем и компонент из которой она состоит, можно однозначно сказать где она находится - вне службы или внутри определенной службы. Это связанно с тем, что системы, построенные по SOA, состоят из служб, которые часто разделены большими расстояниями, работающими на разных платформах и имеющими различные средства обеспечения безопасности. Обмен сообщениями между различными частями таких систем имеет существенные накладные расходы. Поэтому, SOА основано на модели явного обмена сообщениями, а не на модели неявного вызова методов (как в DCOM). Явные границы служб обеспечивают автономность служб и независимость от реализации.
Автономность служб . Каждая служба работает в собственной программной среде, на собственной ОС, реализована на определенном языке программирования и от этих факторов не зависит работа других частей системы, которые использую службу. Она ведет себя как независимый объект, обладающей собственным поведением, способный на взаимодействия с другими независимыми объектами. Поэтому реализация любой службы или же ее расположение в системе может изменена без нарушения общей работы системы. В систему можно добавлять новые службы или удалять существующие - это тоже не должно сказываться на работе системы. Автономность служб подразумевает что любой вызов службы может окончится неудачей, поэтому любой вызов службы должен обеспечиваться корректной обработкой ошибок. Открытая архитектура SOA предоставляет более широкие возможности для злоумышленников по взлому систем. Согласно принципу автономности службы сами должны заботиться об аутентификации, авторизации и безопасности. Поэтому особое внимание при проектировании служб должно уделяться безопасности.
Службы описывают свой контракт и схемы сообщений, но не реализацию. Клиенты службы знают ее контракт (сигнатуры методов и их метаданные) и схемы данных, которые описывают сообщения службы и используемые данные. Информация о том, как реализована служба, ее клиентам не доступна и не нужна. Так же формальное описание контракта и схемы с помощью политик (policy) позволяет службам осуществлять проверку входящих сообщений. Как и в случае использования компонент (например, COM), так же имеющих контракт, особую значимость для работоспособности системы в целом имеет устойчивать контрактов.
Совместимость служб основана на политиках (policy). Применение технологий, таких как WS-Policy, предоставляют декларативные и программные способы описания политик. Политики применяются как для служб, так и для клиентских приложений. Примером политики может быть требование на шифрование обмениваемых данных.
SOA является очередным этапом в архитектуры программного обеспечения. Решая вопросы повышения сложности разрабатываемых систем, обеспечения большей гибкости решений, работы в гетерогенных средах, снижения расходов на разработку и сопровождения, лучшего соответствия потребностям бизнеса за 30 лет произошел переход от монолитных приложений, работающих на мейнфреймах, до распределенных слабосвязанных систем с работающих на стандартизированных кросплатформенных протоколах.
Этапы развития архитектуры программного обеспечения
Объектно-ориентированное программирование играет важную роль при разработке SO систем для разработки самих служб и их клиентов, но не систем целиком. Чем же не устраивает объектно-ориентированная архитектура при разработке больших распределенных информационных систем? Ее существенными ограничениями являются
низкая абстрактность моделей, получаемых в ходе объектно-ориентированного анализа и проектирования. При проектировании больших систем мышление в рамках объектов и связей между ними из-за большой детализации равносильно попытке спроектировать компьютер, оперируя только на уровне транзисторов и диодов
ограничения, накладываемые платформами и компиляторами, что затрудняет разработку приложений для гетерогенных сред
отсутствие встроенных средств безопасности
Архитектура, основанная на компонентах, (CORBA, COM/DCOM) сняло часть проблем - снизило степень детализации и улучшило ситуацию с повторным использованием компонент. Компонентные технологии обеспечивали языки описания интерфейсов (к примеру, IDL) и средства для локального и удаленного вызова компонент.
SOA позволяет проектировать и создавать приложения, предоставляющие другим приложениям удаленно вызывать их методы через опубликованные интерфейсы, и возможность найти эти службы и описания интерфейсов. На схемы на примере web-служб видно 3 основные роли в SOA - службы (service providers), клиенты служб (service consumers) и брокеры (brokers). Доступ к службам происходит через сеть по стандартным протоколам. Сами службы описываются на стандартном языке (контракт службы) и публикуют эту информацию при помощи брокера. Службы разделяют свой интерфейс и его реализацию. Для вызова службы клиентскому приложению нужно только описание интерфейса службы - информация же о реализации службы не нужна клиентам. Реализация службы может меняться, не затрагивая клиентов и без необходимости предоставлять клиентам новую версию описания службы - в этом и проявляется низкая связанность частей системы (loose coupling). Другим преимуществом разделения интерфейса и реализации является возможность выбора клиентом службы из нескольких служб с одинаковым интерфейсом путем простого указания адреса нужной службы. В этом скрыта возможность для расширения и масштабирования системы после ее создания. В систему можно добавлять новые службы или новых клиентов служб не нарушая уже существующую функциональность. Причем для добавления добавления новой функциональности к системе не нужно иметь доступ к ее исходному коду. Для обеспечения такой независимости от реализации при использовании web-служб нужно избегать использования типов данных, привязанных к определенной технологии (например, вместо типизированных DataSet платформы Microsoft .NET использовать сущностные классы или специально созданные объекты переноса данных (DTO)) и расширений WS-*, пока имеющих различия реализаций на разных платформах.
Брокеры хранят информацию о службах и предоставляют эту информацию клиентам.
Web-службы являются наилучшей технологией, на котором основывается SOA. Поиск web-служб происходит в UDDI-каталоге, интерфейс службы описан на WSDL, а вызов происходит по протоколу SOAP. Так как web-службы базируются на стандартизированных технологиях, они работают в кросс-плафторменных средах и не зависят от языка реализации.
Характеристики service oriented architecture. Информационные системы, построенные согласно SOA, обладают следующими характеристиками:
основанность на индустриальных стандартах. SOA использует технологии, разработанные совместно Microsoft, IBM, SUN, BEA, Oracle, W3C. Это освобождает от привязки к конкретной платформе или поставщику программных продуктов. Различные части системы могут быть разработаны на различных языках программирования и работать на разных платформах
низкая связанность (loose coupling) частей системы. Клиенты в SOA системах могут разрабатываться в полной независимости от служб, используя только их опубликованный интерфейс. Из-за разделения интерфейса и реализации служб клиентские приложения подключаются к службам с помощью позднего связывания (late binding). Низкая связанность обеспечивает лучшую способность систем к их расширяемости: изменения в функциональности в службе не должно затрагивать клиентов, а при добавлении новых типов данных средства разработки берут на себя часть работы. Низкая связанность также способствует инкрементному и итеративному подходу к разработки ПО, из-за отсутствия трудностей реализации функцинольности службы за несколько итераций
повторная используемость служб. Службы намного легче использовать повторно в реальных условиях и при решении реальных бизнес-задач чем классы или компоненты. Легкость использования обеспечивается возможностью поиска и доступностью службы, не имеющая пространственные ограничения, посредством вызова через сеть
синхронные и асинхронные вызовы службы. Службы поддерживают как синхронные вызовы методов службы, когда клиент получаем от службы ответ, так и асинхронные вызовы, способные пересылать большие объемы информации и увеличивающие масштабируемость системы.
Типы служб. Службы на основе их функциональности можно условно поделить на пять типов:
службы доступа к данным , предоставляющие чтение и изменение данных (CRUD-функции). Они скрывают реализацию доступа к реальным источникам данных и предоставляют единый унифицированный интерфейс для доступа к данным вне зависимости от количества и вида используемых источников данных. Для обмена данными могут использоваться специально созданные сущностные объекты, XML данные или же объекты, инкапсулирующие таблицы БД (например, объекты DataSet платформы.NET). Этот вид служб SOA самый легкий в реализации и чаще всего используется в приложениях
службы бизнес-логики содержат функциональность, используемую для выполнения различных бизнес-операций (например, оформление заявки на слад или формирование отчета по уровню продаж). В ходе выполнения бизнес-операций обычно вызываются методы других служб (к примеру, служб доступа к данным для получения списка проданных товаров за последнюю неделю)
компоненты внешних приложений , вызываемые через их собственные интерфейсы (например, COM или DCOM). Примером такого приложения может быть CRM система, хранящая данные о покупателях и предоставляющая доступ к этим данным через COM
низкоуровневые вспомогательные службы отвечают за аутентификацию и авторизацию, мониторинг, поиск служб, регистрацию ошибок, вспомогательные функции, используемые в других службах. Часто их называют общие службы (common services) или службы инфраструктуры предприятия (interprise infrastructure services)
составные службы , делегирующие работу остальным типам служб и координирующие их действия. Они интегрируют остальные службы системы и выполняют контроль за транзакциями и преобразование потока данных от одних служб к другим путем конвертации в нужные форматы
Степень детализации служб (service granularity).
Детализация служб относится к масштабу функциональности, предоставляемой службой. На основе функциональности по количеству данных, получаемых и отправляемых службой, можно разделить их на службы с мелкой детализацией (fine-grained), грубой детализацией (coarse-grained) и композитные (composite).
Службы с мелкой детализацией осуществляют прием и отсылку данных небольшими порциями информации и и на каждую их функцию приходится небольшое количество функциональность. Дополнительно может возникнуть необхоимость сохранения с состояния службы между ее вызовами.
При грубой детализации происходит обмен большими порциями информации и каждая функция реализуют б о льшую функциональность. При этом передаваемые данных часто имеют составную структуру и используются специально созданные объекты переноса данных (data transfer objects).
Функции с мелкой детализацией обычно вызываются не реальными приложениями, а другими службами - композитными или с грубой детализацией, использующими высокосоростные сетевые соединения. При вызове служб с мелкой детализацией напрямую клиентскими приложениями из-за большого количества обмениваемых сообщений (особенно при низкой скоростью соединения) суммарное время вызова функций возрастает из-за накладных расходов.
Композитные службы используют для своей работы службы с мелкой и грубой детализацией, делегируя им реальную работу и осуществляя контролирующую функцию и сбор информации.
Microsoft Indigo.
Новая версия операционной системы Windows "Longhorn" будет включать в себя инфраструктуру для разработки распределенных систем под кодовым названием "Indigo", основанная на.NET. Indigo предоставляет общую программную модель для использования web-служб, .NET remoting, System.Messaging и.NET Enterprise Services. Indigo входит в состав WinFX (новой программной моделью Windows) и будет поставлятся так же и для операционных систем Windows XP и Windows 2003. Основными подсистемами Indigo являются сервисная модель, коннектор, хостинговое окружение и службы.
Архитектура Indigo
Сервисная модель
Indigo отвечает за связывание кода, отвечающего за обработку сообщений, и приходящих сообщений. На нее возложены функции поддержки транзакций, обеспечения безопасности передачи сообщений и их гарантированную доставку. Для упрощения разработки активно применяется декларативный подход.
Коннектор
обеспечивает соединение между службами, основанное на SOAP и метаданных служб. Скрывая детали реализации и оперируя такими понятиями как порт, канал и сообщение он позволяет создавать высокопроизводительные приложения, независящие от транспортных протоколов, обеспечивающие безопасность, регулирование нагрузки и надежность передачи сообщений и способных настраиваться на различные конфигурации сетей (SSL, прокси-серверы, файрволы и пр.). Для этого в коннектор входит кодировщик, конвертирующий сообщения в данные, передаваемые по конкретному транспортному протоколу, и обратно. Для гарантированной доставки сообщений можно применять одну из двух моделей гарантированной доставки: экспресс, при которой в памяти содержится буфер сообщений, доставка которых еще не подтверждена, и надежный, при котором этот буфер находится на жестком диске.
Хостинговое окружение.
Сервисная модель Indigo и коннектор могут быть загружены в любой домен приложения. Окружение хостнига было разработано для использования Indigo в максимально большом количестве систем хостинга (dllhost.exe, svchost.exe, IIS и пр.).
Системные службы и службы сообщений.
Для обеспечения функциональности служб Indigo использует специальные службы. В качестве пример системных служб можно привести службы для обеспечения транзакций. Службы сообщений обеспечивают расширенную функциональность для очередей сообщений и поддержку событий.
Как мы видим все подсистемы можно поделить на 2 уровня - на высокоуровневые слой, имеющий удобный для разработки приложений интерфейс, и низкоуровневый слой, обеспечивающий б о льшую производительность и контроль над тонкостями реализации.
Indigo позволяет создавать службы двух видов: web-службы и RemoteObject службы. Web-службы в Indigo представляют собой традиционные asmx службы ASP.NET, соответствующие SOAP 1.2 и дополненные расширенными возможностями: поддержкой распределенных транзакций, гарантированной доставкой сообщений, поддержкой web-serivce farms для увеличения масштабируемости и возможностью обмена сообщениями между службами и клиентами в обоих направлениях.
Службы RemoteObject являются улучшенной версией.NET remoting, позволяющей создавать экземпляры удаленных объектов или удаленно вызывать их методы. Обновления и улучшения коснулись улучшенной поддержки SOAP, импорта и экспорта метаданных, аутентификации, шифрования, распределенных транзакций и автоматической активации.
Сервис-ориентированная архитектура (service-oriented architecture, SOA) придумана в конце 1980-х. Она берёт своё начало в идеях, изложенных в CORBA, DCOM, DCE и других документах. О SOA написано много, есть несколько её реализаций. Но, по сути, SOA можно свести к нескольким идеям, причём архитектура не диктует способы их реализации:
SOA - это набор архитектурных принципов, не зависящих от технологий и продуктов, совсем как полиморфизм или инкапсуляция.
В этой статье я рассмотрю следующие паттерны, относящиеся к SOA:
В 1980-х началось активное использование корпоративных сетей и клиент-серверной архитектуры. Возникла потребность в стандартном способе взаимодействия приложений, которые созданы с использованием разных технологий, исполняются на разных компьютерах и под разными ОС. Для этого была разработана CORBA. Это один из стандартов распределённых вычислений, зародившийся в 1980-х и расцветший к 1991 году.
Стандарт CORBA был реализован несколькими вендорами. Он обеспечивает:
Сегодня CORBA всё ещё используется для разнородных вычислений. Например, он до сих пор является частью Java EE , хотя начиная с Java 9 будет поставляться в виде отдельного модуля .
Хочу отметить, что не считаю CORBA паттерном SOA (хотя отношу и CORBA, и SOA-паттерны к сфере распределённых вычислений). Я рассказываю о нём здесь, поскольку считаю недостатки CORBA одной из причин возникновения SOA.
Сначала нам нужно получить брокер объектных запросов (Object Request Broker, ORB), который соответствует спецификации CORBA. Он предоставляется вендором и использует языковые преобразователи (language mappers) для генерирования «заглушек» (stub) и «скелетов» (skeleton) на языках клиентского кода. С помощью этого ORB и определений интерфейсов, использующих IDL (аналог WSDL), можно на основе реальных классов генерировать в клиенте удалённо вызываемые классы-заглушки (stub classes). А на сервере можно генерировать классы-скелеты (skeleton classes), обрабатывающие входящие запросы и вызывающие реальные целевые объекты.
Вызывающая программа (caller) вызывает локальную процедуру, реализованную заглушкой.
Хотя сегодня можно найти применение для CORBA, но мы знаем, что нужно было уменьшить количество удалённых обращений , чтобы повысить производительность системы. Также требовался надёжный канал связи и более простая спецификация обмена сообщениями .
И для решения этих задач в конце 1990-х начали появляться веб-сервисы.
[Веб-]сервисы можно публиковать, находить и использовать стандартным образом вне зависимости от технологий.
- Microsoft 2004,
Благодаря микросервисам мы перешли в парадигме SOA от удалённого вызова методов объекта (CORBA) к передаче сообщений между сервисами.
Но нужно понимать, что в рамках SOA веб-сервисы - не просто API общего назначения, всего лишь предоставляющие CRUD-доступ к базе данных через HTTP. В каких-то случаях эта реализация может быть полезной, но ради целостности ваших данных необходимо, чтобы пользователи понимали лежащую в основе реализации модель и соблюдали бизнес-правила . SOA подразумевает, что веб-сервисы являются ограниченными контекстами бизнес-субдоменов (business sub-domain) и отделяет реализацию от решаемых веб-сервисами задач.
С точки зрения технологий SOA не просто сервисная архитектура, а набор политик, методик и фреймворков, благодаря которым мы предоставляем и получаем нужные сервисы.
- Microsoft 2004, Understanding Service-Oriented Architecture
У нас есть несколько приложений, которые асинхронно общаются друг с другом с помощью платформо-независимых сообщений. Очередь сообщений улучшает масштабируемость и усиливает изолированность приложений. Им не нужно знать, где находятся другие приложения, сколько их и даже что они собой представляют. Однако все эти приложения должны использовать один язык обмена сообщениями, т. е. заранее определённый текстовый формат представления данных.
Очередь сообщений использует в качестве компонента инфраструктуры программный брокер сообщений (RabbitMQ, Beanstalkd, Kafka и т. д.). Для реализации связи между приложениями можно по-разному настроить очередь:
Запрос/Ответ
Все эти паттерны можно отнести к либо к pull- (polling) , либо к push -подходу:
Сервисная шина предприятия использовала веб-сервисы уже в 1990-х, когда они только развивались (быть может, некоторые реализации сначала использовали CORBA?).
ESB возникла во времена, когда в компаниях были отдельные приложения. Например, одно для работы с финансами, другое для учёта персонала, третье для управления складом, и т. д., и их нужно было как-то связывать друг с другом, как-то интегрировать. Но все эти приложения создавались без учёта интеграции, не было стандартного языка для взаимодействия приложений (как и сегодня). Поэтому разработчики приложений предусматривали конечные точки для отправки и приёма данных в определённом формате. Компании-клиенты потом интегрировали приложения, налаживая между ними каналы связи и преобразуя сообщения с одного языка приложения в другой.
Очередь сообщений может упростить взаимодействие приложений, но она не способна решить проблему разных форматов языков. Впрочем, была сделана попытка превратить очередь сообщений из простого канала связи в посредника, доставляющего сообщения и преобразующего их в нужные форматы/языки. ESB стал следующей ступенью в естественной эволюции простой очереди сообщений.
В этой архитектуре используется модульное приложение (composite application), обычно ориентированное на пользователей, которое общается с веб-сервисами для выполнения каких-то операций. В свою очередь, эти веб-сервисы тоже могут общаться с другими веб-сервисами, впоследствии возвращая приложению какие-то данные. Но ни приложение, ни бэкенд-сервисы ничего друг о друге не знают, включая расположение и протоколы связи. Они знают лишь, с каким сервисом хотят связаться и где находится сервисная шина.
Клиент (сервис или модульное приложение) отправляет запрос на сервисную шину, которая преобразует сообщение в формат, поддерживаемый в точке назначения, и перенаправляет туда запрос. Всё взаимодействие идёт через сервисную шину, так что если она падает, то с ней падают и все остальные системы. То есть ESB - ключевой посредник, очень сложный компонент системы.
Это очень упрощённое описание архитектуры ESB. Более того, хотя ESB является главным компонентом архитектуры, в системе могут использоваться и другие компоненты вроде доменных брокеров (Domain Broker), сервисов данных (Data Service), сервисов процессной оркестровки (Process Orchestration Service) и обработчиков правил (Rules Engine). Тот же паттерн может использовать интегрированная архитектура (federated design): система разделена на бизнес-домены со своими ESB, и все ESB соединены друг с другом. У такой схемы выше производительность и нет единой точки отказа: если какая-то ESB упадёт, то пострадает лишь её бизнес-домен.
Главные обязанности ESB:
Создавая структуры связи между разными процессами, мы видели много продуктов и подходов, в которых применяются очень развитые механизмы связи. Хороший пример - сервисные шины предприятий, часто включающие в себя сложные средства маршрутизации сообщений, хореографии, преобразования и применения бизнес-правил.
- Martin Fowler 2014, Microservices
У этого архитектурного паттерна есть положительные стороны. Однако я считаю его особенно полезным в случаях, когда мы не «владеем» веб-сервисами и нам нужен посредник для трансляции сообщений между сервисами, для оркестрирования бизнес-процессами, использующими несколько веб-сервисов, и прочих задач.
В основе микросервисной архитектуры лежат концепции SOA. Назначение у неё то же, что и у ESB: создать единое общее корпоративное приложение из нескольких специализированных приложений бизнес-доменов.
Главное различие микросервисов и шины в том, что ESB была создана в контексте интеграции отдельных приложений , чтобы получилось единое корпоративное распределённое приложение. А микросервисная архитектура создавалась в контексте быстро и постоянно меняющихся бизнесов, которые (в основном) с нуля создают собственные облачные приложения.
То есть в случае с ESB у нас уже были приложения, которые нам не «принадлежат» , и поэтому мы не могли их изменить. А в случае с микросервисами мы полностью контролируем приложения (при этом в системе могут использоваться и сторонние веб-сервисы).
Характер построения/проектирования микросервисов не требует глубокой интеграции. Микросервисы должны соответствовать бизнес-концепции, ограниченному контексту. Они должны сохранять своё состояние, быть независимыми от других микросервисов, и потому они меньше нуждаются в интеграции. То есть низкая взаимозависимость и высокая связность привели к замечательному побочному эффекту - уменьшению потребности в интеграции.
[Микросервисы - это] маленькие автономные сервисы, работающие вместе и спроектированные вокруг бизнес-домена.
- Sam Newman 2015, Principles Of Microservices
Главным недостатком архитектуры ESB было очень сложное централизованное приложение, от которого зависели все остальные приложения. А в микросервисной архитектуре это приложение почти целиком убрано.
Ещё остались элементы, пронизывающие всю экосистему микросервисов. Но у них гораздо меньше задач по сравнению с ESB. К примеру, для асинхронной связи между микросервисами до сих пор применяется очередь сообщений, но это лишь канал для передачи сообщений, не более того. Или можно вспомнить шлюз экосистемы микросервисов, через который проходит весь внешний обмен данными.
Сообщество предпочитает другой подход: умные конечные точки и глупые каналы . Микросервисы, из которых собираются приложения, должны как можно меньше зависеть друг от друга и при этом быть очень тесно связанными - они содержат собственную доменную логику и работают скорее как фильтры с точки зрения классического Unix: получают запросы, применяют логику и генерируют ответы. Они оркестрируются с помощью простых REST-подобных протоколов, а не сложных протоколов вроде WS-Choreography или BPEL либо какого-то централизованного инструмента.
- Martin Fowler 2014, Microservices
20 ответов
Маленький тизер:
SOA - это стиль архивирования приложений таким образом, что они состоят из дискретных программных агентов, которые имеют простые, хорошо определенные интерфейсы и организованы через свободную связь для выполнения требуемой функции.
В SOA есть 2 роли - поставщик услуг и потребитель службы. Программный агент может играть обе роли. SOA не является совершенно новой концепцией - однако в этой статье основное внимание уделяется SOA, реализованной с помощью веб-сервисов.
SOA - новый значок для некоторых очень старых идей:
Разделите свой код на повторно используемые модули.
Инкапсулируйте в модуле любое дизайнерское решение, которое может измениться.
Создайте свои модули таким образом, чтобы их можно было комбинировать различными способами (иногда называемыми "семейством" или "продуктовой линейкой").
Это все принципы разработки программного обеспечения для коренных пород, многие из которых впервые сформулированы Дэвидом Парнасом.
Что нового в SOA
Вы делаете это в сети.
Модули обмениваются сообщениями, отправляя сообщения друг другу по сети, а не более традиционными механизмами языка программирования, такими как вызовы процедур. В частности, в сервис-ориентированной архитектуре части обычно не разделяют изменяемое состояние (глобальные переменные в традиционной программе). Или, если они разделяют состояние, это состояние тщательно блокируется в базе данных, которая сама является агентом и которая может легко управлять несколькими одновременными клиентами.
Я вижу много ответов, объясняющих сервис-ориентированную архитектуру (SOA), используя еще более сложные слова и технические термины. Я хотел бы рассказать об этом для непрофессионала, используя аналогию на простом английском.
Но сначала описание SOA
SOA можно описать в трех слоях, как показано на рисунке ниже. С одной стороны у нас есть Провайдер, а с другой стороны у нас есть Потребитель, разделенный Мостом, где обе стороны общаются.
Потребитель использует ряд приложений, необходимых для этого бизнеса, и поставщик использует Компоненты, которые предоставляют этим приложениям информацию. Они обмениваются данными через набор служб, используя общую архитектуру.
Аналогия
Представьте себе дом на севере, который во многом является частью более крупного сообщества, такого как город или город. В городе есть свои сложные системы для обеспечения водой и электричеством, обработки санитарии, предоставления транспортных и других коммунальных услуг. Дом является потребителем этой модели, город (или сообщество) является поставщиком, а трубы, канализационные сети, линии электропередачи, оптические волокна и т.д. - это инфраструктура, в которой они общаются.
Эта модель может свободно сравниваться с SOA. Люди в доме используют множество различных "приложений", таких как радиаторы, компьютеры, туалеты, лампы, напольное отопление, ванны и т.д. Эти приложения не заботятся о том, как город генерирует воду, создает электричество или обрабатывает отходы в течение длительного времени как это работает. Компонентами города являются генераторы, водяные насосы и санитарные зоны. Он обеспечивает дом всеми этими потребностями, но он подходит к дому, чтобы использовать его так, как он считает нужным.
Надеюсь, это дало по крайней мере кому-то лучшую картину SOA.
Предположим, у вас есть четыре повара. В SOA вы предполагаете, что они ненавидят друг друга, поэтому вы стараетесь позволить им разговаривать друг с другом как можно меньше.
Как вы это делаете? Ну, сначала вы определите роли и интерфейс - повар 1 сделает салат, повар 2 сделает суп, повар 3 сделает стейк и т.д. Затем вы разместите блюда, хорошо организованные на столе (так это интерфейсы) и сказать: "Все, пожалуйста, поместите свое творение в свои назначенные блюда. Не заботьтесь ни о ком другом".
Таким образом, четыре повара должны разговаривать друг с другом как можно меньше, что очень хорошо при разработке программного обеспечения - не обязательно потому, что они ненавидят друг друга, но по другим причинам, таким как физическое местоположение, эффективность принятия решений и т.д..
Это также означает, что вы можете рекомбинировать блюда (услуги) по своему усмотрению. Например, вы можете просто использовать десерт, чтобы обслуживать кафе, или просто взять суп и объединить его с хлебом, который вы купили у другой компании, чтобы предоставить более дешевое меню, или позволить другим ресторанам использовать ваши салаты в сочетании со своими блюдами и т.д..
Одна из самых успешных реализаций SOA была на Amazon. Из-за их дизайна они могут повторно упаковать всю свою инфраструктуру и продать ее как Amazon Web Service.
* Это только один аспект SOA.
SOA - это архитектурный стиль, но также видение о том, как гетерогенное приложение должно разрабатываться и интегрироваться. Основной целью SOA является переход от монолитных приложений и вместо этого набор повторно используемых сервисов , которые могут быть созданы для создания приложений.
IMHO, SOA имеет смысл только на уровне предприятия и ничего не значит для одного приложения.
На многих предприятиях каждый отдел имел собственный набор корпоративных приложений, который подразумевал
Аналогичная функция была реализована несколько раз
Данные (например, данные клиента или сотрудника) должны быть разделены между несколько приложений
Приложения были децентрализованными.
С SOA идея состоит в том, чтобы предоставлять услуги многократного использования в масштабах всего предприятия, чтобы приложение могло быть построено и составлено из них. Обещание SOA:
Не нужно переопределять подобные функции снова и снова (например, предоставлять услуги клиента или сотрудника)
Облегчает интеграцию приложений вместе и доступ к общим данным или функциям
Для просмотра SOA требуется технологический сдвиг, а также организационный сдвиг. Принимая во внимание, что он решает некоторые проблемы, он также вводит другие, например, безопасность намного сложнее с SOA с монолитным приложением. Поэтому SOA обсуждается, работает ли это или нет.
Это 1000-футовый вид SOA. Однако это не останавливается. Существуют и другие концепции, дополняющие SOA, такие как организация бизнес-процессов (BPM), корпоративная шина обслуживания (ESB), комплексная обработка событий (CEP) и т.д. Они решают проблему ИТ/бизнес-ориентирования , что заключается в том, как ИТ-специалисты смогут эффективно поддерживать бизнес.
SOA - это аббревиатура сервис-ориентированной архитектуры.
SOA разрабатывает и записывает программные приложения таким образом что отдельные программные модули могут быть бесшовно интегрирована с высокой степенью повторного использования.
Большинство людей ограничить SOA как запись клиента/сервера ПО-веб-сервисы. Но это тоже небольшой контекст SOA. SOA много больше, чем за последние несколько лет летних веб-сервисов среды коммутации, которая вероятно, причина, по которой люди думают SOA как веб-служб в целом ограничение границ и смысла SOA.
Вы можете подумать о создании модуля доступа к базе данных, который настолько независим, что он может работать самостоятельно без каких-либо зависимостей. Этот модуль может выставлять классы, которые могут использоваться любым хост-программным обеспечением, которому необходим доступ к базе данных. В хост-приложении нет конфигурации запуска. Все необходимое или необходимое передается через классы, предоставляемые модулем доступа к базе данных. Мы можем назвать эти классы в качестве сервисов и рассмотрим модуль как услугу.
Практика SOA дает высокую степень повторное использование, используя DRY , что приводит к высоко поддерживаемое программное обеспечение. Поддержание работоспособности - это первое, что угодно архитектура программного обеспечения - SOA дает вам это.
Насколько я понимаю, основная концепция заключается в том, что вы создаете небольшие "службы", которые предоставляют что-то полезное для других систем и не создают больших систем, которые, как правило, делают все внутри системы.
Таким образом, вы определяете протокол, который вы будете использовать для взаимодействия (скажем, это могут быть веб-службы SOAP), и пусть ваша "система-то-то-дело-работа-работа" взаимодействует с небольшими службами для достижения вашего "большой цели".
то, что имеет тенденцию происходить в крупных организациях, состоит в том, что со временем все это либо монолитные, либо разрозненные системы повсюду или мало того и другого. Кто-то в конце концов приходит и говорит, что у нас беспорядок. Теперь вы хотите перепроектировать (деньги кому-то), все, чтобы ориентироваться в виде монолитики, зависит от того, кто вы платите парадигму, но в то же время сможете добавлять части и части независимо от мастера/монолита.
Итак, вы покупаете Oracle SOA, а Oracle становится боссом всех ваших частей. Все остальные игроки должны работать с SOA через службу (веб-сервис или что-то еще). Монолит Oracle заботится обо всем (монолит не подразумевается уничижительным). О да, у вас есть ASP.NET MVC спереди или что-то еще.
главное - перемещать вещи в систему и из нее без какого-либо воздействия и поддерживать поставщика Oracle SOA, Microsoft WCF, как мозги всего этого. все, что нравится oop/ood, жидкость, вещи, которые движутся и выходят без какого-либо воздействия, даже человеческие услуги, а не только компьютеры.
Для меня это просто означает кучу веб-сервисов (или как мы их называем в будущем) с хорошим интерфейсом. И если у вас есть база данных, просто нажмите на базу данных и перестаньте беспокоиться о словах. все в порядке.
из блога ittoolbox.
Ниже описываются сходства и отличия от прошлых методов проектирования:
SOA и структурированное программирование o Сходства: большинство похоже на вызовы подпрограмм, где передаются параметры, а функция функции абстрагируется от вызывающего абонента - например, CICS и выполнить и зарезервированное слово COBOL CALL. Копировальные книги используются для определения структуры данных, которая обычно определяется как XML-схема для служб. o Различия: SOA слабо взаимосвязана, что означает, что изменения в сервисе оказывают меньшее влияние на потребителя ("вызывающая" программа), а службы взаимодействуют между языками и платформами.
SOA против OOA/OOD o Сходства: инкапсуляция, абстракция и определенные интерфейсы o Различия: SOA слабо связан с иерархией классов или наследованием, абстракции низкого уровня - уровень класса и бизнес-сервис
SOA и устаревшая разработка на основе компонентов (CBD) - например, CORBA, DCOM, EJB o Сходства: Повторное использование через компоненты сборки, Интерфейсы, Удаленные вызовы o Различия: широкое внедрение стандартов, XML-схем и маршализированных объектов, сервис-оркестровка, проектирование для повторного использования проще, услуги ориентированы на бизнес и ИТ-ориентированные, бизнес-услуги являются конечно-крупными (широкими по охвату)
SOA (для интеграции) по сравнению с интеграцией корпоративных приложений (EAI) o Сходства: лучшие практики (четко определенные интерфейсы, стандартизованные схемы, управляемая событиями архитектура), многоразовые интерфейсы, общие схемы o Различия: стандарты, принятие и улучшенные инструменты
Ну, вы видите. SOA означает сервис-ориентированную архитектуру... Проще говоря, вы пишете фрагмент кода, который является очень общим, т.е. он делает кое-что, что может использоваться во многих приложениях... может быть чем-то вроде адресной книги или может быть калькулятором. и вы запускаете этот код в IIS. Таким образом, вы предоставляете услугу через свой код. Таким образом, вы являетесь поставщиком услуг. Теперь кто-то хочет использовать аналогичный код, тогда ему не нужно снова писать код. Он просто использует ваш код, возможно, через веб-службу. Следовательно, он становится потребителем услуг. Следовательно, создание программы с использованием таких сервисов называется SOA. И свободная связь существует, поскольку поставщик услуг и потребитель могут взаимодействовать, даже если они используют языки программирования diff. Надеюсь, вы понимаете.
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Санкт-Петербургский государственный электротехнический университет
Кафедра МОЭВМ
Сервис-ориентированная архитектура
Выполнил:
Орешко Д.В.
Санкт-Петербург 2004
программный инфраструктура операционный
Введение
1. Предпосылки
2. Архитектура SOA
3. Базовые стандарты SOA
4. Реестр сервисов
5. Оркестровка
6. Что такое Web-сервисы
8. Проблемы SOA
9. Достоинства
Литература
Введение
Сервис ориентированная архитектура (service-oriented architecture - SOA) - принципы построения корпоративной программной инфраструктуры, позволяющий разным приложениям обмениваться данными и процессами независимо от ОС, на которых они исполняются, и языков программирования, на которых они написаны. В такой модели приложение или часть приложения называется сервисом. Другое приложение, или потребитель сервиса, может его найти и вызвать. Доступ выполняется через локальную сеть или Интернет. Таким образом, SOA -- это не продукт и даже не технология, а концепция создания и интеграции отдельных корпоративных приложений.
Приведем формальное определение сервисно-ориентированной архитектуры, которое сформулировано специалистами корпорации IBM: «SOA -- это прикладная архитектура, в которой все функции определены как независимые сервисы с вызываемыми интерфейсами. Обращение к этим сервисам в определенной последовательности позволяет реализовать тот или иной бизнес-процесс». С точки зрения разработчиков, ту же мысль можно передать несколько иными словами: SOA -- это компонентная модель, в которой разные функциональные единицы приложений, называемые сервисами, взаимодействуют по сети посредством интерфейсов. Расшифруем данные определения. Все функции приложений определены как сервисы.
В качестве сервиса может выступать как целое приложение, так и отдельные его функциональные модули. Сервисами могут быть прикладные функции, реализующие определенную бизнес-логику, бизнес-транзакции, состоящие из нескольких функций более низкого уровня, и системные функции, отражающие специфику различных операционных платформ. Все сервисы независимы друг от друга. Они выполняют определенные действия по запросам, полученным от других сервисов, и возвращают результаты. Все детали этого полностью скрыты: в концепции SOA сервисы - это "черные ящики". В интерфейсе сервиса определены параметры и описан результат. Иными словами, интерфейс определяет суть сервиса, а не технологию его реализации. На архитектурном уровне для обращения к сервису не имеет значения, является он локальным (реализован в данной системе) или удаленным (внешний по отношению к ней), какой протокол используется для передачи вызова, какие компоненты инфраструктуры при этом задействованы. SOA предполагает наличие единой схемы обращения к сервису независимо от того, находится ли они в том же самом приложении, в другом адресном пространстве многопроцессорной системы, на другой аппаратной платформе в корпоративной intranet-сети или в приложении в системе партнера.
1. Предпосылки
Как решается задача интеграции приложений? Традиционный подход -- построение промежуточного программного слоя того или иного типа. Оптимальной для объединения разнородных платформ и решений выглядела технология взаимодействия распределенных объектов CORBA, позволявшая инкапсулировать бизнес-логику приложений, выполняющихся на разных платформах и созданных с использованием разных языков программирования, организовав связь между ними на базе строго описанных интерфейсов. Аналогичные возможности -- правда, с естественным ограничением гетерогенности -- предлагала корпорация Microsoft в рамках своей компонентной модели DCOM. Однако этим решениям не хватало универсальности; даже применение CORBA сильно зависело от реализации в продуктах разных поставщиков, появлялись новые объектные модели, не поддерживающие CORBA, интеграция по-прежнему реализовывалась на достаточно низком уровне, практически, исключая возможность динамичного изменения связей между приложениями в ходе выполнения. Важно и то, что все предлагаемые средства интеграции фокусировались на технологических особенностях реализации приложений и не позволяли учитывать специфику бизнес-процессов, в которых эти приложения использовались.
В то же время новые потребности бизнеса диктуют и новые условия интеграции. Динамичность ИТ-среды, ее нацеленность на решение бизнес-задач, необходимость быстрых изменений в ответ на изменение этих задач -- эти характеристики приобретают ключевое значение при проектировании или реформировании корпоративных ИТ-инфраструктур. В этих условиях отдельные, «точечные» решения по интеграции настолько усложняют и саму инфраструктуру, и процесс управления ею, что становятся абсолютно неприемлемыми. Представим себе, к примеру, что в компании существует несколько приложений, каждое из которых интегрировано со всеми остальными посредством соответствующих интерфейсов. Если таких приложений -- n, то всего потребуется n(n-1) интерфейсов. С добавлением всего лишь одного нового приложения появится 2n новых интерфейсов, для которых потребуется соответствующее документирование, тестирование и поддержка. В примере на рис. 1 пять взаимодействующих приложений порождают 20 интерфейсов, а добавление шестого приложения потребует еще 10. При этом придется вносить модификации в код каждого из существующих приложений для учета новых интерфейсов и проводить соответствующее тестирование. Чтобы избежать этого, нужна модель интеграции, которая позволит максимально упростить процесс добавления новых приложений и минимизирует число интерфейсов взаимодействия.
Еще одна серьезная проблема -- избыточность программных компонентов и сложность их многократного использования. В рис. 1 приводится пример программной инфраструктуры банка, включающей в себя несколько групп приложений для различных направлений банковской деятельности, которые были разработаны в рамках никак не связанных между собой проектов. В результате, с большей долей вероятности возможна ситуация, когда одна функция (скажем, получение баланса по вкладу) реализована многократно в системе автоматизации банкоматов, в системе поддержки филиалов и в системе расчетов по кредитным картам, -- даже если все эти системы используют одни и те же данные о счете из общей базы данных. А теперь предположим, что банк намерен разработать новые системы, например, для обслуживания клиентов в Internet или выдачи ссуд в режиме on-line. Расширение функциональности программной среды банка повлечет за собой дополнительную избыточность, если в этой среде отсутствуют механизмы многократного использования компонентов, поддерживающих различные задачи бизнеса. Все эти интеграционные проблемы и привели к появлению идеи сервисно-ориентированной архитектуры (service-oriented architecture, SOA). Для разрешения этих проблем простого набора технологий уже недостаточно. Нужен общий, архитектурный подход, концепция архитектуры программной среды предприятия, в которой возможна адекватная потребностям бизнеса динамика разработки, интеграции и эксплуатации приложений.
2. Архитектура SOA
Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок. SOA не является чем-то новым: IT-отделы компаний успешно создавали и развертывали приложения, поддерживающие сервис-ориентированную архитектуру, уже много лет - задолго до появления XML и Web-сервисов.
SOA - это всего лишь иной стиль построения современных корпоративных систем. Он ориентируется на сервисы, характеризуется распределенной архитектурой и слабосвязанными интерфейсами. Сервис в данном случае - это не что иное, как единица работ, выполняемая сервис-провайдером для обеспечения желаемого результата потребителю сервиса. Именно сервис, а не объект, как в ООП, является повторно используемым, и при этом он не зависит от технологий, языковых сред и других ресурсов. Интегрирующую роль между сервис-провайдером и потребителем берут на себя программные агенты. Ряд архитектурных особенностей SOA позволяет уменьшить степень связанности различных элементов системы. Для взаимодействия компонентов используется сравнительно небольшой набор простых интерфейсов, которые обладают только самой общей семантикой и доступны всем провайдерам и потребителям. Через эти интерфейсы передаются сообщения, ограниченные некоторым словарем. А поскольку даны только общая структура корпоративной системы и словарь, то вся семантика и бизнес-логика, специфичная для приложений, описывается непосредственно в этих сообщениях.
Сами Web-сервисы не предполагают какого-либо архитектурного решения, в то время как именно архитектурой определяется стиль процессов взаимодействия. SOA не предписывает жесткой вертикальной методологии проектирования, внедрения или управления ИТ-инфраструктурой. Вместо этого, SOA ограничивается лишь рядом принципов, характеризующих каждый из этих процессов; поэтому ее иногда называют не архитектурой, а архитектурным стилем.
Отметим некоторые из этих принципов.
Распределенное проектирование. Решения относительно внутренних особенностей информационных систем принимаются различными группами людей, имеющими собственные организационные, политические и экономические мотивы.
Постоянство изменений. Отдельные участки архитектуры могут претерпевать изменения в любой момент времени.
Последовательное совершенствование. Локальное улучшение компонентов архитектуры должно приводить к совершенствованию всей архитектуры в целом - к росту суммарной полезности компонентов того же уровня, что и изменяемый, равно как и компонентов более низкого и более высокого уровня.
Рекурсивность. Однотипные решения имеют место на различных уровнях архитектуры.
Как бы неожиданно это ни показалось, перечисленные принципы были сформулированы американским архитектором Кристофером Александером в отношении архитектуры современного мегаполиса. В 1987 году он и его коллеги опубликовали работу под названием «Новая теория городского проектирования» (A New Theory of Urban Design), где излагались взгляды на возможность децентрализованного развития городов. В своей работе Александр показал, как можно осуществлять развитие городов с учетом существенной демографической разнородности жителей. Аналогичным образом SOA, основанная на адаптации этих принципов, позволяет объединить в общий взаимодействующий организм информационные системы, принадлежащие различным автономным организациям и их относительно автономным структурным подразделениям.
Общая схема.
В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 2). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом). Отсутствие любого из этих элементов недопустимо, а добавление других составляющих на практике не только возможно, но и неизбежно. Среди таких элементов могут быть всевозможные программные средства промежуточного слоя, контролирующие порядок и контекст взаимодействия, осуществляющие мониторинг и управление сервисами, а также управление метаданными и другие вспомогательные процессы.
Рис. 2. Общая схема SOA
Для использования сервиса необходимо следовать соглашению об интерфейсе для обращения к сервису - интерфейс должен не зависеть от платформы. SOA реализует масштабируемость сервисов - возможность добавления сервисов, а также их модернизацию. Поставщик сервиса и его потребитель оказываются несвязанными - они общаются с помощью сообщений. Поскольку интерфейс должен не зависеть от платформы, то и технология, используемая для определения сообщений, также должна не зависеть от платформы. Поэтому, как правило, сообщения являются XML-документами, которые соответствуют XML-схеме.
Модель SOA не зависит от технологий, использующихся для реализации SOA, а основным методологически значимым ее компонентом является реестр сервисов. В обозначенном на схеме асинхронном протоколе общения провайдера и потребителя сервисов он выполняет функции посредника. Провайдер размещает информацию о своих сервисах в реестре, что дает возможность потребителю в любой момент найти необходимый ему сервис. На первый взгляд, кажется, что в этом нет ничего особенного, однако за этим процессом общения скрывается основное качество SOA -- слабая связанность. Благодаря этому свойству, сервисы обретают мобильность, способность перемещаться с одного сервера на другой, не требуя согласования и координации со всеми потребителями. Естественно, что потребители сервисов в ряде случаев не способны и не должны принимать во внимание регулярное перераспределение ресурсов, обеспечивающих функционирование сервисов.
Позднее связывание также позволяет отложить момент конечной сборки связей до времени исполнения, а не времени разработки программы, что характерно для традиционных монолитных систем. Можно также во время исполнения менять параметры связи (такие как адрес, протокол и канал взаимодействия). Это придает несколько измерений гибкости самой связке между провайдером и потребителем сервиса -- соответственно вызываемым и осуществляющим вызов объектами. В частности, провайдер и потребитель могут исполняться на сколь угодно физически удаленных инфраструктурах. Каждая из систем может иметь собственные параметры жизненного цикла, а любые изменения в них, не затрагивающие интерфейс сервиса, не требуют остановки ни одной из них.
В SOA сервисы рассматриваются как автономные объекты, управление которыми не централизовано. Это позволяет взаимодействующим посредством сервисов информационным системам развиваться в соответствии с потребностями бизнеса, которые потребителям сервисов, как правило, не только не известны, но и не интересны. Однако это было бы невозможно, если бы интерфейс сервиса не был прочно закреплен обоюдным соглашением провайдера и потребителя сервиса. Одной из отличительных черт SOA является наличие контрактов, описывающих интерфейсы сервисов. Такой контракт представляет собой документ, специфицирующий ожидания сервиса по отношению к его потребителям и наоборот. Контракты Web-сервисов описываются WSDL-документом, в нотации XML определяющим, как потребители должны обращаться к сервису. Использование XML на этом этапе имеет принципиальное значение, позволяя и провайдеру, и потребителю сервиса не зависеть от определенной платформы.
Подобные контракты существовали и до появления Web-сервисов. Например, в архитектуре CORBA для описания интерфейса объектов использовался язык IDL, который уступает WSDL по ряду существенных параметров. Главный из них -- отсутствие поддержки XML и XML Schema, ставших наиболее распространенными языками разметки передаваемых по сети сообщений и представления моделей данных. Технические контракты, формулируемые провайдером сервисов, должны быть доступны потенциальным потребителям для интерпретации, анализа и реализации интеграции. Для этого используется специальный реестр, каталогизирующий доступные сервисы.
3. Базовые стандарты SOA
Набор базовых стандартов SOA держится на трех «китах». В их число, кроме WSDL и UDDI, входит протокол SOAP -- простой механизм для создания структурированных пакетов данных, предназначенных для обмена информацией между сервисами (сетевыми приложениями). Эту тройку стандартов объединяет то, что все они построены на базе языка XML и являются открытыми, то есть их развитием занимаются независимые комитеты по стандартизации. Чтобы понять, как они работают вместе, сравним технологию Web-сервисов с общением по телефону. В таком случае XML -- это язык, на котором ведется разговор, SOAP описывает правила набора номера, UDDI представляет собой телефонную книгу, а WSDL объясняет, что такое разговор по телефону и как его вести.
4. Реестр сервисов
Сейчас в области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. И так -- по всем направлениям технологии Web-сервисов. В результате на роль «заполнителей дыр» в SOA сейчас претендует множество различных методов, но явного лидера нет.
Была создана организация Web Services-Interoperability (http://www.ws-i.org/), которая пытается выработать некий общий знаменатель для технологии Web-сервисов. В августе нынешнего года она выпустила документ WS-I Basic Profile 1.1, определяющий требования к различным компонентам SOA, которые могут гарантировать их совместимость и прояснить тонкости использования Web-сервисов. Программный интерфейс реестра сервисов составляет часть стека протоколов взаимодействия. В наборе технологий Web-сервисов таким стандартом является UDDI (Universal Description, Discovery and Integration). Его спецификация является единственной из ядра основополагающих стандартов Web-сервисов, разработанной вне рамок консорциума World Wide Web Consortium. Таким ядром принято считать спецификации, входящие в профиль WS-I Basic Profile, призванный обеспечить общую для различных инструментальных платформ базу взаимно совместимых технологий описания, публикации, обнаружения и вызова сервисов.
Для разработки данной спецификации в 2000 году был сформирован Консорциум UDDI (UDDI.org), объединивший более 200 корпоративных членов. В соответствии со своим трехлетним мандатом, консорциум выпустил три версии спецификации и перестал существовать в 2003 году. Уже зрелый стандарт, реализованный многими разработчиками, UDDI был передан в организацию Organization for the Advancement of Structured Information Standards (OASIS), занимающую важное место в мире ИТ-стандартов. Текущей версией UDDI, официально принятой в качестве стандарта OASIS, является вторая; ратификация третьей версии ожидается в конце лета этого года, а технический комитет UDDI в составе OASIS уже разрабатывает очередную порцию нововведений.
UDDI обладает весьма развитой функциональностью, существенно более богатой чем, аналогичный компонент набора стандартов CORBA -- CORBA Naming Service. В отличие от предыдущих поколений реестров, UDDI был изначально нацелен на применение как внутри организаций, так и между ними, поэтому реестры UDDI одинаково удобны для ведения информации о нескольких или о тысячах сервисах. Для этого UDDI предусматривает гибкую информационную модель и средства распределения доступа. C точки зрения применимости UDDI в SOA, наиболее методологически значимым элементом информационной модели UDDI является возможность стандартизации типов сервисов (рис. 3). Интерфейс сервиса, описанный WSDL-документом, или даже отдельную его характеристику (скажем, стоимость или поддержка некоего протокола, такого, как HTTP Basic или WS-Security для авторизации) можно представить самостоятельным объектом метаданных в UDDI. Совокупность ссылок на такие объекты характеризует профиль интероперабельности данного сервиса. Используя те или иные параметры, потребитель может найти в реестре сервис, соответствующий его техническим или деловым потребностям.
Рис. 3. Стандартизация типов сервисов
Стандартные типы сервисов жизненно необходимы для любой более или менее масштабной сервис-ориентированной архитектуры. Представьте себе, что произойдет в реальной жизни с поставщиком, который заставляет потребителей подстраиваться под себя? Жизнь заставит его либо перейти на общепринятые формы взаимодействия, либо установить собственный стандарт, для чего необходимо предоставлять уникальную полезность. Экземпляров же сервисов, соответствующих определенным стандартам, может быть сколь угодно много.
С момента публичного представления первой версии UDDI функционирует общедоступный реестр UDDI Business Registry (UBR), который сейчас состоит из четырех географически распределенных реплицируемых узлов: Microsoft (западное побережье США), IBM (восточное побережье США), SAP (Европа) и NTT Telecom (Азия). Наиболее популярным применением UDDI все же остается организация закрытого сообщества взаимодействующих информационных систем либо внутри компании, либо в строго ограниченном кругу ее деловых партнеров. Очевидно, что частный реестр UDDI при этом является центральным звеном корпоративной сервис-ориентированной архитектуры.
5. Оркестровка
Весьма интересна терминология, связанная с веб-сервисами. Так, средства обмена сообщениями, с помощью которых несколько независимых агентов стремятся достичь желаемого состояния, получили название "хореографии", а взаимодействие сервисов - "оркестровки". Для "оркестровки" (т.е., по сути, описания бизнес-логики) были разработаны (с участием крупнейших вендоров, таких, как IBM, Microsoft, Oracle и BEA Systems) специальные средства программирования - BPEL4WS, XLANG, WSFL и др.
Оркестровка относится к определению бизнес-процесса, который может взаимодействовать с внешними и внутренними Web-сервисами. Происходящие на основе обмена сообщениями взаимодействия включают бизнес-логику и порядок выполнения задач; они могут выходить за границы приложений и организаций, определяя долговременную, транзакционную, многошаговую бизнес-модель. Оркестровка всегда представляет управление с позиций одного участника процесса. Хореография позволяет каждому участнику описать свою часть взаимодействия. При использовании хореографии отслеживаются последовательности сообщений между несколькими участниками и источниками. Предлагаемые стандарты оркестровки и хореографии должны удовлетворять нескольким требованиям, относящимся к языку описания потока работ бизнес-процесса и инфраструктуре выполнения процесса. К числу этих требований относятся асинхронный вызов службы; управление исключительными ситуациями и обеспечение транзакционной целостности на основе компенсационного подхода; динамичность, гибкость и адаптируемость оркестровки к изменению потребностей бизнеса; возможность композиции сервисов более высокого уровня из существующих оркестрованных процессов.
К ранним языкам определения бизнес-процессов путем комбинирования Web-сервисов относятся XLANG компании Microsoft (www.gotdotnet.com/team/ xml_wsspecs/xlang_c/default.htm) и Web Services Flow Language (WSFL) компании IBM (www-3.ibm.com/software/solutions/ webservices/pdf/WSFL.pdf). XLANG основан на языке WSDL; его основное назначение состоит в определении бизнес-процессов и организации обмена сообщениями между Web-сервисами. WSFL позволяет описывать как публичные, так и частные процессы. Определяется обмен данными, последовательность выполнения и отображение каждого шага процесса на конкретные операции.
6. Что такое Web-сервисы
Web-сервисами мы называем активный контент, реализующий некоторую функциональность, и данные, расположенные на Web-серверах и предоставляемые для использования внешним приложениям. Web-сервисы полностью независимы от языка и платформы реализации. Внешние приложения работают с сервисами посредством стандартных протоколов и форматов данных. Технология Web-сервисов является краеугольным камнем программной модели Microsoft .NET.
Любой разговор о SOA невольно переходит на рассуждение о роли и месте Web-сервисов. Несмотря на то, что основные положения SOA сложились задолго до появления Web-сервисов, сегодня Web-сервисы занимают центральное место в SOA. Использование XML и Web-сервисов "поднимает SOA на более высокий уровень". Действительно, открытые стандарты, описывающие XML и Web-сервисы, позволяют применять SOA ко всем технологиям и приложениям, установленным в компании. Как известно, Web-сервисы базируются на широко распространенных и открытых протоколах: HTTP, XML, UDDI, WSDL и SOAP. Именно эти стандарты реализуют основные требования SOA - во-первых, сервис должен поддаваться динамическому обнаружению и вызову (UDDI, WSDL и SOAP), во-вторых, должен использоваться независящий от платформы интерфейс (XML). Наконец, HTTP обеспечивает функциональную совместимость. Наконец, сегодня Web-сервисы рассматриваются как эффективный инструмент для интеграции, в том числе для взаимодействия процессов, выполняемых в различных компаниях.
Для демонстрации возможностей SOAP может быть использована недавно вышедшая реализация SOAP Toolkit версии 2.0 производства Microsoft. Объект SOAPClient выступает в роли посредника (proxy), предоставляющего интерфейс Web-сервиса и позволяющего работать с ним как с обычным COM-объектом.
Рис. 4. Механизм взаимодействия клиента и сервера SOAP
Клиентское приложение создает экземпляр объекта SOAPClient. SOAPClient читает файлы описания методов Web-сервиса (на языках WSDL и Web Services Meta Language, WSML). Эти файлы могут храниться и на стороне клиента. Клиентское приложение, используя возможности позднего связывания методов объекта SOAPClient, вызывает метод сервиса. SOAPClient формирует пакет запроса (SOAP Envelope) и отправляет его на сервер. Можно применить любой транспортный протокол, но, как правило, используется HTTP.
Серверное приложение Listener (это может быть ISAPI-приложение или ASP-страница) принимает пакет, создает объект SOAPServer и передает ему пакет запроса. Помимо этого Listener обрабатывает HTTP-пакеты от клиента, отправляет клиенту пакеты с результатом работы сервиса, обрабатывает ошибки и использует функциональность SOAP-объектов. SOAPServer читает описание Web-сервиса, загружает описание и пакет запроса в деревья XML DOM. SOAPServer вызывает метод объекта или приложения, реализующего сервис. Результаты выполнения метода или описание ошибки конвертируются объектом SOAPServer в пакет ответа и отправляются клиенту. Объект SOAPClient проводит разбор принятого пакета и возвращает клиентскому приложению результаты работы сервиса или описание возникшей ошибки.
WSDL-файл - это документ в формате XML, описывающий методы, предоставляемые Web-сервисом, а также параметры методов, их типы, названия и местонахождение сервиса Listener. Мастер SOAP Toolkit автоматически генерирует этот документ, фрагмент которого приведен ниже: SOAP Envelope (Пакет) - это XML-документ, который содержит в себе запрос на выполнение метода или ответ на него. Удобнее всего рассматривать пакет как почтовый конверт, в который вложена информация.
Рис. 5. Структура SOAP-пакета
7. Четыре уровня адаптации SOA
Переход к SOA -- сложный процесс, который связан не только с серьезными трансформациями ИТ-инфраструктуры, но и с изменениями во взаимосвязях между бизнес-процессами и ИТ. IBM предлагает выполнять такой переход поэтапно, беря за отправную точку тот уровень адаптации принципов SOA, который наиболее соответствует состоянию дел на предприятии. Для каждого уровня предлагается не только соответствующий набор инфраструктурных программных решений, но и комплекс консалтинговых услуг, включая обучение.
Уровень 1.
Реализация отдельных Web-сервисов. Это начальный уровень развертывания SOA, на котором технологии Web-сервисов используются для разработки новых приложений или преобразования существующих, например, для интеграции с помощью WSDL-интерфейсов систем, написанных на С++, Cobol и Java. Здесь компании должны реализовать этапы создания и развертывания сервисов. Для создания предлагается инструментарий WebSphere Studio Application Developer, а также набор средств Emerging Technology Toolkit, который позволяет разработчикам опробовать новые решения в области Web-служб. Развертывание Web-сервисов поддерживается сервером приложений WebSphere Application Server.
Уровень 2.
Сервисно-ориентированная интеграция бизнес-функций. На этом уровне мы уже добились преобразования приложений в сервисы и хотим интегрировать их таким образом, чтобы реализовать определенную бизнес-задачу. Одно из основных преимуществ SOA состоит в том, что эта архитектура, в отличие от многих традиционных программных моделей, нацелена на поддержку не программы, а процесса. В программе, написанной исходя из представлений программиста об оптимальности, логика процесса могла быть произвольным образом распределена между компонентами. Скажем, для того чтобы добиться многократного использования нужных компонентов, программисты прибегают к самым разным приемам -- копированию кода, использованию разделяемых библиотек, наследованию объектов и т.д. В SOA приложение разрабатывается исходя из логики бизнес-процесса. Процесс разбивается на некоторую последовательность шагов, каждый из которых реализуется как сервисный компонент приложения. И эти компоненты интегрируются таким образом, чтобы их выполнение в определенной последовательности приводило к нужному бизнес-результату.
Говоря об интеграции, мы подразумеваем взаимодействие между сервисами в SOA на уровне интерфейсов. Однако надо иметь в виду, что в реальной ИТ-инфраструктуре, где будет происходить переориентация на сервисы, проблема интеграции может оказаться гораздо шире, и необходимо будет учитывать различные типы и стили интеграции. Назовем некоторые из них. Интеграция на уровне пользовательского интерфейса. Получение удобного и эффективного интерфейса для взаимодействия пользователя со средой интегрированных сервисов. Эта область интеграции связана с развитием портальных технологий.
Информационная интеграция. Обеспечение согласованного доступа к данным без каких-либо ограничений, связанных с форматом, логическим и физическим размещением данных. Поддержка различных способов коммуникаций низкого уровня между приложениями. Речь идет о таких механизмах, как синхронные и асинхронные коммуникации, маршрутизация, трансформация и высокоскоростное распределение данных, шлюзы и конвертеры протоколов, виртуализация ввода/вывода и т.д.
Интеграция процессов. Поддержка нужной последовательности сервисов для реализации бизнес-процесса, интеграция процессов с другими процессами (для этого типа интеграции также используются термины "хореография" и "оркестровка" сервисов).
Интеграция унаследованных систем. Здесь стоит выделить еще одну архитектурную концепцию, используемую для сервисно-ориентированной интеграции. Речь идет о концепции сервисной шины предприятия (enterprise service bus, ESB). Ее задача -- предоставить единый механизм передачи запросов и получения результатов сервисов, выполнения необходимых преобразований сообщений и транспортных протоколов (скажем, от SOAP на базе HTTP к SOAP на основе WebSphere MQ), обеспечения требований безопасности доступа и, что наиболее важно, управления потоком обращений к сервисам. Благодаря такому управлению выполняется нужная последовательность вызовов сервиса для реализации бизнес-процесса; определение процесса как серии обращений к сервисам поддерживается, например, в разработанном усиловиями IBM и Microcoft языке Business Process Execution Language (BPEL). Обратившись к схематичной иллюстрации шины ESB (рис. 3), можно увидеть, что этот подход решает одну из главных проблем интеграции -- проблему минимизации интерфейсов. Добавление нового сервиса к общей картине приведет к появлению одного и только одного дополнительного интерфейса для интеграции с остальными компонентами архитектуры.
Рис. 6. Модель сервисной шины
Все задачи интеграции, отображения бизнес-процессов компании в сервисы -- предмет реализации на втором и третьем уровнях перехода к SOA в трактовке IBM. На этих уровнях вступают в действие все четыре этапа жизненного цикла сервисов, и используется множество программных продуктов. Второй уровень -- это реализация SOA для ограниченного числа подразделений в компании. Здесь, на этапе создания к средствам разработки WebSphere Studio Application Developer добавляется система WebSphere Host Access Transformation Services. Для развертывания используется поддерживающий язык BPEL сервер интеграции бизнес-процессов WebSphere Business Integration Server Foundation и шлюзы CICS Tranaction Gateway или IMS Connect. Для использования полученных возможностей предлагается WebSphere Portal, а функции управления возлагаются на модули семейства Tivoli -- Access Manager и Monitoring for Transaction Performance.
Уровень 3.
Трансформация ИТ-инфраструктуры в масштабе предприятия. Здесь речь идет о сервисно-ориентированной интеграции приложений и процессов уже в масштабах всей компании, причем согласованный, сервисный подход к ИТ-инфраструктуре распространяется не только на внутренние подразделения, но и на партнеров и поставщиков. Здесь вступают в действие системы, обеспечивающие более глубокую детализацию разработки и интеграцию сервисов с учетом всех уже рассмотренных типов интеграции. IBM предлагает WebSphere Business Integration Modeler и Rational Rose XDE для этапа создания сервисов, WebSphere Business Integration Message Broker для развертывания, DB2 Information Integrator и Lotus Workplace для стадии использования. Управление такой полноценной средой SOA реализуется с помощью инструментов семейства Tivoli -- Identity Manager, Business System Manager и Monitoring for Business Integration, а также WebSphere Business Integration Monitor.
По данным IDC, до 2003 года включительно, большинство организаций, проявивших практический интерес к технологиям Web-сервисов, тратили свои средства и усилия на разработку отдельных сервисов и изучение возможностей их использования в корпоративной инфраструктуре. Сейчас для них наступает новый этап, состоящий в интеграции сервисов в единую среду и решении задач управления ею и обеспечения безопасности. Таким образом, второй и третий уровень адаптации SOA приобретают вполне практический смысл.
Уровень 4.
Изменения в бизнесе. Последний уровень связан с изменениями в самих способах ведения бизнеса в ответ на глобальные трансформации ИТ-инфраструктуры. Здесь надо обратить внимание на связь между SOA и стратегией on-demand computing, которую проповедует IBM и которой подчинена вся стратегия развития ее программных и аппаратных решений. SOA становится архитектурной основой для реализации принципов данной стратегии на прикладном уровне благодаря гибкости, которую обеспечивает сервисный подход к реализации и развертыванию приложений. В SOA для поддержки бизнес-процессов используются не монолитные приложения, а динамичные сервисы, и потому всякое изменение в требованиях для решения бизнес-задач быстро получит адекватное отражение на уровне приложений: необходимые сервисы будут найдены, реконфигурированы и собраны в единое целое.
8. Проблемы SOA
Несогласованность стандартов. В области Web-сервисов сложились две группировки: одна включает IBM, BEA и Microsoft, а вторая -- Sun, Fujitsu и Oracle. Каждая из них продвигает свои разработки. Например, для управления транзакциями первая предлагает протокол WS-Transactions, а вторая -- WS-Transactions Management; для гарантированной доставки сообщений первая выпустила WS-ReliableMessaging, а вторая -- WS-Reliability. (Стоит отметить, что после анонсирования Microsoft Visual Studio Team System, а также предложений IBM по конкретным решениям, основанным на SOA, это противостояние стало минимальным, и можно ожидать продвижения в разработке единых стандартов, регламентирующих использование Web-сервисов).
На первое место при создании SOA-приложений выходит проектирование интерфейса, что, в свою очередь, выдвигает новые требования к разработчикам, связанные с кардинальной переменой самой идеологии программной разработки, которые не могут обеспечить современные средства проектирования, изначально ориентированные на классическую клиент-серверную архитектуру. Трех существующих стандартов Web-сервисов достаточно для создания простых систем, но явно маловато для разработки сложных решений, которые, как правило, и нужны в корпоративной среде. Чтобы Web-сервисы могли выполнять задания бизнеса, нужно обеспечить гарантированную асинхронную доставку сообщений, управление транзакциями, шифрование, координацию распределенных программных компонентов, аутентификацию, авторизацию и многое другое. Массовое распространение SOA и Web-сервисов сдерживается и недостатком соответствующих инструментов. Но, может скоро положение измениться к лучшему.
9. Достоинства
Слабая связанность сервисов существенно повышает их мобильность и возможность многосторонней интеграции. Благодаря этому сервисы можно перемещать с одного сервера на другой, менять параметры связи и объединять сервисы в единое приложение не на этапе разработки, а на этапе исполнения. Это придает системе, построенной на базе SOA, особую гибкость и позволяет предприятиям осуществить давнюю мечту о многократном использовании одного и того же кода.
Внедрение не требует полной перестройки корпоративной инфраструктуры. Предприятиям не нужно отказываться от привычных, хорошо себя зарекомендовавших приложений. Достаточно снабдить их соответствующими интерфейсами -- и Web-сервисы готовы. «Практическая ценность SOA для бизнеса заключается в возможности постепенного эволюционного развития корпоративной информационной инфраструктуры». Благодаря Web-сервисам бизнес-менеджеры могут гораздо активнее участвовать в создании корпоративных приложений. Правда, пока это лишь теоретическая возможность: необходимы специальные инструменты, позволяющие создавать сервисы без программирования. Но они уже начинают появляться. Например, компания UnitSpace выпустила ПО промежуточного слоя BCR. Оно позволяет адаптировать приложения к SOA, создавая Web-сервисы на основе заданных бизнес-аналитиками метаданных, без программирования. «Средства автоматического преобразования форматов позволяют приложениям обмениваться данными на основе их общей семантики, а выполнением бизнес-процессов управлять с помощью сценариев, написанных на стандартном языке BPEL.
Новая архитектура дает предприятию возможность быстрее адаптироваться к изменяющимся условиям: можно быстро заменить одну реализацию сервиса на другую, не меняя его интерфейс. Использование открытых стандартов вместо закрытых протоколов делает архитектуру SOA независимой от платформ. «SOA поднимет на новый уровень интеграцию, обеспечивая взаимодействие гетерогенных систем». Сервис-ориентированная архитектура предлагает разработчикам совершенно иной подход к многократному использованию кода. Вместо традиционного объектно-ориентированного наследования предполагается композиция, то есть создание более сложных сервисов из сервисов низкого уровня. При этом преодолевается основное ограничение наследования -- сервисы могут быть распределены в сети и даже принадлежать различным компаниям. Попутно композиция нивелирует эффекты специализации, интегрируя элементарные операции в бизнес-функции соответствующего уровня восприятия.
Итак, SOA представляется весьма своевременным явлением, поскольку способна упростить и упорядочить интеграцию бизнеса. При этом SOA позволяет одновременно удовлетворить кажущиеся несовместимыми потребности и во взаимодействии и в адаптивности, не требуя при этом кардинальных изменений в образе деятельности каждой из взаимодействующих сторон. В свою очередь, универсальность технологий Web-сервисов делает реализацию SOA доступной каждой организации.
Литература
1. Сергей Кузнецов. Обзор октябрьского 2003 года номера журнала Computer (IEEE Computer Society, Vol. 36, No. 10, October 2003).
2. Валентин Колесов Демонстрация работы SOAP на примере написания Web-сервер.
3. Отчет "Сервис-ориентированная архитектура" (Service Oriented Architecture. InfoWorld Research Report. 2005).
4. Хао Хи (Hao He) "Что такое сервис-ориентированная архитектура" (What is Service-Oriented Architecture?).
5. Клив Финкельштейн (Clive Finkelstein) "Корпорация: сервис-ориентированная архитектура" (The Enterprise: Service-Oriented Architecture (SOA)).
6. Джерими Уэстерман (Jeremy Westerman) "Сервис-ориентированная архитектура сегодня: введение в SOA" (SOA Today: Introduction to Service-Oriented Architecture).
7. Владимир Беленкович, Тимофей Горшков Логическая структура понятия сервисов в рамках SOA.
8. Елена Гореткина Непростой путь от Web-сервисов к SOA.
9. Даниил Фейгин Концепция SOA.
10. Наталья Дубова SOA: подходы к реализации.
Размещено на Allbest.ru
...Подобные документы
Технология распределенных вычислений CORBA, взаимодействие компонентов и архитектура. Основное назначение CORBA и COM. Поддержка операционных систем, предлагаемые службы и масштабируемость. Формальное описание архитектуры и проблемы ее реализации.
курсовая работа , добавлен 02.12.2013
Объект CORBA и жизненный цикл серванта. Общий протокол межброкерного взаимодействия (GIOP). Связывание с языком высокого уровня. Статические и динамические вызовы. Применение технологии CORBA при построении распределенных информационных приложений.
курсовая работа , добавлен 23.12.2014
Сущность, развитие и применение СОМ-технологий, их достоинства, недостатки, терминология. Особенности СОМ-интерфейса, сервера, клиента, расширений. Локальные и удаленные серверы, их функции и реализация. Технология OMG CORBA и архитектура комплекса.
курсовая работа , добавлен 13.11.2011
Технология CORBA для написания распределенных приложений, ее предназначение, преимущества и правила использования. Язык IDL и его использование в качестве универсальной нотации для определения границ объекта и для подержания наследования интерфейсов.
лабораторная работа , добавлен 30.06.2009
Обзор существующих объектных архитектур. Архитектура программного обеспечения. Создание веб-сервиса "Библиотека", предоставляющего механизмы работы с данными на стороне клиентского приложения. WEB-сервис и трехуровневая архитектура в основе приложения.
лабораторная работа , добавлен 16.06.2013
Технология CORBA (Общая Архитектура Брокера Объектных запросов): интерфейс, управление объектами. Создание сервисного приложения, простейшего объекта. Установка связи между клиентом и серверным объектом. Массивы, обработка ошибок и устойчивость к сбоям.
реферат , добавлен 09.11.2011
Изучение внутренней и внешней архитектуры персонального компьютера. Логическая организация и структура аппаратных и программных ресурсов вычислительной системы. Описание различных компонентов ПК. Принципы их взаимодействия, функции и характеристики.
контрольная работа , добавлен 15.06.2014
Агентно-ориентированная программная архитектура систем обработки потоковых данных. Обеспечение гибкости и живучести программного обеспечения распределенных информационно-управляющих систем. Спецификации программных комплексов распределенной обработки.
реферат , добавлен 28.11.2015
Виды архитектуры распределенных информационных систем. Сущность синхронного и асинхронного, блокирующего и неблокирующего взаимодействия в распределенных информационных системах. Основные проблемы и принципы реализации удаленного вызова процедур.
реферат , добавлен 22.06.2011
Назначение и цели создания системы. Разработка логической модели данных, выбор хранилища. Диаграмма классов для диспетчера и контент-менеджера, схема взаимодействия объектов системы. Описание программных модулей. Тестирование веб-базированной системы.
Тематические материалы:Обновлено: 28.09.2019103583Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter
