Визуализация и тестирование REST API с помощью Swagger на WebSphere Liberty

В последние годы все большую популярность набирает стандарт описания интерфейсов RESTful веб-сервисов Swagger. Фактически Swagger становится для RESTful-сервисов тем же, чем является WSDL для SOAP-сервисов. При этом разработчики серверов приложений активно добавляют поддержку данного стандарта в свои продукты. Вот и флагманский сервер приложений WebSphere Liberty корпорации IBM обзавелся новой возможностью apiDiscovery, позволяющей найти все доступные на сервере REST API и динамически создать Swagger-подобный интерфейс пользователя для тестирования найденных конечных точек.

В данной статье мы рассмотрим процесс реализации некоего REST API с помощью сервлетов, его документирования на Swagger и тестирования с помощью пользовательского интерфейса apiDiscovery. Дополнительно я расскажу о достаточно богатом механизме обнаружения сервером приложений доступных Swagger-документов и генерации таковых по аннотациям JAX-RS и Swagger.

Первое знакомство с Red Hat JBoss Fuse

Здравствуйте, коллеги.

Сегодня проводил семинар в Accenture Riga Delivery Center по поводу интересной для меня темы Red Hat JBoss Fuse и решил поделиться своими впечатлениями от этой сервисной шины с вами.

Что такое Red Hat JBoss Fuse? По сути это - среда исполнения для реализации набора паттернов интеграции корпоративных приложений (Enterprise Application Integration Patterns (EIP)) Apache Camel.

Данная среда исполнения поставляется в двух вариантах:

• Apache Karaf - готовая к промышленному использованию реализация стандарта OSGi.
  
  
• Red Hat JBoss Enterprise Application Platform - широко известный Java EE-совместимый сервер приложений с коммерческой поддержкой. К сожалению, Red Hat JBoss Fuse устанавливается только на версию 6.4.0 данного сервера приложений, реализующую лишь стандарт Java EE 6, что приводит к проблемам, некоторые из которых описаны ниже.
  

Сo-location как путь к высокой производительности Java EE приложений

Введение

Спецификация JDBC API, разработанная в рамках Java Community Process (JCP), определяет только лишь набор интерфейсов и базовых классов, которые в свою очередь должны быть реализованы разработчиками того или иного драйвера. Можно выделить четыре подхода к разработке драйверов JDBC:

1. JDBC Driver - Type 1 (JDBC ODBC Bridge)
   
   Данный подход подразумевает, что код, написанный на языке Java, обращается к коду, реализованному на одном из нативных языков, поддерживаемых Microsoft, который уже в свою очередь общается с базой данных.
   
   
2. JDBC Driver - Type 2 (Part Native Driver)
   
   Данный подход подразумевает, что код, написанный на языке Java, обращается к коду, реализованному производителем СУБД на нативном языке, который уже в свою очередь общается с базой данных.
   
   
3. JDBC Driver - Type 3
   
   Данный подход подразумевает, что код, написанный на языке Java, обращается к коду, реализованному производителем сервера приложений, который уже в свою очередь общается с базой данных. В данном случае драйвер взаимодействует с программным обеспечением промежуточного слоя. Данный тип драйвера отличается особой гибкостью, поскольку не требует установки никакого кода на клиентской стороне и один драйвер может обеспечивать связь с несколькими типами СУБД.
   
   
4. JDBC Driver - Type 4 (Thin Driver)
   
   Данный подход подразумевает, что реализованный производителем СУБД код драйвера, написанный на языке Java, напрямую взаимодействует с базой данных. Другими словами данный тип драйвера представляет собой чисто Java-библиотеку, транслирующую JDBC-запросы напрямую в специфичный протокол базы данных.
   

В мире распределенных систем наиболее используемым типом драйвера является JDBC Type 4, в то время как в мире мейнфреймов (IBM z Systems) принят другой подход. Целью данной статьи является продемонстрировать какие именно преимущества с точки зрения обеспечения высокой производительности можно получить, просто выбрав правильный тип драйвера.

• Бенчмарк
  
  
• Профиль нагрузки
  
  
• Данные
  
  
• Анализ
  
  
• Потребление процессорных ресурсов
  
  
• Полученные значения
  
  
• Выводы

Не очередями сообщений едиными или что такое федерализация данных

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

Одним из очевидных и наиболее популярных подходов к интеграции данных является их распространение путем передачи из базы данных одного приложения в базу данных другого. Tак как бизнес хочет видеть данные в каждом приложении, участвующем в бизнес-процессах компании, как можно быстрее, обмен информацией реализуется путем передачи небольших порций данных по очередям сообщений (синхронное распространение данных оставим вне рассмотрения, в последнее время оно не является мейнстримом, т.к. привносит с собой сильную связность между информационными системами). Поскольку современные решения класса Enterprise Service Bus (ESB) содержат удобнейшие зачастую декларативно настраиваемые адаптеры к большому количеству СУБД и провайдеров очередей сообщений (Message-oriented Middleware (MOM)), а также поставляются с визуальными редакторами, в разы ускоряющими разработку, то их и выбирают для решения вышеозначенной задачи. В итоге внедрение сервисной шины предприятия воспринимается как реализация асинхронного обмена данными между несколькими источниками, в большинстве своем представляющими собой реляционные базы данных тех или иных корпоративных приложений. Вариантом подхода является вставка данных не непосредственно в базу, а через некие сервисы, предоставляемые системой-приемником, что абстрагирует детали строения ее базы данных от разработчиков интеграции.

• Недостатки распространения данных
  
  
• Федерализация данных
  
  
• Применимость шаблона "федерализация данных"
  
  
• Ограничения при внедрении шаблона "федерализация данных"
  
  
• Выводы
  
  
• Материалы

Java EE 7 на большом железе - до 140 процессоров и 10 ТБ ОЗУ!

Очень хочу рассказать о том, что уже примерно год доступны все возможности Java EE 7 на большом железе, т.е. на вычислительной платформе, предоставляющей в ваше распоряжение до 140 процессоров и 10 ТБ оперативной памяти. Да, вы правы, речь идет о сервере приложений WebSphere Liberty Profile, работающем на мейнфрейме IBM z13.

• Установка сервера приложений на z/OS
  
  
• Стартовые процедуры для WebSphere Liberty Profile
  
  
• Получение доступа к авторизованным сервисам
  
  
• Подключение к DB2 с помощью JDBC Type 2
  
  
• Подключение к менеджеру очередей IBM MQ с использованием BINDINGS
  
  
• Используем подсистему безопасности z/OS в приложениях Java EE
  
  
• Сквозная аутентификация WebSphere Liberty Profile, z/OS и DB2
  
  
• Интеграция с Workload Manager'ом (WLM)
  
  
• Java EE 7
  
  
• Выводы

Почему же все-таки покупают коммерческие сервера приложений, если есть бесплатные решения?

Вынесено из комментариев, мнение исключительно мое.

Железо, ОС, DB2 и WAS как часть общей платформы идут на мейнфреймах, да и то несколько месяцев назад анонсированы новые сервера LinuxONE, представляющие собой мейнфреймы, снабженные только IFL-процессорами, т.е. позволяющие запускать только Linux, позиционируемые как неограничено масштабируемая платформа для работы как IBM'овского, так и Open Source софта. Да что говорить, там поддерживаются даже Ubuntu и KVM. На остальных - дистрибьютед платформах, как мы их называем, - WebSphere Application Server покупают просто как сервер приложений, успешно ходят из него в Oracle Database и запускают на нем самые разные системы, как самописные, разработанные на самом предприятии или подрядчиком, так и известные пакетные приложения, например EMC Documentum. Насколько я знаю, даже Oracle SOA Suite может работать на WebSphere Application Server'е, правда скорее всего на Classic.

Почему же заказчики покупают сервер приложений с поддержкой от известного вендора, вместо того, чтобы использовать бесплатные решения? Частично я освещал эту тему в статье А почему бы мне не заплатить за мой Spring Framework? Ключевое - нефункциональные требования. Да, и Apache TomEE, и Glassfish (похоже R.I.P), и JBoss (платный?) являются платформами для того же самого стека Java EE, но дьявол как обычно кроется в мелочах. И задача продавца из IBM, который будет помогать вам аргументировать покупку, заключается в том, чтобы понять, а нужны ли вам эти опции. Нужны ли Dynamic Routing, Auto Scaling, Intelligent Management и т.д.

Другая причина, по которой покупают промышленные сервера приложений, - поддержка известным производителем. Существуют системы, несколько часов/сутки простоя которых стоят дороже, чем лицензии на сервер приложений, СУБД и другое програмное обеспечение. Речь даже не столько о финансовых учреждениях, хотя большинство россиян столкнулись со знаменитым простоем карточного процессинга одного известного банка несколько лет назад. Представьте себе простой любого московского аэропорта, крупной железнодорожной компании (единственной в стране крупной железнодорожной компании :)), энергосбыта и т.д. Я конечно не говорю, что у всех у них WebSphere Application Server, но менеджменту зачастую нужно, чтобы в случае критичных проблем тут же приехал (связался по телефону) человек и починил за четко установленное в SLA время. Я не знаю ни одного случая внедрения TomEE в нашей богоспасаемой стране, ровно как и фирмы, гарантирующей 24/7 поддержку данного сервера приложений. Аналогичные соображения про Glassfish, знаю только, что есть коммерческая версия данного сервера, но ее поддерживают коллеги из Туманного Альбиона и похоже только там + та Европа, что западнее Белоруссии. Red Hat, надо отдать должное, более активен.

А что можете сказать вы? Поделитесь своим мнением по поводу нужности/ненужности коммерческих серверов приложений в комментариях!

Понравилось сообщение - подпишитесь на блог

Spring Framework: влияние сканирования зависимостей на время запуска веб-приложения

В комментариях к заметке Пишем простой RESTful веб-сервис на Spring Web MVC прозвучал довольно интересный вопрос, суть которого сводится к следующему: как сервер приложений находит все классы, реализующие интерфейс javax.servlet.ServletContainerInitializer, и сколько времени это занимает. Попробуем разобраться.

• Какие компоненты ищет сервер приложений при запуске.
  
  
• Servlet Container Initializer (CSI).
  
  
• Сколько времени занимает сканирование.
  
  
• Отключаем поиск компонентов веб-приложения.
  
  
• Отключаем поиск SCI.
  
  
• Выводы.
  
  
• Используемые материалы.
  

Какие компоненты ищет сервер приложений при запуске

Часть 8 спецификации Servlet 3.0 вводит понятие "подключаемой возможности" ("plugability features"), что существенно упрощает структуру веб-приложения, а так же подключение дополнительных фреймворков. Однако, данные возможности требуют времени на сканирование JAR-архивов и файлов с классами приложения. Спецификация требует, чтобы данное сканирование производилось по-умолчанию, однако его можно частично или полностью избежать в зависимости от используемого сервера приложений.

Сканирования зависимостей и классов приложения требуют следующие возможности:

• Впервые предложенные в спецификации Servlet 3.0:
  
  
  • SCI (javax.servlet.ServletContainerInitializer);
    
    
  • Веб-фрагменты (META-INF/web-fragment.xml);
    
    
  • Ресурсы веб-приложения, собранные в JAR-файлах (META-INF/resources/*);
    
    
  • Аннотации, определяющие компоненты веб-приложения (@WebServlet и т.д.);
    
    
  • Аннотации, определяющие компоненты для сторонних библиотек, инициализируемые с помощью SCI (аннотации, которые определены в аннотации @HandlesTypes на SCI-классе. Класс конфигурации контекста приложения Spring Framework из примера - ApplicationInitializer - является таким компонентом.
  
  
• Старые возможности, впервые предложенные в ранних версиях спецификации:
  
  
  • Tag Library Descriptor (TLD), определяет библиотеки тегов. Сервер приложений ищет файлы META-INF/**/*.tld.
    

Servlet Container Initializer (CSI)

В принципе, на Stack Overflow дан довольно подробный и развернутый ответ на вопрос о том, как сервер приложений ищет классы инициализации контекста. В каталоге META-INF/services архива с библиотекой должен находиться файл javax.servlet.ServletContainerInitializer, содержащий перечисление полных имен классов, реализующих интерфейс javax.servlet.ServletContainerInitializer (по одному имени на строке). Например:

psamolysov.demo.spring.restws.ServletContextInitializer1
psamolysov.demo.spring.restws.ServletContextInitializer2

Аналогичным образом можно зарегистрировать слушатели, находящиеся непосредственно в коде самого веб-приложения, при этом файл javax.servlet.ServletContainerInitializer должен находиться в каталоге WEB-INF/classes/META-INF/services.