Migração de Banco de Dados

Nos últimos 3 meses eu trabalhei em uma migração de banco de dados em uma das empresas no qual eu trabalho e gostaria de deixar neste post o histórico do que aconteceu. Primeiramente a empresa migrou 9 anos de Sybase para o SqlServer devido a uma série de benefícios + custos oferecidos pelo empresa. As atividades foram:

1. Migração de Estruturas – usamos uma ferramenta proprietária para ler as bases no banco atual e criar as mesmas estruturas no novo banco de dados.

2. Migração de Bases – usamos uma ferramenta proprietária para migrar todas as informações existentes nas bases no banco atual para novas bases no novo banco.

3. Reescrever Procedures/Triggers – tivemos que reescrever a maioria das procedures/triggers devido a bugs que passaram a ocorrer devido a incompatíveis sintaxes e tipos de campos de dados entre os 2 banco de dados.

4. Alterar Aplicações Java JDBC – as aplicações java que estavam se conectando na aplicação via JDBC tiverem que ser levemente alteradas devidos a certas incompatibilidades em alguns campos dos tipos DATE e CLOB/BLOB e alguns comandos SQL com sintaxes incompatíveis.

5. Aplicações JPA com Hibernate – as aplicações feitas com camadas de persistências usando JPA +  provedorer Hibernate não tiveram que ser mudados !!  Isto não é lindooooo ??? Como defendido pela especificação, quando ocorrer a mudança do banco, deve ser mudado a configuração do provedor de JPA e a determinada implementação deve resolver todos os novos comandos SQL no novo banco de dados…e foi justamente isso que aconteceu ! Para aqueles que ainda duvidavam…fica registrado então !!!!!! kkkkkkkk 

Gostaria de aproveitar o post e reafirmar como é importante implementar uma correta camada de persistência nas aplicações, independente de seu tamanho. Além de organizado, o produto final fica pronto para qualquer eventual migração que na maioria das vezes nunca aparenta que vai acontecer. Sobre material de referencia, eu indicaria o livro Java Persistence com Hibernate que alem de abordar este incrível framework, aborda também a especificação JPA, apresentando também uma boa base recheados de exemplos para se implementar uma camada de persistência genérica e reutilizável. Me coloco a disposição para resolver qualquer eventual dúvida sobre o assunto. A paz para todos e até a próxima 🙂

“Mas ele sabe o meu caminho; se ele me provasse, sairia eu como o ouro. Os meus pés seguiram as suas pisadas; guardei o seu caminho e não me desviei dele.” Jó 23:10-11

Anúncios

Caucho Resin Reference Card

Foi liberado hoje pela DZone o cartão de referência sobre o Cauche Resin que consiste em um servidor de aplicações java conhecido pela sua simplicidade, velocidade, confiabilidade  e escalabilidade. O cartão cobre os aspectos básicos e as novas features existentes na versõa 4.0 deste produto.

“Deus não nos tem dado espírito de covardia, mas de poder, de amor e de moderação.” 2 Timóteo 1:7

Mitos sobres velhos desenvolvedores

“Dave recentemente comemorou seu aniversário de 40 anos. Um amigo brincou: “Ei, acho que significa que você está velho demais para programar !” Eu ri muito, mas depois me deu uma pausa. Gente COBOL enfrentou este problema anos atrás, e eu me lembro bem de como nós rimos sobre o código legado e sua inflexibilidade.”
Dave descreve 5 profundos mitos negativos sobre os desenvolvedores de software antigos. Ele continua: 
“Há uma série de mitos sobre os desenvolvedores de software mais antigos, que continuam a ser perpetuadas em TI que de alguma forma colocar mais velhos, os trabalhadores experientes em desvantagem. Um resumo deles:

* Desenvolvedores de software mais antigos são mais caros que os mais jovens, fazendo com que os desenvolvedores jovens mais desejáveis.

* Antigos desenvolvedores de software são menos flexíveis e menos capazes de aprender novas tecnologias, devido ao seu conhecimento legado.

* Antigos desenvolvedores de software são menos capazes de executar as tarefas árduas de desenvolvimento de software (trabalhar longas e dolorosas horas), devido a compromissos familiares e outros aspectos que os trabalhadores mais jovens não têm.

* Antigos desenvolvedores de software são mentalmente menos ágeis do que os mais jovens.

* Antigos desenvolvedores de software são cansados e cínico e, portanto, menos desejáveis no local de trabalho que os mais jovens. Colaboradores mais jovens são mais entusiasmados do que os mais velhos.

Se você está se aproximando da marca de 40-anos de idade, ou que já passou, mais cedo ou mais tarde você vai ter a chance de testar se estes mitos são verdadeiras. O que você acha ? Veja o post completo no seu blog.

“Respondeu-lhe Jesus: Amarás o Senhor, teu Deus, de todo o teu coração, de toda a tua alma e de todo o teu entendimento.” Mateus 22:37

Container JavaServer Faces

A história nos mostra que a pouco tempo atraz, os programadores eram completamente responsáveis pelo gerenciamento do ciclo de vida de todos os objetos decorrentes da implementação. Ou seja, os programadores escreviam o determinado código para criar, relacionar, usar e destruir objetos ao longo da execução da determinada solução. Atualmente este quadro mudou, vemos as tecnologias chamadas de “server side” a cada dia engolindo estas responsabilidades. Eu poderia até me arricar em afirmar que esta responsabilidade já foi retirada das mãos dos programadores e passada a ser implementada pela parte “infraestrutural” da solução.  Para aqueles que ainda não conseguiram visualizar o fato, a questão chave é entender que implementar manualmente este gerenciamento objetos não é uma tarefa trivial, que pode ainda crescer em complexidade devida a natureza e escalabilidade da solução. A tecnologia java vem seguindo esta tendência e amadurecendo juntamente ao longo dos anos e hoje, vemos  especificações dos chamados “containers” que tem se tornado a parte infraestrutural de sistema com o propósito de assumir esta responsabilidade. 

Resumindo: Gerenciar todos os possíveis objetos em uma solução flexível, escalável e algumas vezes distribuída é uma tarefa muito complexa, que por este mesmo motivo foi abandonado pelos programadores e passado para componentes de softwares externos apelidados de containers. 

Injeção de Dependência – DI

Se aprofundarmos na questão, veremos que a evolução natural do gerenciamento de objetos por estes controladores externos chamados de containers nortearam para a criação de um padrão que revolucionou a forma de se contruir programas orientados a objetos. É ai que entra a conhecida Dependecy Injection – DI “Injeção de dependência” ou a antigamente chamada de Inversion of Control – IoC “Inversão de controle”. A DI define um padrão de desenvolvimento de programas de computadores utilizado quando é necessário manter baixo o nível de acoplamento entre diferentes módulos de um sistema. Nesta solução as dependências entre os módulos não são definidas programaticamente, mas sim pela configuração de uma infraestrutura de software container que é responsável por “injetar” em cada componente suas dependências declaradas. 

Conceitos Chaves da DI

Os container que já eram responsáveis por cuidar dos objetos, passaram a faze-lo com muito mais classe e flexibilidade com a adoção da DI que foi rapidamente popularizado. Segue abaixo um descritivo básico e prático de conceitos de um container com injeção de dependência:  

1. Construção de Objetos – o desenvolvedores deixaram de implementar a contrução dos objetos, passando a delegar configuravelmente isso dentro do container de DI. Isto é bem simples de entender: não existe mais operador new dentro dos programas !!! Isto é feito automaticamente e “debaixo dos panos” pelos container. O programador simplemente configura isso de alguma forma no container. 

2. Inicialização de Propriedades – os desenvolvedores deixaram de implementar a definição de valores padrões para as propriedades de um objeto criado, delegando também de forma configuravel nos containers. 

3. Gerenciamente de Dependência – os desenvolvedores deixaram de implementar a dependências entre os objetos do sistema, delegando também de forma configurável nos containers. 

4. Ciclo de Vida – os desenvolvedores deixaram de implementar o tamanho e a forma de visibilidade dos escopos referentes aos objetos durante a execução, passando a configura-los muito mais facilmente dentro do containers.  

5. Configurações declarativa – um container DI deve fornecer uma forma de configuração declaravel, ou seja: o meio de declaração de ser um arquivo externo de facil edição e alteração. O XML tem sido o predominante. 

O que eu gostaria de pontuar é que eu redundantementee destaquei as palavras “deixaram de implementar com o propósito de gerar no leitor a idéia de que com o uso de container de DI, a codigo fonte final deixa possuir as caracteristicas acima mencionadas. 

Containers Java

Atualmente existem vários containers já consagrados na tecnologia java, alguns padrões baseados em especificações e outros proprietários. Em alguns casos é até viável combinar alguns dentes em uma mesma solução para se cheguar em um ambiente desejado. Aqui vai algumas sugestões de estudo: Spring, HiveMind e Guice.  Não estarei indicando e nem comentando outros containers, por que o foco de hoje é trazer a conhecimento de todos que dentro do JavaServer Faces existe um completo container de DI que venho percebendo ao longo de minhas consultorias que poucas pessoas o conhecem e o usam de verdade. 

JSF Managed Bean Facility Container – JSF

Para aqueles que nunca ouviram falar, a tecnologia JSF vem com um completo container DI embutido chamado de Managed Bean Facility. Com ele é possivel fazer todas as operações básicas de um container. O objetivo deste post é apresentar estas operações, mostrando que na maioria das vezes, os desenvolvedores não precisam gastar horas e horas resolvendo ou costurando outros containers externos em aplicações web usando JavaServer Faces. 

1. Construção de Objetos

Uns dos primeiros critérios importantes para um container DI é controlar o ciclo de vida (vida e morte) dos objetos e o JSF Bean Facility oferece uma robusta solução para isso.  A implementação é feita pela configuração do qualquer POJO no arquivo arquivo faces-config.xml. Veja o exemplo da definição de uma classe e sua configuração que instrui o JSF Bean Facility a gerenciar os objetos dentro um escopo denomidado “request”:

 Acabamos de configurar um objeto para ser criado e destruído a cada pedido HTTP feito para aplicação JSF. As páginas faces podem referenciar este objeto usando a EL – Expression Language #{clienteBean.nome}.

2. Ciclo de Vida

Algo importante para se pontuar é que existem 4 escopos que podem ser utilizados para delimitar o “tempo de vida” de um objeto. Segue um resumo deles:

  • application – criado e armazenado no contexto do servlet. Todos os usuários da aplicação compartilham este objeto. Ele é destruído quando a aplicação for desligado “undeploy”. 
  • session – criado quando a aplicação precisar usar e é armazenado na sessão servlet de cada usuário. Cada usuário tera seu proprio objeto. Ele é destruído quando a sessão do usuário for destruido, não importa a forma.
  • request – criado e armazenado no request servlet do pedido HTTP. Ele é destruído ao termino da resposta HTTP.
  • none – criado e não é armazenado em nenhum lugar. Ele é criado e passado para o recurso que necessitar. Este objeto não é destruído pelo JSF Bean Facility, ficando a cargo do recurso que esta usando  se responsabilizar por isso isso.

3. Inicialização de Propriedades

JSF Bean Facility possui mecanismos bem simples para ser instruido a inicializar propriedades do objetos que estão sobre o seu controle. Segue o exemplo que acrescenta a configuração das propriedades da classe exemplo.Cliente usada no exemplo anterior:

4. Gerenciamento de Dependências

Cuidar das  dependências entres os objetos é um dos requisitos fundamentais de um container, e o JSF Bean Facility tambem não deixa a desejar. Os relacionamentos entre os objetos podem ser declados no  faces-config.xml através da EL – Expression Language. A única limitação do  JSF Bean Facility que vale ser citada é que ele não faz “dependências cíclicas”. Segue abaixo a continuação do mesmo exemplo da classe exemplo.Cliente que agora é agregador de uma classe de chamada de exemplo.Nota. Ou seja, um objeto de Nota sera criado e injetado em um objeto Cliente. Veja as classes completas e a configuração declarativa:

Arquivo  faces-config.xml:

Eu coloquei a declaração dos objetos em sequência lógica para ficar didaticamente mais intuitivo, mas eles podem ser declarado em qualquer ordem que serão resolvidos de qualquer forma. Algo importante de se resaltar é que existe uma simples regra: o escopo do objeto agregador deve ser igual ou maior a do objeto dependende. Para qualquer dúvida, releia o tópico 2 que apresenta todos os escopos existentes no container JSF.

Conclusão

JSF Bean Facility reafirma então a popularização do desenvolvimento baseado em POJOs e a centralização de gerenciamento de objetos baseando em containers. Mesmo ele não oferencendo um leque completo de recursos + serviços como encontrado em outros container conhecidos no mercado, o JSF Bean Facility é suficiente eficaz para controlar objetos que seram utilizados na camada da visão, no qual é o lugar do propria filosofia da especificação JSF. Vale lembrar que outros containers mais completos podem ser integrados com ele, criando assim um ambiente único para suportar outras camadas e serviços para o aplicativo final. Os exemplos apresentados foram elaborados com o objetivo único de apresentar e pontuar os determinados recursos discutivos em questão, estando eles incompletos. Estou a disposição para qualquer eventual dúvida, ajuda  ou idéia complementar. Para todas as informações e possibilidades consulte os livros Core JSF ou JSF in Action. Até a próxima 😉 .

Rod Johnson fala sobre Spring 3.0

Rod Johnson, fundador da Spring e “General Manager” da SpringSource Division da VMware fala sobre as notas features do Spring 3.0, apontando as principais caracteristicas que prometem fazer a o desenvolvimento de aplicações java com Spring muito mais simples que nunca antes. Veja o video e a tradução completa no link oficial da InfQ.

“Nós amamos porque ele nos amou primeiro.” 1 João 4:19

Certificações Sun/Oracle

Veja neste link as respostas de muitas dúvidas relacionados com o fututo das certificações SUN/ORACLE:

Will Oracle University support the Sun Certification Program?
Oracle plans to migrate and offer Sun certification offerings to Oracle certification offerings. Changes in the program will be communicated to candidates on the Sun and/or Oracle Certification Program Web pages. Please check these sites frequently if you have questions or concerns.

Will my Sun certification continue to be valid?
Any Sun certifications that you have earned will continue to be recognized by Oracle and remain valid for the version specified by your credential. Retirement or decommissioning of any certification track will be announced on the Oracle Certification Program Web page.

Will I be required to recertify as a result of Oracle’s acquisition of Sun?
Credential holders will not need to retake exams in order to keep their current Sun credentials. Future certification offerings may require candidates to take an exam if they wish to upgrade. All program requirements will be explained on the Oracle Certification Program Web page.

Can I still get Sun certified? What should I do?
Yes. Sun certification is still available. Follow the paths and instructions that are posted on the Oracle Certification Program Web page. Any updates or changes in requirements will be posted there.

Will the Sun certification tracks or requirements change?
Sun certification tracks will be modified to follow Oracle’s certification model: Associate, Professional, Master, and Expert. All changes to the Sun certification credential names, tracks, and requirements will be available on the Oracle Certification Program Web page.

What is the exam registration process?
Currently, Sun exams are administered at Authorized Prometric Testing Centers. Candidates who wish to take Sun exams should register for those exams under “Sun Microsystems” on Prometric’s Web site.

How can I learn more about Sun certification?
Visit the Oracle Certification Program Web page for information about the Sun Certification Program. This site includes information on available tracks, requirements, and training.

Will my credential be branded Oracle or Sun?
For now, the credential will remain a Sun certification. In the future, Sun certification credentials will be fulfilled through the Oracle Certification Program. Any branding changes will be posted on the Oracle Certification Web page.

Will Oracle continue to sell individual and bundled ePractices?
Yes. ePractice exams will be available for individual purchase and also available within Classroom Value Packages.

How do I obtain vouchers for Sun exams through Oracle University?
Candidates will no longer need to obtain an exam voucher prior to registering for Sun exams at Prometric. Simply go to prometric.com/sun and pay the exam fee with your credit card during the registration process. If you already have an exam voucher, this can still be used as payment at Prometric when you register.

Will Oracle continue to offer the Certification Re-take Promotion?
Certification re-takes will be exclusive to Certification Value Packages. At this time, there are no plans to offer re-take promotions or re-take vouchers on a stand-alone basis.

Whom do I contact for Sun certification customer service inquiries?
Contact ocpexam_ww@oracle.com with Sun certification questions

“Mas Deus, sendo rico em misericórdia, por causa do grande amor com que nos amou, e estando nós mortos em nossos delitos, nos deu vida juntamente com Cristo..” Efésios 2:4

Java EE6 com EJB 3.1

A especificação Enterprise Java Bean 3.0 (EJB 3) marcou de uma maneira muito importante a história da computação distribuida. Ele representou muito mais um simples “paradigma de serviços”, que foi mais um que um “POJO friendly” e bem menos complicado. Se EJB 3.0 foi uma revolução, EJB 3.1 é uma evolução além das expectativas, bem-vindo !!!!! EJB 3.1 apresenta um conjunto de características que aparentemente já deveriam ter sido disponibilizadas no EJB 3.0. Pode-se perdoar o ritmo cauteloso da especificação – melhor ter direito a 80% do que congelar um modelo imperfeito sobre a “evolução glacial” de uma especificação. Vale a pena pontuar que, mesmo com todos esses novos recursos, a especificação EJB 3.1 e toda a compatibilidade retroativa estão em 626 páginas, 14 páginas menores que a especificação EJB 2.1 de quase uma década atrás ! Veja o artigo completo apresentando as novas features no EJB 3.1.

“Porque a mensagem que ouvistes desde o princípio é esta: que nos amemos uns aos outros” 1 João 3:11