Пишем простой RESTful веб-сервис на Spring Web MVC

Суровый разместил на GitHub'е новый репозиторий, в котором будет собирать примеры использования Spring Framework 4.x. И сегодня я поделюсь с уважаемыми читателями блога примером простого RESTful веб-сервиса, реализованного на базе фреймворка Spring Web MVC и не содержащего ни строчки XML за исключением pom.xml.

• Архитектура сервиса
  
  
• Контроллер
  
  
• Настройка контекста приложения
  
  
• Как Spring MVC трансформирует объекты в JSON и XML
  
  
• Развертывание и тестирование приложения
  
  
• Выводы
  

Архитектура сервиса

Задачей примера было продемонстрировать реализацию классической многослойной архитектуры, к которой тяготеет большинство приложений, построенных на основе Spring Framework. Точкой входа является контроллер MessageController, в который инжектируются "сервисы" MessageService и ZShopService:

Валидация XML-сообщений

В статье Проектирование контракта сервиса мы отметили, что действительно самодокументируемый контракт подразумевает возможность автоматической валидации сообщений, которыми данный сервис общается с внешним миром. Пришло время рассмотреть данный процесс подробнее.

Прежде всего давайте разберемся в каких случаях необходима валидация сообщений.

1. Мы можем ничего не знать о клиенте нашего сервиса, соответственно нам необходимо проверить запросы, поступающие от данного клиента, перед тем как их обрабатывать.
   
   
2. Сообщения, поступающие от внешних сервисов, т.е. сервисов, которые мы не контролируем, должны подвергаться валидации.
   

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

Не обязательно осуществлять валидацию сообщений в следующих случаях:

1. Если сообщение передается от одного компонента к другому внутри композитного приложения, то необходимости валидации нет: это наше приложение, мы его полностью контролируем.
   
   
2. Во внутренних сервисах или других контролируемых нами приложениях валидация обычно не требуется, но может быть реализована. В случае, если внутренний сервис осуществляет обработку данных, вводимых пользователями, то валидация необходима.
   

В данной заметке мы рассмотрим некоторые приемы валидации сообщений, а так же способы обработки ошибок, возникающих при проверке некорректных сообщений.

Паттерны проектирования XML-схем

В данной заметке мы продолжим тему разработки контрактов сервисов. В предыдущей статье мы отметили, что стандартом де-факто в настоящее время для представления контрактов сервисов является WSDL. Предполагается, что общение с сервисом осуществляется посредством сообщений, представленных в формате XML. Структура данных сообщений описывается с помощью языка XML Schema.

Существует несколько паттернов проектирования XML-схем. Использование данных паттернов позволяет описать одну и ту же структуру XML-документа разными способами, каждый из которых имеет свои преимущества и недостатки. Рассмотрим данные способы подробнее.

К вопросам обработки XML-сообщений в Oracle SOA Suite

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

Зачастую перед непосредственно трансформацией сообщения необходимо произвести его разбор: преобразовать из строки в объект, описывающий XML-документ. В Oracle SOA Suite для такого преобразования служит функция oraext:parseXML. Данная функция возвращает объект, который можно присвоить BPEL-переменной.

Здесь и начинаются сложности. Дело в том, что любая BPEL-переменная должна иметь тип. Тип переменной за исключением т.н. простых типов (строка, число, логическое значение) определяется XML-схемой. В дальнейшем все манипуляции с переменной описываются с помощью XPath-выражений, которые в среде разработки (JDeveloper) строятся так же на основании типа переменной, т.е. в конечном итоге - на основании схемы. В связи с этим хочется рассмотреть два вопроса:

1. Что произойдет, если на вход функции oraext:parseXML подать строку, представляющую собой XML, не соответствующий схеме.

2. Как влияют определения пространств имен на соответствие XML-документа схеме.