Service Oriented Architecture
ОГЛАВЛЕНИЕ
Обычно архитектура таких систем и потоки данных в них близки к структуре бизнес-подразделений, использующих их, и взаимодействий между ними. В некоторой степени происходит соединение информационных технологий и бизнес-процессов на концептуальном уровне. Такое слияние положительно влияет на понимание информационных систем представителями бизнеса (концепция службы более наглядна чем термины "репликация", или "удаленный вызов процедуры"), и на понимание бизнес-процессов разработчиками системы. В качестве платформы для 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-службы базируются на стандартизированных технологиях, они работают в кросс-плафторменных средах и не зависят от языка реализации.
