Tecnologia da Informação

Pensando no artigo anterior "Faça funcionar, então, melhore!", e levando em conta as necessidades das empresas de desenvolvimento, dos desenvolvedores, arquitetos e analistas de sistemas, projetei e testei a eficiência de uma arquitetura relativamente símples para suportar aplicações corporativas e aderente á onda da Web 2.0 sem esquecer da necessidade de agilidade no desenvolvimento.

Modelo Web 2.0 e Java EE(tm) de aplicações:

Dessa forma, para um universo de 90% das aplicações Web 2.0, a arquitetura projetada abaixo garante índices consideravelmente altos das qualidades sistêmicas de:

• escalabidade: garantida pelo uso do modelo AJAX DWR, pois a comunicação do navegador do cliente com o servidor é feita baseada em Marshlling de objetos do padrão JSON, muito menos sobrecarregado que WebServices ou outro modelo baseado em XML.
• confiabilidade: garantidada pelo modelo transacional da plataforma Java EE 5 e da peristência baseada em JPA;
• eficiência: devido ao tráfego reduzido entre o cliente e o servidor, e do uso do cache do JPA, esse modelo tem índices excelentes de taxa de transferência X quantidade de acessos;
• segurança: garantia pela associação do modelo de segurança básico da Java EE 5  com o DWR, pois a Java EE 5 provê a autenticação e autorização e o DWR identifica as requisições dos clientes, impedindo que um cliente não identificado envie mensagens ao servidor;
• evolutividade: garantida pelo modelo das classes idealizadas para separar as responsabilidades de geração de páginas, de persistência, de serviços dos EJBs, de serviços do DWR e de scripts JS do cliente.

Arquitetura Java EE 5(tm) usando DWR:

• Componentes amarelos: criados pelo desenvolvedor;
• Componentes azuis: gerados dinâmicamente;
• Componentes roseados: fornecidos pelo servidor ou terceiros;

E sem complicar o processo de deploy, tal modelo permite que a publicação da aplicação seja feita num ambiente símples ou complexo como os modelos abaixo:

Sem Cluster:

Com Cluster:

Atualmente estamos desenvolvendo 5 projetos usando tal arquitetura, e ela tem se mostrado extremanente sólida, confiável e produtiva.

Referências:

• DWR 2.0 - http://getahead.org/dwr
• EJB3 - http://java.sun.com/products/ejb/
• JPA - http://java.sun.com/developer/technicalArticles/J2EE/jpa/
• Glassfish - http://glassfish.java.net/

Usem os comentários para discussão de críticas, melhorias e sugestões.

Conversando hoje pela manhã com o experientíssimo Arquiteto de Sistemas Sênior, o Sr. Claudio Teixeira, sobre requisitos funcionais e não-funcionais de um sistema distribuído que estamos projetando e desenvolvendo, nos deparamos com alguns pontos “extraordinários” de problemas que podem acontecer quando desenvolve-se produtos de software para corporações que não são do ramo de TI, por exemplo:

• Armazenamento e versionamento de documentos;
• Criptografia de dados e arquivos;
• Ambiente redundante de servidores;
• etc;

Descobrimos que estávamos indo um pouco além dos requisitos não-funcionais realmente necessários para que esse produto possa ser utilizado pelos seus usuários, saindo do escopo do aplicativo e entrando em escopo de software básico e infra, assim, relembramos velhos termos uvidos no passado como:

• “Cuidado para o ótimo não virar inimigo do bom”;
• “Keep It Simple, Stupid!” - KISS Theory;
• “Make it work, then, make it better”;
• etc;

Devemos nos lembrar sempre que todo software e hardware ( sistema ) tem suas qualidades e restrições, e que é impossível desenvolver um projeto que faça tudo o que o usuário deseja de uma única vez pois as funcionalidades e restrições estão ligados diretamente ao custo, prazo e qualidade do sistema, portanto devemos ter sempre em mentes as seguintes linhas gerais:

• Não aumentar a complexidade do que já é complexo;
• Criar componentes e utilizar “frameworks” de mercado para facilitar a manutenção;
• Trabalhar com ciclo de vida de produto;

Sendo assim, toda vez que formos participar de um projeto de software, principalmente na etapa de venda e projeto, devemos estar cientes e principalmente deixar o cliente confortável com o que vai ser feito, quando vai ser entregue e que melhorias podem ser implementadas ao curto e médio prazo num sistema de informação.

Bom trabalho a todos.

A ComputerWorld, recentemente publicou um artigo sobre a Tecnologia Java,
mas discordo completamente de tal análise.

Vejo que o mercado se acomodará de acordo com suas necessidades,
por tipo de necessidade de “client” e capacidade de processamento “server”,
mas somente a Tecnologia Java atualmente consegue ser o “martelo certo” para
quase todos os problemas computacionais, desde o “mobile”, passando pelo “server”,
incluindo “integration” e o “desktop”.

Acreditem, temos 13 anos de Java, e acho essa tecnologia e suas plataformas evoluirão
constantemente por mais uns 20 anos em ondas associadas a Web 3.0, Federation,
RFID, Virtualização, GRID Computing, etc.

Não esqueci de SOA, é que SOA é tão antigo quanto a especificação que permitiu
a descoberta e uso do AJAX, pois é um Padrão de Arquitetura associado a ferramentas
e especificações que não são novas: WebServices, Messaging, ETL, etc.

Independente do que a Microsoft faça, e a ComputerWorld diga, a plataforma .NET
ainda é considerada pelas empresas uma solução barata, fácil de desenvolver,
que qualquer programador medíocre é capaz de aprender e fazer “aplicativos”,
mas extremamente amadora do ponto de vista de “confiabilidade” para a construção
de “sistemas” integrados e robustos, principalmente quando falamos em aplicações
com grandes volumes de dados e usuários.

Recentemente até o Banco Itaú, que declaradamente só usava a plataforma .NET
se rendeu ao Java EE, e já está “migrando” seus sistemas do Internet Banking para
Java EE rodando em WebSphere no Mainframe, pois o Itaú estava gastando muito $$$$
para administrar e provisionar recursos para os mais de 170 Servidores IIS rodando .NET.

A IBM do Brasil tem mais 4 grandes casos de sucesso de outros bancos que estão fazendo o mesmo.

Ou seja, temos espaço para todos os tipos de ferramentas para variados tipos de problemas, entretanto, existem soluções “mais adequadas” em prazo-custo-qualidade que outras, e atualmente a plataforma Java EE tem se mostrado a que melhor resolve essa equação.

Bom trabalho a todos.

Muitas aplicações usam o Log4J e seu empacotamento/inicialização
podem se tornar um problema em servidores que tem múltiplos classloaders
para separar componentes do servidor dos módulos e aplicações.

Dessa forma descobri uma maneira muito simples de configurar o Log4J
na inicialização do Glassfish ou do Sun Java System App Server nas versões 7, 8 e 9
que elimina a necessidade de ter um listener para inicializá-lo e configurar as categorias
bem como empacotar o Log4J em cada módulo ou aplicação.

1 - Faça o Download do Log4J

2 - Copie o log4j-x.jar no diretório $APP_SERVER_HOME/domains/domain1/lib/ext

3 - Insira as propriedades abaixo alterando a seção do domain.xml ou via a console
administrativa as propriedades da JVM


<jvm-options>

-Dlog4j.configuration=file:${com.sun.aas.instanceRoot}/config/log4j.xml

</jvm-options>
<jvm-options>

-Dlog4j.configuratorClass=org.apache.log4j.xml.DOMConfigurator

</jvm-options>


4 - Crie um arquivo log4j.xml no diretório $APP_SERVER_HOME/domains/domain1/config
com os appenders e as categorias configuradas baseado no modelo abaixo:

5 - Em cada uma das classes que se deseja ter o uso do Log4J,
defina o Logger assim:


package app.package;
public class MyClass {
private static Logger logger;
static {
try {
logger = Logger.getLogger( MyClass.class );
} catch (Exception e) {
e.printStackTrace( System.err );
}
}
}

Boa sorte!

O tutorial abaixo mostra como implementar um filtro de requisições HTTP na plataforma Java Enteprise Web para forçar o donwload de arquivos que geralmente são abertos diretamente pelos navegadores modernos.

Esta funcionalidade é muito útil quando tem-se aplicativos que geram arquivos dinâmicos muito pesados e tem um tempo de download muito grande, forçando ao usuário ficar aguardando com uma tela em branco enquanto o download não termina.

Pode ser utilizado também para arquivos fixos que estão localizados dentro das aplicações web java ( módulo WAR ) e que não estão colocados como arquivos em servidores Web.

Download do Tutorial

Já há alguns meses o mercado mundial de TI vem demonstrando alguma surpresa com os sólidos números apresentados pelas vendas de mainframes nos últimos trimestres. Maior exemplo disso foram os últimos relatórios trimestrais de desempenho dos fabricantes apresentados pelo Gartner e pela IDC (International Data Corporation). As duas organizações de pesquisa, com pequena variação de percentual, apontaram o mercado mundial de servidores em crescimento e a IBM na liderança do segmento.

Até aí, nenhuma surpresa. O surpreendente nestes tempos de idolatração da plataforma baixa, foi a constatação – tanto do Gartner como da IDC – de que uma boa parcela do desempenho da IBM deve-se à venda de mainframes. Sim, os bons e velhos mainframes. Segundo a IDC, as vendas de equipamentos da linha System z cresceram, no primeiro trimestre deste ano, 4% em relação ao mesmo período do ano passado.
Há um número ainda mais sintomático: terminado o primeiro trimestre de 2007, o mercado percebe que os mainframes representaram 9,5% de todas as vendas de servidores da IBM. Os números são recentes, mas a tendência já havia sido indicada em uma outra pesquisa, esta realizada pela Software Strategies, que indicava justamente a boa saúde dos mainframes em 2007. Como fator para o “renascimento”, o estudo apontava a capacidade de processamento, segurança e a flexibilidade de utilização tanto para novas aplicações como para as tradicionais como principais motivos.

Outro fator apontado pela Software Strategies é a crescente utilização de SOA como arquitetura universal para novos aplicativos de negócios. A dobradinha SOA/mainframe, ao que parece, vem se mostrando das mais eficientes e seguras tanto para aplicações como para bancos de dados. Todos estes números e pesquisas tem sido utilizados por fornecedores e analistas para apontar o “renascimento” do mainframe, o que demonstra, na verdade, uma visão distorcida deste mercado.

O mainframe não está renascendo porque, de fato, nunca morreu. Um olhar um pouco mais profundo sobre a trajetória do mercado mostra que houve, sim, um período em que uma determinada parcela do mercado estava desatendida por equipamentos de menor valor e se viu obrigada a recorrer a aquisição de mainframes. A questão era simples: determinadas aplicações ainda não eram suportadas a contento pelos servidores de plataforma baixa.

Para estas aplicações, apesar de superdimensionados, os mainframes eram a alternativa mais segura e eficiente. Com o tempo, as tecnologias aplicadas à plataforma baixa se desenvolveram e começaram a dar a estas empresas outras opções, mais baratas e tão eficientes quanto o mainframe. Houve então uma migração natural para estes equipamentos, agora dimensionados de acordo com a real necessidade de seus usuários. Este movimento fez com que muitos decretassem a morte do mainframe.

Na realidade, e o próprio mercado demonstra isso hoje, o mainframe não morreu, apenas retornou ao seu lugar de direito: um equipamento confiável e seguro para cargas de trabalho críticas. Está claro que a maioria das empresas usuárias de mainframe o vêem hoje como crucial para aplicações críticas e não abrem mão de sua disponibilidade e segurança.

O mainframe não está renascendo, mas ganhando o reconhecimento por aquilo para o que foi criado. Não há mágica nisso, é apenas o mercado ajustando-se às suas necessidades e encontrando a melhor solução para cada uma delas.

Maurício da Costa e Silva, CEO da Eccox S.A.
eccox@eccox.com.br
www.eccox.com.br

Esta apresentação trás um resumo de como desenvolver aplicativos Java Enterprise

Podemos agendar esta e outras palestras na sua empresa ou grupo de estudo!

Faça o download aqui

Bom trabalho a todos.

Este roteiro trás as informações necessárias de como configurar e usar
o famoso framework Jakarta Struts ( versões 1.X )
na família Sun ONE ( versões 7 até 9 ) / Glassfish

Faça o download aqui

Bom trabalho a todos.

Panomara do mercado de servidores de aplicação Java Enterprise.

Tenho certeza que muitos se perguntam: Qual o melhor servidor de aplicações do mercado?

Esta resposta não é tão simples, pois atualmente temos:

1. Java2 EE 1.4: 17 fornecedores certificados
2. Java EE 5: 9 fornecedores certificados

De fato, não temos como saber qual o melhor servidor,
mas temos como identificar qual o fornecedor e produto que melhor se enquadra para cada organização.

Sugiro um método símples para adoção do servidor de aplicações:

1. Verifique se o servidor é certificado pela Sun/JCP/Padrões ( lista de compatibilidade ).
2. Verifique se o fornecedor tem suporte nível 1, 2 e 3 no país.
3. Verifique se o produto além de estar certificado, oferece ferramentas web de monitoração,
   gerenciamento de configuração e publicação.
4. Verifique as formas de licensiamento e custo, pois geralmente variam por tipo de contrato,
   empresa, número de servidores, etc ( ambientes complexos tem contratos complexos ).
5. Verifique a lista de BUGs documentados do produto, pois muitas vezes esses BUGs podem
   ser eliminados com dicas/configurações fornecidas pelo fabricante.
6. Verifique se o produto usa partes de produtos OpenSource, pois dessa forma
   temos certeza que a empresa aposta na evolução do mesmo.

Se o servidor se enquadra em todos o itens acima e o preço cabe no budget do projeto,
então pode-se criar uma tabela como abaixo pontuando o itens e ter-se a média.

Fórmula NOTA: = ( ( C + S + P + F + B + O ) / 53 ) * 10

Sempre devemos dar preferência por produtos certificados pela SUN,
e aquele que tiver a melhor nota, fica com a preferência de escolha.

Atualmente o mercado de Servidores de Aplicações Java tem grande concorrência
entre Oracle, IBM, SAP e SUN, e o market share maior de instalações “pagas” é da IBM,
devido á sua agressividade comercial. Nos ambiente de desenvolvimento, e instalações “open”
baseadas em produtos Free, o líder é o JBoss AS.

O site TheServerSide.com tem um artigo interessante sobre servidores de aplicação e uma matriz de compatilidade

Bom trabalho a todos.

Esta semana deparei-me mais uma vez com quatro empresas de recrutamento e seleção necessitando de profissionais para projetos de Desenvolvimento de Software Java Enterprise, mas que não conseguiam encontrar profissionais (PeopleWare) com o conhecimento e habilidades necessárias para seus projetos, e a média de vagas abertas cresceu consideravelmente.

Acredito que este problema atinga não somente as soluções baseadas em Java, mas também afeta a implementações de ERP, CRM, BI, DataWarehouse, etc, basta ver o número de ofertas repetidas em sites de recrutamento / seleção mês-a-mês. E quando a necessidade envolve uma tecnologia muito nova?? O problema é maior ainda, o profissional se torna “mosca branca”.

Recentemente a Você SA na edição 110 publicou um artigo Deu Pau no TI do Presidente da Progress Software do Brasil que aponta que em 2012, a TI no Brasil viverá o momento de maior stress, pois faltarão profissionais qualificados em todas as áreas, principalmente nas áreas operacionais.

Atualmente existem poucas instituições acadêmicas que fornecem a qualificação adequada em TI, sem falar na falta de fluência na língua inglesa por parte dos brasileiros, e somente este fato faz com que a maior empresa de TI do Brasil tenha um faturamento 10 vezes menor que a maior empresa de TI da Índica.

Um outro fato que influencia muito esta diferença, é falta de interesse do profissional brasileiro na certificação profissional ou especialização acadêmica. Por isso digo a todos meus alunos, ter as certificações do fornecedor do produto/ferramenta/linguagem associado á uma especialização acadêmica são diferenciais muito bem valorizados pelo mercado de TI, pois atesta os conhecimentos e habilidades de fato, garantem a empregabilidade e melhorias salarias.

Neste momento estamos passando por um grande desiquilibrio na equação vagas X profissionais, devido principalmente aos fatores de falta de formalismo do conhecimento, problemas com línguas estrangeiras, e falta de investimento em pesquisa e desenvolvimento. Você sabem quanto a indústria médica e farmacêutica investe em P&D por ano no Brasil? Tenho certeza que é no mínimo o dobro que TI.

Nossa visão em TI está tão turva e distorcida que no final da década de 90 as faculdades e colégios técnicos tiraram a Linguagem COBOL da lista de disciplinas, substituindo pelo VB, Deplhi e outras, causando um problema enorme nos tempos atuais para as instituições financeiras, de manufatura e de telecom. Os programadores/analistas COBOL estão literalmente morrendo, ficando velhos, se aposentando, sem que haja uma reposição no mercado, e dessa forma o custo médio da hora/homem vem subindo e dificultando a manutenção de contratos já firmados.

O Presidente da Progress Software tem razão, estamos rumo ao colapso.

Por isso sugiro:

• Aos gerentes de RH: invistam em reciclagem / especialização dos profissionais da base; contratem profissionais no níveis Júnior para trabalhar com profissionais Pleno e Sênior e evitar a evasão para o mercado;
• Aos recrutadores: deêm preferência aos profissinais reconhecidos formalmente por certificações ou especializações “Latu-senso”.
• Aos profissionais: dediquem-se ao estudo e fluência do inglês; obtenham as certificações das ferramentas; faça uma especialização “Latu-senso” na área de TI.
• As instituições educacionais: melhorem o processo de egresso das especializações com módulos introdutórios e de nivelamento.
• Aos governantes:facilitem o acesso ao desenvolvimento e pesquisa de novas tecnologias.

Bom estudo e boa colocação!