Domine o Wildfly 8: Curso com foco em Administração e DevOps

Administração com Cluster de Alta Performance em ambiente DevOps.

Novidades do Curso além dos recursos novos do Wildfly

No curso existe uma máquina DEVOPS (com ferramentas dev, como GIT, Maven) onde o administrador Jboss se aproxima mais no mundo DEV, pois ele aprenderá a gerar seu próprio build (pacote war) para fazer deploy Adicionaremos um capítulo de Cloud, onde o aluno tem a oportunidade de administrar um Jboss na nuvem através do projeto OpenShift da própria RedHat

Vários cursos da 4Linux em 2015 adotaram um pouco de Nuvem, Formação PHP, Formação FrontEnd usando esse mesmo projeto onde o aluno terá a oportunidade de publicar na nuvem o trabalho feito em sala de aula.

PERGUNTAS E RESPOSTAS:

1 – Quais são os nomes Jboss que existem no mercado?

O nome JBoss é usado para se referir a

•  Projeto Open Source do Servidor de aplicações Java EE que era o “JBoss  AS”, agora Wildfly
•  Produto Comercial do Servidor de aplicações Java EE que é chamado de “JBoss EAP”
•  A divisão de middleware Red Hat onde os nomes de produtos começam com  JBoss e não estão diretamente relacionados com servidores de aplicações
•  O ponto central de encontro de projetos Open Source Java patrocinados  pela Red Hat em jboss.org

2 – Dos nomes Jboss, o que cada um é? (Livre, só RedHat…)?

Para grande parte das pessoas, JBoss é um servidor de aplicações Java EE.

Além de emprestar o nome ao JBoss AS e JBoss EAP, JBoss é a divisão de  middleware da Red Hat e também é o ponto central de projetos Open Source em middleware relacionados a Java e com patrocínio da Red Hat em www.jboss.org.

Assim, produtos de middleware como ESB, Virtualização de dados e Servidores de aplicações tem nomes como JBoss Fuse, JBoss Data Grid e JBoss EAP. Destes apenas o JBoss EAP é um servidor de aplicações e seria o que grande  parte das pessoas chama de JBoss.

3 – Quais as diferenças entre cada um e porque foi criado Wildfly?

Wildfly é essencialmente a continuação do projeto JBoss AS com novo nome. A última série do JBoss AS é a 7, depois o nome passou a ser Wildfly para que não existissem dúvidas sobre os produtos JBoss Red Hat e com os diversos projetos dentro de JBoss.org onde o AS é um deles.

O projeto Wildfly sempre estará a frente do produto JBoss EAP. Tanto Wildfly quanto JBoss EAP procuram objetivos comuns de aderência a padrões, gerenciabilidade, estabilidade, escalabilidade e adequação aos cenários corporativos mais exigentes. Contudo, o projeto Wildfly permite maior agilidade para inclusão de novas funcionalidades e para integrar-se com novas versões de Java e de Java EE. O objetivo do produto JBoss EAP é ser um produto corporativo com ciclo de vida longo sem inserção de novas funcionalidades e com suporte comercial pela Red Hat.

O JBoss EAP segue numeração de versão majoritária conforme a versão da especificação Java EE alvo de certificação. Assim, o JBoss EAP 6.3 é certificado como produto que atende plenamente as especificações Java EE 6. Futuramente, um JBoss EAP 7 deverá atender plenamente as especificações Java EE 7 (JSR 342)

A numeração Wildfly/JBoss AS será baseada em funcionalidades dentro de um roadmap e serão independentes da versão do Java EE. Assim, o Wildfly 8 é certificado em Java EE 7, mas não é certo qual versão do Wildfly seria certificado em Java EE 8 (JSR 366) que no momento da escrita deste ainda está em estudos iniciais. Contudo, seria certo que a versão do JBoss EAP seria a 8.

4 – Quais as vantagens do Wildfly versão 8?

A gerenciabilidade, escalabilidade e leveza já conseguidos pelo JBoss AS 7 são ainda maiores no Wildfly. Além disso, é uma das poucas implantações *Java EE 7 Full Platform Compatible, ou seja é um dos poucos servidores de aplicação prontos e certificados para uso em projetos Java EE 7.

No momento da escrita deste, apenas 4 plataformas eram certificadas: http://www.oracle.com/technetwork/java/javaee/overview/compatibility-jsp-136984.html

 5 – Como é a migração para Wildfly? Quais preocupações deve-se ter na migração?

Migração é sempre dependente do histórico da aplicação é das práticas de desenvolvimento e de operações seguidas. Em aplicações que seguem padrões Java EE, a migração passaria por etapas como verificações de itens antes disponíveis por bibliotecas externas e agora fornecidas pelo servidor de aplicações, mudanças em descritores, empacotamento e por final em código propriamente ditos. Em aplicações com alta aderência a padrões entre versões recentes de JBoss AS (7,6), a migração é mais tranquila.

Para os demais casos, é necessário uma equipe que possa adequar, a partir das funcionalidades e especificações da aplicação a ser migrada, a aplicação a uma arquitetura Java EE e quando possível fazer separação de funcionalidades para migração em etapas.

Clique aqui e conheça nosso Curso Wildfly 8 

CURSOSCONSULTORIACONTATO