É uma solução para realizar cacheamento de páginas ou trechos de páginas JSP através da utilização de um biblioteca de Tags e de um conjunto de classes para realizar o tratamento dinâmico do cache.

Permite ainda que a realização do cacheamento seja feito em memória ou em disco e pode ser utilizado para permitir que a aplicação se recupere de forma elegante de erros críticos. Por exemplo: se houver queda do banco de dados você pode enviar ao usuário o conteúdo disponível no cache permitindo a navegação e utilização do sistema.

Como realizar o cachamento de páginas JSP

• realizar a importação da taglib <%@ taglib uri=”http://www.opensymphony.com/oscache” prefix=”cache”%>
• delimitar o conteúdo a ser cacheado pelas tags <cache:cache> e
  </cache:cache>

• Exemplo de Implementação:

<cache:cache key="idTrecho" duration="24k">   <x:transform doc="xmlDoc" xslt="xsltDoc">

<x:param name="parametro" value="xpto"/>

</x:transform>

<cache:addgroup group="meuGrupo"/>

</cache:cache>

• Atributos da tag cache:cache

• key - utilizado para dar uma identificação única ao trecho cacheado.

• duration - indica a duração do cache. Segue o mesmo pattern do SimpleDateFormat.

• Atributos da tag cache:addgroup

• group - utilizado para identificar de qual grupo o trecho faz parte. Esta informação é muito importante para a o momento de invalidação, pois a mesma é feita por grupos.

Como realizar a invalidação do cache de páginas JSP

Para realizar a invalidação do cache deve-se utilizar a tag <cache:flush>. Veja exemplos de invalidação:

• Invalidação de todo conteúdo cacheado: <cache:flush scope=”application”/>

• Invalidação do conteúdo cacheado e de um grupo específico: <cache:flush scope=”application” group=”meuGrupo” />

• Atributos da tag cache:flush

• scope - scope onde o cacheamento foi realizado. Por default, quando algo é cacheado o escopo é definido como de aplicação.

• group - identifica o nome do grupo que terá o cache invalidado.

Referências

http://www.opensymphony.com/oscache/

Dependendo do tamanho da aplicação, quando é feito o rededploy (redisponibilização) no container OC4J ocorre o seguinte erro de PermGen space: “… nested exception is java.lang.OutOfMemoryError: PermGen spaceCaused by: java.lang.OutOfMemoryError: PermGen space”.

Isto geralmente ocorre quando a instância utiliza os parâmetros default do JDK.

A solução é realizar a configuração do PermGen space que será utilizado pelo OC4J que pode ser feita de duas maneiras:

• Executando a linha de comando: java -jar -XX:MaxPermSize=256M oc4j.jar;
• Ou editando o arquivo opmn.xml e incluindo o parâmetro -XX:MaxPermSize=256M na inicialização do java-options. Veja o exemplo abaixo:

<data id=”java-options” value=”-server -XX:MaxPermSize=256M -Djava.security.policy=$ORACLE_HOME/j2ee/SysturApps/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false”/>

Para maiores detalhes, veja referência da Oracle.

Este assunto sempre dá “pano para manga”, principalmente por não haver nada que padronize e defina suas regras.

Por isto, minha idéia, aqui, foi a de compilar tudo que conheço sobre o assunto e de buscar alguns fundamentos e bases substanciais para endossar meu conhecimento.

E, o primeiro passo para realizarmos a tarefa de controlar a identificação de nossas releases é entender que as melhores práticas para definição de uma esquema para este fim não estão relacionadas apenas com o formato e a distribuição dos identificadores, mas também com algo mais abrangente denominado: Gerenciamento de Release.

Contudo, antes de definirmos este conceito, precisamos definir o significado do termo release de software, que segundo a Wikipedia é:

“release de software é uma distribuição, pública ou privada, de uma primeira ou uma nova versão atualizada de um determinado software“

Então, de forma bem pragmática, Gerenciamento de Release consiste em planejar e organizar as distribuições de seu software.

Por isto, é fundamental sabermos que uma distribuição (release) possui um ciclo de vida composto por diferentes etapas. Onde, cada qual é responsável por descrever a estabilidade do produto e também de denotar quanto desenvolvimento será necessário antes da entrega da versão final do produto.

As fases do ciclo de vida de uma release são:

• alpha - é a versão que está em construção e que foi disponibilizada para a área de homologação, que é geralmente interna à comunidade ou organização que desenvolve o software.
• beta - é a primeira versão lançada fora da organização ou da comunidade que desenvolve o produto, para efeitos de avaliação ou de testes de caixa preta.
• release candidate - refere-se a liberação de uma versão com potencial para se tornar o produto final. Nesta fase, o produto apresenta todas as funcionalidades concebidas sem a presença de bugs impeditivos;
• gold - é a versão final de um determinado produto e normalmente é quase idêntica à release candidate, só que acrescida apenas da correção de pequenos bugs identificados nos testes finais. É considerada muito estável e relativamente livre de bugs, possuindo assim uma qualidade adequada para ampla distribuição e utilização por parte dos usuários finais.

Utilizar esta nomenclatura, como dito antes, auxilia no entendimento da estabilidade do produto bem como na identificação do quão distantes estamos de finalizar a implementação do produto, mas isto por si só, não determina uma identidade única para a release.

Então, para identificarmos unicamente uma distribuição utilizamos um esquema numérico(sequencial e incremental). Este esquema geralmente é composto por três números separados por pontos, por exemplo: 1.0.0.

Este esquema é o mesmo utilizado pela Apache Software Foundation para identificar as releases de seus produtos, veja:

• Esquema da Apache Foundation
  

Esquema	Nome	Características
X.x.x	Major Release	Novas funcionalidades significativas
x.X.x	Minor Release	Melhorias, refatoramentos e evoluções
x.x.X	Revision Release	Correções de bugs

Vamos agora a um exemplo prático da adoção do controle de fases e do esquema utilizado pela Apache:

Faremos o lançamento hipotético de um produto nos próximos 6 meses e definimos que este produto se chamará Sirius e que possuirá 5 funcionalidades.

A release inicial deste produto será identificada, por exemplo, como 0.0.0, o que quer dizer que é a minha primeira versão.

Durante o primeiro mês de trabalho foram implementadas duas funcionalidades e resolveu-se liberar uma versão alpha do produto para a área de homologação chamada: Sirius-0.0.0-alpha.

Durante os testes (que duraram duas semanas) foram encontrados bugs,  que foram corrigidos durante as duas semanas seguintes e liberados em uma nova versão alfa chamada: Sirius-0.0.1-alpha. Notem que a revisão da versão foi incrementada, pois somente o que foi liberado nesta release foram as correções.

Após os novos testes (duas semana depois) não foram encontrados bugs significativos e decidiu-se realizar a liberação da versão beta: Sirius-0.0.1-beta.

E, nesta mesma data, como os desenvolvedores finalizaram mais duas funcionalidades, também foi feita a liberação da versão alpha: Sirius-1.0.0-alpha.

Portanto, com  2 meses de projeto o cenário é o seguinte:

• 4 funcionalidades desenvolvidas;
• 2 funcionalidades testadas e corrigidas internamente (Sirius-0.0.1-alpha);
• 2 funcionalidades liberadas para comunidade (Sirius-0.0.1-beta gerada a partir da Sirius-0.0.1-alpha);
• 2 novas funcionalidades liberadas para testes internos (Sirius-1.0.0-alpha);

Durante o mês seguinte (3º mês), a comunidade pegou vários bugs, assim como os testes internos identificaram outros tantos. Todos estes bugs foram corrigidos e também a última funcionalidade foi desenvolvida. E, com isto, foram liberadas as seguintes versões:

• Sirius-2.0.0-alpha - correções dos bugs encontrados na release Sirius-1.0.0-alpha e liberação da última funcionalidade;
• Sirius-1.0.0-beta - 2 novas funcionalidades e correções dos bugs da release Sirius-1.0.0-alpha e correções dos bugs encontrados na release Sirius-0.0.1-beta;

E depois de mais um mês (4º mês) todos os bugs encontrados nas releases alpha e beta foram corrigidos e foi feita a liberação da versão Sirius-2.0.0-beta contendo todas as 5 funcionalidades e as correções dos bugs das releases  Sirius-2.0.0-alpha e Sirius-1.0.0-beta.

Durante o 5º mês a comunidade identificou outros bugs que foram corrigidos e originaram a release Sirius-2.0.1-alpha que foi liberada internamente e passou nos testes internos sem que houvesse a necessidade de realizar correções e por isto logo em seguida foi liberada a release Sirius-2.0.1-rc (release candidate).

Depois de vários outros testes e da utilização por parte dos usuários e da comunidade, não foram identificados bugs impeditivos e foi liberada a versão final do projeto, chamada de Sirius-2.0.1 (gold).

Bom, é isto aí!

Em breve falarei sobre como tudo isto se integra com um ambiente que utiliza ferramentas SCM e de Integração Contínua.

Aguardem!

Gostaria de atender um pedido de um ex-aluno e falar um pouquinho sobre Orientação a Objetos (OO) e as dificuldades que enfrentei quando,  em 1998, comecei a trabalhar e estudar programação orientada a objeto.

No início, minha maior dificuldade foi romper o cordão umbilical que me ligava ao paradigma de programação/análise estruturada e deixar cair por terra algums paradigmas que tinha sobre programação e desenvolvimento de software.

Nos primeiros meses foi muito difícil fazer com que os conceitos de OO entrassem na minha cabeça de forma clara e consistente.

Tinha muitas dúvidas sobre quais comportamentos e informações deveriam estar ou não em uma determinada classe e também como é que uma classe se relacionaria com outra!

Somente consegui romper esta barreira e deixar para trás estas dúvidas com muita leitura e estudo, para ter na ponta da lingua todos os conceitos básicos de OO, mas foi principalmente observando e estudando soluções que outras pessoas conceberam é que fui conseguindo uma melhor compreensão de como tudo funciona em OO.

Pois bem! Então, como dica para quem está começando ou deseja enveredar-se por este caminho, sugiro:

• Ler e estudar sempre (todos os dias se possível);
• Observe e analise o que pessoas mais experientes fizeram;
• E, questione! Não fique com dúvidas! Busque respostas para tudo que lhe causar estranheza ou desconforto.

Resolvi escrever também, além deste pequeno depoimento, de uma forma um pouco mais estruturada sobre o assunto. E por isto realizei abaixo uma rápida e breve compilação dos principais conceitos e caracterísiticas de OO.

Histórico

Orientação a Objetos (OO) surgiu na década de 60 com o intuito de ajudar a diminuir a complexidade de construção e manutenção de software, enfatizando fortemente: unidades discretas de programação lógica e reutilização de software.

Simula foi a primeira linguagem de programação a introduzir tais conceitos que ganharam grande evidência na década 90 através da linguagem C++ e pela crescente popularidade das interfaces gráficas.

Já na última década ganhou mais notoriedade devido a popularização da linguagem Java, principalmente, pelo fato desta ser multiplataforma.

O que é OO?

É um paradigma utilizado para desenvolvimento de software que baseia-se na utilização de componentes individuais denominados objetos que colaboram entre si para construir sistemas complexos.

A colaboração entre os objetos é feita através do envio de mensagens.

Analogamente, significa organizar o mundo real como uma coleção de objetos que incorporam dados e operações que manipulam estes dados.

Benefícios

• Os modelos refletem o mundo real de maneira mais próxima;
• São mais fáceis de entender, manter e evoluir;
• Possibilitam a reutilização de código;
• Redução das linhas de código programadas;
• Auxiliam e propiciam a separação de responsabilidades;
• Ajudam na modularização e componentização da solução;

Conceitos Gerais

• Classe
  • Define características abstratas dos objetos;
  • Define os atributos (informações) e métodos (comportamentos) dos objetos;
  • É a “planta” que define como serão os objetos.

• Objeto
  • Um objeto possui um estado (atributos), exibe um comportamento (operações) bem-definido e possui uma identidade única (referência).

• Atributo
  • São características de um objeto, basicamente a estrutura de dados que vai representar a classe. Exemplos:
    1. Classe Funcionário: nome, endereço,telefone, CPF;
    2. Classe Carro: nome, marca, ano, cor;
    3. Classe Livro: autor, editora, ano.

• Método (operações/comportamentos)
  • Define os comportamentos dos objetos.
  • Por exemplo, Spartacus é uma instância da classe Cachorro e portanto tem habilidade para latir, definida através do método latir().
  • Este comportamento somente ocorre quando o método é invocado através do objeto, no caso Spartacus.latir().
  • Programaticamente a utilização de um método deve afetar apenas um objeto em particular, pois todos cachorros podem latir, mas queremos que apenas Spartacus dê o latido.

• Mensagem
  • É a chamada de um método de um objeto com o objetivo de ativar um determinado comportamento descrito pela classe deste objeto.
  • Uma mensagem pode ser enviada para um método de um objeto ou de uma classe, neste último caso ele é chamado de método estático.

• Abstração
  • É operação pela qual o espírito considera separadamente coisas inseparáveis na natureza e resulta no processo mental em que as idéias estão distanciadas dos objetos por meio de uma operação intelectual que isola os generalismos teóricos dos problemas concretos, para que estes sejam resolvidos
  • Trata-se de um mecanismo essencial em disciplinas filosóficas e científicas, pois traz consigo a habilidade de concentrar nos aspectos essenciais de um contexto qualquer, ignorando características menos importantes ou acidentais.
  • Em OO, uma classe é uma abstração de entidades existentes no domínio de um sistema de software.

Caracterísiticas

• Encapsulamento
  • Consiste na separação de aspectos internos e externos de um objeto.
  • É um mecanismo amplamente utilizado para impedir o acesso direto ao estado de um objeto (seus atributos), disponibilizando externamente apenas os métodos que alteram estes estados.
  • Por exemplo: você não precisa conhecer os detalhes dos circuitos de um telefone para utilizá-lo, pois a carcaça do telefone encapsula esses detalhes, provendo a você uma interface mais amigável (os botões, o monofone e os sinais de tom).
• Herança
  • Herança é um mecanismo da OO que permite criar novas classes a partir de classes já existentes, aproveitando-se das características existentes na classe a ser extendida.
  • Este mecanismo promove reuso e reaproveitamento de código além de possibilitar a criação de classes derivadas (subclasses) a partir de classes bases (superclasses).
  • As subclasses são mais especializadas do que as suas superclasses, mais genéricas, e todas herdam todas as características de suas superclasses, como seus atributos e métodos.
• Polimorfismo
  • É a capacidade de um objeto ser referenciado de várias formas o que quer dizer que a referência ao objeto se transforma, ou fica se transformando ao longo do tempo.
  • Vale ressaltar que um objeto nasce e morre sendo de um mesmo tipo e o que muda ou transforma-se é a maneira de como nos referenciamos a ele. Por exemplo: um gerente financeiro pode ser tratado (referenciado) como gerente financeiro, gerente ou funcionário quando estamos em um contexto de uma empresa. Se ampliarmos este contexto também podemos dizer que um gerente financeiro pode ser tratado (referenciado) como pessoa física, por exemplo.

Espero que este material possa ajudá-lo a entrar no mundo OO com pé direito.

Sucesso e boa sorte na jornada!

 

Domingo, dia 03/02, estávamos, eu e meu filho Gabriel, fazendo uma típica atividade de pai e filho: assistindo um desenho animado!

O desenho contava a estória de um garoto que encontrou uma lâmpada mágica e um gênio que lhe concedia três desejos. Até aí tudo normal, no entanto, no meio de toda a estória, meu filho fuzilou a seguinte pegunta:

Papai quais seriam os seus três desejos?

Confesso: titubiei, travei, deu pane!

Não respondi!

Mas fiz o que geralmente os pais fazem quando não querem ou não sabem a resposta: devolvi a pergunta, que prontamente foi respondida com a apresentação de uma enorme lista de brinquedos, é claro que todos com alguma coisa do homem aranha!

O engraçado é que aquela pergunta ficou martelando! E não consigue parar de pensar nisto!

Primeiro, pensei em fazer pedidos que sanariam alguns desejos pessoais como: dinheiro, carros, viagens, etc, etc, etc; mas o o engraçado é que logo bateu um grande sentimento de egoísmo!

Afinal, teria oportunidade para mudar ou fazer qualquer coisa que ajudasse várias pessoas ao mesmo tempo e porque não fazê-lo? Será que outras pessoas também teriam o mesmo pensamento?

Então, semana passada, comentei sobre o ocorrido com a galera da Arquitetura da CVC (Leandro, Morais, Hirata e Valdir) e a conversa fluiu de forma um tanto quanto esperada, pois, todos, também resolveriam e pediriam coisas pessoais.

Mas, quando questionei-os sobre ter o poder para mudar o mundo, curar doenças, dar emprego ou dar estudo e dignidade as pessoas é que me surpreendi!

Isto porque concluímos que: bens materiais, comida, esmolas ou uma casa, por exemplo, não resolveriam o(s) problema(s) das pessoas menos favorecidas, mas sim, propiciar a estas pessoas a chance de tornarem-se cidadãos, sábios de seus direitos e deveres, capazes de construir uma vida digna e honrada. O que somente pode ser feito dando oportunidades de crescimento e amadurecimento físico, moral, emocial, psicológio e educacional a estas pessoas.

Pois bem, depois de toda esta conversa, fiquei pensando: será que precisamos encontrar uma lâmpada com um gênio mágico para realizarmos nossos desejos pessoais e principalmente para começarmos a agir como catalisadores de mudanças em nossa sociedade?

Com certeza, não!

Por isto, gostaria de lançar um desafio a todos nós:

Vamos nos empenhar e atuar de fato, até o final deste ano de 2008, como catalisador de mudança de vida para pelo menos uma pessoa?

O que vocês acham?

Vão encarar?

Uma das operações que mais consomem tempo em aplicações JavaEE é a de estabelecer conexão com o banco de dados. Os servidores de aplicação possuem recursos de caching e pooling de conexões para minimizar o overhead causado por este tipo de tarefa.

No OC4J este mecanismo esta relacionado com o tipo de datasource utilizado pela aplicação. Os tipos de datasource suportados pelo application server são:

Managed Data Source

É gerenciado pelo application server e pode ser utilizado através da interface java.sql.DataSource, que atua como um wrapper para um driver JDBC ou para o datasource. Por sua vez, os componentes JavaEE acessam estes datasources via JNDI que faz o mapeamento com o wrapper em questão.
Para este tipo de datasource, o OC4J provê uma infra-estrutura com gerenciamento de controle transacional, cache e pool de conexões, configuração dinâmica via JMX além de tratamento de erros.

Native Data Source

Este tipo também é utilizado através da interface java.sql.DataSource, no entanto são implementados pelo respectivo driver JDB. Desta maneira este tipo de datasource não são gerenciados pelo OC4J.

Como configurar o database connection caching

Configurar o connection caching no OC4J é relativamente simples, pois isto é feito de forma declarativa diretamente no arquivo data-sources.xml. Este arquivo pode ser encontrado na pasta config da instância do OC4J.

Os passos necessários para sua configuração são:

1. editar o arquivo data-sources.xml
2. adicionar o elemento <connection-pool> e definir seus atributos
3. adicionar o elemento <managed-data-source> ou o elemento <native-data-source> e definir seus atributos
4. salvar o arquivo
5. reiniciar a instância do OC4J utilizando-se o opmnctl ou através do enterprise manager

Atributos do elemento connection-pool

Atributo	Descrição	Default
name	(Requerido) Nome do pool de conexões. Deve ser único	n/a
min-connections	o número mínimo de conexões abertas que o pool deverá manter	0
max-connections	número máximo de conexões que o pool deverá manter. Se um valor menor ou igual a zero for setado indicará que não existe um número máximo de conexões e sempre que necessário uma nova conexão será criada.	0
initial-limit	indica a quantidade de conexões que deverão ser criadas inicialmente no cache na inicialização ou reinicialização da instância. Esta propriedade geralmente é utilizada para reduzir custo de criação de conexões e desta forma otimizar o cache de conexões.	0
used-connection-wait-timeout	Tempo em segundos que o application espera para que o cliente libere a conexão. Este atributo aplica-se somente quando todas as conexões definidas no max-connections estiverem em uso. Neste caso quando um cliente solicita uma conexão e todas estão sendo utilizadas o application aguarda este tempo para que uma das conexões seja liberada .	60
inactivity-timeout	indica quanto tempo em segundos as conexões inativas permanecerão no pool. Após este intervalo tempo o application remove a conexão do pool	60
login-timeout	tempo máximo em segundos que será aguardado para que a conexão com o banco de dados seja realizada. O valor zero indica deve ser utilizado o timeout padrão do sistema, se houver. Caso contrário, indica que não há limite de tempo	0
connection-retry-interval	intervalo em segundos que o application aguarda antes de retornar erro na tentativa de obtenção/abertura de conexão. Este atributo é utilizado em conjunto com o atributo max-connnect-attempts	1
max-connect-attempts	número de tentativas para retornar uma conexão. É utilizado em conjunto com o atributo connection-retry-interval	3
validate-connection	indica se a conexão, quando obtida do pool, deverá ser validada contra a base de dados. O valor “true” indica o statement declarado no atributo validate-connection-statement será executado para verificar se a conexão é válida ou não.O valor “false” indica que o statement não será executada. É utilizado em conjunto com o atributo validate-connection-statement	false
validate-connection-statement	statement SQL que será executado para validar a conexão contra a base de dados, quando a mesma for obtida no pool. É utilizado em conjunto com o atributo validate-connection	n/a
num-cached-statements	número máximo de statements que serão armazenados em cada conexão. Qualquer valor superior a 0 faz automaticamente o cache do statement para o datasource.	0
time-to-live-timeout	tempo máximo, em segundos, que uma conexão ativa pode ser utilizada. Quando esse tempo limite expirar, a conexão será fechada incondicionalmente, e os handles dos statements em execução serão cancelados e a conexão será devolvida para o pool. O valor -1 indica que este recurso não está ligado.	-1
abandoned-connection-timeout	Utilizado somente para banco de dados Oracle. É semelhante ao inactivity-timeout, mas atua sobre uma conexão lógica.	-1
disable-server-connection-pooling	Determina se o pool de conexões será desativado ou não. Está disponível porque alguns drivers JDBC fornecem pool de conexões e quando o driver é Oracle e utiliza pool implícito este atributo será ignorado.	false
property-check-interval	Utilizado somente para banco de dados Oracle, este intervalo de tempo, em segundos, é utilizado para determinar o limite de tempo de espera das threads do cache daemon	900
lower-threshold-limit	Utilizado somente para banco de dados Oracle. O menor limite do pool de conexões, seu padrão é de 20% da quantidade indicada no atributo max-connections	20%

Atributos do elemento connection-factory

Attributo	Descrição	Default
factory-class	(Requerido) define o path completo da classe de implementação do connection-factory e deve ser uma implementação das interfaces java.sql.Driver, javax.sql.DataSource, javax.sql.ConnectionPoolDataSource, ou javax.sql.XADataSource.	n/a
url	(Requerido) Url de conexão com o banco de dados	n/a
user	o login do usuário utilizado para realizar a conexão com o banco de dados	n/a
password	a senha utilizada para realizar a conexão com o banco de dados	n/a
login-timeout	O tempo máximo em segundos que deverá ser esperado enquanto é realizada a conexão com o banco de dados. O valor zero indica que não há timeout para esta operação e este é o valor default.	0

Veja um exemplo completo do connection-pool e connection-factory:

<connection-pool name="myConnectionPool"

min-connections="10"

max-connections="30"

inactivity-timeout="30">

<connection-factory

factory-class="oracle.jdbc.xa.client.OracleXADataSource"

user="scott"

password="tiger"

url="jdbc:oracle:thin:@localhost:1521:oracle"/>

<property name="nativeXA" value="true"/>

</connection-factory>

</connection-pool>

Atributos do elemento managed-data-source

Atributo	Descrição
jndi-name	nome JNDI utilizado para o servidor fazer o lookup do pool de conexões. Deve ser único
description	descrição do datasource
connection-pool-name	nome do pool de conexões criado no elemento connection-pool
name	nome do datasource. Deve ser único

Veja um exemplo:

<managed-data-source jndi-name="jdbc/ManagedXADS"

description="Managed DataSource"

connection-pool-name="myConnectionPool"

name="ManagedXADS"/>

Atributos do elemento native-data-source

Atributo	Descrição
jndi-name	nome JNDI utilizado para o servidor fazer o lookup do pool de conexões. Deve ser único
description	descrição do datasource
name	nome do datasource. Deve ser único
data-source-class	define o path completo da classe que obtém a conexão

Veja um exemplo:

<native-data-source
 name="nativeDataSource"
 jndi-name="jdbc/nativeDS"
 description="Native DataSource"
 data-source-class="oracle.jdbc.pool.OracleDataSource"
 user="scott"
 password="tiger"
 url="jdbc:oracle:thin:@localhost:1521:oracle">
  <property name="connectionCacheName" value="ICC1"/>
  <property name="connectionCachingEnabled" value="true"/>
  <property name="fastConnectionFailoverEnabled" value="false"/>

</native-data-source>

Um dos relacionamentos relacionais mais comuns é o um para um. Neste post mostrarei como fazer o mapeamento de objetos que relacionam-se desta forma e portanto devem ser persistidos utilizando-se esta estratégia.

Imagine o seguinte cenário: uma pessoa que é representada pela classe Pessoa possui um único endereço aqui representado pela classe Endereço.

Neste cenário temos uma relação de associação entre as classes Pessoa e Endereço e a navegabilidade é unidirecional partindo da classe Pessoa.

Para fazermos tal mapeamento ORM devemos criar as entidades da seguinte maneira:

@Entity
@Table(name = “TB_PESSOA”)
public class Pessoa implements Serializable {
@Id
@GeneratedValue
@Column(name = “ID_PESSOA”)
private long id;

@OneToOne
@JoinColumn(name = “ID_ENDERECO”)
private Item item;
}

@Entity
@Table(name = “TB_ENDERECO”)
public class Endereco implements Serializable {

@Transient
private String logradouro;

@Id
@GeneratedValue
@Column(name = “ID_ENDERECO”, insertable = true, updatable = false)
private long id;
}

Simples né!

Mais detalhes e um exemplo de implementação podem ser obtidos clicando-se aqui.

Há algum tempo tenho sentido vontade de escrever sobre assuntos relacionados ao desenvolvimento de software e apesar deste sentimento, não conseguia organizar-me e até mesmo estimular-me para fazê-lo de forma periódica e consistente.

No entanto, nos últimos meses, este cenário mudou!

Deixe-me explicar o porquê: em agosto/2007 comecei a prestar serviços de consultoria na CVC Turismo pela SeedTS para atuar como Arquiteto e Mentor de Tecnologias Java, com o objetivo deste trabalho é de auxiliar a recém criada área de Arquitetura e Qualidade da CVC a definir, criar, dissiminar e manter novos processos, metodologias, tecnologias e ferramentas para apoiar todo o processo de desenvolvimento de software da empresa.

Outro fator motivador foi a constatação que tive com os alunos de um curso de extensão que ministrei na FIP (UEMG campus Passos/MG) em setembro/2007, onde percebi que todos são e estão ávidos por conhecimentos e por novidades. Por isto comecei a pensar em uma maneira de encontrar outras formas além de cursos presenciais, para compartilhar o pouco do conhecimento e experiência que tenho na área e assim ajudá-los a desenvolverem-se mais na área.

Tudo isto tornou-se o catalisador para tornar realidade o sentimento de outrora!

Durante os últimos três meses ensaiei o início de um blog com o objetivo de “pegar o jeito da coisa”, escolher ferramentas e principalmente de maturar e definir quais seriam os assuntos e temas que o blog trataria.

E, depois de ensaiar, agora estou pronto para efetivamente começar a está história que terá como temas os assuntos que venho desenvolvendo juntamente com a equipe de arquitetura da CVC: Domain Driven Design(DDD), Scrum, Continuous Integration (CI), Fundamentos JavaEE, Conceitos OO e Desenvolvimento orientado a testes (TDD).

Todos os posts que havia pulbicado anteriormente durante o “período de testes” foram transferidos para este blog, portanto, chega de blá blá blá e vamos ao que interessa…

Gostaria de compartilhar com vocês minha leitura do evento http://www.javabrasil.org/ e para isto começar dizendo: quem não foi perdeu!

Perdeu um evento com um alto nível técnico e oportunidades de conhecer e trocar figurinhas com profissionais de todo Brasil e que mesmo com os pequenos contratempos perdeu um evento muito bem organizado e com uma estrutura de boa qualidade.

Também não poderia deixar de registrar alguns pontos altos, na minha opinião, que marcaram positivamente o evento:
- a palestra do Lucas Machado sobre JSF foi de arrepiar, um verdadeiro show. O cara é TORA!!
- outro que detonou foi o Rodrigo Yoshima: “Xô Gant Chart”
- e mais um incrível show aconteceu no Agile Immersion do dia 02/11 com o Manoel Pimentel (aquela dinâmica de encerramento foi DUCA e fechou o dia com chave de ouro).

Resumindo: foi simplesmente um show! Valeu cada centavo investido.

Segue uma breve transcrição do que na minha opinião foi mais importante:

Agile Imersion - Manoel Pimentel

Foi um workshop de aproximadamente 6 horas, onde foram passados os conceitos e valores dos métodos ágeis e depois uma breve conceituação de SCRUM, seguida de um exercício prático onde todos os conceitos e práticas do SCRUM foram utilizados. Um dos pontos altos foi a dinâmica de encerramento que nos evidenciou o quanto equipes alto gerenciadas podem ser mais produtivas e eficientes.

Gerenciamento de Projetos com Scrum - Rodrigo Yoshima

Este foi outro workshop de 6 horas sobre SCRUM. Foi um pouco mais conceitual que o Agile Immersion, no entanto foi bem completo e focou em situações corriqueiras
do dia a dia da utilização do SCRUM, como:

- atuação do Scrum Master conjuntamente com o product owner na identicação dos itens do Product backlog
- atuação do Scrum Master e do time nas reuniões de planejamento da sprint,
- negociação e definição da prioridade de itens com o product owner
- estimativa de itens do product backlog;
- daily meeting;
- tratamento de impedimentos;
- reuniões de Sprint review e Sprint retrospective;

Enfim foi uma abordagem teórica, só que calcada na grande experiência e vivência prática que o Rodrigo possui.

Minhas conclusões

Para mim, o evento cumpriu o que propôs: falar sobre práticas e métodos ágeis com um foco especial em SCRUM.

Com isto consegui identificar que tudo que venho aplicando nos últimos meses estão aderentes as tendências de mercado, e principalmente que a adoção de práticas ágeis na gestão, concepção, design e desenvolvimento não são mais tendências e sim uma grande e sonora realidade.

Vi também que devemos romper algumas barreiras em relação a alguns pontos e conceitos:

- Prestamos um serviço intelectual e não repetitivo o que caracteriza a necessidade de utlizarmos abordagens de um processo empírico pois o software é um organismo vivo e temos que parar de achar que os requisito são imutáveis pois não o são;

- Portanto, o software está em constante evolução e por este motivo trabalhar com escopo, prazo e custo fechado é loucura;

- Temos que envolver o cliente no processo de produção do software, ou seja, temos que estreitar e tornar periódica esta comunicação;

- Temos que entregar software pronto (para entrar em produção) e que agregue valor de negócio ao cliente, pois pesquisas comprovam que 45% das funcionalidades de um sistema nunca são utilizadas;

- Devemos documentar, mas somente aquilo que for necessário para garantir a qualidade interna do produto e conseqüentemente a fácil evolução e manutenção do mesmo.

Bem, esta é minha humilde opinião e espero que ela possa, de alguma forma, contribuir.

JVM (Java Virtual Machine)

empre me pergutam sobre as diferenças entre JRE e JDK, Java e JavaEE, por isto resolvi descrevê-las aqui:

É a peça chave para fornecer capacidade de multiplataforma para as aplicações java: “Write once, run everywhere”.
A JVM é a máquina virtual responsável por interpretar e executar o código Java compilado (bytecode) e portanto são provedoras de formas e meios de o aplicativo conversar com o sistema operacional.

Esta abstração viabiliza a implementações da JVM para diferentes plataformas de hardware e de sistemas operacionais, o que possibilita que aplicativos Java sejam multi-plataforma.

Uma JVM pode ser desenvolvida por qualquer organização (comunidades / institutos / empresas), desde que sigam as especificações para a Java Virtual Machine.

JRE (Java Runtime Environment)

É composto pela JVM e pela biblioteca de classes Java utilizadas para execução de aplicações java, estas bibliotecas são chamadas de APIs Java.

Portanto para rodarmos uma aplicação java é necessário instalarmos uma JRE no computador onde o software foi instalado.

JDK (Java Development Kit)

É o conjunto de ferramentas necessárias para realizar o desenvolvimento de aplicações java e inclui a JRE e ferramentas de programação, como:

• javac - compilador
• jar - empacotador
• javadoc - ferramenta para geração de documentação

Java Platform

São “distribuições” ou edições de programas e APIs java relacionadas entre si.

Estas edições têem o intuito de facilitar o download e a e instalação de ferramentas e APIs para realizar o desenvolvimento e execução de aplicações java.

Cada edição contém ferramentas e APIs específicas para um determinado tipo de aplicação, veja quais são as edições disponíveis:

• Java SE
  É a base da plataforma Java e é utilizada para desenvolver aplicativos desktops e servidores.
• Java EE
  Necessária para desenvolver softwares que rodam em servidores de aplicações (geralmente aplicações web).
• Java ME
  Utilizada para desenvolver softwares para dispositivos móveis e para dispositivos com pouca capacidade de processamento, como por exemplo: telefones celulares e impressoras.

Java

É a linguagem de programação Java.

Veja detalhes e composições dos itens acima através da galeria de imagens abaixo: