sábado, março 29, 2008

Jira and Enterprise Architect Integration

Click here to see more about Jira, Enterprise Architect and Excel integrations.

Primeiro a imagem (porque eu preciso dela). Depois eu conto o resto :)


sexta-feira, março 21, 2008

Bem Vinda, JSR 303 - Bean Validation

Foi ontem que o Harold, do JCP mandou o email avisando que a Early Draft da JSR 303 está sob júdice do público. Sim, temos a primeira versão candidata da especificação para validação de beans, ou a Bean Validation.

Eu esperava essa JSR há tempos, e não perdi nenhum segundo a mais e fui logo imprimir as 43 páginas para me deliciar nesse fim de semana (sim, sou daqueles que não consegue ler PDF's).

Devido eu estar brincando (quase que literalmente) com clusterização no JBoss, eu não pude avançar mais do que as cinco primeiras páginas do documento. Logo, esse post também é um draft :)

Antecipo, porém, que quem ler a especificação não vai encontrar nada de (muito) novo em relação aos conceitos do Hibernate Validator, já nosso conhecido.

DDD, Anotações e Validadores
Na prática, a ênfase é seguir a Driven Domain Development (DDD), colocando todo o necessário nos beans da aplicação na forma de anotações. Essas anotações são resolvidas pelos validadores e, enfim, a aplicação cliente encarrega-se de mostrar as mensagens de erro produzidas.

Dispenso maiores comentários, pois, como disse, o Hibernate Validator é a base de tudo. Entretanto, registro que gosto de funcionalidades como a busca recursiva no grafo de objetos, a separação de validadores por grupos e o suporte de overriding através de XML (herança do EJB3).

Estilo
O Emmanuel (amigo do Gavin) está fazendo um bom trabalho sim. Mas quem lê o conteúdo desse draft, percebe logo que ela é bem mais baixo nível que uma JSR 220 ou 318 "da vida". Nada contra, mas são estilos de escrita diferentes. E aprovo esse estilo técnico também (embora em excesso ele possa ser tendencioso).

Pontos em Aberto
Alguns pontos estão em aberto na JSR. Ênfase para a escolha das anotações que serão as padrões (built-in) no framework e como será o mecanismo de overriding XML. Também o processo de bootstrapping parece não estar bem definido e o suporte EL não foi mostrado com carinho.

Até o dia 19 de Abril próximo (e claro, eu acredito que nessa data vocês podem colocar mais uns 45 dias) o comitê está aceitando sugestões para avanços nessa especificação. Assim, participem, meninos!

Pra quando e pra quem
A seção 2.3 do modelo 2.6 do JCP solicita a versão target da JSR. Nesse caso, visto que ela é em anotações (JSR 175), essa JSR deve funcionar apenas com JDK 1.5 ou superior. Isso caracteriza uma tendência óbvia - que o pessoal do Merlin (codinome do JDK 1.4, e não do gerador de IU...) está definitivamente indo para escanteio...

Quanto à inserção no Java SE, correm as línguas que o Dolphin (Java 7) deve trazer o pacote javax.validation junto. E isso é uma boa, pois nesse mesmo período deve estar chegando o Java EE 6 (JSR 316), a JPA 2.0 (JSR 317) o EJB 3.1 (JSR 318), o Swing Framework (JSR 296), o Web Beans (JSR 299) e outros releases importantes.

Sim, estamos em um limiar e 2009 promete.

sexta-feira, março 14, 2008

3PUP com acesso publico

Breve,

O 3PUP é uma parceira entre a 3Layer e a Pandorga, o qual visa a definição de uma metodologia unificada para desenvolvimento de sistemas enterprise com métodos ágeis e em plataformas diversas - atualmente Java EE e .NET.

Embora cada empresa (3Layer e Pandorga) vão implementar essa metodologia utilizando tecnologias e ferramentas próprias, a definição dessa metodologia é agnóstica em relação a isso.

Diversos conteúdos estão sendo disponibilizados nesse projeto, incluindo documentação textual, vídeos e, claro, muitos diagramas que cobrem todos os processos da metodologia.

Até hoje, esses trabalhos estavam operando internamente nas empresas, mas agora decidimos publicar seu conteúdo para Internet.

No link http://3layer.no-ip.info:6666/confluence/display/3PUP vocês podem ter acesso aos primeiros drafts que estão sendo colocadas na wiki.

Contribuições
Quem quiser contribuir com comentários e sugestões é bem vindo.

O status desse projeto é Alpha e um Estudo de Caso está sendo desenvolvido para um sistema de média complexidade para gerenciamento eletrônico de documentos (GED).

Acreditamos que uma versão estável dessa metodologia esteja disponível para o terceiro trimestre desse ano e, tão logo isso ocorra, deveremos estar homologando ela frente ao MPS Br.

quarta-feira, março 12, 2008

Finalmente, Top One

O Antes
Há quase dois anos postei o primeiro post do Telas de Cadastro. Naquela época, meu interesse era falar sobre assuntos relacionados a esses famigerados artefatos que consomem horas e horas de trabalho dos melhores programadores.
Nesse meio tempo, abordei assuntos diversos e, sempre tendencioso, insinuei o framework Merlin como uma solução para esses tempos perdidos.
Mas, enfim, o tempo passou. Vários posts foram colocados no ar e esse blog acabou dando origens a outros diversos, como o blog do Magoo, o blog do Merlin e alguns do mundo underground (embora sobre esses eu ainda não possa falar).
Nesse meio tempo, sempre procurei a expressão “telas de cadastro” no Google para saber em que pé anda esse blog. Ficava triste sempre pois, embora ele fosse Top Ten, ela não era Top One.

O Agora
Hoje, porém, após 68 posts, as coisas mudaram. Ao buscar “telas de cadastro” no branquelo, retornamos em primeiro lugar.
Fiquei muito feliz, uma vez que a política de grafos do Google nos deu a primeira colocação. Em palavras simples, de todas as páginas que sofreram o seu crawling (e acreditem, é muita coisa), a expressão Telas De Cadastro é Top One aqui.

O Futuro
Espero que eu consiga manter esse hit. Vou me empenhar em dedicar tempo para o blog e sempre que possível, achar assuntos de interesse para todos nós programadores.

Um abraço a todos e boas Telas de Cadastro.

segunda-feira, março 10, 2008

EJB 3.1, preparem-se

É, Bill Burke bem que tentou, mas ainda não será dessa vez que teremos “EJBs POJO”. Sim, estou falando do draft da JSR 318 que saiu no último dia de Fevereiro e que deve fazer parte da Umbrella JSR 316.

EJBs POJO podems ser vistos como classes Java normais, as quais simplesmente estão marcadas com @Stateless ou @Stateful e não precisam implementar nem estender nada. Seria algo como:

@Stateles class Clientes {

public double getSaldoConsolidado(Cliente c) {

// código EJB

}

Para os menos atentos, observem que um código do lado cliente seria algo como:

Clientes clientes = ServiceLocator.getInstance().lookup(Clientes.class);

double saldo = clientes.getSaldoConsolidado( new Cliente(1234));

System.out.println(saldo);

Sacaram? Pois bem, é justamente essa a discussão que o tio Bill puxou no seu site. Muita gente discordou, porque agumenta que o cliente teria acesso ao código da implementação do EJB (visto que não existe mais uma interface client para eles) ou que existiria um alto acoplamento entre lado cliente e lado servidor, ou...bem, vários argumentos!

Tio Bill enfatiza que isso seria um improvement, mas mesmo assim não pegou e, pelo menos nessa versão 3.1, ainda não teremos Enterprise POJOs...

O que teremos, então?

Mesmo não tendo EJBs realmente planos, teremos uma série de outras features, há muito aguardadas. Para ser enxuto, replico aqui o que diz a seção 1.2 da nova especificação (ainda em draft até o próximo dia 30):

  • Acesso direto de EJBs pela camada web dentro do mesmo EAR: A anotação @EJB já é uma commoditie (mesmo que sistemas homéricos tendem a subestimá-la) e é uma mão na roda para chamadas entre serviços dentro do container EJB. Ela encarrega-se de propagar o principal da chamada e todos os trâmites para gerenciamento das transações na aplicação. Porém, a boa nova é que agora ela pode ser usada diretamente pelo container web. Assim, um código de servlet pode injetar EJBs sem se preocupar com lookups por classes utilitárias. Claro, um certo overhead (?) de configuração pode ser necessário, a fim de garantir que as roles na web e nos EJBs sejam compatíveis. Também, devemos ter o cuidado disso tudo estar no mesmo Application Unit e temos o inconveniente de ter que usar (sempre) referencias locais e não podemos distribuir a aplicação em JVMs e containers separados (exceto ativando Trusted Connections). Mesmo assim, é uma benévola para os desenvolvedores web e, claro, essas limitações que eu comentei são coisas intrínsicas ao padrão atual e, com sorte, em um Java EE 7 ou 8 isso deve ser eliminado.
  • Empacotamento de EJBs dentro de arquivos WAR: Para mim, isso não é um grande benefício. Quem usa ANT ou Maven (ou qualquer outra ferramenta do gênero) não se preocupa muito nesse tipo de picuínha. Porém, pode ser uma diferença grande no ambiente de execução. Se o container for Java EE certificado, ele devera colocar para funcionar o .WAR integralmente, com as JSPs e também com os EJBs. Isso me lembra muito o Tomcat com o EJB Embedded e parece que os caras estão começando a misturar as coisas. A palavra Web ARchive deveria exprimir a função do pacote, mas pelo jeito ela também agora é outra commoditie. Não li muito sobre as entranhas disso ainda mas, enfim, essa tendência de reduzir artefatos está mesmo em voga.
  • EJBs Singleton: Isso me deixa feliz. Mas em parte. Primeiro, feliz por ter singletons em EJBs. Aos puristas, vão reclamar que isso pode ser pesado e que pode trazer outros malefícios, como afunilamento de chamadas de clientes e tal. Mas isso é um engano. Quem nunca tentou fazer um código maluco para simular (sim, simular) singletons em EJBs que atire a primeira pedra! Se não tentou ainda, é porque não teve que passar por mal bocados. Singletons em containers é uma tarefa difícil, e em ambientes de alta concorrência a coisa pode render boas noites de pizza e coca-cola. Poder anotar um EJB com @Singleton, e indicar ainda se ele vai ter dependências de inicialização, comportamentos @ReadOnly, @ReadWrite ou ainda se vai ser gerenciado manualmente (tal como os famigerados modelos BMP para os Entity Beans) é, sem dúvida alguma, um ponto positivo nesse release da especificação. Porém, fico triste de os caras não terem ido além (sim, talvez eu seja muito perfeccionista mesmo). Singletons são garantidos por container e, assim, em ambientes clusterizados cai novamente para o desenvolvedor a tarefa de comer pizzas nas madrugadas.
  • Timers criados automaticamente: Isso é outra coisa que eu aprovo. Até a versão 3, tínhamos que explicitamente ativar um EJB de timer para, somente então, ele começar a trabalhar. Agora, com as features de @Startup, as coisas mudam de figura. Em tempo de deployment o container já se encarrega de localizar e ativer os timers conforme nossa necessidade. Nada mais de consoles com métodos admistrativos (muitas vezes operando com sistema de autenticação diferenciados e avessos aos interceptadores padrões do sistema) para ativar essas pecinhas!
  • EJBs Assíncronos: Isso só pode ser herança do AJAX. Mas é uma herança boa, ao meu ver. Também, até a versão 3, toda chamada para um EJB é síncrona, o que implica que o cliente (ou melhor, a thread chamadora deste) deve ficar parado até que o retorno do método de EJB ocorra. E isso pode ser um tempo perdido muito grande. Soluções seriam usar AJAX (e fazer uma sincronização manual no lado cliente) ou lançar mão de JMS para esses métodos mais demorados. Agora, poderemos usar em tranquilamente a API java.util.concurrent.Interface Future, que já existe no Tiger há muito tempo... Com isso, o cliente deixa de ficar ocioso e pode trabalhar tranquilamente até que sua requisição EJB tenha uma resposta. Como Future é um objeto criado pelo servidor e retornado para o cliente, o cliente tem um link do servidor para, tanto monitorar o momento em que uma reposta ocorra, tanto para...cancelar sua requisição. Isso mesmo, diferente de AJAX, que o cliente deveria lançar outra requisição de EJB (e fazer uma lógica maluca para garantir o funcionamento de requisições Stateless no pool do servidor) para efetuar o cancelamento da chamada original, agora Future encapsula tudo para nós e deixa tudo transparente. Imaginem as possibilidade, meninos...
  • Profiles: Lembram do Java ME e seus profiles? Pois bem, agora a Java EE está nessa onda também. A idéia é que, como a tecnologia Enterprise do Java está crescendo muito e, por isso ela pode facilmente se tornar um canhão para matar moscas, a própria especificação já cuide para criar subconjuntos de componentes para os containers. Seria como ter um container Web, um container Web com EJB Light, um container WebService com EJB, etc. Na prática, isso já vem sendo implementado pelos containers atuais, como o JBoss, que traz seus diretórios minimal, default e all. A diferença é que agora a Umbrella estaria ditando quais são esses profiles e o que deveria existir dentro deles. As picuinhas entre os prós e contras é grande, sendo que uns argumentam que isso não deve ser preocupação do JCP ou que abriria brechas para meias-certificações, algo como um provider certificar somente parte do seu servidor e o restante deixar numa versão mais antiga, ainda não homologada pelo TCK. Na minha opinião, tanto faz.

Conclusões

Conheço muita gente que ainda nem usa o JDK 5. Muitos também são avessos às anotações, tipos genéricos e conceitos um pouco mais avançados, como Resources, Múltiplos Classloaders, WebServices, etc. Para todos eu digo: corram (bastante), rapazes!

Java evolui a passos largos, e se a tendência é seguir novidades oriundas do pessoal do Spring, Ruby, Smalltalk, Groovy e outros. Assim, um ajuste pequeno como esse na especificação EJB deveria se passar como manteiga sobre o pão.

Para mim, todas as features são bem vindas e, para ser sincero, espero muito mais para os próximos releases. Se a idéia do tio Bill de usar EJBs POJO não vingar, quiçá me deixem usar a mesma anotação para EJBs locais e remotos. Só isso já seria uma mão na roda.