13.1.5. Отказоустойчивость Web-служб

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

Для обеспечения отказоустойчивости при передаче сообщений разрабатывается дополнительный стандарт WS-Reliability [28], расширяющий SOAP. Использование WS-Reliability позволяет гарантировать доставку сообщений, используемых в работе Web-служб.

13.1.6. Безопасность Web-служб

Наиболее вероятным кандидатом на место широко используемого стандарта защиты информации, передаваемой в сообщениях при работе с Web-службами, является стандарт WS-Security [18,29].

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

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

13.2.1. Концепция soa

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

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

СОА - это модель для объединения вычислительных ресурсов (в основном, приложений и данных) с требованиями достижения желаемых результатов для потребителей сервисов (которые могут быть представлены как конечными пользователями, так и другими сервисами). OASIS (Организация по Продвижению Стандартов Структурированной Информации) определяет СОА следующим образом:

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

Архитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована используя один из этих протоколов и, например, может использовать механизм файловой системы для обмена данными. Главное, что отличает SOA, это использование независимых сервисов с чётко определёнными интерфейсами, которые могут быть вызваны стандартным способом для выполнения их задач, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает каким образом сервисы выполняют свою задачу.

СОА также может быть рассматриваться как стиль архитуктуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабо-связанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса. Таким образом системы, основанные на СОА, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т.д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов.

СОА может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако СОА не определяет и не предоставляет методологий или фреймворков для документирования сервисов.