Revista MundoJ Edição 51 by Adoro Design

_índice

NÚMERO 51 | ANO IX | JANEIRO & FEVEREIRO DE 2012 www.mundoj.com.br

06 NoSQL: Conceitos e Evolução

Conheça o conceito de NoSQL, as motivações que levaram a sua criação e seu atual estado da arte para tirar suas conclusões sobre se vale ou não a pena investir nesse modelo de banco de dados Por José Yoshiriro Ajisaka Ramos e Adriana de Farias Nascimento

10 Java e MongoDBs

Aprenda como acessar o MongoDB, um banco de dados NoSQL, através de uma aplicação Java Por Marcio Garcia “Mangar”

18 Neo4j na Prática

Utilize o Neo4J para simplificar a solução de problemas não triviais em bancos de dados relacionais e como uma boa alternativa à tradicional modelagem relacional Por Adriano Almeida

artigos > 34

Framework FACTO para Arquitetura Corporativa Conheça os princípios para

a criação de uma arquitetura corporativa através do framework FACTO e os passos adotados durante a sua implantação Por Jaguaraci Silva

Programação Multithread de Maneira Fácil com Scala + Akka Como criar

procedimentos e funções em banco de dados Oracle utilizando Java Por Gilberto T. Garcia Jr.

Reconhecimento de Som em Java ME

Trabalhe com reconhecimento de Som em Java ME através do Framework SRM Por Marcelo Ruaro

Utilizando Código Java em Banco de Dados Oracle Como criar procedimentos e funções em banco de dados Oracle utilizando Java Por Edgard Resende Bilharinho

colunas > 26 Cinto de Utilidades – Máquinas de Estado com o Padrão de Projeto State Veja como implementar máquinas

de estado de forma prática e direta, observando uma opção de implementação do padrão State em Java usando Enums e a Java Persistence API Por Alexandre Gazola

32 Tópicos Mais Quentes do GUJ.com. br. Veja o que apareceu, foi notícia e

gerou discussão no fórum do GUJ durante novembro e dezembro de 2011 Por Paulo Silveira

65 Tendências em Foco – Open Source: Ontem, Hoje e Amanhã Entenda a

evolução e o estado atual do Open Source, projetando uma a perspectiva para o futuro Por Cezar Taurion

nosql_

NoSQL CONCEITOS E EVOLUçãO

Conheça o conceito de NoSQL, as motivações que levaram a sua criação e seu atual estado da arte para tirar suas conclusões sobre se vale ou não a pena investir nesse modelo de banco de dados.

ste artigo fará uma abordagem geral sobre o estado da arte do NoSQL (Not Only SQL), um modelo de banco de dados que traz conceitos que ajudam a resolver alguns dos problemas que o relacional parece falhar em resolver. O objetivo é ajudar o leitor a perceber a importância desse modelo de banco de dados, cada vez mais presente em diversos tipos de soluções. Não é um tutorial de configuração/uso de algum SGBD NoSQL e sim uma apresentação desse emergente modelo por meio dos seguintes tópicos: o conceito de NoSQL; diferenças em relação ao modelo relacional; exemplos de uso e principais SGBDs NoSQL. Finalmente, são feitas as considerações finais e recomendações bibliográficas sobre o tema do artigo.

O que é NoSQL

O objetivo deste artigo é tratar do NoSQL enquanto modelo de bancos de dados, porém existe um SGBD com o mesmo nome. Assim, segue uma sucinta descrição da origem de ambos para facilitar o entendimento da diferença entre eles.

NoSQL, o programa, o SGBD

Lançado em 1998 por Carlo Strozzi como um SGBD Relacional. No site oficial de Strozzi [3] há um artigo no que chama seu programa de “NoSQL: a non-SQL RDBMS” afirmando que “NoSQL is a fast, portable, relational database management system without arbitrary limits...”. Este produto é, basicamente, um SGBD que possui como principal diferencial permitir o uso de outra linguagem ao invés da SQL. Este artigo não irá tratar desse programa e sim do modelo descrito nas próximas seções.

NoSQL, o modelo de banco de dados

Começou a ser divulgado com esse nome pelo

“Movimento NoSQL”, o qual propõe algumas mudanças para maior flexibilidade e escalabilidade de bancos de dados, dentre as quais está um novo modelo de banco de dados, cujas carasterísticas vão ao encontro a muitas do Modelo Relacional, por isso qualificado como Não Relacional. É o modelo “NoSQL” (de “Not Only SQL”).

Diferenças em relação ao Modelo Relacional

O Modelo de Banco de Dados Relacional provalemente é aquele com o qual o leitor deve ter tido mais “contato” (afinal é esse modelo que é ensinado nas faculdades, cobrado em concursos públicos e largamente usado no mercado). MySQL, Oracle Database, PostgreSQL, SQL Server e DB2 são provavelmente

Origem do nome “NoSQL” Em 2009, o termo “NoSQL” foi retomado por Erick Evans durante a organização de um evento sobre bancos de dados distribuídos de código aberto (que acabou sendo chamado de “NOSQL meetup”)[1]. Desde então, “NoSQL” passou a ser a palavra usada para descrever o novo modelo de banco de dados descrito neste artigo. BigTable, da Google, Dynamo da Amazon e outros SGBDs que já seguiam ideias do NoSQL antes de 2009, portanto, as ideias propostas por esse novo modelo vinham sendo aplicadas antes de ele ser “batizado”. Outrossim, características desse modelo são encontradas no conceitos NF², N1NF (non first normal form), nested relational, dimensional, multivalue, free-form, schemaless, document database e no modelo relacional não normalizado (MRNN).

Escalabilidade Vertical x Horizontal Faz-se uma Escalabilidade Vertical (scale up) quando aumentam-se recursos de memória, processamento e armazenamento em um ou mais computadores. Ex.: um SGBD funciona em um Cluster de três servidores. Com o aumento de dados e/ou acessos, aumentou-se a memória e o espaço em disco além de se trocar os processadores por mais rápidos em 1 ou mais nós. Faz-se uma Escalabilidade Horizontal (scale out) quando se aumenta o número de CPUs. Ex.: um SGBD funciona em um Cluster de três servidores. Com o aumento de dados e/ou acessos, foram adicionados mais três servidores ao Cluster, não necessariamente com o mesmo perfil de hardware dos anteriores. cas e é recomendada para uma solução específica. Na seção “Principais SGBDs NoSQL”, na tabela 2 há uma listagem das implementações de armazenamento por SGBD NoSQL. A diferença que costuma mais chamar atenção (a até “chocar” os mais ortodoxos) é quanto à Redundância de dados. Quanto mais “doutrinado” no modelo Relacional alguém estiver, mais ele vai achar estranho a abordagem NoSQL para essa questão. De fato, aqui está sendo abandonando simplesmente o que dá nome ao modelo relacional: os relacionamentos. Um bom exemplo para elucidar essa diferença entre os modelos seria explicar como uma modelagem Relacional (figura 1) ficaria em um banco NoSQL. Na figura 1 temos um exemplo que segue os preceitos de não-redundância e relacionamentos do modelo Relacional. O que o SQBG faria ao se... 1. Tentar inserir um registro em “matrícula”? »» Verificaria se o valor informado em “idaluno” existe em “aluno”. »» Verificaria se o valor informado em “idturma” existe em “turma”. »» Verificaria se não existe um registro na tabela com o mesmo par de valores “idaluno” e “idturma”. 2. Tentar excluir um registro em “turma”? »» Verificaria qual o tipo de comportamento da

chave estrangeira entre “matrícula” e “turma”. »» Registros de “matrícula” seriam preenchidos com “nulo”, excluídos ou ainda a exclusão em “turma” pode ser “barrada”, de acordo com o comportamento configurado na chave entre “matrícula” e “turma”. Ao mesmo tempo em que os relcionamentos são ótimos para garantir a consistência e evitar redundâncias, acabam por serem responsáveis pela queda de performance quando há muitos dados, tabelas e relacionamentos envolvidos nas operações de acesso a dados. No exemplo “aluno x turma x matrícula” atente para a quantidade de passos necessários para cada operação solicitada e o custo computacional de tantas consultas e atualizações feitas por causa dos relacionamentos. Para poder aumentar a performance do sistema na abordagem do modelo Relacional, faz-se preciso uma Escalabilidade Vertical. Na abordagem NoSQL, precisa-se de Escalabilidade Horizontal que, muitas vezes, é mais barata e fácil de fazer. Além disso, uma solução que precisa de Escalabilidade Horizontal é a mais indicada para soluções distribuídas, por isso que o NoSQL é considerado mais viável para bancos de dados distribuídos. As características do NoSQL que o diferenciam do Relacional visam a criação de sistemas com maior escalabilidade, mesmo que sacrificando a consistência. O exemplo anterior poderia ser refeito em NoSQL criando-se apenas uma entidade: “aluno” que teria os campos equivalentes aos campos de “aluno” e “turma” de uma só vez. Um exemplo de “aluno” no MongoDB (um SGBD NoSQL) ficaria como na Listagem 1. Cada operação solicitada envolveria apenas uma entidade, consequentemente menos operações seriam feitas “por baixo” pelo SGBD, ou seja, menor custo computacional. Há ainda a questão da maior flexibilidade na estrutura dos dados. Enquanto no modelo Relacional a criação ou exclusão ou alteração das propriedades de um campo em uma tabela influencia todos os registros (afinal um registro deve estar presente e ter a mesma estrutura em todos os registros de uma mesma tabela), no NoSQL pode-se alterar a estrutura dos registros individualmente. Ainda como referência o exemplo anterior: no modelo relacional, se criarmos o campo “obs” em “aluno”, todos os registros passariam a ter esse campo, mesmo que apenas 10 em 10 mil realmente venham a tê-lo preenchido. Em NoSQL, poderíamos criar esse campo apenas nos registros que desejarmos.

Exemplos de uso do NoSQL Figura 1. Exemplo de modelagem Relacional entre três tabelas. /8

Ainda nesta edição da MundoJ há artigos específicos sobre implementações de NoSQL e uso de comandos específicos, portanto serão apresentados

mongodb_

Java e MongoDB O desenvolvimento de uma aplicação onde seja requerido o armazenamento de grandes volumes de dados pode ser bastante custoso não só para o tempo de desenvolvimento, mas principalmente para a manutenção do sistema e também para a infraestrutura. Neste artigo, é mostrado como utilizar o MongoDB, um banco de dados NoSQL com Java utilizando o Morphia nesta comunicação.

á muito tempo se utilizava arquivos sequenciais para armazenamento de dados (os famosos arquivos .dat), depois veio a migração para banco de dados relacional. Desde esta última evolução, nunca houve questionamento em relação ao modelo de banco de dados a ser utilizado, o questionamento, quando havia, era sobre a compra de licença ou do expertise das equipes da empresa em trabalhar com um ou outro banco de dados. Após problemas de escalabilidade, custo e performance, muitas empresas começaram a pesquisar e a investir em novos mecanismos de armazenamento. Entre elas: Facebook com o Cassandra, Google com o BigTable e Linkedin com o Voldemort. Tais bancos de dados são considerados NoSQL, onde não existe obrigatoriedade quanto ao modelo de dados, estruturas fixas de tabelas e schemas. Estas também não suportam joins entre as “tabelas”. É um erro, no entanto, considerar que basta escolher um banco de dados NoSQL que esteja na moda e este resolverá todos os seus problemas quanto a escalabilidade. Existem alguns modelos de bancos de dados e cada qual focado em resolver um ou mais problemas, vide quadro “Tipos de bancos de dados NoSQL”. O objetivo deste artigo é mostrar ao leitor como

/ 10

trabalhar na prática com Java e MongoDB, que é um banco de dados NoSQL orientado a documentos e um dos mais genéricos dos bancos de dados NoSQL. Utilizar um banco de dados relacional em um sistema que terá um grande volume de acessos até há alguns anos poderia ser a única solução, incluindo neste cenário muito dinheiro com licenças de softwares, arquiteturas complexas e times de especialistas a preço de ouro. A partir de meados da década de 90, começaram mais fortemente as pesquisas sobre formas alternativas de armazenamento de dados que não tivessem como base os bancos de dados relacionais. Entre essas soluções, pode-se citar: banco de dados orientado a documentos, banco de dados orientados a objetos, banco de dados chave/valor e tabular. Tais soluções começaram a ser utilizadas de forma comercial focadas na solução de alguns problemas bem específicos, como, por exemplo, armazenar dados em cache, ou seja, em vez de buscar dados do banco de dados ou mesmo de arquivos em disco, no caso de arquivos estáticos, poderia se “lançar mão” da utilização de um banco de dados chave/ valor em memória com persistência em disco para acelerar a entrega deste conteúdo. Um banco de dados que desempenha muito bem este papel é o Redis.

Listagem 17. AppLimitOffset.java – Utilização de Limite e Offset. public void all() { System.out.println(“\n----------- all() ----------- “);

}

> MongoDB – http://www.mongodb.org/ > Morphia – http://code.google.com/p/morphia/

Query<Cidade> q = super.ds.createQuery(Cidade.class); for (Cidade c: q.fetch()) { System.out.println(c); }

public void limit(int no) { System.out.println(“\n------ limit(“ + no + “) ------- “); Query<Cidade> q = super.ds.createQuery(Cidade.class). limit(no); for (Cidade c: q.fetch()) { System.out.println(c); } } public void offset(int no) { System.out.println(“\n----- offset(“ + no + “) -------- “); Query<Cidade> q = super.ds.createQuery(Cidade.class). offset(no); for (Cidade c: q.fetch()) { System.out.println(c); } } public void offsetLimit(int noO, int noL) { System.out.println(“\n------ offsetLimit(“ + noO + “,” + noL + “) ----------- “);

}

/referências

Query<Cidade> q = super.ds.createQuery(Cidade.class). offset(noO).limit(noL); for (Cidade c: q.fetch()) { System.out.println(c); }

Considerações finais

A utilização de um banco de dados orientado NoSQL depende, e muito, das características de cada aplicação e suas necessidades e limites técnicos e não-técnicos. O Morphia é uma alternativa muito produtiva em comparação com o driver nativo Java para o MongoDB. Sua curva de aprendizado para quem está acostumado a trabalhar com JPA é bastante reduzida. A parte mais difícil é se adaptar ao mecanismo orientado a documentos do MongoDB, que acredito ser muito gratificante, principalmente quanto ao tempo de desenvolvimento e manutenção da aplicação, após se adquirir fluência na maneira como os documentos podem ser manipulados.

Tipos de bancos de dados NoSQL Existe alguns tipos de bancos de dados NoSQL, cada um destinado a solucionar um problema específico. Os bancos de dados orientados a documentos estão tomando cada vez mais força no âmbito comercial. Entre suas principais características, está a escalabilidade vertical de fácil manutenção e instalação. Para startups e sites de grandes volumes de manipulação de dados, a utilização de bancos de dados NoSQL orientado a documentos podem ser a solução mais adequada. Os principais modelos de bancos de dados NoSQL são: Orientado a documento: MongoDB, CouchDB, MarLkogic Server, BaseX, sXist Orientado a objetos: Db4o Chave/valor: MemcachedDB, Project Voldemort, Rdis, SimpleDB, Hbase Tabular: Cassandra, Hypertable Gráfico: Neo4j, DEX

MongoDB e ACID – Atomicidade, Consistência, Isolamento e Durabilidade No desenvolvimento do MongoDB foram priorizadas algumas funcionalidades (Flexibilidade, Facilidade e Velocidade) em detrimento de outras (Transações). O MongoDB não suporta transações ACID. Pelo menos não de forma nativa entre coleções, como os bancos de dados relacionais suportam entre tabelas. O MongoDB oferece suporte a ACID nativamente quando as alterações são entre documentos aninhados, mas não entre coleções. Para os casos em que são necessárias controle de transações entre coleções, é possível, através de uma camada intermediária entre a aplicação e o banco de dados.

17 \

neo4j_

Neo4j na prática Como entrar no mundo dos bancos de dados de grafo O mundo dos bancos de dados não-relacionais (NoSQL) cada vez mais tem ganhado reconhecimento do mercado, inclusive com grandes empresas adotando alguma das soluções disponíveis ou patrocinando o desenvolvimento das já existentes. Nesse cenário, ganhando grande atenção no mercado internacional e baseado em uma das mais antigas teorias matemáticas, o banco de dados Neo4j, implementado em Java, traz os grafos ao cenário da persistência de dados, de uma maneira que pode simplificar a solução de problemas não-triviais em bancos de dados relacionais ou até mesmo como uma boa alternativa à tradicional modelagem relacional.

adoção de um banco de dados não-relacional geralmente passa por alguns fatores bastante comuns, como necessidade de alta escalabilidade e disponibilidade, flexibilidade de schema e ganhos de performance. O banco de dados Neo4j pode prover todos esses recursos às aplicações, aliando a elas um modelo rico de dados, baseado em grafos, permitindo a criação de modelos de dados extremamente complexos e, ainda assim, mantendo uma considerável facilidade em pesquisar dados e adicionando a tudo isso características que tornaram os bancos de dados relacionais ferramentas tão reconhecidas no mercado, como transações ACID e uma linguagem simples para realizar pesquisa de dados. Neste artigo o leitor aprenderá como modelar suas aplicações dentro desse novo paradigma que é a modelagem via grafos, e será introduzido aos / 18

conceitos desse novo paradigma através de uma adaptação do modelo de dados de um e-commerce. Também será mostrado como utilizar a API do Neo4j para persistir e pesquisar as informações no banco de dados, utilizando desde a API Java até a poderosa linguagem de pesquisas Cypher.

A modelagem através de grafos

Muitos desenvolvedores estão acostumados com o processo de modelagem relacional, onde definimos quais tabelas e colunas farão parte do nosso modelo de dados. Definimos também as tabelas envolvidas e seus respectivos relacionamentos pensando em suas cardinalidades, por exemplo. A modelagem nos consegue mostrar como as informações são interligadas em nosso modelo de negócio e como os dados estão relacionados entre si.

Adriano Almeida | adriano.almeida@caelum.com.br Trabalha como instrutor, consultor e desenvolvedor pela Caelum e é formado em Sistemas de Informação pela FIAP. Desenvolve aplicações em Java desde 2005 e contribui com alguns projetos open sources, inclusive o banco de dados Neo4j

Para podermos nos aprofundar nas características dos grafos e também na construção de uma solução que envolverá o uso do banco de dados Neo4j, utilizaremos um domínio de um e-commerce, onde clientes poderão realizar compras de produtos categorizados por tipos, poderão indicar que outros clientes são seus amigos e também quais produtos eles possuem interesse em comprar no futuro, podendo indicar o nível desses interesses em uma escala de 1 a 5 (pouco interesse

ív

fifa 12

o contend

realizou compra

adriano

é um

jogo

e er

é um

call of duty se

até muito interesse). Um exemplo de um grafo possível pode ser visto na imagem 1. Em nosso caso, indicamos que uma pessoa possui interesse em alguns produtos. Os produtos, por sua vez, possuem uma relação com sua categoria. A partir do momento em que o cliente realiza uma compra, também passa a existir um relacionamento entre o cliente e a compra, que pode possuir vários produtos associados a ela. Os clientes podem possuir amizade com outros clientes. No grafo, alguns pontos são importantes de serem notados. Os nós são representados pelos círculos e podem possuir propriedades. Enquanto os relacionamentos são representados pelas setas, que são sempre direcionadas, ou seja, possui um nó de saída e um nó de chegada, como, por exemplo, o cliente que possui um relacionamento “INTERESSE” com um produto. Os relacionamentos podem possuir propriedades também, como, por exemplo, o nível de interesse, que mediremos em um ranking de 1 a 5 estrelas. É importantíssimo verificar também que em nenhum momento definimos chaves estrangeiras em nosso modelo. Essa é uma característica vital na modelagem através de grafos, onde os dados se relacionam de forma natural, ou seja, através de seu papel no domínio, sem a necessidade da criação de uma estrutura específica para tal.

data

12.02.2010

contendo

playstation 3

éu

am de ricardo

realizou compra

data

14.07.2010

contendo

xbox 360

é um

video game

Imagem 1. Grafo demonstrando diversos relacionamentos entre diferentes tipos de informações.

19 \

padrão state_

cinto de utilidades

Máquinas de estado com o

Padrão de Projeto State D

esenvolver software é trabalhar com abstrações o tempo todo, pois estas nos ajudam a gerenciar a complexidade nos sistemas que desenvolvemos. Uma das abstrações mais poderosas que podemos empregar são as máquinas de estado. Com elas, é possível modelar diversas coisas, desde simples workflows até complexos autômatos para uso em compiladores e aplicações de inteligência artificial. O modelo de máquina de estados é extremamente interessante por ser de fácil construção, sucinto e altamente comunicativo, facilitando bastante a comunicação com os usuários do sistema e especialistas de domínio. No entanto, o que acontece é que muitos utilizam a modelagem de máquinas de estados apenas em nível conceitual, perdendo-o de vista no momento da implementação. Muitos até fazem a modelagem em máquina de estados de uma maneira mais formal usando algo como UML1, mas apenas para propósitos de documentação de requisitos e comunicação. No momento da codificação, a máquina de estados é convertida em diversos ifs, que se espalham por variadas partes do sistema, aumentando as lacunas sintática e semântica entre o modelo de domínio “discutido pelas pessoas” e o modelo de domínio “codificado”. Perde-se a oportunidade de representar um conceito da linguagem do domínio explicitamente em código, como advogado pelo Domain-driven Design2. Mas não precisa ser assim!

1. Máquinas de estados são um recurso de modelagem também previsto num dos diagramas da Unified Modeling Language (UML). 2. Para mais detalhes sobre Domain-driven Design, recomendo fortemente / 26

Neste artigo, mostraremos como implementar máquinas de estado por meio do padrão de projeto State. Primeiramente, faremos um resumo do padrão e, em seguida, ilustraremos seu uso por meio de um exemplo prático associado com o uso da Java Persistence API. Ressaltamos que este artigo assume que o leitor já possui um conhecimento básico do funcionamento de Enums e de JPA/Hibernate (para os que desejam mais informações, ver seção de referências).

O padrão State

O padrão State é um dos 23 padrões de projeto da Gang of Four (GoF), já velho conhecido da comunidade (o livro foi publicado em 1994). Apesar de alguns desses padrões hoje serem até meio controversos (como é o padrão Singleton, por exemplo), o padrão State (juntamente com seu irmão gêmeo Strategy) continua sendo de elevada aplicabilidade nos sistemas desenvolvidos atualmente. A ideia do State é representar os estados de uma máquina de estados por meio de classes que implementam uma interface comum, a qual contém as regras de transição. Cada classe implementa, então, a ação devida quando a transição é acionada por essa interface. O outro elemento do padrão é o chamado “contexto”, que é a classe da qual o estado faz parte e também é a classe com a qual o restante do sistema interage. Quando uma regra de negócio é acionada no contexto e este verifica que é necessária a realiza-

a leitura do livro homônimo de Eric Evans.

Alexandre Gazola | alexandregazola@gmail.com | @alexandregazola Bacharel em Ciência da Computação pela Universidade Federal de Viçosa (UFV) e mestre em Informática pela PUC-Rio. Trabalha como Analista de Sistemas no BNDES, desenvolve em Java desde 2003 e possui as certificações SCJP e SCWCD. É articulista e editor-técnico da revista MundoJ, além de manter um blog em http://alexandregazola.wordpress.com. Bacharel em Ciências da Computação pela Unesp, foi instrutor oficial da Sun Microsystems e da Oracle Education. Atualmente contribui para alguns projetos open source, como KDE e Mentawai, e é da equipe de arquitetura da CodeIT Solutions, uma empresa especializada na prestação de serviços de desenvolvimento de software para as indústrias de seguros.

Máquinas de estados são uma construção extremamente comum para se modelar requisitos de diversos sistemas. Normalmente, são fáceis de desenhar (em forma de modelos) e interessantes instrumentos para comunicação e validação com os usuários por serem de simples entendimento. No entanto, muitos desenvolvedores perdem a integridade dessa abstração no momento da codificação. Neste artigo, abordamos o padrão de projeto State, bastante útil para modelagem de máquinas de estado em código. Como sempre, damos uma ênfase mais prática e direta, mostrando uma opção de implementação do padrão em Java usando Enums e a Java Persistence API. ção de uma transição de estado, o contexto dispara então a transição no estado, o qual fica encarregado de realizar a ação correspondente e determinar o próximo estado. É importante que o contexto seja passado como parâmetro ao estado para que o estado possa decidir o estado seguinte, setando um objeto da classe adequada no contexto. A figura 1 exibe a estrutura geral do padrão State. Vamos à seção seguinte, na qual utilizaremos um exemplo concreto para o qual aplicaremos o padrão.

Aplicando o padrão State na prática

Como ilustração, imaginemos uma aplicação para controlar o workflow de submissão, aprovação e publicação de artigos para um periódico qualquer. Neste exemplo, estamos interessados em modelar os estados e transições de um artigo. Após discussão Context

State

+ Request ( )

+ Handle ( )

state.Handle

( )

com os usuários, chegamos ao diagrama de estados exibido na figura 2. O modelo apresentado é bastante autoexplicativo. Os estados são representados pelos retângulos e as transições por setas. Tudo começa quando um artigo é submetido pelo sistema. Quando isso acontece, ele vai para o estado “Recebido”. A partir desse estado, o sistema realiza algumas validações automáticas no artigo, como, por exemplo, ortografia, formatos etc. O sucesso ou não dessa validação automática determina se o artigo irá para o estado “Aceito para revisão” ou “Recusado”. No estado “Recusado”, o usuário pode fazer alterações à vontade e realizar uma nova submissão. Uma vez que um artigo esteja “Aceito para revisão”, um humano fará a leitura e revisão do artigo, determinando se o mesmo está satisfatório, se apresenta erros básicos ou se, simplesmente, foi recusado. Cada um desses eventos faz com que o artigo vá, respectivamente, para os estados “Aceito para publicação”, “Aceito com correções” e “Recusado”.

ConcreteState A

ConcreteState B

+ Handle ( )

Figura 1. Estrutura geral do padrão State.

Implementação tradicional do padrão

Agora, vamos ao que interessa: o código! A Listagem 1 apresenta a interface para os estados do nosso modelo, contendo as possíveis transições da máquina. Na Listagem 2 trazemos 27 \

guj.com.br

tópicos mais quentes do

guj.com.br e

sl i

s da

das a t n e com

tí no

ai m s cia

A nova versão do Android foi lançada, unindo as forças de tablets e smartphones. O Galaxy Nexus é o primeiro celular a vir com o sistema e será comercializado no Brasil.

O PrimeFaces, implementação JSF com componentes extras cada vez mais utilizados no mercado, traz muitas novidades para a versão 3.0. Qual será a resposta do RichFaces?

PrimeFaces 3.0 RC1 lançado http://www.guj.com.br/260574

Em movimentos já esperados, Adobe anuncia fim do desenvolvimento do Flash para mobile. Parte da motivação é pelas regras da Apple em relação a App Store. Será que JavaFX e Silverlight possuem destinos semelhantes?

Adobe está se afastando cada vez mais do flash.

Android 4.0 - Ice Cream Sandwich http://www.guj.com. br/255725

A Mozilla fez um surpreendente anúncio: em 2012 terá um concorrente para o iOS e o Android. Há chances de vingar?

Criadores do Firefox anunciam rival para o Android e o iOS

www.guj.com.br/ 257792 Sairam as primeiras releases candidates da nova versão do Netbeans. Como ele se compara com Netbeans 7.1 RC o Eclipse? Quais www.guj.com.br/ 260420 as novidades? Suporte para PHP, JavaFX2, CSS3, Git e mais.

www.guj.com.br/258795

ACOMPANHE O GUj twitter.com/guj_noticias facebook.com.br/guj.com.br

fórum exclusivo guj.com.br/mundoj Nesse fórum você pode conversar com os autores de cada edição da MundoJ, tirando dúvidas, colaborando, adicionando e criticando todos os artigos. 31 \

Paulo Silveira | paulo.silveira@caelum.com.br Um dos fundadores do GUJ.com.br, o maior fórum em língua portuguesa sobre a plataforma Java, nascido em 2002. É desenvolvedor e instrutor pela Caelum e editor-técnico da revista MundoJ.

Como converter de String para int sem usar a biblioteca Java www.guj.com.br/256513

Desenvolvedores Android, Salários e Mercado de Trabalho. http://www.guj.com.br/256156

Alguns problemas simples podem ajudar quem está aprendendo a conhecer a linguagem, além de praticar lógica com algoritmos.

Um tema que sempre volta. Vale a pena uma certificação? E O que eu ganho tirando especificamente a certificação OCJP? a OCJP? Há imwww.guj.com.br/258572 pacto no salário? Dinheiro e tempo investidos compensam? O mercado para desenvolvedores Android (assim como iOS) está em alta. Quais são os números, valores, caminhos e segredos?

ais lidos

mentados co

tóp i

sm o c

Alguns pontos do desenvolvimento swing fazem surgir dificuldades. Um certo conhecimento de programação concorrente é exigido, caso contrário você pode segurar a thread que renderiza os componentes ocupada, dando aquela conhecida sensação de congelamento da aplicação

Com a estagnação da api AWT/ Swing, uma aplicação desktop deve ser feita em Java? Quais são as promessas do JavaFX, e será que ele ganhará mercado?

É aconselhável usar java para desktop?

Thread Worker / Observer e JProgressBar www.guj.com.br/255258

Usar uma ferramenta Hibernate e JPA por que? de mapea- www.guj.com.br/255094 mento objeto relacional é prática comum. É obrigatório? Quais os casos não aconselháveis? E o JPA/Hibernate em especial?

www.guj.com.br/256850 33 \

arquitetura_

Arquitetura Corporativa

Apresentando o FACTO Framework de Arquitetura Tecnológica Corporativa. Uma arquitetura corporativa assegura o uso efetivo da TI alinhando as estratégias de negócio e TI, melhora a comunicação e a colaboração entre os interessados, além de possibilitar a todos múltiplas visões em diversos níveis de detalhes arquitetônicos. O artigo apresenta de forma objetiva os seus benefícios, principais componentes, os passos para a sua adoção, os frameworks mais conhecidos e uma forma de avaliá-los. E, no final, apresenta o framework FACTO e os passos adotados durante a sua implantação.

rquitetura Corporativa é uma visão integrada e holística da organização fundamental de um sistema, incorporados em seus elementos (pessoas, processos, aplicações e visões), suas relações entre si e ao meio ambiente são os princípios que orientam a sua concepção e evolução. Essa visão sistemática surgiu em 1980 e foi incorporada ao framework de John Zachman como uma forma de lidar com a complexidade das organizações, que cada vez mais precisam se adaptar a evolução das tendências de novos negócios e de TI. Tendências de negócios compreendem a globalização, fusões e aquisições, e-commerce e de relacionamento com clientes e da cadeia de suprimentos de gestão. Tendências de TI compreendem avanços em tecnologias da Internet, plataformas de hardware e servidores de aplicação, além da automação do fluxo de trabalho ou processo de negócio. Com a crescente importância da arquitetura corporativa, as empresas, como o Open Group e IBM, estão oferecendo oportunidades de certificação em um esforço para padronizar um método aberto de arquitetura de TI. A visão integrada proporcionada pela

/ 34

arquitetura corporativa facilita a implantação de projetos de TI melhora a comunicação, colaboração e o entendimento dos objetivos do negócio. Assegura também o uso efetivo da TI, alinhando as suas estratégias e as do negócio para alavancar uma vantagem competiva e baseia-se, principalmente, na satisfação dos clientes dos processos de negócio e no alcance de suas metas. Permite ainda a visualização de diversas perspectivas como forma de promover a organização e estruturação dos seus componentes diante dessas perspectivas, fornecendo informações a diferentes perfis de interessados com os detalhes arquitetônicos apropriados. Além disso, é a base para iniciar a Arquitetura Orientada a Serviços (SOA) e outras formas de integração entre os sistemas corporativos (sistemas legados e pacotes de software) em diferentes tipos de negócios. O artigo fornece uma visão clara e objetiva dos conceitos que envolvem uma arquitetura corporativa, quais os seus benefícios, visão de arquitetura de solução e especificação. Aduzi os principais componentes internos e os passos para realizar o alinhamento da estratégia da arquitetura corporativa com a estratégia da empresa. Introduz os principais frameworks e indica os melhores cenários para aproveitamento. O artigo também descreve o resultado de

O planejamento iniciou pelos passos apresentados para definição da arquitetura de especificação e solução, alinhando as áreas de processos de gestão da configuração e capacidade, integração de software, desenvolvimento e teste software junto às perspectivas básicas para definição das metas, insumos, produtos e ciclo de vida do software. As áreas de gestão modelo de processo de software, gerência de projetos e portfólio de aplicações foram adequadas às perspectivas de qualidade, visões e abstrações dos componentes de acordo com a organização definida na arquitetura de integração contínua, que também assegura a construção da arquitetura corporativa guiada por princípios e regras. Outras perspectivas também foram criadas para obstrução das barreiras culturais e melhorar a colaboração entre os interessados: utilização de uma linguagem fácil para mapeamento de processos de negócios, diminuição de padrões de documentos durante a fase de alinhamento das estratégias de negócio a TI e a apresentação de feedbacks em reuniões semanais para encorajar o uso de novas ideias e proporcionar um ambiente seguro para o desenvolvimento da equipe.

Considerações finais

Durante a adoção de um projeto de arquitetura corporativa é muito importante verificar o atendimento das diversas perspectivas já mencionadas na avaliação e principalmente ter um plano de requisitos básicos a serem atendidos. Uma boa prática é coletar os problemas de todos os perfis de interessados e a utilização de uma metodologia de Business Process Management (BPM). Deve-se mapear o conjunto de atividades a serem atendidas com base nos objetivos e prioridades dos processos de negócio. Além disso, é necessário verificar se o framework irá facilitar a aderência aos modelos de gestão da configuração e projetos que a empresa possui. O framework deve suportar bem a expansão dos sistemas corporativos em função dos processos mapeados nos termos de escala e complexidade e possuir boa capacidade para alavancar uma possível evolução diante das necessidades atuais de agilidade. Precisam assegurar o retorno à empresa quando direcionado para grandes ou mútiplos pequenos projetos. Também sobre isso, é importante saber se a integração de um grande número de pequenos sistemas pode ser endereçada corretamente aos frameworks baseados em métodos e/ou práticas ágeis (TOGAF, FACTO) por conta dos processos de gestão de projetos e/ou configuração da empresa. O modelo de gestão utilizando escritórios de projetos (PMO) reforçam e muito boas práticas de gerência de projetos a partir de uma perspectiva central e de integração das necessidades do negócio, o que facilita a adoção desse tipo de framework.

Conforme foi visto no artigo, não existe o melhor framework, existe o que adere melhor às perspectivas da empresa. Entretanto, a grande motivação para criação do FACTO foi apresentar ao mercado uma proposta sólida e factível a curto prazo para sanar os problemas de gestão da configuração e de projetos encontrados nos principais frameworks avaliados. Também possibilitar o uso da arquitetura corporativa como um meio de assegurar a integração dos modelos de governança de TI (ITIL, COBIT e CMMI) por fornecer uma visão holística e integrada de processos, sistemas, infraestrutura e pessoas. Por fim, proporcionar um baixo custo durante a sua adoação.

Este artigo é dedicado à memória de um grande amigo, uma pessoa querida por todos na Cia de Ferro Ligas da Bahia e que agora está na “stairway to heaven”. Márcio Gonzaga, sua alegria irá permanecer para sempre em nossa lembrança, descanse em paz meu irmão!.

/referências > Agnes Owuato Odongo, Sungwon Kang, In-Young Ko. “A Scheme for Systematically Selecting an Enterprise Architecture Framework”. 9th IEEE/ACIS International Conference on Computer and Information Science, 2010. > Matthias Lange and Jan Mendling. “Goals, Framework Adoption and Benefit Assessment”. 15th IEEE International Enterprise Distributed Object Computing Conference Workshops, 2011. > Richard V. McCarthy. “Toward a Unified Enterprise Architecture Framework: An Analytical Evaluation”,.Issues in Information Systems Volume VII, No2,2006. > Hyunkyung Song and Yeong-Tae Song. “Enterprise Architecture Institutionalization and Assessment”. 9th IEEE/ACIS International Conference on Computer and Information Science, 2010. > Hanifa Shah and Mohamed El Kourdi. “Frameworks for Enterprise Architecture”. IT PRO, 2007. > Sabine Buckl, Alexander M. Ernst, Florian Matthes, Ren´e Ramacher, Christian M. Schweda. “Using Enterprise Architecture Management Patterns to complement TOGAF”. IEEE International Enterprise Distributed Object Computing Conference, 2009. > aguaraci Silva. “FACTO – Framework de Arquitetura Tecnológica Corporativa”. http://www.slideshare.net/ jaguaraci/f-a-c-t-o-framework-de-governana-tecnolgicacorporativa, 2011. > Alistair Cockburn. “The Crystal Methods or How to Make a Methodology Fit”. http://Alistair.Cockburn.us, 2011.

43 \

scala akka_

Scala + Akka programação multithread de maneira fácil

Introdução ao akka, framework que torna a programação multithread simples e fácil.

Hoje em dia, visto que processadores ganham cada vez mais núcleos, é de extrema importância que, além de criar sistemas multithread eficientes para nos beneficiarmos de todo o poder dos processadores modernos e, desse modo, criar sistemas com maior capacidade de processamento, também criemos sistema de fácil manutenção e com o menor número possível de erros. Vamos mostrar como escrever um programa multithread de análise de dados de forma simples, porém robusta.

abemos que criar programas multithread não é uma tarefa simples. Pelo contrário, a complexidade de se fazer esse tipo de sistema é enorme e é capaz de tornar o dia-a-dia de desenvolvedores em uma batalha épica, tanto para conseguir pensar em como os threads interagem entre si e evitar memory leaks e deadlocks e outros problemas que possam aparecer, como para, quando necessário, debugar e corrigir problemas. Akka, segundo os seus criadores, é um framework para facilitar essa tarefa e assim diminuir o número de erros que surgem em consequência de implementações erradas, sejam elas devido à complexidade da tarefa ou por qualquer outro motivo. A grande força do framework vem do fato que, além de facilitar a programação multithread e permitir construir sistemas que escalem tanto horizontal como verticalmente. Pois podemos criar mais atores (ver caixa: Entendendo atores) dentro de um mesmo computador, utilizando dessa maneira toda capacidade do processador e de que podemos, caso seja necessário, criar um cluster de atores utilizando vários computadores (ver figura 1) como do fato de que podemos utilizá-lo dentro de vários cenários diferentes (ver caixa: Diferentes cenários para o uso do Akka) há também a possibilidade de ser utilizado em projetos Java (Ver caixa: Java + Akka). Neste artigo, irei mostrar com utilizar o framework para criar um sistema multithread em Scala, porém, não faz parte do escopo mostrar funcionalidades mais avançadas, como, por exemplo, a clusterização de atores. Para mais informações, o site do framework possui uma documentação completa e de fácil entendimento.

/ 44

Entendendo atores Para facilitar a compreensão do que são atores, podemos imaginá-los como threads, isto é, cada ator seria uma thread. Diferentemente do que, normalmente, fazemos em Java, os atores não compartilham estado entre si. Eles se comunicam, entre si, através de mensagens as quais, normalmente são classes case. Portanto, quando trabalhamos com atores, nós não utilizamos o modelo de estado compartilhado (shared-state), das linguagens imperativas tradicionais.

Implementando o sistema

Iremos construir um sistema que analisa notas dos alunos de uma escola e nos dá as seguintes informações: 1. Lista de alunos aprovados 2. Lista de alunos reprovados 3. Maior média 4. Menor média Esse exemplo servirá para mostrar como podemos otimizar a análise de dados, que é uma tarefa que consome muita memória, processamento e costuma ser demorada, criando um sistema paralelizado de maneira simples e fácil (ver caixa: Imagem não é tudo). A arquitetura do sistema consiste, basicamente, em um objeto Analisador, que será o responsável por criar os atores, passar as tarefas a serem executas para os mesmos e consolidar o resultado e, em vários atores que farão o trabalho duro (analisar os dados) (ver figura 2).

Gilberto T. Garcia Jr. | ggarcia@eureka.inf.br Formado em Filosofia pela USP, trabalha com Java e atualmente estuda linguagens funcionais. Há 12 anos no mercado de TI, já atuou em diversos segmentos do mercado, como telefonia, financeiro e seguros. Desde 2010 pesquisa linguagens funcionais para descobrir técnicas que gerem aumento de produtividade no desenvolvimento de sistemas, além de ser o criador do site Scalado (site voltado ao Scala e Lift).

Diferentes cenários para o uso do Akka Você pode utilizar o framework como se fosse uma biblioteca, caso esteja escrevendo uma aplicação para a Web ou, se quiser, sua aplicação web poderia invocar os atores como se fossem serviços externos à aplicação. Ou ainda, poderíamos utilizá-lo como um microkernel stand-alone. Java + Akka A utilização do framework em Java é quase igual a utilização em Scala. A diferença é que, ao utilizar em projetos Scala, devemos importar Actor, ActorFactory e LoadBalancer, enquanto em projetos Java, devemos importar UntypedActor, UntypedActorFactory e UntypedLoadBalancer. Para mais detalhes, ver referência no final do artigo.

ANALISADOR

resultado trabalho TRABALHADOR 2

trabalho resultado TRABALHADOR 1

Figura 2. Arquitetura do sistema.

Atores como roteadores Um trabalhador pode atuar como roteador e gerar mais trabalhadores, criando, assim, uma verdadeira cadeia de processamento (ver figura 3).

O trabalhador

A classe Trabalhador define as nossas regras de negócio. Será ela a responsável por analisar os dados e devolver o resultado para o analisador. Trabalhador estende do trait Actor do framework. O trait Actor define o método abstrato receive, o qual devemos implementar em nosso ator (ver Listagem 1 – ImImagem não é tudo plementação da classe trabalhador). Esse método é o O leitor que não se engane, o exemplo pode responsável por receber as mensagens do analisador, ser simples, mas o conceito é muito poderoso. O processá-las e devolver o resultado, ou seja, ele é o Google criou um framework chamado MapReduce ponto de entrada de mensagens para os atores. para suportar computação distribuída de enormes Durante a transmissão da mensagem, o framassas de dados. Esse framework é inspirado nas mework passa uma referência implícita do ator mesfunções map e reduce, comumente encontradas tre (chamada de self) para os trabalhadores, para que em linguagens funcionais. possam utilizá-lo para dar a resposta do processaBancos utilizam esse mesmo conceito para, mento ou repassá-lo para outros atores, caso exista por exemplo, fazer análise de riscos de seus uma cadeia de trabalhadores (ver caixa: Atores como clientes. roteadores). É por causa dessa referência implícita, que podemos chamar o método MULTITHREAD COM MULTITHREAD EM reply e assim passar o UM ÚNICO COMPUTADOR AMBIENTE CLUSTERIZADO resultado da análise COMPUTADOR 1 COMPUTADOR 1 COMPUTADOR 2 para o ator mestre ATOR 1 (analisador). O método analise MESTRE utiliza a classe helMESTRE ATOR 2 per Dados (ver caixa: Obtendo dados) para obter a lista de alunos ATOR 1 ATOR 2 ATOR 3 ATOR 1 ATOR 2 ATOR 3 ATOR 3 que deverá ser analisada (ver Listagem 1 – Implementação da classe trabalhador).

Figura 1. Possíveis arquiteturas.

45 \

som em java me_

Reconhecimento de Som

em Java ME

reconhecendo sons através do Framework srm

evolução da capacidade de processamento dos sistemas embarcados permite integrar técnicas que até então se limitavam aos ambientes de grande porte. O Reconhecimento de Som é uma destas técnicas que, combinada com a mobilidade dos dispositivos móveis, torna mais natural a interação com estes dispositivos. Atualmente, a maioria dos dispositivos móveis integra algum recurso de reconhecimento de som, porém o desenvolvimento de aplicações Java ME que aborda este recurso, ainda não é comum, pois há poucas ferramentas, e as disponíveis ou são proprietárias, ou não apresentam um nível de abstração para aplicações mais casuais. Sendo assim, o Framework SRM (Sound Recongizer ME) se encaixa neste contexto, oferecendo um reconhecimento, para palavras isoladas dependente de locutor e sons abstratos. Utilizando a API nativa MMAPI (Mobile Media API) para a captura do som, o RMS (Record Management System) para a persistência das informações úteis ao reconhecimento, juntamente com técnicas de extração de informação e reconhecimento de voz / 50

difundidas com sucesso pela literatura, o SRM é capaz de reconhecer de forma precisa e pouco onerosa os gêneros de sons envolvidos, chegado no melhor caso a 94% de acertos. Este artigo tem o objetivo de explicar como realizar a integração do Framework SRM em uma aplicação Java ME, tanto para o reconhecimento de som quanto o de voz, expondo inicialmente suas principais características juntamente com exemplos práticos e, ao final, uma aplicação completa capaz de realizar chamadas, através da pronúncia de dígitos e comandos de voz. O Framework SRM, juntamente com o código aberto e o artigo que o descreve, pode ser encontrado no Source Forge em: http://sourceforge.net/projects/ frameworksrm/.

Framework SRM

O SRM é um Framework escrito inteiramente na linguagem Java ME com o objetivo de disponibilizar o reconhecimento de som e o reconhecimento de voz. Mais especificamente, o reconhecimento de palavras isoladas dependentes de locutor (se encai-

O reconhecimento de som, aos poucos, se torna um recurso cada vez mais difundido nos dispositivos móveis, e com a evolução de processamento dos mesmos, este recurso vem agregando técnicas que possibilitam uma taxa de acertos considerável nestas plataformas. Atualmente, desenvolver desde o início uma ferramenta de reconhecimento de som para uma aplicação específica ou casual torna-se praticamente inviável, pois o desenvolvedor deverá desempenhar uma atenção especial para cada etapa do reconhecimento, demandando grande esforço de tempo, já ao procurar por APIs ou Frameworks, as raras soluções encontradas ou são privadas, ou não fornecem grandes facilidades no momento da integração. Sendo assim, o objetivo deste artigo é apresentar o Framework SRM, um software de código aberto, escrito em Java ME, que possibilita ao desenvolvedor integrar o reconhecimento de som em aplicações de uma forma rápida e abstraída.

Marcelo Ruaro | mceloruaro@gmail.com Formado em Ciência da Computação pela URI-Santo Ângelo, tem experiência de mais de 4 anos em Java ME, e atualmente trabalha na área de gerência de rádios de telecomunicações nas linguagens JavaEE e C embarcado.

xando no contexto de reconhecimento de voz), e o reconhecimento de sons abstratos, sendo definidos como qualquer som que não se encaixe na definição de palavra. Uma das suas características é oferecer o recurso de reconhecimento de som de uma maneira simples e abstraída para que sua integração em aplicações possa ser feita de forma rápida, não demandando muitos esforços de aprendizado em técnicas de reconhecimento de voz. Desta maneira, o SRM é dividido em pacotes, cujos objetivos são o de organizar as principais funcionalidades oferecidas. Os pacotes são denominados sound, back-end e front-end, e a composição destes está representada na figura 1. Resumidamente, o pacote sound é responsável pela aquisição, execução e manipulação de amostras que podem ser definidas como padrão. Já o pacote front-end é inteiramente dedicado ao processamento do sinal digital, capaz de extrair as informações necessárias do sinal original para que o pacote back-end possa realizar a interface de reconhecimento com o usuário através de métodos que abstraem este processo. A classe GraphicWave tem como único

objetivo a representação gráfica das amplitudes do sinal ao longo do tempo, e se torna útil para fins de estudo do sinal. Já a biblioteca MathC é integrada para a realização de funções matemáticas, que não são implementadas pela biblioteca Math genuína do Java ME.

Captura do som através da MMAPI

No Framework SRM a captura do sinal de som é realizada através da MMAPI, com a qual é possível manipular o processo de digitalização do sinal analógico, obtendo um arquivo que corresponde ao som capturado. A seguir, serão apresentados os conceitos básicos envolvidos na fase de captura de som, inicialmente será descrita a API MMAPI e após serão explicados os principais termos associados às características de um arquivo de som, como a frequência de amostragem, bits por amostra e codificação.

Mobile Media API (MMAPI)

A Mobile Media API (MMAPI) é uma API nativa da linguagem Java ME que oferece um grande apoio 51 \

bd oracle_

Utilizando código Java em

banco de dados Oracle

Como criar procedimentos e funções em banco de dados Oracle utilizando Java

O SGBD (Sistema de Gerenciamento de Banco de Dados) da Oracle possui, a partir da versão 8i, uma JVM (Java Virtual Machine) embutida, tornando-o assim capaz de armazenar e executar códigos Java. Neste artigo, será explicado como funciona esta estrutura e mostrado como criar uma classe Java dentro da base de dados, habilitando assim que seus métodos sejam executados como procedimentos nativos.

Oracle em 1999 lançou a versão 8i de seu gerenciador de banco de dados. A grande novidade em relação às versões anteriores era a implementação de uma máquina virtual Java interna, exceto nas versões Express. Esta mudança tornaria os bancos de dados a partir desta versão capazes de armazenar internamente classes Java. Os métodos públicos de cada classe poderiam ser compatibilizados com o padrão PL/SQL nativo, tornando-os acessíveis como se fossem funções ou procedimentos. A implantação de uma máquina virtual Java interna nos bancos de dados Oracle traz alguns recursos interessantes, dentre os quais podemos destacar: opção para o desenvolvedor Java criar soluções nas plataformas da Oracle; possibilidade de integrar no banco de dados aplicações Java já existentes; tirar proveito das medidas de segurança providas pela máquina virtual e, por fim, alocação de memória em separado para cada sessão de usuário. Este texto irá explicar como é a arquitetura da máquina virtual dentro do banco de dados, como é

/ 58

feito o armazenamento das classes e o gerenciamento da sessão de cada usuário. Será mostrado também um exemplo para criar procedimentos em Java dentro do banco de dados.

aplicações java em servidor bibliotecas específicas da oracle bibliotecas java padrão máquina virtual java do sgbd bibliotecas nativas do oracle sistema operacional Figura 1. Arquitetura Java interna no gerenciador de banco de dados.

} catch(SQLException e) { sResultado = “Houve um erro na busca do CPF.” + e.getMessage(); } if (iQtde == 0) { sResultado = “O CPF informado não está adastrado.”; } }

return(sResultado);

private static String buscaVeiculo(String sPlaca) { String sResultado = null; String sConsulta = “SELECT COUNT(1) FROM Veiculo WHERE Placa = ? “; ResultSet rs = null; int iQtde = 0; try { Connection conn = DriverManager.getConnection( “jdbc:default:connection:”); PreparedStatement stm = conn.prepareStatement(sConsulta); stm.setString(1,sPlaca); rs = stm.executeQuery(); rs.next(); iQtde = rs.getInt(1); stm.close();

}

} catch(SQLException e) { sResultado = “Houve um erro na busca do veículo.” + e.getMessage(); } if (iQtde == 0) { sResultado = “O veículo informado não está cadastrado.”; } return(sResultado);

private static void disparaEmail(String cpf, float valor) {

/ 62

//busca o nome e o email da pessoa ResultSet rs = null; String sEmail = null; String sNome = null; try { Connection conn = DriverManager.getConnection( “jdbc:default:connection:”); PreparedStatement stm = conn.prepareStatement( “SELECT nome, email FROM Pessoas WHERE Cpf = ?”); stm.setString(1,cpf); rs = stm.executeQuery(); rs.next(); sNome = rs.getString(1); sEmail = rs.getString(2); stm.close(); } catch(SQLException e) {} // ajusta a configuração do servidor de // envio de emails Properties propriedades = System.getProperties(); propriedades.put(“mail.smtp.host”, “smtp.minhaempresa.com.br”); Session session = Session.getDefaultInstance( propriedades, null); try { // cria a mensagem de email MimeMessage msg = new MimeMessage(session); { // ajusta o email do remetente InternetAddress[] enderecos= InternetAddress.parse( “contato@minhaempresa.com”); msg.addFrom(enderecos); } { // ajusta o email de destino InternetAddress[] enderecos =InternetAddress. parse(sEmail); msg.addRecipients(Message.RecipientType.TO, enderecos); }