Para um novato Java que queira criar um EJB na especificação 3.1, o processo é muito simples. Você cria uma classe Java e com apenas uma anotação você tem um objeto distribuído que responde via protocolo RMI/IIOP.

Se você desejar criar um objeto distribuído que responda através de SOAP, i.e, um WebService, basta adicionar uma outra linha de código, conforme mostrado abaixo.

Entretanto, se olharmos as especificações anteriores do EJB, veremos que esta simplicidade foi alcançada depois de muito trabalho na remoção de complexidades.

Por exemplo, o mesmo código em EJB 3.0 requer uma classe e duas interfaces Java, conforme mostrado abaixo:

Mais impressionante é notar que na especificação EJB 2.1 este mesmo exemplo seria implementado como uma interface local, uma interface remota, uma interface home, uma classe de implementação de negócio, uma classe de implementação da interface home e alguns arquivos XML. Um exemplo arqueológico pode ser encontrado aqui para os mais curiosos. Para criar um único método distribuído, precisamos de várias dezenas de linhas de código.

Se observamos ainda mais atrás no tempo um objeto CORBA, fonte de inspiração dos primeiros EJB, veremos ainda um código mais complexo.

Felizmente temos observado este movimento de simplificação de APIs em vários outros lugares da API Java. O JBOSS Seam inspirou a simplificação do JSF na nova especificação do JSF (JSF 2.0), conforme podemos observar neste artigo em anexo.

O modelo de servlets também foi simplificado. Agora podemos ter Servlets que são configuradas puramente com anotações ao invés de arquivos XML, conforme podemos ver no exemplo abaixo:

Um ambiente que já suporta estas novidades de simplicidade é o NetBeans 6.8. Notavelmente, o NetBeans tem conseguido “roubar” muita audiência dos desenvolvedores Java justamente por ser mais simples do que o poderoso (mas complexo) Eclipse. Para os programadores Java que nos leem, um tutorial é fornecido aqui.

Pensamento do dia: “Tudo deveria ser mantido o mais simples possível, mas não mais simples que isso”, Albert Einstein.

Pensamento do dia seguinte: “Se em tudo o mais forem idênticas as várias explicações de um fenómeno, a mais simples é a melhor””, William de Ockham

No Budismo, o caminho do meio (madhyamā-pratipad, em sânscrito) é a prática de ensinamentos que nos afastem das vaidades, extremismos e nos guiem a uma busca por mais sabedoria, moralidade e raciocínio. No mundo Java e .NET, o caminho do meio possui o mesmo conceito. Gostaria de compartilhar, neste contexto, uma interessante leitura sobre experiências de diversos arquitetos de software que guardam uma espantosa coincidência com as idéias e conceitos do caminho do meio. Esta lições estão coletadas no excelente e sucinto livro 97 Things Every Software Architect Should Know, escritas por diversos arquitetos de todo o mundo e compiladas por Richard Monson-Haefel.

Dentro das 97 dicas presentes neste livro, gostaria de destacar três:

• Não coloque seu resumè a frente dos seus requisitos. Este pequeno texto discute porque bons arquitetos primeiro entendem o problema e o contexto de negócio antes de propor a tecnologia preferida do seu currículo. A lição é clara: não leve a sua tecnologia Java ou .NET preferida para o seu cliente antes de entender claramente o problema.
• Simplifique a complexidade essencial, diminua a complexidade acidental. A complexidade essencial diz respeito a complexidade inerente a um problema. A complexidade acidental diz respeito a efeitos colaterais introduzidos por escolha de tecnologias complexas e soluções estado da arte. Exemplos são o uso de EJBs, servidores como o BizTalk, servidores de transações distribuídas ou modelos complexos de orientação por objetos para problemas simples que não necessitam deste tipo de solução. A lição novamente é clara: não introduza complexidade acidental para aprender uma nova tecnologia. É responsabilidade do arquiteto gerir bem o dinheiro do projeto, da sua empresa e do seu cliente. Não brinque com o dinheiro alheio por vaidade.
• Arquitetura é sobre equilíbrio. A arquitetura deve equilibrar aspectos técnicos e aspectos de negócio (condutores de negócio). “Arquitetos Java e .NET” que se esquecem de olhar para o negócio estão violando o caminho do meio. Estão buscando apenas um meio de satisafazer seus egos no uso de soluções “elegantes” e criar novos desafios técnicos que apenas eles precisam.

Um “arquiteto Java” e um “arquiteto .NET”, portanto, irá se tornar um melhor arquiteto se não ficar cego pelas palavras “Java” e “.NET” e colocar no seu cardápio porções de liderança técnica e práticas de alinhamento ao negócio.

Pensamento do dia: “A pior escravidão possível é a escravidão a si mesmo”, Sêneca.

A divisão Rational da IBM incorporou à sua IDE (RAD/RSA) - que ganhou recentemente o prêmio de melhor IDE do mercado na última pesquisa do Evans Data Group de Abril de 2008 - suporte visual para JPA. Este era um gap muito aguardado pela comunidade Java que trabalha com softwares IBM. Grande parte deste enorme atraso (se considerarmos que Java EE foi lançado em 2005) se deve a coordenação do lançamento do RAD 7.5 com o novo servidor de aplicação WAS 7.0, que possui suporte ao Java EE 5.0. O plugin para JPA é baseado no projeto open-source Eclipse Dali, mas conta com várias melhorias que fornecem maior velocidade e produtividade ao desenvolvimento de aplicações de larga escala.

Com o suporte da IBM temos o último dos grandes fornecedores de IDEs Java EE (junto com Oracle/BEA, SUN, JBOSS e BORLAND) com suporte oficial ao Java EE 5.0 e consolidação do JPA como tendência definitiva de mercado para a camada de persistência em Java. Para mais informações, um artigo sobre estas novas features está disponivel no Developer Works da IBM.

Gosto do título desta frase, que remonta ao inglês arcaico do século XVI (”Byrdes of on kynde and color flok and flye allwayes together”) e que metaforicamente diz que pessoas com interesses comuns se juntam e permanecem juntas em suas atividades.

Tive a chance de acompanhar dois interessantes eventos de comunidades esta semana (SUN Tech Days - Capítulo MG e o Primeiro Encontro de Comunidades Microsoft de Minas Gerais) e presenciar como redes sociais físicas podem potencializar e criar valor único para todos os seus participantes

O primeiro evento foi organizado pelo MGJUG, comunidade de usuários Java de Minas Gerais. Embora o evento tenha deixado a desejar no seu número de participantes, tivemos a oportunidade de acompanhar três boas palestras em temas como SOA e Java Mobile. Em particular, a SUN divulgou o seu programa de parceria acadêmica que fornece benefícios bem interessantes a alunos das faculdades credenciadas.

O segundo evento foi um encontro para fomentar a criação de comunidades ligadas a temas Microsoft (tecnologias e produtos). Atualmente já existem algumas comunidades em Minas Gerais como por exemplo os .NET Raptors ou o CanalSharePoint. O evento propôs a criação de diversas comunidades que terão espaço permanente no portal de redes sociais do Mundo IT, do Yuri Gitahy. Inicialmente as comunidades de BI, Gerência de Projetos, InfraEstrutura e Arquitetura de Software serão criadas no mundo IT. Impossível não citar também as excelentes palestras e depoimentos do Ricardo Guerra (coordenador regional da INETA - organismo responsável por fomento às comunidades de desenvolvimento Microsoft) e também do Marco Aurélio Peres (Coordenador do grupo de SharePoint MG) , entre vários outros, que mostraram o quão bem organizada a Microsoft é no fomento a programas de parcerias e comunidades. A quantidade e qualidade destes programas é mais um aspecto invejável (no bom sentido da palavra invidia) e que deveria ser copiado por comunidades open-source e empresas como a IBM, SUN ou Oracle.

A mensagem é simples. Se você tem algum interesse, busque comunidades para potencializar o seu interesse, compartilhar experiências e aprender com os nossos amigos de trabalho. Afinal, como diz um outro ditado - “Nenhum de nós é melhor que todos nós”.

O grupo JBOSS (agora incorporado pela RedHat) tem trazido soluções cada vez mais robustas e completas para a implementação de uma arquitetura sólida de TI e para suporte a iniciativas BPM/SOA. Antes restrito apenas ao mercado de servidores de aplicação com o produto JBOSS AS , o grupo JBOSS está ganhando espaço no disputado mercado de middleware de aplicações.

Esta plataforma (chamada JBOSS Enterprise Middleware Systems) é descrita tecnicamente em uma apresentação gravada no JBOSS RoadShow (Apresentação JEMS), evento técnico do grupo JBOSS que circulou as principais capitais brasileiras neste ano de 2008. Encontramos no link acima também a visão do grupo JBOSS para SOA e um novo produto (JBoss Operations Network), comprado pela RedHat, para cuidar da monitoração de servidores de aplicação e também para suporte a BAM (Business Activity Monitoring).

Alternativamente aos vídeos, as várias apresentações deste evento foram também disponibilizadas em PDF neste link.

Tive a sorte de poder acompanhar e trabalhar com Java desde o começo da linguagem, em 1995. Naquela época, o papel do arquiteto de software era algo praticamente inexistente no Brasil e a menção a estes termos era distante e mencionado por pessoas como Grady Booch, Bertrand Meyer, Erich Gamma, Dana Bredenmeyer, Paul Clements e outros visionários. Desde o começo do século XXI, entretanto, a figura do arquiteto de software começou a se tornar popular no Brasil e em Belo Horizonte. Três fatores que ajudaram neste espalhamento foram o processo unificado (UP), a plataforma Java e a certificação SUN SCEA.

O processo unificado (UP), em minha visão, teve uma importância ímpar no espalhamento da figura do arquiteto. Isso é claro em um livro chave de 1995 chamado Object Solutions, de Grady Booch. Por o processo unificado (e suas derivações como o AUP, RUP ou EUP) ser um processo dirigido por cenários arquiteturais, vários gerentes e várias empresas começaram a entender a importância da figura do arquiteto. Hoje, 2008, toda fábrica de software de porte no Brasil possui algum arquiteto de software em seu corpo de profissionais.

A plataforma Java, por sua grande inovação e grande complexidade exigia também um outro tipo de papel além do clássico programador (hacker) no sentido original e bom desta palavra - sem nenhuma relação com os crackers.

A certificação SUN Java Certified Enterprise Architect também teve um papel chave para que a figura do arquiteto fosse conhecido. Isso certamente foi bom. Isso reconhecou a nossa profissão no mundo Java e nos valorizou profissionalmente. Entretanto, o objeto deste blog é avaliar o quão fraca são as certificações das empresas “Java” de mercado e constatar (heresia!?) que a certificação mais completa de arquitetura de mercado é de uma empresa que não pratica Java.

A certificação Java SCEA certamente foi muito bem construída e muito trabalho sério e competente foi colocado ali. Ela mede, sem dúvida, o nosso conhecimento de Java e aspectos de design de Java EE, APIs Java EE e os Core Java EE Patterns. Entretanto, aos analisarmos os seus objetivos vemos que diversas habilidades de um arquiteto de software não são trabalhados.

Alguns destes aspectos incluem:

• Experiência prática. Todos sabemos que um arquiteto Java que não tem uma vasta experiência prática de projetos (medido em milhares de horas como desenvolvedor e líder técnico) é igual a uma nota de 3 reais.
• Habilidades de liderança. A principal característica de um arquiteto é a capacidade de estabelecer autoridade moral dentro de um time para conseguir transmitir boas práticas e criar uma visão arquitetural e uma arquitetura executável adequada para o projeto.
• Compreensão de aspectos de negócios. Um arquiteto deve conhecer sobre arquiteturas de negócio e saber avaliar requisitos de negócio para saber como a sua solução técnica irá realizar estes aspectos.
• Habilidades de gestão de riscos técnicos. Fazer uma arquitetura é, em boa parte, gerir e mitigar riscos técnicos.
• Conhecimento lateral de tecnologias. Um arquiteto Java deve conhecer (mesmo que superficialmente) outras tecnologias além de Java (ex: Estratégias de EAI, Protocolos de EDI, Plataformas Altas, Bancos de Dados, Sistemas de Messageria, Sistemas de Orquestração de Processos, Ferramentas de BI, Portais, CRMs, ERPs, Sistemas Especialistas para o negócio sendo modelado, Usabilidade, Segurança da Informação, Testes de Desempenho, Planejamento de Capacidade, Processos de Software, Metodologias Ágeis, Redes, BPM, SOA, ITIL, Six Sigma e COBIT).
• Forte conhecimento de métodos arquiteturais (ex: SEI ATAM, RUP 4+1, ARID, FURPS+, ISO 9126).
• Arquiteturas corporativas. (ex: EABOK, TOGAF ou Zachman Framework).

As certificações com título de arquiteto da IBM e BEA, entre outras que observo, medem conhecimentos semelhantes à certificação de Java EE da SUN. Elas pecam, novamente, por não avaliar alguns dos aspectos citados acima.

Tentarei explicar aqui porquê o programa de certificação de arquitetura da Microsoft é tão rico e mais apropriado para alguém que queira trabalhar com arquitetura de software.

• Ele é um programa e não uma prova. Esta certificação é um processo com um tutor do núcleo de arquitetura da Microsoft que culmina na defesa de um projeto do mundo real perante uma banca para a avaliação das habilidades, conhecimentos e atitudes do candidato.
• As principais competências exigidas e avaliadas são (nesta ordem) - Forte conhecimento do negócio, Pensamento Inovador e Estratégico, Capacidade de Investigar Novas Tecnologias, Conhecimento de Frameworks Arquitetônicos e Melhores Práticas, Capacidade de Usar e Criticar Frameworks, Capacidade de Atingir Rápida Proficiência em Qualquer Tecnologia e Capacidade de Trabalhar com Informações Incompletas,

Como curiosidade, em todo o texto detalhado das competências exigidas por esta certificação, a palavra C# não é mencionada uma única vez. A palavra “Java EE” é citada uma vez! Uma outra curiosidade é que a primeira característica citada nesta página chama-se: Liderança.

Infelizmente, esta certificação (MCA) é muito cara (pelo menos para mim!) e requer a defesa em território americano. Talvez não por acaso existam somente 90 pessoas no mundo com esta certificação. Obviamente, esta certificação não é perfeita. Nenhuma certificação o é, mas ela consegue medir mais adequadamente, em minha modesta opinião, o que esperamos de um arquiteto de software em um projeto de TI.

Gostaria que a SUN, a IBM ou mesmo a Microsoft tivessem uma certificação como essa sendo executada em terrítório Brasileiro, com preços mais acessíveis. Até lá, é muito importante ter cuidado com “arquitetos de papel” que habitam o nosso mercado com suas certificações reluzentes.

Uma nota final. Para quem ficou interessado no programa da Microsoft (que inclui também 4 semanas obrigatórias de treinamento em Redmond), segue o link com mais informações.

É fato notório para a comunidade de TI Brasileira o uso das soluções JBOSS para o desenvolvimento de aplicações corporativas basadas em Java. A ausência de um reconhecimento formal, entretanto, gerava questionamento por diversos decisores sobre a maturidade desta solução. Uma notícia recente, entretanto, lança o devido reconhecimento técnico e mercadológico desta solução.

O JBOSS AS figura no Gartner Magic Quadrant como um membro do quadrante líder, conforme mostrado na figura abaixo.

.

Vejo esta análise de forma similar as análises realizadas pelo grupos de investimento internacionais, como o Standard and Poors, a respeito da maturidade da economia Brasileira. A análise, por si só, nada muda na solução JBOSS AS, mas traz possibilidade de adoção da solução em contextos onde esta hipótese nao caberia por falta de respaldo de institutos de renome como o Gartner.

Apesar disso, o grupo JBOSS ainda carece de um modelo de serviço e suporte mais presente no Brasil para que possa enfrentar definitivamente os seus grandes concorrentes (BEA, IBM, Oracle e Microsoft) no disputado mercado de servidores de aplicação. Mais informações sobre esta análise podem ser encontradas no relatório do Gartner, disponível aqui.

A Internet nos trouxe as bibliotecas digitais. Bibliotecas digitais são excelentes mecanismos para conhecer novos assuntos, nos aprofundarmos em assuntos já conhecidos ou mesmo aumentar a nossa produtividade enquanto engenheiros de software.

Melhor ainda se a biblioteca digital puder ser usada sem a violação de direitos autorais, fato que infelizmente não ocorre com outras “bibliotecas” de endereço e reputação duvidosa.

Em particular, recorro sempre à um biblioteca de excelente qualidade chamada RedBooks. O RedBooks (http://www.redbooks.ibm.com) é uma biblioteca pública de livros diversos de TI. O download dos livros em formato digital é gratuito e os livros podem eventualmente ser comprados em formato impresso.

O segredo do Redbooks é que esta é uma rede social, i.e., qualquer pessoa com conhecimento técnico suficiente pode se inscrever e participar de um projeto que irá escrever um novo livro. Vários Brasileiros participam ativamente deste processo, inclusive.

Existem vários domínios (assuntos) dentro desta bibliotecas. Destaco três em particular:

• RedBooks para Desenvolvimento de Aplicações.
• Software Rational (Ferramentas para Governança do Desenvolvimento e Entrega de Aplicações)
• Software WebSphere (Ferramentas para Operações de Aplicações e SOA)

A qualidade dos RedBooks, de forma geral, é muito boa. É possível, inclusive, votar na qualidade e criticar os livros, que eventualmente são melhorados ao longo do tempo. Dados de pesquisa da IBM junto a seus clientes mostraram dados interessantes do aumento de produtividade no uso dos RedBooks. Coloco aqui um fragmento desta pesquisa.

Para não perder o hábito de falar sobre SOA, coloco aqui as dezenas de ocorrências que encontrei sobre SOA no RedBooks Online.
- Redbooks de SOA

A IBM recentemente lançou o IBM WAS CE (WebSphere Application Server Community Edition) 2.0, com conformidade completa ao padrão Java EE 5.0. O WAS CE é baseado no kernel do Apache Geronimo e conta com tecnologias tais como o OpenEJB, Apache Axis, Apache ActiveMQ e Apache Derby, entre outras.

Assim como o JBOSS AS, este produto também não possui custo de licenciamento e se torna mais uma opção interessante no mercado de servidores Java EE de código aberto e licenciamento livre.

Alguns recursos sobre o WAS CE são disponibilizados abaixo:

• Artigo Introdutório
• Página de Download
• Plugin para Eclipse 3.3

Europa foi uma das várias mulheres de Zeus (Júpíter) na mitologia greco-romana. Em homenagem ao planeta, a segunda maior lua de Júpiter foi batizada de Europa.

Europa também é o nome do novo projeto Eclipse, assim como Callisto (outra lua de Júpiter e outra de suas mulheres), compilação de uma linha de base com 11 projetos no Eclipse 3.2.

Seguindo a idéia do projeto Callisto, o Eclipse continua em um processo de coordenação de múltiplos projetos em um linha de base cada vez mais madura e profissional. Neste lançamento, temos 21 projetos compilados em uma linha de base sobre o Eclipse 3.3.

Os projetos são:

• AspectJ Development Tools (AJDT) 1.5
• Business Intelligence and Reporting Tools (BIRT) 2.2.0
• Buckminster 0.1.0
• C/C++ Development Tools (CDT) 4.0
• Data Tools Platform (DTP) 1.5
• Device Software Development Platform - Device Debugging (DSDP.DD) 0.9
• Device Software Development Platform - Target Management (DSDP.TM) 2.0
• Dynamic Languages Toolkit (DLTK) 1.0
• Dash (Eclipse Monkey) 1.0
• Eclipse Communication Framework (ECF) 1.0.0
• Eclipse Platform, JDT, PDE and Equinox 3.3
• Eclipse Modeling Framework (EMF) 2.3
• Eclipse Modeling Framework - Query, Transaction, Validation (MQ, MT, VF) 1.1
• Graphical Editing Framework (GEF) 3.3
• Graphical Modeling Framework (GMF) 2.0
• Model Development Tools (MDT) 1.0
• Model to Text (M2T) - JET 0.8
• Mylyn 2.0
• SOA Tools Platform (STP)
• Test and Performance Tools Platform (TPTP) 4.4
• Web Tools Platform (WTP) 2.0

Sem dúvida, a grande vedete deste lançamento é o WTP 2.0 (Web Tools Platform), que traz importantes ferramentas visuais para suporte a JPA , JSF e projetos completos Java EE 5.0. Temos, por exemplo, um editor visual drag and drop para JSF.

Apesar disto, faço minhas apostas em outros projetos que ainda não tem tanta expressão, mas que prometem bastante.

• STP - SOA Tools Platform - Embora ainda em processo de maturação (0.6), este projeto irá ofertar uma infra-estrutura para o desenvolvimento de projetos de arquiteturas orientadas por serviço. Esta versão inicial traz já uma amostra do potencial do Eclipse para suporte a SOA.
• MyLyn - Um projeto simples, mas excepcionalmente interessante. O MyLyn é uma ferramenta para micro-gerência de projetos e sucede o projeto Mylar, do qual escrevi um blog aqui há algum tempo. O MyLyn permite que uma pessoa controle o tempo gasto nas suas tarefas ou nas tarefas do seu time, bem como fazer o controle de ciclo de vida de atividades, defeitos, melhorias e outros tipos de ocorrências, integrado ou não a itens de configuração do Eclipse (códigos, arquivos, modelos e outros elementos de projetos). O MyLyn deve permitir que desenvolvedores, líderes técnicos e mesmo gerentes consigam implementar conceitos de gerência e agile management de forma bastante transparente e não intrusiva.
• ECF - O Eclipse Communications Framework traz para o Eclipse ferramentas colaborativas, mensagens e comunicação ponto a ponto. Ele segue uma tendência da tecnologia Jazz, que promete revolucionar a forma como times colaboram para desenvolver projetos. Mais informações sobre o ECF podem ser achadas aqui, embora esta tecnologia ainda deve se tornar mais estável (assim como o STP) na versão Eclipse 2008, chamada Ganimedes.

Mais informações sobre o Europa podem ser achadas aqui:

• Página principal: http://www.eclipse.org/europa
• Revisões: http://www.eclipse.org/europa/europareviews.php
• Personalização do Europa: http://www.eclipse.org/downloads/moreinfo/custom.php

Quem é Ganimedes? Mais uma mulher de Zeus? Em verdade, Ganimedes era um cara, mas Zeus não perdoava ninguém e se apaixonou por ele (Wiki-Ganimedes). Em tempo, Ganimedes também é mais uma lua de Júpiter. Em 2008 escrevo um blog sobre ele!