A algum tempo fiz um post sobre o Dukescript e agora vou colocar as minhas impressões sobre essa pequena experiência com a tecnologia. Pontos positivos binários multi-plataforma sem complicações - a build abstrai toda a complexidade na geração do binário; separação MVC bem clara - a view, o model e o controller são muito bem separados na arquitetura do Dukescript; utilização de HTML5 e CSS - a parte visual da aplicação fica muito mais rica e simples utilizando o HTML5 e CSS; o Java de volta ao browser - utilizar Java em navegadores sem plugins ou applets é excelente; utilização de bibliotecas Javascript - Jquery, Knockout etc podem ser utilizadas facilmente pelo Dukescript; facilidade para testes automatizados - a estrutura do Dukescript permite a criação fácil de testes automatizados para cada camada da aplicação; sem redeploys - ao salvar o código só é necessário efetuar um reload na aplicação, para o mesmo ser refletido na aplicação.
No último post fiquei devendo uma explicação de como criar um Servlet, é bem simples basta só seguir alguns passos: criar e compilar o servlet no ambiente de desenvolvimento; copiar o arquivo compilado para o ambiente de implantação; criar o web.xml (deployment descriptor) nos dois ambientes; reiniciar o tomcat e testar o servlet. Como o objetivo é entender o funcionamento, irei fazer os exemplos apenas com um editor de texto e a linha de comando (abandonando o eclipse), mas lembro que em um ambiente utilizando IDE muito desses passos são automáticos.
Antes de ver a estrutura de arquivos e diretórios, irei explicar um pouco sobre o padrão MVC dentro do contexto da certificação, para ajudar a entender alguns pontos mais adiante. O padrão MVC significa Model-View-Controller (Modelo-Apresentação-Controlador), onde o Model é o arquivo java (onde está a lógica de negócio), a View são as páginas JSP e HTML (disponibilizadas para o usuário) e o Controller é o Servlet que atua como um intermediário entre os dois anteriores.
Após muito tempo trago mais um post sobre Go, confesso que a demora foi devido a o meu interesse atual pelo Dukescript, que me fez deixar de lado um pouco os estudos do Go. Mas decidi retomar aos poucos os estudos da linguagem revendo meu pequeno projeto de manipulação da API web do Steam. HTTP em Go/Golang Para usar a api do Steam precisei manipular chamadas HTTP e logo descobri que pode ser feito facilmente com a utilização do pacote net/http e net/url do Go.
O fundador do projeto Netbeans e arquiteto de software Jaroslav Tulach com Anton Epple consultor e instrutor Java, ganharam o Duke’s Choice Award de 2014 ao apresentarem o Dukescript, uma tecnologia que tenta trazer o Java mais próximo da visão inicial de seu criador de levá-lo a todos os dispositivos escrevendo apenas um código (Write Once, Run Everywhere). Para isso utiliza o HTML5/Javascript como mecanismo de rendering e o Java no lado cliente (sem plug-in!
O ciclo de vida do servlet passa através dos seguintes estágios: carregamento da classe servlet; instanciação da classe servlet; inicialização; serviço; destruição. Lembrando que um servlet não tem um método main() sendo controlado pelo container. Segue uma figura representativa do ciclo: Interação cliente-servidor O que acontece quando uma request vem do browser? Vejamos esse código html: <form action="HelloServlet" method="POST"> Quando clicamos no botão de submit do form em questão o browser envia a solicitação para o container e o mesmo identifica que a solicitação é para um servlet e cria dois objetos, um do tipo HttpServletRequest e um * HttpServletResponse*.
Quando ouvi falar da linguagem Go em 2009 achei muito interssante, a sintaxe proposta para a utilização de concorrência por goroutines, de duck typing e garbage colector, mas na época eu não fiquei interessado o suficiente para querer aprender a linguagem. Alguns anos se passaram desde então e eu senti a necessidade de aprender uma nova linguagem (principalmente após ler o livro O Progamador Apaixonado) e decidi pelo Go por ser bem diferente de Java (pra me tirar da zona de conforto) e por ser compilado.
Antes de escrever sobre a comunicação com o cliente HTTP, vou colocar aqui alguns benefícios da tecnologia Servlet do Java: Os servlets são independentes de plataforma, pois são integrados na tecnologia java; são mais leves que os processos CGI (Common Gateway Inteface), já que cada requisição não gera um novo processo no servidor; oferecem segurança, escalabilidade e robustez; são integrados com toda a API J2EE tirando proveito de todos os serviços disponíveis como JNDI, JTA, JAAS e RMI.
A arquitetura web é baseada no modelo cliente-servidor onde o cliente faz uma requisição (request) para obter uma resposta (response). Para esse processo é necessário que os dois lados da comunicação possuam uma forma padrão de comunicação, um protocolo, para se entenderem no ambiente heterogêneo que é a Internet. O protocolo para a navegação de páginas é o Hypertext Transfer Protocol o famoso HTTP, que define um formato para as requests e responses, composto de um header (cabeçalho) e um body (corpo).
Após procrastinar por muito tempo os estudos para a certificação (e deixar meu blog abandonado), devido ao trabalho e “desculpinhas” que sempre encontro para justificar a preguiça, decidi retomar os estudos e ao mesmo tempo movimentar meu blog. Aqui irei descrever os passos que estarei fazendo, abordando os assuntos a medida que eu for estudando e quem quiser pode contribuir com comentários e críticas construtivas (por favor!). Para o estudo vou utilizar o livro OCEJWCD Study Companion que um amigo meu me emprestou, e para praticar os assuntos vou utilizar o Tomcat junto com o Eclipse e/ou Netbeans postando aqui todo código produzido.