Sun Tech Days 2008: Agora Vai!

Há algum tempo, escrevi que não sabia se haveria ou não Sun tech Days neste ano, pois costumeiramente o evento acontece em meados abril. Até que acessando www.suntechdays.com.br me deparei com uma grata surpresa

Está bem em cima da hora para não ter nem link de inscrição, mas o negócio é ficar atento. Tomara que o evento não seja tão absurdamente comercial quanto foi no ano passado!

SOA com Java EE, Parte I

No mais recente projeto java que rola por aqui de que tanto falo, as integrações com sistemas externos serão muito mais do que meras interações esporádicas, são parte essencial da captação de quase todos os dados que existirão no produto.

Sei que a maior parte do tão falado SOA não passam de um hype, sendo que tudo que existe hoje neste sentido parece muito mais com uma coleção de design patterns catalogados especificamente para organizar as aplicações de modo a minimizar os impactos de integrações com sistemas Back-End, mas de qualquer maneira, as possibilidades de utilizar-se deste paradigma em Java são bastante interessantes, e é a respeito desta experiência que tivémos na última semana é que irei tentar reportar.

Como já falei, o projeto em questão receberá quase que 100% de suas informações a partir de dados provenientes de sistemas Back-End do cliente, utilizando-se maneiras e protocolos diversos. Dado o cenário, observamos a necessidade de separar os processos de integração do sistema de sua semântica, de seu objetivo. Neste sentido, as perspectivas ofertados pelo paradigma SOA parecem surgir com certa precisão para alcançar esta meta. Como em Java sempre existe a liberdade de escolha, que nos permite alcançar o mesmo objetivo utilizando-se diversos frameworks e produtos, existem diversas alternativas para implementar aplicações que utilizam o paradigma SOA. O importante nesta situação é optar por alternativas que seguem alguma API ou especificação JSR. isto lhe trará seguranças em diversos aspectos, principalmente ao vender (ou tentar vender) seu produto.

As APIs em Java que trarão o paradigma SOA à sua aplicação, fazem parte da JSR 208 - JBI (Java Business Integration). As características completas da especificação podem ser encontradas aqui, mas em essência diria que API foi construída no modelo de Web Services, integrando os consumidores e provedores de informações através de componentes plugáveis, chamados de Service Units (SU). Estes componentes plugáveis são divididos em duas categorias (se é que posso dizer assim):

• Binding Components (BC): São os componentes que representam os meios de acesso ou consumo da informação necessária, ou do seu próprio processo. Dentre os BCs existentes, teríamos por exemplo: SOAP, HTTP, FILE, Message Queue, CICS e etc, implementando portanto, como consumir ou disponibilizar determinada informação.
• Service Engines (SE):  São componentes que fazem parte do seu processo de integração e realizam tarefas específicas. Poderíamos ter por exemplo, service engines que executam tranformações de strings XML, acessam bases de dados, objetos EJB ou outros web services.

Os processos de integração que utilizam BCs e SEs em ambiente JBI são realizados de diversas formas, dentre elas processos BPEL, onde podemos harmonizar todas as condições nas quais as interações entre nossos componentes devem acontecer, em qual tempo e em qual ordem. A composição dos diversos SUs, dá origem a uma aplicação composta, chamada de Service Assembly (SA).

O interessante nisto tudo é ressaltar que o JBI define as formas (dentre muitas outras coisas) nas quais os componentes BC e SE devem ser construídos, quais interfaces devem implementar e quais arquivos xml devem ser providos.Isto facilita e muito a adição de novos Service Units, tornando a adição de novas tecnologias como CEP por exemplo, muito facilitada. Um viva aos padrões!!!

Durante a avaliação dos JBI Servers gratuitos que implementem JBI e que possuísem fonte aberto, os produtos que comparei por um tempo foram esses (não tive muito tempo, mas acho que o que pude ver foi bastante satisfatório):

Apache ServiceMix - Esta é a implementação JBI da Apache Software Foundation. Apesar de parecer bastante simples ao fazer download, minha impressão a respeito do ServiceMix é que ele não serve muito bem para iniciantes. Faz-se necessário um conhecimento bastante grande a respeito de suas especificações, das estruturas de diretórios necessárias, dos arquivos xml de configuração e por aí vai… Não consegui encontrar nenhum plugin para o eclipse que realmente tenham valido a pena, ou que me poupassem ao menos metado do trabalho necessário para publicar uma aplicação “Hello World”. Um problema grande (e bota grande nisso) é o fato de os tutorias publicados no site da Apache conterem diversos (e absurdos) erros, o que dificulta e muito seu aprendizado. Uma das coisas bacanas é a disponibilização de diversos builds Maven para empacotamento dos deploys.

Mule - Apesar de bastante utilizado e comentado, não implementa especificação nenhuma, portanto não pude olhar este cara muito a fundo. Segundo os artigos e tutorias que li, é bastante rápido, fáicl de gerenciar e de se usar. Como não segue nenhuma especificação, cuidado se escolhê-lo, você pode morrer abraçado a ele.

Open ESB - É de longe o mais fácil de se utilizar e um dos mais completos em termos de Binding Components disponíveis após download. Antigo See Beyond, hoje é a base da distribuição Java CAPS da SUN.  Seu uso através do editor CASA NetBeans é muito intuitivo e apresenta resultados muito de maneira muito rápida. Além do que, os tutorias disponíveis no site da comunidade NetBeans estão muito bem escritos e realmente funcionam. Possui integração facilitada com servidores GlassFish e JBOSS, o que o torna uma excelente opção tanto para aprendizado como para ambiente produtivo.

É isot, neste post procurei descrever de maneira um pouco abstrata talvez, como a plataforma Java soluciona os paradigmas SOA através de suas especificações e APIs, além de apresentar algumas opções de ESBs disponpiveis. Nos próximos POSTS, colocarei alguns exemplos interessantes de aplicações que não consegui encontrar na internet e tivemos que descobrir na marra. Também vou escrever a respeito de CEP, que parece ser algo bastante promissor daqui pra frente!

A importância (ou não) das notações

Há algum tempo (três anos, acredito eu) assisti uma palestra de algumas horas sobre metodologias de desenvolvimento e documentação de softwares. O palestrante era pesquisador do SEI, e seu foco de pesquisa no momento era a utilização de WIKIs como forma de documentação ágil de sistemas.

Independentemente de seu foco de pesquisa, o palestrante procurou enfatizar a importância da utilização de uma notação adequada ao documentar uma arquitetura. Mas o que poderia eventualmente significar “notação adequada” ? Pois bem, aí é que começa a bagunça.

Quem nunca se deparou com um “diagrama” recheado de círculos e/ou quadrados, com setas ou traços ligando os elementos?  Isso é o que mais vemos todos os dias, como por exemplo nesta imagem do site da SUN, contida dentro de um artigo sobre a VM java e como ela se relaciona com linguagens de script:

(http://java.sun.com/developer/technicalArticles/scripting/languages/images/scriptingengine.gif)

O exemplo acima traduz claramente o que o palestrante quis dizer. Na grande maioria das vezes as pessoas optam por expressar suas arquiteturas ou idéias, através de notações próprias e que muitas vezes não querem dizer nada para nenhuma pessoa além dela mesma. Isto é um problema? É e não é.

Não é um problema porque o objetivo é e sempre será expressar idéias, planos ou implementações da melhor forma possível. Além de que, não são todas as pessoas (eliminando os desenvolvedores (será?)) que conhecem notações como a UML por exemplo. Muitos de nossos superiores não conhecem ou não julgam ser adequado em determinados momentos, utilizar a notação UML. Isto é um fato que não podemos simplesmente desprezar, nem nos tornarmos xiitas a ponto de dizer que se não for assim não será feito.  Essas pessoas geralmente julgam círculos, quadrados, setas e desenhos contendo servidores como algo muito mais intuitivo, mesmo que não possuam uma notação extremanente formal a ser seguida nem sequer uma metodologia (por exemplo: círculos indicarem processos e retângulos armazenamentos). Mas aí é que a coisa se torna um problema…

Esse tipo de diagramação torna-se um problema a partir do momento em que não definimos o que cada símbolo representa no contexto expresso. No exemplo acima retirado do site da própria SUN, esta definição  não foi feita. A não ser que tentemos adivinhar o que cada um dos símbolos representa, não conseguimos afirmar com propriedade que os quadrados representam os módulos da VM e as setas uma possível comunicação entre eles (pelo menos é o que me parece). Mas e se não for isso? E se o autor quis dizer uma outra coisa completamente diferente como por exemplo, indicar que as setas fechadas são chamadas de bibliotecas nativas e e as abertas são chamadas entre classes java? Não iremos saber, de forma alguma…

O que é importante ressaltar é que não é incorreto utilizar sua própria forma de expressar uma arquitetura ou idéia. O importante é descrever em qual notação ela foi feita, ou até mesmo dizer que não é uma notação definida, sendo que neste caso, a legenda contendo a indicação de cada um dos símbolos bem como o que significam deve estar presente. No caso de uma notação mundialmente conhecida ao menos seu nome precisamos referenciar, obrigatóriamente. Caso apresentemos um diagrama de classes UML por exemplo, devemos sempre colocar próximo a ele ou em um rodapé, mesmo soando redundante para nós , o dizer: NOTAÇÃO UML.

O exemplo da SUN de forma mais correta portanto, seria algo do tipo (não sei se está certo, se eles tivessem colocado uma legenda, não me induziriam ao erro! )

É isto! Parece ser uma bobeira tremenda e até mesmo causar certo espanto, mas quanto mais formos claros em relação à documentar ou apresentar uma idéia ou arquitetura, teremos menos desentendimentos e dores de cabeça em nossos projetos!!

As ofertas de emprego java continuam

Há algum um tempo, postei que a empresa em que trabalho oferecia vagas para desenvolvedores java. Disse também que estaríamos recebendo os currículos no máximo até o final de junho.. Pois bem, as coisas sofreram um certo atraso e portanto, ainda estamos recebendo currículos.

Além do já mencionado, seria bastante interessante se os candidatos possuíssem:

• Conhecimentos em algum framework ESB, de preferência Apache Service MIX, MULE ou Java CAPS
• Conhecimentos em métodos de forecasting, como Redes Neurais ou métodos de regressão linear.

Novamente, os conhecimentos provavelmente não são obrigatórios, mas provavelmente farão uma diferença grande durante a seleção!

Visual Basic 6: Expression too complex

Java para mim representa duas coisas: meu ganha pão e minha inspiração. Porém, como todo desenvolvedor de hoje em dia não pode ficar limitado a determinada plataforma, também não fico restrito apenas a codificar em Java. Uma das coisas que trabalho, e que já trabalhei bastante, é com plataforma Windows DNA, utilizando ASP3, VB6 e COM+.

Se eu gosto? Não não gosto, mas muitas vezes a profissão obriga. Temos muitos sistemas legados por aqui que a cada dois meses precisam de manutenções pontuais e portanto não podem ser desprezados. Em duas oprtunidades, em manutenções deste tipo, obtive erros em tempo de execução simplesmente bizarros… Bizarros ao extremo eu diria. Citerei os dois campeões na minha opinião:

• 8000FFFF - Catastrophic Failure: Se você recebe uma mensagem desta tarde da noite, com cliente buzinando no ouvido para que o sistema volte a funcionar o que você faz ? Se você tiver uma pistola à mão, a resposta é bem simples… Não sei explicar até hoje como este problema foi solucionado. Ele simplesmente sofreu um processo de cura automático. Falei por dois dias com o suporte da Microsoft, que caia na Argentina, sem obter sucesso. Acho que algum patch automático enviado pels administradores de rede por questão de releases da Microsoft acabou solucionando o problema.
• Expression too Complex: Não é novidade que os seres humanos criaram os computadores para resolver seus problemas mais difícies. O que é novidade, é que a própria máquina passe a se recusar a solucioná-los porque também os considera difíceis demais!!!! Este problema ocorreu, porque segundo o Visual Basic, utilizei uma instrução muito, mas muito complexa, na qual reproduzo a seguir:
  

  IF (((CDbl((MesAtual) + getDiferencaMeses(tempMes))) - CDbl(tempMes)) <= (finalSufixo)) then …

Sim.. Este IF é tão complexo, mas tão complexo, que o Visual Basic se recusa a fazê-lo por você. Tá certo, o código poderia ser melhorado, mas até aí não conseguir resolvê-lo já é demais… Bota demais nisso!

JavaScript com Eclipse Ganymede

Neste artigo, comentei que o suporte para javascript no Eclipse Ganymede não estava funcionando corretamente. Na ocasião, utilizava o último RC do projeto e, aparentemente, somente arquivos do tipo .js eram bem aproveitados pelo mecanismo de autosugest do eclipse.

Pois bem, após baixar a versão oficial no lançamento, percebi que esse problema foi corrigido, apesar de o suporte para javascript continuar extremamente precário. Sou obrigado a admitir que neste ponto, o Visual Studio da Microsoft é realmente muito melhor que o eclipse. Ainda não vi um plugin realmente decente que faça o javascript sugerir coisas realmente importantes, como por exemplo, listar nomes de itens existentes em nossas páginas (forms, caixas de texto e etc).

O plugin mais interessante que vi funcionando, é o Simple JavaScript Plugin, mas dequalque maneira só funciona para arquivos com extensão .js. O interessante deste plugin, é a exibição do que funciona ou não em cada browser, exibindo um ínco ao lado da instrução. Como a última versão do plugin é de 2004, e aparentemente o projeto descontinuou, não consigo nem incluir um sreenshot desta visualização.. mas que era interessante era. Ainda assim, não era nada próximo às sugestões do Visual Studio, que funcionam bem legal desde o Visual Interdev (também para por aí, já até elogiei a Microsoft hoje, acho que preciso retomar minha sessões com a Dra Ângela).

De qualquer forma, o suporte para javascript no Ganymede em projetos que não são do tipo “Static Web Project” ou “Dynamic Web Project” não vem habilitado por padrão. Para que ele passe a funcionar, é preciso clicar em “Add JavaScript Support” sob as propriedades do projeto, como mostra a imagem a seguir:

Habilitando esta propriedade o suporte a javascript torna-se funcional ao projeto. De qualquer maneira, me parece que ainda existe um bug relacionado a isto porque muitas das vezes em que eu fecho e abro o editor, o suporte precisa ser adicionado novamente.

Apesar dos problemas até agora, esta versão continua me agradando. Conforme surgirem novidades vou postanto por aqui!

Eclipse Ganymede

Após muitas frustrações com a série de Eclipses Europa que foram lançados, a estabilidade e a correção de milhares de bugs efetuadas no Eclipse Ganymede soa como uma notícia excelente.Naixei ontem a última RC e a usabilidade estava incrível. Notei apenas alguns erros no paienl de logs, que aparentemente não comprometeram o uso em geral, mas logo em seguida percebi que já haviam sido apontados como BUG no bugzilla do projeto.

Todos os plugins que eu já utilizava (CheckStyle, FindBugs, FileSync, Mylyn e VSS) continuaram funcionando perfeitamente e isso representa muita coisa. Quando utilizávamos o eclipse Fall e logo em seguida o substituímos pelo Winter a coisa desestabilizou geral. Muitos plugins pararam sem a menor pista, mas desta vez a coisa tomou um rumo mais adequado.

O calcanhar de Aquíles continua sendo o auto complete de trechos javascript. Para a versão que baixei, este recurso não funcionou em arquivos .jsp nem .html, apenas em arquivos.js… Uma pena tremenda porque o que seu funcionamento em arquivos .js é excelente, muito melhor que os anteriores. Quando (e se) funcionar em arquivos de outras extensões aí sim teremos algo a celebrar de verdade!

IA com Java: Forecasting, Redes Neurais e Algoritmos Genéticos

Se em determinado momento de sua experiência profisisonal, por ocasião de um projeto um tanto inusitado para os padrões em que você e sua equipe vinham trabalhando até então, você se deparasse com uma questão que envolvesse um risco grande em relação à falta de conhecimento, receio em relação à custos de modo que ou você consegue uma solução técnica perfeita com viabilidade econômica, ou tudo iria para o mais profundo buraco negor, o que você faria? A partir deste instante, a primeira questão formulada em minha mente será: “Estou trabalhando com uma plataforma aberta, com uma comunidade rica e não egoísta, com trilhões de bibliotecas disponíveis gratuitamente?“.

Não sei se posso dizer que mais uma vez me surpreendi com as possibilidades oferecidas pelo Java. É simplesmente fenomenal, de imenso prazer e de enorme conforto o fato de você saber que trabalha utilizando esta plataforma, esta tecnologia.

Recentemente ganhamos um edital público bastante grande e interessante. Como em todo edital público, ou você faz ou você simplesmente nao atende, não existe meio termo. Neste edital em particular, um dos itens chamou a atenção de muita gente, o fato da possibilidade de um algoritmo de previsão de tendências numéricas. Aparentemente simples, mas não tão simples assim quando o custo final envolvido pode chegar a casa dos milhões facilmente em caso de desvios muito significativos na previsão sugerida.

O edital já havia indicado a plataforma a seguir, (Java obviamente, ainda mais se tratando de um órgão público) portanto nos restava oferecer a solução matemática mais próxima do ideal para alcançar o objetivo final. Após nos depararmos com módelos de médias lineares e móveis, o que mais foi indicado pela comunidade matemática e computacional de um modo em geral, foi a utilização da combinação de duas ferramentas poderosas: IA com Redes Neurais e Algoritmos Genéticos.

Java tem uma solução? Sim Java tem uma solução. Pronta. Estável. Gratuita (LGPL). Feita por uma comunidade incrivelmente atuante, da qual muitos de nós, e me incluo nesta também, as vezes se esquece de colaborar de volta.

Estou bastante sem tempo ultimamente, mas iniciarei uma série de posts a respeito de IA com Redes Neurais e como aplicar Algoritmos Genéticos para alcançar o Forecasting (previsão) mais próximo do ideal possível.

Nossa fonte de estudos estará concentrada na utilização dos modelos matemáticos, resolvendo a implementação em java através da utilização de uma integração entre o JOONE e o JGAP.

Pode ser que meus posts demorem, mas sairão!

Oferta de Emprego Java

Seguinte, a empresa em que trabalho abrirá um número considerável de vagas para desenvolvedores Java. O projeto é bastante ambicioso, de longo prazo mas com a entrega da primeira fase em um período bastante apertadod e tempo. As vagas são para São Paulo/SP, e os perfis que procuramos precisam possuir muitos, mas não todos, dos requisitos listados abaixo:

• Conhecimentos profundos em Java EE 5 incluindo o uso de padrões estabelecidos pela SUN.
• Conhecimentos avançados em EJB utilizando JBOSS, incluíndo JMS
• Conhecimentos em EJB3-QL.
• Conhecimento diversificado no que diz respeito a Design Patterns e teorias de desenvolvimento.
• Conhecimentos razoáveis de sistemas Operacionais Linux Debian ou Solaris
• Conhecimentos avançados em desenvolvimento de aplicações web, com pattern MVC.
• Conhecimentos de JSF
• Conhecimento de ferramentas de integração, como iBatis por exemplo.
  
• Conhecimentos em utilização de produtos de mensageria (por exemplo Mule) com integração a Websphere MQ
• Experiência em desenvolvimento de projetos com integrações a sistemas legados.
• Experiência em desenvolvimento web para projetos cross browser.
• Conhecimentos em UML 2
• Utilização de testes unitários com jUnit.
• Conhecimentos em SQL ANSI para utilização em bases de dados Oracle ou PostgreSQL

Trabalhamos em um ambiente bem legal, com vestimenta a gosto do desenvolvedor e horário bastante flexível. Quem acredita estar apto a uma conversa conosco, me enviem um email para mmilanez@gmail.com que agendaremos as entrevistas.

Se você ler esta mensagem até o final de junho/2008, acredito que ainda haja tempo de concorrer às vagas!

AutoBoxing e Expression Language

Hoje descobri mais um problema relacionado ao mecanismo de Expression Languages (EL) do Tomcat. Todos nós sabemos que para que uma propriedade seja corretamente utilizada em EL, ela necessariamente precisa ser declarada na classe como isXXX() ou getXXX(). Por exemplo, suponha uma classe Equipmento, como abaixo:


public class Equipamento {

…

public boolean isAtivo() {
return isEquipamentoAtivo;
}

public boolean getNumeroIP() {
return numeroIP;
}
}

Como os métodos que retornam precisam iniciar com ‘is’ (exclusivos para boolean) e ‘get’ para que funcionem corretamente em EL (e por boas práticas também), os exemplos acima já estão formatados de acordo com o adequado.

Suponha que esta mesma classe, foi adicionada a uma variável JSTL de nome equipamentoPrincipal. Para que pudéssemos invocar os métodos isAtivo() e getNumeroIP(), repectivamente, precisaríamos suprimir as letras iniciais ‘is’ e ‘get’, respecitvamente. Ficaria algo mais ou menos assim (tags html apenas para efeito de demonstração):

<html>

…

<font color=green> Equipamento está OK <b> ${equipamentoPrincipal.ativo}</b></font>

<font color=green> Número IP do Equipamento <b> ${equipamentoPrincipal.numeroIP}</b></font>

…

</html>

OK, partindo deste princípio e sabendo que a partir da versão 5 do Java, contamos com a facilidade do AutoBoxing ,  seria de se imaginar que caso eu declarasse o retorno do método isAtivo como Boolean (wrapper), meu EL  poderia funcionar corretamente.  Errado! Ocorre um erro em Runtime indicando que a propriedade não pode ser encontrada. Algo do tipo “Property ‘ativo’ not found on type package.path.Equipamento“. Provavelmente o interpretador EL do JSP não está adequado à gambi feita pela galera da SUN para adicionar o AutoBoxing ao JAVA….