Nova linguagem, JAVABOL! Riscos e oportunidades!

A empresas que possuem milhares de processos de negócios escritos em COBOL e outras linguagens rodando em servidores IBM MainFrame , e nesta temporada acompanhei a entrada massiça de aplicações Java no ambiente UNIX e uma entrada lenta e vagarosa de aplicações Java Enterprise no ambiente MainFrame inpulsinodo pelo WebSphere Application Server for Z/OS.

O nossos colegas de profissão chamados carinhosamente de “Dinosauros” da TI, tem na média 30 anos de experiência a mais que os profissionais que chegam ao mercado todos os dias, entretanto, eles estão se deparando com um novo paradígma, de rodar aplicações Web no ambiente MainFrame , que até pouco tempo atrás só tinha a telinha do terminal TN3270 ou acesso via SNA
Essa mudança ( talvez forçada pela própria IBM ) está trazendo preocupações para os CIOs e CEOs dessas empresas, principalmente pelos novos conceitos de SOA e de Orientação a Objetos e UML , ou seja, se não bastasse ter mais linguagens e tecnologias suportadas, tem-se um novo modelo orientado a serviços e não a processos.
Para piorar o problema, cada vez mais profissionais do ambiente MainFrame se aposentam e os profissionais que entram no mercado não dominam as tecnologias deste ambiente.
Em 2006 o Gartner Group publicou um estudo que mostra que dos profissionais atuais do ambiente MainFrame apenas 30% teriam capacidade de assimilar novas tecnologias como o Java Enterprise .
Atualmente, muitos sistemas corporativos escritos em COBOL tem clientes ricos, principalmente construidos usando a plataforma Java Enterprise, assim nasce o JAVABOL, ponta cliente em Java rodando em Servidores UNIX e processos de negócios em COBOL no MainFrame.
Acho que está na hora das faculdades retomarem as disciplinas de COBOL e de Análise Estruturada e seus Diagramas para suprir essa deficiência, e das empresas investirem um pouco na reciclagem dos Analistas e Programadores da plataforma MainFrame, só assim teremos custos e riscos menores de TI com o recurso de “peopleware” que atua nesta plataforma atualmente.
O Futuro não podemos prever, mas atualmente a coexistência de aplicações Java Enterprise integradas com sistemas coporativos que rodam em MainFrame é perfeita.
Viva o JAVABOL!

Arquiteto, Engenheiro, Analista, Projetista, Desenvolvedor, Programador, o que sou???

No mercado de trabalho relacionados ao desenvolvimento e engenharia de software, e é sempre dificil traçar o perfil o exato de cada papel e garantir a fronteira entre eles.
Vejo todos os dias inúmeras vagas com perfis tão exigentes no Apinfo, mas separadas em pouquíssimos papéis, o que me leva a crer que as empresas terceirizadoras de serviços de TI (as famozas consultorias) na maioria das vezes não sabe o que procurar no mercado.
O pior anuncio é aquele que procura Analista Programador, pois é o que exigirá mais responsabilidade profissional com menor remuneração, pois esse papel tem inúmeras funções e atribuições das duas áreas mas geralmente paga muito pouco a mais que um cargo de Programador.
Conversando com amigos que estão no exterior (Inglaterra, Angola, USA, Chile e Índia) descobri que os brasileiros se sobresaem com relação á outros povos neste quesito, justamente pela flexibilidade e capacidade de desempenhar vários papéis, a diferença é que nesses paízes as empresas valorizam mais esta capacidade que as empresas do Brasil.
Papéis e atribuições

• Arquiteto: definir e manter atualizados os padrões de soluções e tecnologias que serão utilizadas durante o projeto, para cada tipo/conjunto de funcionalidades, separadas pelos requisitos não funcionais e sempre levando em consideração as interfaces de comunição entre os diferentes componentes do software.
• Engenheiro: definir e manter atualizados as informações referente ao projeto de infra-estrutura e integração entre os componentes físicos desde a rede até o ambiente de aplicações.
• Administrador: dar sustentação ao ambiente de software/hardware, fazendo as implementações da infra-estrutura e administrando os ambientes operacionais e servidores.
• Analista: levantar, racionalizar e especificar junto aos usuários diretos e indiretos os requisitos funcionais do software, bem como realizar os testes de homologação.
• Projetista: projetar (criar as realizações dos casos de uso racionalizados pelo analista) o software baseado nos padrões definidos pelo arquiteto levando em conta as tecnologias/linguagens que serão utilizadas.
• Programador: codificar os componentes do software baseado na documentação elaborada pelo projetista e pelo analista, fazer os testes iniciais de cada componente.
• Desenvolvedor: integrar os componentes do software baseado na arquitetura e seguindo as realizações do projetista, fazer os testes integrados.

Níveis de experiência (por área)

• até 1 ano de experiência – Júnior
• de 1 a 3 anos de experiência – Pleno
• de 3 a 5 anos de experiência – Sênior
• mais de 5 anos de experiência – Especialista

Vamos levar para dentro das empresas, e durante as entrevista de emprego, esse conceitos símples, de como cada papel deve atuar, permitindo que o mercado regule os valores das remunerações de acordo com cada papel e evitando distorções.
Comente, dê sua opnião sobre nossa categoria de trabalho, somente assim podemos exercer nossos direitos caso a Regulamentação das Profissões da Informática venha a ganhar força no congresso.
Boa sorte

Utility Computing, o que é isso?

De uma maneira geral, Utility Computing é uma evolução do Outsourcing de TI, com uma diferença, não seremos mais “donos dos sistemas” e sim “donos dos processos e informações”, acho que sempre deveria ser assim!
A Utility Computing não um paradigma tão novo, algumas empresa de Outsource já fazem isso, cobram por uso e demanda.
Agora, imaginemos uma empresa de marketing, onde gestão de TI não é o “core do negócio”! Então, me faz total sentido “alugar” máquinas e sistemas para fazer a Gestão Empresarial, Pagamentos, Rebecimentos, Portais de Intranet, Sites de Internet, CRM, e inclusive de manufatura, deixando mais fôlego para a empresa fazer e produzir em “Marketing”. Nesse caso TI passa a ser de suporte ao negócio efetivamente.
E é uma grande tendência de mercado, principalmente pelo controle de custos, pois atualmente nas empresas não se sabe quanto se gasta com TI, nem quanto poderia ser enconomizado.
Esta tendência aponta inclusive para o aluguel de aplicativos ou sistemas que fazem parte do suporte ao core business das empresas, vale lembrar que Gestão de TI é sempre complexo, por isso deve ser feito por empresas especializadas.
Dentro da Utility Computing temos os conceitos de On-Demand (sob demanda), Rent ( aluguel ), Virtualization ( virtualização ), Grid ( rede de computadores interligados que operam conjuntamente ) que possibilitam a implementação eficaz e eficiente dos serviços, permitindo o controle necessário para uma cobrança justa dos serviços utilizados.
A Utility Computing abrigará que as empresas se re-estruturem internamente, diminuindo o quadro de funcionários que não operam o “negócio” e fazem tarefas de BackOffice, e aumentando o quadro de funcionários que conhecem e fazem o “negócio” acontecer, até porque “negócios” são feitos por pessoas e não por computadores.
Você pode encontrar mais recursos nos sites lá de fora, onde a Utility já saiu da zona de descoberta e passa a ser realidade para algumas grandes empresas!

Fontes externas
• Sun Grid
• Utilitycomputing.com
• network.com
• Utility Computing

Se eu fosse o CEO de uma empresa, obrigaria meu CIO a usar o máximo de Utility Computing, diminuindo os custos de gestão das estruturas complexas de TI, focando a empresa ao máximo no “negócio”…

Servidores de Aplicação Java EE.

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.

Produto	Certificado ( 0 ou 10 )	Suporte ( 0 á 3 )	Preço / Contrato ( 0 á 10)	Ferramentas ( 0 á 10 )	Bugs Documentados ( 0 á 10 )	Componentes OpenSource ( 0 á 10 )	Nota
A	0	8	2	5	6	10	5,85
B	10	3	2	5	3	7	5,66

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.

Mainframe: retorno ou reconhecimento?

á 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.

Créditos à:

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

Configurando o Log4J no Glassfish ou Sun Java System App Server

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:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/" debug="false">
<appender name="app" class="org.apache.log4j.RollingFileAppender">
<param name="File" value="../logs/app.log"/>
<param name="Append" value="false"/>
<param name="MaxFileSize" value="5000KB"/>
<param name="MaxBackupIndex" value="0"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5r %-5p [%c] (%t:%M:%L) %m%n"/>
</layout>
</appender>
<category name="app.package">
<priority value="INFO"/>
<appender-ref ref="app"/>
</category>
</log4j:configuration>

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!

Depurando aplicações no Glassfish com NetBeans 6

A depuração ( debug ) de código é uma ferramenta valiosa na procura de BUGs em programas e no entendimento de como as chamadas acontecem dentro de uma aplicação complexa, principalmente se forma aplicações Java EE.
Atualmente a maneira mais eficiente e menos intrusiva de fazermos isso é usando o debug remoto baseado no JPDA ( Java Platform Debug Architecture ).
Para configurar o DEBUG ( depuração ) de código no servidor Glassfish usando o NetBeans 6 Debugger seguimos os simples passos abaixo:
1 – Na Console Administrativa do Glassfish, acessar as opções:

• Application Server – JVM Settings – General
• Habilitar o DEBUG ( veja o círculo vermelho )

2 – Clique no botão SAVE para salvar as novas configurações.
3 – Aparecerá um aviso de que é necessário reiniciar o servidor para que as alteracões tenham efeito.
4 – Durante o start-up com as novas configurações a console de log mostrará que a porta 9009 está liberada para conexões de debug remoto ( veja em vermelho )

5 – Faça o deploy dos componentes Java EE no servidor.
6 – Defina os breakpoints na visão de edição do código fonte clicando na barra cinza com a numeração de linhas.

A linha do breakpoint ficará marcada com um fundo rosa e aparecerá na lateral um quadradinho informando o breapoint criado.

7 – Anexe ( attach ) o depurador ( debug ) do NetBeans.

Em vermelho vemos as configurações do JPDA habilitado no servidor configurado anteriormente.

8 – Quando qualquer Thread de qualquer requisição ou serviço passar pelo Breakpoint o NetBeans interromperá dando um aviso do depurador
9 – A barra de botões de ações permite navegar entre as chamadas de código das classes ou até sair delas e interromper a depuração ( debug ).

Boa diversão!