Неделю назад мы выпустили версию WildFly 8.0.0.Alpha3. Как обычно, загрузка доступна на странице загрузок WildFly . Этот выпуск выйдет в течение месяца после выпуска 8.0.0.Alpha2. В соответствии с целями WildFly 8, этот новый выпуск содержит дополнительную поддержку EE7, некоторые исправления ошибок, а также некоторые специфические функции WildFly. Полные примечания к выпуску доступны здесь .
В этой статье я расскажу некоторые подробности об одной из функций WildFly, реализованной в этом выпуске.
WildFly порты
Традиционно WildFly и ранее названный JBoss AS открывали разные порты для разных протоколов и связи. Например, в JBoss AS7, а теперь и в серии WildFly 8 по умолчанию сервер открывает порт http (по умолчанию 8080), порт удаленного взаимодействия (который поддерживается JBoss Remoting и по умолчанию 4447) и другие подобные порты для использования. приложениями, развернутыми на сервере. Одна из целей WildFly 8 (Final) — открыть один порт для всех типов связи. Это предназначено для того, чтобы администраторы могли лучше контролировать сервер (например, правила брандмауэра).
Поддержка HTTP-обновления в Undertow
Как некоторые из вас уже могут знать, серия WildFly 8 теперь использует
Undertow в качестве веб-контейнера. Undertow поддерживает стандартную функцию, которая называется
HTTP Upgrade . Как можно прочитать из этого RFC, эта функция позволяет протоколу HTTP переключаться на другой протокол, основываясь на наличии заголовка в данных протокола. Эта функция обновления HTTP выступает в качестве основы предлагаемой функции «единый порт для связи» в WildFly.
EJB-вызов по HTTP
Теперь, когда у нас есть некоторые сведения об обновлении HTTP, давайте перейдем к деталям о новой функции, которую представляет WildFly 8.0.0.Alpha3. Вплоть до WildFly 8.0.0.Alpha2 (и ранее в серии JBoss AS7) проект под названием JBoss Remoting был основным протоколом для удаленной связи с сервером. По умолчанию связь осуществлялась через порт 4447. Многие из вас знакомы с этим портом, поскольку именно это вы использовали при поиске EJB-компонентов с удаленного клиента.
Начиная с WildFly 8.0.0.Alpha3 (т.е. этой новой версии), этот порт больше не открывается WildFly по умолчанию. Так как же вызвать EJB или даже использовать удаленное именование (которое тоже использовало этот порт), начиная эту версию? Ответ прост: эти удаленные клиенты теперь должны будут использовать порт HTTP, который по умолчанию является портом 8080. Остальная часть кода останется прежней. Этот порт HTTP управляется сервером Undertow, который, как я говорил ранее, поддерживает HTTP Upgrade. Внутри проекта клиентского API EJB (который является специфическим проектом JBoss, связанным с удаленными вызовами EJB) выполняется необходимая сантехника, чтобы запросить Undertow переключиться на протокол «Remoting» JBoss при обмене данными через этот порт HTTP. Затем Undertow переключает протокол на «удаленное взаимодействие»и остальная часть сообщения прозрачно происходит, как если бы это был обычный вызов на удаленном порту.
Итак, давайте посмотрим некоторый код, чтобы понять, что именно меняется с предыдущей версии на новую версию с точки зрения удаленного клиента. Давайте возьмем пример jboss-ejb-client.properties, который используется для вызова EJB. Ранее вы, вероятно, имели:
remote.connections=default # the server hostname/IP remote.connection.default.host=10.19.20.12 # the port for communication remote.connection.default.port=4447
(и некоторые другие свойства)
Начиная с этого выпуска, меняется только номер порта в этих свойствах, остальная часть остается неизменной. Так:
remote.connections=default # the server hostname/IP remote.connection.default.host=10.19.20.12 # the port for communication (the HTTP port) remote.connection.default.port=8080
Вот и все с типичной клиентской точки зрения.
Чтобы узнать о других новых функциях и исправлениях ошибок, ознакомьтесь с заметками о
выпуске .