Сервисно-ориентированная архитектура

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

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

Основные принципы данного архитектурного стиля:

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

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

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

- при обмене данными сервисы совместно используют контрактыи схемы, но не внутренние классысовместимость основана на политике (политика в данном случаеозначает описание характеристик, таких как транспорт, протокол ибезопасность.

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

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

Рисунок 11.10. Пример обмена информацией

для сервисно-ориентированныхсистем.

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

Преимущества данного архитектурного стиля:

- согласование предметных областей – повторное использованиеобщих сервисов со стандартными интерфейсами расширяет технологические и бизнес-возможности, а также сокращает стоимость;

- абстракция– сервисы являются автономными, доступ к нимосуществляется по формальному контракту, что обеспечивает слабоесвязывание и абстракцию;

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

- возможностьвзаимодействия – поскольку протоколы и форматы данных основываются на отраслевых стандартах, поставщик ипотребитель сервиса могут создаваться и развертываться на разныхплатформах;

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

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