Segundo o guia de implementação do Mps.Br Nível C, o propósito do processo Gerência de Riscos é identificar, analisar, tratar,monitorar e reduzir continuamente os riscos em nível organizacional e de projeto. Sem sombra de dúvidas não há como discordar com essa definição. Porém os líderes de projetos devem se ater ao fato que independentemente de qual nível sua organização se encontre com relação ao Mps.Br, CMMI, ou qualquer outro orgão que promova a melhoria ou capacitação do processo, é importante se ater a medidas que podem evitar que um projeto fracasse. A Gerência de Risco é uma dessas medidas que pessoalmente acho muito importante, mas que não tira a importância de outras faculdades de gerenciamento. O IEEE define risco como a probabilidade de um evento, perigo, ameaça ou situação ocorrer associado a indesejáveis consequências, ou seja, um problema potencial. Para essa definição de risco, o IEEE define um fluxo de sequências a serem seguidas para garantir que a Gerência de Riscos seja eficiente e efetiva durante todo o ciclo de vida do projeto.
Fluxo da Gestão de Risco proposto pelo IEEE
1 – O processo técnico e gerencial envolve os stakeholders, define os requisitos e o processo de gestão de risco que deve ser sustentado.
2 – Essas informações requisitadas são passadas para ambas atividades “Planejar e Implementar a Gestão de Risco” e “Gerenciar o perfil do risco de projeto”. Na atividade “Planejar e Implementar a Gestão de Risco”, estão as políticas a respeito das orientações gerais sob qual gestão de risco será conduzida, os procedimentos a serem utilizados, as técnicas específicas para serem aplicadas, e assim por diante.
3 – Na atividade “Gerenciar o perfil do risco do projeto” o contexto atual e histórico da gestão de risco e as informações sobre o estado do risco são capturados. O perfil do risco do projeto inclui a soma total de dos perfis individuais do risco, que por sua vez, incluem todos os estados do risco.
4 – A informação sobre o perfil do risco de projeto é continuamente atualizado e mantido através da atividade “Realizar análise do risco”, que identifica os riscos, determina suas probabilidades e conseqüências, determina as exposições ao risco, e prepara requisitos de ação para combater o risco, recomendando tratamento para riscos determinados a serem superiores ao seu limiar de risco.
5 – Recomendações de tratamento, juntamente com o status dos outros riscos e seus status de tratamento, são enviadas para a gerência para revisão. A gerência decide qual tratamento de risco é implementado para qualquer risco encontrado que seja inaceitável. Planos de tratamento de risco são criados para os riscos que requerem tratamento. Esses planos são coordenados com outros planos de gestão e outras atividades em curso.
6 – Todos os riscos são continuamento monitorados até que eles não precisem mais ser controlados durante a atividade “Realizar monitoramento de risco”. Em adição novos riscos são procurados.
7 – Periódica evolução do processo de gestão de risco é requisitada para assegurar sua efetividade. Durante a atividade “Avaliar processo de gestão de risco”, a informação, incluindo usuário e outro feedback, é capturada para melhorar o processo ou para melhorar a habilidade de gestão de risco da organização ou projeto. Melhoramentos definidos como resultado de avaliação são implementados na atividade “Planejar e implementar a gestão de risco”.
O processo de gestão de risco é aplicado continuamente através do ciclo de vida do produto. Entretanto, atividades e tarefas do processo de gestão de risco interagem com o risco individual de uma maneira iterativa uma vez que o processo de gestão de risco se inicia. Por exemplo, na atividade “Realizar análise de risco”, o risco pode ser re-estimado várias vezes durante a realização da avaliação do risco com o objetivo de melhorar o ganho de conhecimento sobre o risco durante a avaliação da própria tarefa. O processo de gestão de risco não é um processo em “cascata”.
Em resumo este é um processo que você como gerente ou líder de projeto, talvez deva ter como princípio, ou ao menos parcialmente, para aqueles projetos que expõe maior grau ao risco. Por experiência própria essas medidas podem assegurar uma explosão de mini-benefícios em série, que ao final do projeto, certamente farão muita diferença entre o sucesso ou insucesso do projeto. Portanto, mesmo sem um processo bem definido na organização onde você trabalha, tente ter um processo para gerenciar os riscos dos projetos onde você atua.
Invocando EJB 2 do EJB 3
Como parte da nossa estratégia de migração, verificaremos as invocações do EJB 2 feitas a partir do EJB 3. É perfeitamente posssível invocar session beans ou entity beans do EJB 2 a partir do EJB 3. Em nosso caso, precisaremos declarar a dependência do nosso projeto diarioEletronicoEJB3 ao .jar do projeto diarioEletronicoEJB, pois existem classes e métodos específicos que ainda não foram migrados e precisam ser conservados, ao menos por enquanto, no EJB 2.
Clicando com o botão direito do mouse em cima do projeto diarioEletronicoEJB3 entramos em properties , logo em seguida, clicamos em Java EE Module Dependencies e marcamos o diarioEletronicoEJB.jar para mantermos dependência. Veja a Figura 11.
Figura 11
Depois de realizada essa tarefa, nos resta realizar um teste para verificarmos se conseguiremos ou não realizar as chamadas aos beans do EJB 2, a figura 12, explica o que estamos tentando fazer aqui.
Figura 12
Para ilustramos, vamos assumir um Entity Bean implementado em EJB 2 chamado (AvaliacaoBean) que possui um método chamado findAvaliacaoByTurma, abaixo temos a assinatura do método em sua interface local:
... public java.util.Collection findAvaliacaoByTurma(java.lang.String codigoPeriodo, java.lang.String codigoOfertante, java.lang.String codigoTipoAtividade, java.lang.String codigoAtividade, java.lang.String codigoTurma) throws javax.ejb.FinderException; ...
Não entraremos nos detalhes dessa implementação. Em nosso Session Bean implementado em EJB3 vamos usar a a anotação @EJB para injetar uma instância de um objeto Home para ManterAvaliacaoBean.
...
@EJB AvaliacaoLocalHome avaliacaoLocalHome;
...
public ArrayList pesquisarAvaliacoesTurma(TurmaKeyTO turmaKeyTO) throws ufmg.cecom.diario.DiarioException{
ArrayList res = new ArrayList();
try{
Collection colecaoAvaliacao = avaliacaoLocalHome.findAvaliacaoByTurma(turmaKeyTO.getCodigoPeriodo(),turmaKeyTO.getCodigoOfertante(), turmaKeyTO.getCodigoTipoAtividade(),turmaKeyTO.getCodigoAtividade(),turmaKeyTO.getCodigoTurma());
if (colecaoAvaliacao!=null) {
res = AvaliacaoTOAssembler.obtemInstancia().montarAvaliacao(colecaoAvaliacao, true);
}
}catch (FinderException e){e.printStackTrace();}
Collections.sort(res);
return res;
}
...
avaliacaoLocalHome é a variável do tipo AvaliacaoLocalHome injetada com @EJB, depois da variável injetada, é possível fazer a chamada para findAvaliacaoByTurma. Por questões de implemetação estamos utilizando TurmaKeyTO que trata-se de um DTO para podermos obter os valores de pesquisa apenas, e a classe AvaliacaoTOAssembler serve única e exclusivamente para montar os objetos que eu preciso. Finalmente, isso cobre as invocações do EJB 2 a partir do EJB 3.
Conclusão
Existem muitas outras questões envolvendo o processo de migração de tecnologia EJB 2 para EJB 3, o nosso objetivo aqui era apenas criar um passo a passo em um ambiente específico, que no nosso caso é o Websphere Application Server v.7.0 e IDE IBM Rational® Application Developer™ for WebSphere® Software 7.5.5.1. Cabe ao arquiteto de software elaborar a melhor estratégia e tentar mitigar todos os riscos antes de entrar em um processo de migração massivo, pois sem essas premissas, o preço que se paga pode ser muito alto. Fazendo uma comparação, seria o mesmo que realizar uma mudança de residência vendo apenas as fotos do novo imóvel sem nunca tê-lo visitado. Com certeza o pobre novo morador encontrará surpresas que não esperava. Espero que esse tutorial, possa ajudá-lo de alguma maneira. No decorrer do tempo publicarei outras informações sobre o processo de migração. Me coloco a disposição para esclarecimentos.
Testando a invocação de métodos do EJB3.
Antes de passarmos para a fase de invokes vamos realizar um teste para ver se realmente nossa aplicação está se comunicando com o projeto diarioEletronicoEJB3.
Em nossso exemplo, criei um session bean chamado ManterAvaliacaoBean como na figura abaixo, aqui não entraremos no mérito de implementação de um session bean em EJB 3, pois esse não é o nosso foco, por isso estou considerando que o leitor já tenha um conhecimento prévio sobre EJB 3.
Figura 8
Em ManterAvaliacaoBean temos o seguinte código implementado apenas para efeito de teste:
package teste.diarioEJB3.negocio.avaliacao.ejb;
import javax.ejb.Stateless;
/**
* Session Bean implementation class ManterAvaliacaoBean
*/
@Stateless
public class ManterAvaliacaoBean implements ManterAvaliacaoBeanRemote, ManterAvaliacaoBeanLocal {
/**
* Default constructor.
*/
public ManterAvaliacaoBean() {
// TODO Auto-generated constructor stub
}
public String testeEJB3 (){
return "Teste de comunicação de EJB 3 funcionando";
}
}
Bem, no que diz respeito ao Naming do bean ManterAvaliacaoBean eu utilizei JNDI com o design pattern Service Locator, porém não vou entrar em detalhes de implementação aqui, apenas mostrarei a configuração e códigos utilizados. Abaixo temos o ejb-jar.xml:
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"> <display-name>DiarioEletronicoEJB3</display-name> <enterprise-beans> <session> <ejb-name>ManterAvaliacaoBean</ejb-name> <mapped-name>ManterAvaliacaoBean</mapped-name> <business-local>teste.diarioEJB3.negocio.avaliacao.ejb.ManterAvaliacaoBeanLocal</business-local> <business-remote>teste.diarioEJB3.negocio.avaliacao.ejb.ManterAvaliacaoBeanRemote</business-remote> <ejb-class>teste.diarioEJB3.negocio.avaliacao.ejb.ManterAvaliacaoBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> </enterprise-beans> </ejb-jar>
em seguinte temos o arquivo ibm-ejb-jar-bnd.xml que é gerado automaticamente pelo RAD, nesse caso criei um simple-binding-name para o bean chamado diarioejb3/ejb/FachadaAvaliacao.
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-ejb-jar-bnd_1_0.xsd" version="1.0"> <session name="ManterAvaliacaoBean" simple-binding-name="diarioejb3/ejb/FachadaAvaliacao"></session> </ejb-jar-bnd>
Aqui temos o método do Service Locator para localizar via JNDI o bean de ManterAvaliacaoBean.
...
public ManterAvaliacaoBeanRemote getFachadaTestarEJB3() {
InitialContext ctx;
try {
ctx = new InitialContext();
ManterAvaliacaoBeanRemote me = (ManterAvaliacaoBeanRemote)ctx.lookup("diarioejb3/ejb/FachadaAvaliacao");
return me;
} catch (NamingException e) {
e.printStackTrace();
}
return null;
}
...
Para matar a curiosidade de muitos, aqui está o Name Space Binding que eu configurei no servidor local.
Figura 9
Bom, depois de enveredarmos um pouco pelo caminho da configuração, vamos ao que interessa, em nosso projeto diarioEletronicoWeb, pegarei uma classe qualquer e farei uma chamada ao meu EJB para saber se o mesmo responde e se o fato de estarmos utilizando EJB 2 e EJB 3 na mesma aplicação não resultará em algum efeito colateral. Abaixo temos o trecho de código que faz uma chamada remota ao método testeEJB3() no bean ManterAvaliacaoBean.
... System.out.println(ServiceLocatorTeste.obtemInstancia().getFachadaTestarEJB3().testeEJB3()); return forward; } ...
Ao executar o método que contêm a chamada anterior, podemos ver no console a saída e o funcionamento correto de nossa aplicação.
Motivos para migrar EJB 2 para EJB 3
A migração, seguramente é menos cara do que a reconstrução de um novo sistema. Existem diversos motivos para a migração de EJB 2 para EJB 3, mas particulamente, acho que a facilidade fornecida para desenvolvimento e detecção de problemas, já são motivos mais do que suficientes. Por esses simples motivos, posso assegurar que incontáveis aplicações escritas em EJB 2 serão migradas para EJB 3 em todo mundo. As migrações podem ocorrer através de porções ou não totalmente, pois toda migração, envolve riscos, que nem sempre podem ser mitigados ao extremo por diversas questões como, compatibilidade oferecida pelos fabricantes, problemas de interoperabilidade, etc.
Nesse post vamos tentar elaborar um passo a passo da estratégia de migração que adotei, levando-se em consideração a tecnologia, o fabricante e os riscos, isso significa que tavez, você possa adotar uma estratégia mais ousada e menos engessada.
A migração de EJB 2 para EJB 3 se dará no seguinte ambiente:
- Websphere Application Server v.7.0
- IDE IBM Rational® Application Developer™ for WebSphere® Software 7.5.5.1
Migração, compatibilidade e interoperabilidade entre EJB 2 e EJB 3
Existem diversas estratégias adotadas pelos fabricantes, especificando como garantir a migração entre EJB 2 e EJB 3. A JSR 220 em EJB 3.0 Simplified API capítulo 9 assegura-nos que:
“Existing EJB 2.1 and earlier applications must be supported to run unchanged in EJB 3.0 containers. All EJB 3.0 implementations must support EJB 1.1, EJB 2.0, and EJB 2.1 deployment descriptors for
applications written to earlier versions of the Enterprise JavaBeans specification.”
Figura 1
A compatibilidade e interoperabilidade devem ser preservadas, deve ser um objetivo a ser alcançado no projeto de migração de tais tecnologias, por isso, uma prova de conceito se faz necessária, pois a técnica para dar suporte para versões anteriores pode mudar de fabricante para fabricante.
Graças a compatibilidade preservada pela JSR 220, existem muitas possibilidade de utilizar EJB 2 e 3 juntos, você pode optar por migrar apenas alguns componentes da aplicação para EJB 3 e manter os outros na versão anterior como parte de uma estratégia de migração incremental, ou talvez uma aplicação desenvolvida em EJB 3 necessite utilizar um componente EJB 2, ou simplesmente migrar a camada de pesistência CMP 2 para EJB 3, ou mover apenas a camada de lógica de negócio para EJB 3 e m
anter a camada de pesistência construída com CMP 2 inalterada. Dentre essas possibilidades existem outras não descritas.
Em nosso passo a passo utilizaremos as recomendações descritas no site da IBM no que diz respeito ao ambiente, e duas estratégias de migração. Optaremos por uma migração incremental e movendo para EJB 3 inicialmente, apenas a camada de lógica de negócio de nossa aplicação mantendo a camada de persistência CMP 2.
Empacotando EJB 2 e EJB 3 juntos
Se você utiliza o ambiente IBM descrito anteriormente, então sabe que não possui um ambiente de desenvolvimento green-field por causa dos códigos proprietários do RAD que são aplicados nos projetos EJB para facilitar o desenvolvimento, portanto para adotarmos a estratégia de migração descrita anteriormente, será necessário criar um archive exclusivo para EJB 3, ou seja, teremos que criar uma projeto EJB 3 para empacotá-lo com o projeto EJB 2. Na Figura 1, temos a imagem de três Projects sendo, o diarioEletronico nosso Enterprise Project J2EE 1.4, diarioEletronicoEJB pertencente a tecnologia EJB 2 e o nosso projeto web diarioEletronicoWeb.
No caso em questão não discutiremos detalhes de implementação, pois o nosso foco está sobre o processo de migração de versões EJB.Como próximo passo agora criaremos um projeto EJB 3, com algumas restrições. Clique em File > New > EJB Project para ter a tela exibida na Figura 2.
Figura 2
Aqui, daremos o nome ao projeto de diarioEletronicoEJB3, nossa versão de Target Runtime é Websphere Application Server v.7.0 e EJB Module version é 3.0.
Nesse momento nós não nos preocuparemos em associar um EAR ao diarioEletronicoEJB3 nosso projeto como demonstrado na área vermelha, até porque, se procuramos o diarioEletronico não o encontraremos, pois o mesmo é um projeto J2EE 1.4 e não dará suporte para um projeto EJB 3.Clique em Next e a tela exibida na Figura 3 aparecerá.
Figura 3
Como não iremos criar um client apenas clique em finish. Depois de clicar em finish o projeto diarioEletronicoEJB3 aparecerá no package explorer do RAD como na Figura 4.
Figura 4
Percebam que agora nós temos 2 projetos EJB um da versão 2 e outro da versão 3, como o último foi criado sem ser associado ao EAR diarioEletronico, precisaremos fazer essa vinculação. O primeiro passo para realizarmos essa vinculação é mudarmos a versão de suporte do projeto diarioEletronico de J2EE 1.4 para JEE 5 para que ele possa suportar o projeto diarioEletronicoEJB3. Clique com o botão direito do mouse em cima do projeto diarioEletronico e entre em properties, como na FIgura 5.
Figura 5
Mude a versão 1.4 para 5.0 e clique em Ok. Agora o nosso próximo passo é associar o nosso projeto diarioEletronicoEJB3 ao Enterprise Project diarioEletronico. Abrindo o projeto diarioEletronico abra o arquivo application.xml como deployment descriptor, clique em add e adicione o projeto diarioEletronicoEJB3 como um módulo do projeto diarioEletronico.
Figura 6
e voilà…
Figura 7
Obs: Se por acaso o projeto estiver como Projetct Utility JARs remova-o de tal condição e logo em seguida adicione-o como módulo.
Agora temos um projeto diarioEletronicoEJB3 inserido como módulo ao nosso Enterprise Project.
A questão do empacotamento está concluída. Passaremos para a próxima etapa que são os invokes de EJB 3 para EJB 2. É preciso ficar claro que você pode misturar EJB 2 e versões anteriores com EJB 3 na mesma aplicação, porém, você precisará separar os beans do EJB 2 e suas versões anteriores dos beans do EJB 3 para que eles não fiquem no mesmo módulo. Os beans EJB3 não são reconhecidos em módulos que possuem EJB 2 ou suas versões anteriores.
(Continua…)
Depois de algumas reuniões e conversas com colegas e alguns alunos, percebi que nem todos os profissionais conhecem bem o real funcionamento do Two Phase Commit (2PC), percebendo isso, resolvi escrever esse post, tentando, como sempre, fazer associações de seu funcionamento a coisas do cotidiano. Eu e meu pequeno mundo de Bob, dessa vez tentamos a Fórmula 1.
Two phase commit 2PC é um protocolo atomic commitment, traduzindo para o português, com compromisso atômico, para processamento de transações, banco de dados e redes de computadores. Fazendo uso de um algorítimo distribuído, adota a estratégia de coordenar todos os processos envolvidos em uma transação atômica distribuída seja
Lollipopman - Responsável por sinalizar para o piloto.
para comitar ou abortar uma transação.
Como fã moderado da fórmula 1 e para explicar o seu funcionamento resolvi utilizar a etapa do pit stop, um dos momentos mais tensos e excitantes das corridas de fórmula 1 para explicar seu funcionamento. Ao lado, temos o lollipopman, que no nosso exemplo de funcionamento 2PC será o coordinator, como o 2PC é baseado nas fases commit-request, é preciso de um coordinator (Lollipopman) para coordenar todos os processos envolvidos na transação.
Os processos ( também conhecidos como participants, cohorts, or workers) no 2PC, serão representados pelos membros da equipe. A função de cada um deles durante o pit stop é executar o seu trabalho como trocar os pneus, reabastecer, limpar os dutos de passagem de ar, limpar o visor do capacete do piloto, etc.
Membros da equipe
O coordinator decide se libera o piloto ou não baseado num sistema de voting (Sim “commit” ou Não “abort”), sendo assim, a medida que cada worker realiza a sua tarefa, o mesmo sinaliza positivamente ou negativamente para o coordinator. Se todos sinalizam positivamente, o coordinator então realiza o commit (libera o piloto) ou caso haja apenas um único sinal negativo ele realiza o abort (não libera o piloto).
A grande desvantagem do 2PC é que ele é um protocolo de bloqueio, isso quer dizer que as operações mesmo depois de excutadas manterão o seu bloqueio até que recebam a ordem do coordinator para commit ou abort. Enquanto isso outras operações tem que esperar a liberação do lock para poderem executar. Em outras palavras, isso pode impactar diretamente no desempenho das transações, porém, é o mais adequado protocolo de para processamento de transações para as complicações que aparecem com o uso de gerência de recursos distribuído como por exemplo, ambientes que tenham mais de um banco de dados participando de uma transação.
Muitos vendors já possuem essa solução disponível em seus produtos como opção, e como citado anteriormente, é uma solução que tem o ônus do desempenho, por isso, se faz necessária uma avaliação minuciosa pelo arquiteto do projeto com o intuito de mitigar todos os riscos que envolvem a adoção dessa solução para seus projetos.
Uma análise mal feita sobre a utilização desse recurso pode ser comparada aos acidentes que acontecem durante um pit-stop na fórmula 1, mecânicos sendo atropelados, carros arrancando com a mangueira de combustível pendurada, pegando fogo, etc.
No Aurélio, o adjetivo “Nativo” é definido como algo que é natural, congênito, graça nativa, que nasce, procede, procedente. É inegável que os nativos sempre conheceram suas terras como a própia palma da mão, e desde o início das colonizações, os nativos sempre foram usados pelos colonizadores como dismistificadores nas terras nunca antes exploradas e também como possíveis comunicadores por meio de seus dialetos.
Indígenas Australianos (Aborigenes) - Os Aborigenes na época da colonização britânica eram obrigados a transmitir suas técnicas primitivas de caça (Boomerang) e sobrevivência em terras Australianas de ambiente hostil e que atingiam até 50 graus, além de se comunicarem com os demais através de seus dialetos sob ordens britânicas.
No avanço do desenvolvimento de software com JPA essa conotação é válida no mesmo sentido. A cada dia vemos uma evolução constante dos recursos que o JPA oferece, e apesar dos recursos interessantíssimos de mapeamentos e consultas de objetos-relacionais, o JPA não abre mão do bom e velho SQL nativo e faz uso de suas pirotecnias tecnológicas para se comunicar com os bancos de dados relacionais que já se tornaram praticamente um padrão na maioria das organizações. A comunicação utilizando SQL nativo com o uso do JPA pode ser feita com o uso da anotação @NamedNativeQuery . Em uma aplicação que utiliza JPA é possível executar consultas dinamicamente com SQL nativo ou você pode pré-definir as mesmas e executá-las pelo nome em run-time. (e.g)
O uso do recurso @SqlResultSetMapping serve para obter os dados como objetos derivados da query.
@Entity
@SqlResultSetMapping(name="StudentsFormated",
columns={
@ColumnResult(name="ID_STUDENT"),
@ColumnResult(name="BIRTH_STUDENT"),
@ColumnResult(name="NAME_STUDENT"),
}
)
Na mesma classe, temos uma consulta implementando @NamedNativeQuery e nomeando-a como findAllStudents, repare que ao final da consulta,existe a nomeação da resultSelMapping apontando para a StudentsFormated como definido anteriormente.
@NamedNativeQuery(
name="findAllStudents",
query="SELECT ID_STUDENT, BIRTH_STUDENT, NAME_STUDENT FROM STUDENT",
resultSetMapping= "StudentsFormated"
)
public class Students implements Serializable {
...
}
para executá-la, basta buscá-la pelo nome
...
Query queryStudents = em.createNamedQuery("findAllStudents");
Collection students = queryStudents.getResultList();
...
o resultado obtido dentro da Collection students seria como descrito a seguir:
...
{[1, 16/11, "Paul"], [2, 01/06, "Ringo"], ...}
...
e finalmente, poderíamos iterar sobre a lista de forma bem simples:
...
for(Iterator it = students.iterator();it.hasNext();){
Object [] object = (Object []) it.next();
System.out.println(object[0].toString(), object[1].toString(),object[2].toString());
}
....
Bem simples e útil, esse é um recurso que como descrito na analogia utilizada para este post, dismistifica e se comunica com os bancos de dados relacionais sob a forte pressão do “colonizador” JPA.
Para mais informações sobre esse recurso acesse aqui.
