понедельник, 20 февраля 2017 г.

Визуализация и тестирование 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.

понедельник, 16 января 2017 г.

Первое знакомство с 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, что приводит к проблемам, некоторые из которых описаны ниже.

четверг, 1 декабря 2016 г.

С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) принят другой подход. Целью данной статьи является продемонстрировать какие именно преимущества с точки зрения обеспечения высокой производительности можно получить, просто выбрав правильный тип драйвера.


четверг, 10 ноября 2016 г.

Знакомимся: IT Strategies from Oracle


Давно хотел написать об этой в целом неновой инициативе, но, работая в IBM, писать про Oracle глупо, в общем сложилось только сейчас.

Итак, IT Strategies from Oracle - это авторизованная библиотека руководств и описаний эталонных архитектур, которая помогает системным архитекторам и управленцам лучше планировать, строить и управлять архитектурой предприятия и IT-инициативами. Библиотека предоставляет два типа документов для описания лучших принятых в индустрии практик: практические руководства (содержат советы и подходы) и эталонные архитектуры (содержат проявившие себя технологические паттерны для быстрого запуска новых инициатив).

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


  • Overview documents - содержит описание каждого ресурса, доступного в библиотеке, и модели зрелости для лучших практик (best practices maturity models).

  • Oracle Reference Architecture (ORA) - определяет детализированную и полную архитектуру для разработки и интеграции решений, основанных на технологиях Oracle. Эталонная архитектура предлагает принципы и руководства, основанные на рекомендациях технических экспертов, работающих в Oracle. Она покрывает широкий спектр компонентов технологической архитектуры: программное обеспечение промежуточного слоя, базы данных, аппаратное обеспечение, процессы и сервисы.

  • Enterprise Technology Strategies (ETS) - предлагают ценные руководства по внедрению горизонтальных технологий на предприятии. Эти документы раскрывают как успешно реализовать стратегию путем решения вопросов с архитектурой, технологией, разработкой, стратегией и управлением. Организация может использовать данные материалы для измерения своего уровня зрелости, разработки собственных стратегий и достижения высокого уровня успешности. Дополнительно ETS расширяет Oracle Reference Architecture путем добавления уникальных возможностей и компонентов, предлагаемых конкретной технологией.

  • Enterprise Solution Designs (ESD) - специфичные для той или иной индустрии решения, основанные на ORA. Они определяют необходимые для построения решений уровня предприятия высоко-уровневые бизнес-процессы и функции, а также возможности лежащей в основе технологической инфраструктуры.

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

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

Суровый однозначно рекомендует к изучению.

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

пятница, 27 мая 2016 г.

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

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

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



понедельник, 18 апреля 2016 г.

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

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



среда, 23 марта 2016 г.

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

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

Железо, ОС, 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, надо отдать должное, более активен.

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

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