Compartilhamento de Informaes sobre Obras Musicais Utilizando um Sistema Distribudo

Jaguaraci B. Silva Laboratrio de Sistemas Distribudos Universidade Federal da Bahia (UFBA) Salvador, BA Brazil
jaguarac@ufba.br

Resumo. O msico de instrumentos de cordas (e. g. violo, baixo e guitarra), aps o conhecimento de uma obra, realiza anotaes sobre a forma e a seqncia dos acordes utilizados. Seja em papel ou at documentos digitais, o objetivo lembrar a forma de execuo de maneira rpida. Entretanto, tais mdias podem no fornecer uma maior rapidez na obteno dos dados, por no oferecer mecanismos especficos de busca para o domnio da informao. A proposta deste trabalho a construo de um software que visa ajudar o msico a manter informaes sobre obras musicais na Internet, possibilitando a consulta em qualquer lugar utilizando diversas mdias (e. g. palms, celulares e computadores pessoais) e o compartilhamento dessas informaes com outros profissionais.

1. Introduo
Hoje a tecnologia est presente em diversas reas e campos de atuao profissional. Na msica, vrios softwares permitem a composio e regncia de obras musicais (e. g. Encore (Encore, 2007) e Finale (Finale, 2007)), facilitando o aprendizado. Antes, apenas as universidades poderiam oferecer os recursos necessrios para a formao de um msico ou musiclogo. Na dcada de 80, Almir Chediak lanou diversos livros, entre eles, um Best-seller, utilizado pelos maiores msicos do Brasil, Harmonia e Improvisao (Chediak, 1986). O livro fornece um estudo conciso e prtico da teoria musical sendo acessvel para todos, conforme frisou o cantor e compositor Djavan (Chediak, 1986, P. 1). Apesar de prtico, o guia vem perdendo o espao que est sendo ocupado pelas novas tecnologias, pois em seu formato original, difcil buscar informaes de maneira rpida como na Internet. Alm disso, o msico de instrumentos de cordas (e. g. violo, baixo e guitarra), aps o conhecimento de uma obra, realiza anotaes sobre a forma e a seqncia dos acordes utilizados. Seja em papel ou at documentos digitais, o objetivo lembrar a forma de execuo de maneira rpida. Entretanto, tais mdias podem no fornecer uma maior rapidez na obteno dos dados, por no oferecer mecanismos especficos de busca para o domnio da informao. A proposta deste trabalho a construo de um software que visa ajudar o msico a manter informaes sobre obras musicais na Internet, possibilitando a consulta em qualquer lugar utilizando diversas mdias (e. g. palms, celulares e computadores pessoais) e o compartilhamento dessas informaes com outros profissionais. Um programa foi construdo, utilizando as tecnologias EJB (Enterprise Java Beans) verso 3 e Web services para manter um cadastro de obras musicais. As informaes, armazenadas em um banco de dados, focam o resumo de uma msica, contendo os seus

principais elementos: nome da msica, tom, dominante primrio e secundrio, o tipo do acorde diminuto se ascendente, descendente ou alternativo e a existncia de clich harmnico. Estas informaes podem ser comparadas a um abstract de um artigo cientfico e so teis ao msico em um momento prvio sua apresentao ou em seus estudos. O trabalho est dividido em 4 partes. A proposta e problemas relacionados na seo 1. Uma viso geral sobre os elementos utilizados na formao de acordes nos instrumentos de percusso (e.g. violo, guitarra e baixo) e as informaes que compe um resumo de uma obra musical para estes instrumentos na seo 2. As tecnologias utilizadas para a construo do software na seo 3. As concluses na seo 4 e as referncias na parte final deste artigo.

2. Uma viso geral sobre a formao dos acordes e a sua cadncia harmnica
Um acorde um conjunto de trs ou mais sons ouvidos simultaneamente, so representados por notaes chamadas cifras. Para cada som, existe uma cifra respectiva (e.g. L = A, Si = B, D= C, R= D, Mi= E, F = F, Sol = G). Uma cifra tambm composta por nmeros que representam os intervalos da escala a partir da nota fundamental em que so formados os acordes. O acorde C7(#9) ou D com a stima e a nona aumentada, por exemplo, significa que o acorde formado pelas notas D, Mi, Sol, Si bemol ou Sib e R# ou R sustenido, conforme possvel ver na Figura 1.

Figura 1 Exemplo de intervalos e smbolos (Chediak, 1986, P. 76). Os smbolos # ou sustenido e b ou bemol, indicam que a nota est meio tom acima ou abaixo respectivamente, tendo como referncia escala da nota fundamental. Para formar uma escala de tons de uma nota, necessrio conhec-las utilizando um modelo. Alguns dos possveis tipos de acordes so: os maiores, menores, 7 da dominante e 7 de diminuta. Na Figura 2 possvel ver as construes dos acordes usando uma partitura ou pentagrama um tpico caderno usado na composio de msicas. O acorde maior, no caso da nota D, representado pela letra C maiscula e o menor seguido de um m minsculo. O acorde C, mostrado na Figura 2, formado a partir de um modelo para acordes maiores como segue: I, IIm, IIIm, IV, V, VIm e VII ou

1 grau maior, segundo e terceiro menor, quarto e quinto maior, sexto menor e stimo diminuto. Cada grau formado por uma trade ou ttrade de notas, conforme a Figura 2, formando sons diatnicos ou no. Os sons diatnicos so formados pelas notas naturais da escala de uma tonalidade qualquer, enquanto os no-diatnicos no pertencem a essa formao natural. Um acorde no diatnico, por exemplo, seria C4# ou seja, a trade de notas naturais da escala de D mais a nota F# ou F sustenido que no pertence a escala natural.

Figura 2 Alguns tipos de acordes (Chediak, 1986, P.77). Uma msica o resultado da execuo de uma seqncia de acordes, do ponto de vista de um instrumento de cordas, esta seqncia defina utilizando os tipos de acordes possveis em uma tonalidade. Cada um dos acordes tem um som funcional, preparando e resolvendo para os outros sendo mais forte, meio-forte ou fraco. Em uma escala, o acorde mais forte chamado de dominante e o meio-forte subdominante. A cadncia harmnica perfeita normalmente segue algumas regras para a construo da seqncia de acordes, alguns acordes dominantes e subdominantes podem ser vistos na Figura 3.

Figura 3 Quadro de funes harmnicas de algumas escalas (Chediak, 1986, P.96). possvel ainda existirem acordes dissonantes, aumentados ou diminutos, largamente utilizados em vrios estilos de msicas, como a bossa-nova (Bossa Nova, 2007). So formados por uma trade ou ttrade de notas, contendo uma ou mais notas no pertencentes a uma escala padro (e.g. maior, menor natural, menor harmnica e menor meldica). Uma forma de criar uma cadncia harmnica perfeita utilizar as preparaes para os acordes, para que haja uma execuo de sons que no cause perturbao aos ouvidos. Alguns tipos de preparaes so bastantes conhecidas como: dominante primrio e secundrio, acordes diminutos e um clich harmnico. A preparao para um acorde do 1 grau pode ser feita utilizando um acorde de dominante primrio, neste caso, utilizado o acorde mais forte sempre antes do acorde de 1 grau. Os dominantes dos outros graus diatnicos recebem o nome de secundrio e so resolvidos pelos acordes dominantes do grau formado pelo acorde. Os acordes diminutos podem ser ascendentes, descendentes ou auxiliares. Os ascendentes so utilizados para resolverem acordes em que a nota fundamental esteja um semitom acima

(e. g. G7 | G# | Am7 ou V7 | #V | VIm7). O diminuto descendente o contrrio, pois a preparao acontece quando a fundamental est um semitom abaixo (e. g. C7M | Dm7 | D# | C/E ou I7M | IIm7 | #II | I/3). O diminuto auxiliar ou alternativo retarda a resoluo de acordes, pode ser usado para repetir um acorde anterior (e.g. C7M | C | C7M ou I7M | I | I7M). Por ltimo, o clich harmnico oferece a possibilidade do msico reconhecer uma seqncia de repeties de acordes, pode ser comparado a um refro de uma msica. Neste caso, a composio pode ter uma pequena quantidade de acordes. A msica diversidade e plural no tocante a sua criao, pois, basta ter uma idia para que as possibilidades de acordes nunca se findem. O estudo da teoria musical abordado neste trabalho, apenas demonstrou aspectos bsicos para a compreenso da dificuldade em se guardar tantas informaes a respeito de uma obra musical. O captulo seguinte ir abordar as tecnologias utilizadas e o software desenvolvido para obter informaes rpidas de uma composio musical, os instrumentos de corda que utilizam a clave de Sol (Chediak, 1986) como referncia em um pentagrama foram privilegiados nesta seo.

3. Tecnologias utilizadas e o desenvolvimento do trabalho

Neste trabalho, foram utilizadas diversas tecnologias emergentes no cenrio de desenvolvimento de software para a Web: EJB, Web services e padres de Projeto. Uma viso geral sobre as tecnologias ser apresentada nas prximas subsees. 3.1 Enterprise Java Beans O EJB (Enterprise Java Beans), foi criado pela SUN Microsystems (Sun, 2007) na dcada de 90, a proposta desta tecnologia utilizar componentes para separar interesses (e. g. lgica de negcio, persistncia, transao e apresentao) durante o desenvolvimento de softwares distribudos. Os componentes so desenvolvidos e colocados em um continer chamado de EJB continer ou Server e podem ser acessados por objetos ou outros componentes de um software. Um componente EJB pode ser de trs tipos: entity beans, session beans e message driven beans. Um cliente pode acessar um session ou um entity bean somente com os mtodos definidos nas suas interfaces de acesso. Estas interfaces definem, a viso do cliente em relao ao bean, podem ser remotas ou locais. A interface remota de um EJB define os mtodos de negcio expostos ao mundo externo, que ir utilizar o bean. Esta interface anotada com @javax.ejb.Remote. A interface local define os mtodos que o EJB ir disponibilizar para o acesso local, anotada com @javax.ejb.Local. Um EJB pode tanto oferecer acesso remoto ou acesso local, basta implementar as interfaces correspondentes. 3.1.1 Session Bean Um session bean representa um acesso de um cliente dentro do container, o cliente invoca os mtodos do session bean atravs de uma interface local ou remota. Existem dois tipos de session beans: o stateful e o stateless. O estado de um objeto consiste nos valores de suas variveis de instncia. Em um bean de sesso do tipo stateful, este estado mantido durante a sesso do cliente com o container. Para definir um bean

como sendo stateful, pode-se utilizar a anotao @javax.ejb.Stateful antes do nome da classe. O bean do tipo stateless no mantm o estado da sesso, quando um cliente invoca um mtodo deste tipo de bean, as variveis podem conter um estado, mas somente para a durao da invocao, ao terminar a execuo, o estado encerrado. Em funo dos beans stateless poderem suportar mltiplos clientes, podem oferecer escalabilidade para as aplicaes que requerem um grande nmero de clientes. O container possui um pool de beans que so ativados quando necessrio, servindo a um usurio e ao seu trmino de execuo voltam para o pool. Um bean do tipo stateless precisa ter a anotao @javax.ejb.Stateless antes do nome da classe. 3.1.2 Message Drive Bean Quando se utiliza variveis de instncia, significa que os beans de sesso do tipo stateless no podem ser usados para guardar informaes de estado de um cliente particular, porque no garantido que o mesmo bean atenda ao mesmo cliente. Neste caso, o message drive beans ou beans de mensagem so semelhantes ao stateless. O container interage com este tipo de bean atravs dos mtodos de callback que ele implementa. Estes mtodos so similares aos usados pelos beans de sesso e os beans de entidade, notificando ao bean que determinados eventos ocorrem ou ocorreram. O message drive bean permite que as aplicaes processem mensagens de modo assncrono, funcionando como um listener de mensagens para o Java Message Service (JMS), similar ao de eventos. As mensagens podem ser emitidas por qualquer componente de Java (e. g. um cliente da aplicao, um EJB ou um componente Web) ou por uma aplicao JMS que no utilize a tecnologia Java EE. As aplicaes que utilizam JMS so chamadas de clientes, e o sistema de mensagens que realiza o roteamento e entrega de mensagens chamado de provedor. Uma aplicao JMS composta de vrios clientes e um provedor, onde um cliente que envia as mensagens chamado de produtor, e o que recebe consumidor. Para criar um bean de mensagem, dever estar declarada a anotao @javax.ejb.MessageDriven, antes do nome da classe. Este tipo de bean implementa a interface javax.jms.MessageListener o que obrigar o programador a implementar o mtodo onMessage() para tratar o recebimento de mensagens de um produtor cliente. O cdigo a ser executado quando receber uma mensagem posto no mtodo onMessage() e o bean estar escutando uma fila de mensagens ou estar inscrito para receber mensagens de um tpico. O tpico um modelo de mensagens JMS baseado em um servio de publicao e subscrio (e. g. uma publicao e muitos subscritores), a mensagem ser enviada para um topic do container EJB e este ir imediatamente realizar um envio de uma cpia desta mensagem para todos aqueles clientes que estiverem inscritos para receber mensagens daquele tpico. Funciona semelhante a um broadcast de mensagens. Uma diferena importante com relao ao modelo de tpico que a mensagem em uma fila ser consumida apenas por um cliente e no distribuda para todos os inscritos como acontece com um topic. Todas as mensagens enviadas por clientes ficam na fila aguardando algum para consumir. A deciso de qual modelo utilizar na sua aplicao ir depender em cada caso do que precisa ser representado com JMS, o modelo de fila ou queue garante que somente um cliente ir processar a mensagem recebida.

3.1.3 Entity Beans Os entity beans so utilizados para representar entidades do mundo real (e. g. aluno, curso, pedido ou venda.) ou as que j estejam no banco de dados em forma de tabelas, onde cada instncia do bean representa uma linha de uma tabela. Quando um novo bean criado, um novo registro deve ser inserido na base de dados e uma instncia do bean associada a este dado. Conforme o bean usado, o seu estado alterado e estas mudanas devem estar sincronizadas com a base de dados, alm disso, um bean de entidade pode estar mapeado para uma ou mais tabelas. O desenvolvimento de um entity bean deve atender a uma srie de requisitos. A classe deve estar anotada com @javax.persistence.Entity ser public ou protected e possuir um construtor sem parmetros. A classe no pode ser final, bem como seus mtodos e atributos e deve implementar a interface Serializable. Atributos de classes que representam entidades precisam ser declarados como privados, protegidos ou pacote e serem acessados somente por mtodos pblicos. Os entity beans permitem o acesso compartilhado, tm chaves primrias e podem participar de relacionamentos com outros beans do mesmo tipo. O container EJB fornece a gerncia da transao, cada entity possui um identificador para uma instncia do objeto. Seja um identificador nico ou uma chave primria, este mecanismo permitem a aplicao cliente encontrar um entity bean em particular. A anotao @javax.persistence.Entity introduzida antes do nome da classe define um bean de entidade e faz o mapeamento para uma tabela do banco de dados. Alm dessa anotao, existem outras que simbolizam os elementos encontrados no banco de dados (e. g. nome de tabelas, campos, tipo de transao). Para que o continer conhea as configuraes de persistncia para um determinado contexto, criado o arquivo persistence.xml. Neste arquivo especificado o data source para o banco de dados que deve ser utilizado, bem como as classes de persistncia (e. g. entity beans). Caso contrrio, o servidor ir varrer todo o arquivo jar instalado em busca de classes com a anotao @javax.persistence.Entity(). Para realizar as operaes no banco de dados usando um entity bean, criada uma instncia da classe EntityManager em um bean de sesso. Esta classe possui vrias operaes que facilitam a vida do programador (e. g. incluir, pesquisar, atualizar e apagar), atravs dos mtodos: persist(), find(), merge(), remove(), refresh(), flush(), contains() e clear(). possvel tambm no utilizar o gerenciamento do continer EJB, construindo os mtodos manualmente (Mukhar, 2006, P. 441). 3.2 Web services Com o crescimento da utilizao da Internet, vrias empresas comearam a publicar servios e trocar informaes entre aplicaes na Web. A necessidade de uma padronizao motivou o surgimento de vrias tecnologias, entre elas, os servios Web. Os servios Web provem uma forma mais estruturada de comunicao entre os pontos finais de comunicao. Na Figura 4, possvel conhecer a sua arquitetura. As aplicaes, representadas na camada superior da Figura 4, acessam os servios Web descritos na linguagem WSDL (Web Services Description Language) (W3C, 2007), utilizando um servio de diretrio repositrio de informaes sobre os servios Web ou diretamente quando possui o conhecimento da sua URL (Uniform Resource Location). Os dados so empacotados usando o protocolo de troca de

mensagens SOAP (Simple Object Access Protocol), possuindo as caractersticas de formatao da linguagem XML (Extended Markup Language) para representao dos dados. So enviados dos servidores Web, onde residem os servios, usando o protocolo HTTP para os clientes que os requisitam atravs de browsers (e. g. Internet Explorer, Netscape Navigator e Firefox), aplicaes que utilizam middlewares especficos (e.g. RMI, CORBA e .Net Remoting) ou outros servios Web.

Figura 4 Arquitetura dos servios Web (Coulouris, 2005 P. 785). O protocolo SOAP surgiu como uma alternativa aos problemas causados pelo aumento do nmero de portas de comunicao usadas nas aplicaes distribudas e nos servios dos sistemas operacionais, devido necessidade de se estabelecer uma comunicao entre os extremos usando um protocolo da camada de transporte (Tanenbaum, 1994, P. 443). Por questes de segurana das informaes internas, as empresas que expe os seus servios na Internet, utilizam um firewall software que controla as portas virtuais entre os extremos de uma comunicao. Pela configurao do firewall ser feita manualmente e a vasta gama de servios que fazem o uso de portas virtuais, muitos profissionais que administram as redes de computadores e as empresas so bastante criteriosos em permitir o acesso sua infraestrutura, ocasionando em um retardo ou prejuzo para o consumidor desses servios. Com a utilizao do protocolo HTTP para o trfego de informaes, o SOAP facilitou o uso e a disseminao dos servios Web, pois as portas de comunicao do protocolo HTTP j esto configuradas para o acesso ao contedo de sites nas empresas. Uma empresa que deseja implementar um servidor para suportar os servios Web usando o protocolo SOAP, deve seguir a especificao do padro (W3C, 2007). A especificao contm informaes que visam forma em que o contedo das mensagens devero estar usando a linguagem XML, padro de mensagens de requisio e resposta, as regras que o recipiente das mensagens deve seguir para processar o contedo XML e como deve ser o protocolo de comunicao. Felizmente, as linguagens de programao facilitam a utilizao dos protocolos de comunicao, ocultando os detalhes durante a implementao (Couloris, 2005, P. 789). Uma API (Application Program Interface) facilita essa abstrao, e utilizada para o desenvolvimento dos servios Web e os clientes que os acessam sobre o protocolo SOAP. Na linguagem Java chamada de JAX-RPC (Couloris, 2005, P. 795). A API faz a traduo de tipos entre as linguagens Java e o XML utilizado nas mensagens SOAP e no WSDL, entretanto, deve-se seguir as regras descritas em um documento JSR (Java Specification Request) (JCP, 2007). Para construir e consumir um Web service usando a linguagem Java e a API JAX-RPC (Java

API for XML-based Remote Procedure Call), deve-se: criar uma interface para o servio implementar os mtodos da interface, compilar as classes utilizadas gerando um arquivo com a extenso JAR (JCP, 2007), publicar o servio, copiando o artefato para o recipiente ou continer EJB no lado do servidor e construir uma aplicao cliente para acess-lo.

Figura 5 Arquitetura de uso dos Web services no Java EE 5 (Raj, 2006). A Figura 5 mostra a arquitetura utilizada pelos servios Web usando a JAX-WS 2.0, especificao atual usada para construo e utilizao de Web services na plataforma Java 5 (Raj, 2006). possvel utilizar um continer EJB ou Web para publicar o servio. Quando utilizado em um continer EJB, os mtodos do servio WEB podem ser implementados usando o bean de sesso do tipo Stateless. O arquivo WSDL ser gerado automaticamente neste caso, contendo as informaes sobre como acessar o servio (e. g. um continer residente em um servidor de aplicao, um dispositivo mvel ou um aplicativo) no formato reconhecido por mltiplos protocolos como o SOAP 1.1 e 1.2 e XML. O componente Port associado a um Endpoint contido no arquivo WSDL atravs de uma classe Java que prov a lgica de negcio e esta ligada ao comportamento do continer. No continer existe um escutador de eventos para o Endpoint do arquivo WSDL e meios para despachar a requisio ao bean do servio. Para acessar o servio, o cliente deve utilizar o proxy, e assim, ter a referncia do Web service localmente para executar os mtodos. 3.3 Design Patterns Durante a ltima dcada, o uso da modelagem de projeto, durante o desenvolvimento de software, tornou-se muito popular. Os padres de projeto definem em sua essncia, o reuso de boas idias bem conhecidas, para resolver um problema particular. As idias para os padres de projeto originam-se do arquiteto Christopher Alexander, a partir dos seus livros: The Timeless Way of Building (Alexander, 1979) e A Pattern Language (Alexander, 1977). Os livros fornecem idias e padres para criar estruturas arquitetnicas da alta qualidade. Os conceitos foram desenvolvidos, originalmente, com edifcios e os mesmos princpios foram utilizados no desenvolvimento de arquiteturas e de produtos de software. Erich Gama, Richard Helm, Ralph Johnson e John Vlissides,

ou como so popularmente conhecidos: The Gang of four ou GoF, popularizaram o uso dos padres no projeto de software com seu livro Elements of Reusable Software em 1995 (Gamma et al, 1995). Os padres de projeto usados no paradigma de orientao a objetos, esto em um nvel acima da linguagem de programao, segundo (Metsker, 2004). Alm de fornecer arcabouos conceituais, para a utilizao de uma linguagem de representao como a UML (Unified Modeling Language) (Rumbaugh et al, 1999). Alguns livros versam sobre os tipos de padres mais utilizados na engenharia de software atual, entre eles: Analysis Patterns: Reusable objects Models (Fowler, 1997) padres para modelagem de softwares orientados a objetos Core J2EE Patterns: Best Practices and Desing Strategies (Malks et al, 2003) padres de arquitetura para a plataforma Java Enterprise Edition (Sun, 2007) e Applying UML and Patterns, Second Edition (Larman, 2002) padres de projeto. Apesar do livro (Malks el tal, 2003) mostrar padres de arquitetura J2EE, o livro utiliza os padres do Gof (Gamma et al, 1995) como referncia. Um exemplo de um padro de projeto pode ser visto na Figura 6. Para que um programa, usando a arquitetura cliente & servidor, tenha acesso a um software servidor construdo com o RMI (Remote Method Invocation) (Sun, 2007), preciso existir um objeto que represente a implementao da interface Interface EditorRemoto para invocar os seus mtodos atravs de um representante ou proxy (Metsker, 2004, P. 115).
Tabela 1 Exemplo de utilizao do padro Proxy (Silva, 2007 P. 18).
NameComponent component = new NameComponent( "ObjetoServidor", "" ); NameComponent path [] = {component}; interfaces.InterfaceEditorRemoto servImpl = InterfaceEditorRemotoHelper.narrow(ncRef.resolve(path)); servImpl.setLimpar(currX, currY, prevX, prevY);

Aps a implementao da interface o cliente precisa invocar os mtodos usando o representante da classe, neste caso, o objeto servImpl, mostrado na Tabela 1. Este ir obter a referncia remota da instncia da classe que implementa a interface InterfaceEditorRemoto mostrada na Figura 6, possibilitando a invocao dos mtodos em um outro computador atravs do programa cliente. Este padro tambm utilizado no Design Pattens Facade (Malks et al, 2003), na verso atual do EJB, conforme mostrado na seo anterior, para utilizar um bean de entidade necessrio usar um outro de sesso do tipo Stateless, servindo esse, como um representante para que as demais classes possam persistir dados sem acessar diretamente o bean de entidade. Na construo dos mtodos possvel utilizar-se de outro padro, o Data Transfer Objects (Malks et al, 2003), para que seja passado um objeto como parmetro de entrada nos mtodos de acesso ao bean de entidade. Dessa forma, facilita a manuteno posterior, caso haja a insero de novos atributos ou mudanas nas regras de implementao do bean de entidade.

Figura 6 Exemplo do padro de projeto Proxy (Silva, 2007 P. 7). 3.4 Desenvolvimento do trabalho O desenvolvimento da aplicao utiliza as boas prticas dos padres de projeto, com isso, a aplicao foi dividida em camadas de forma a facilitar a implementao e manuteno das classes. O continer EJB utilizado foi o JBoss AS 4.0.5GA(JBoss, 2007), o servio Web foi implementado usando o JBoss-WS 1.0.3GA (Jboss WS, 2007), a verso utilizada da Java Virtual Machine foi a 1.5.0 update 9, por questes de compatibilidade com as APIs utilizadas no continer EJB 3 (Jboss Forum, 2007). 3.4.1 Arquitetura da aplicao A construo da aplicao foi divida em duas partes: a construo dos servios no lado do servidor usando a tecnologia EJB e Web services e a utilizao desses servios pelos clientes. A Figura 7 apresenta a arquitetura de acesso um servio Web atravs de um diagrama de seqncia (Rumbaught et al, 1999). Trechos de cdigo para explanao de todas as classes sero mostrados na tabelas seguintes. Uma instncia da classe WebserviceClient, atravs do cdigo contido na Tabela 9, acessa a um servio Web publicado no servidor de aplicao JBoss. A arquitetura foi dividida em camadas lgicas de forma a representar um certo isolamento de responsabilidades, diminuindo o acoplamento entres as classes. Na construo do programa foram utilizadas as camadas de persistncia, lgica de negcios, delegao, servio e apresentao.

Figura 7 Diagrama de seqncia da arquitetura. 3.4.2 Construo do EJB 3.4.2.1 Camada de persistncia Na Tabela 2, mostrado um trecho do cdigo utilizado para a construo da camada de persistncia aos dados usando um beans de entidade e o recurso de anotaes do EJB 3. Conforme a seo 2, para criar uma classe que representa uma tabela em um banco de dados foi utilizada a anotao @Entity antes do nome da classe, o mtodo getID() ir gerar um novo identificador para uma nova msica inserida no banco de dados. Para isto foi utilizada a anotao @GeneratedValue antes do nome do mtodo. Foi criado tambm um mtodo construtor padro, conforme a especificao da JSR 109 (JCP, 2007), sem parmetros de entrada e qualquer implementao.
Tabela 2 Parte do cdigo Java utilizado para construo do bean de entidade.
@Entity public class Musica implements Serializable { ... public Musica(){} @Id @GeneratedValue public Integer getID() { return ID; } ...

Na construo da camada de persistncia, foi criado o arquivo persistence.xml, esse arquivo define vrias informaes para configurao das classes de persistncia. Entre as configuraes possveis mostrada na Tabela 3, a informao da classe que

representa uma tabela no banco de dados (e. g. beans.Musica), construda usando um bean de entidade definida na linha 4. A configurao da fonte para o acesso ao banco de dados foi criada na linha 3 e o banco de dados utilizado o HSQLDB (HSQLDB, 2007).
Tabela 3 Arquivo de configurao da camada de persistncia.
<persistence> <persistence-unit name="ManterMusicaFacade"> <jta-data-source>java:/DefaultDS</jta-data-source> <class>beans.Musica</class> <properties><property value="org.hibernate.dialect.HSQLDialect"/> name="hibernate.dialect"

<property name="hibernate.hbm2ddl.auto" value="create-drop"/> </properties> </persistence-unit> </persistence>

3.4.2.2 Camada de lgica de negcio A camada de lgica de negcio representa a viso do cliente, pode ser explicitada usando os diagramas de caso de uso da UML (Rumbaught, 2002), onde cada caso de uso representa uma ao a ser realizada pelo cliente na utilizao do sistema. No projeto, foram definidas as aes de adicionar msica, apagar msica, atualizar as informaes de uma msica e a possibilidade do msico poder obter informaes de uma ou vrios msicas. Todas essas aes foram definidas utilizando uma interface remota, pois o sistema permitir a sua utilizao em mquinas virtuais Java em diferentes locais, conforme o cdigo exibido nas Tabela 4. O padro de projeto utilizado para definir o acesso a camada de persistncia foi o Session Facade (Malks et al, 2003).
Tabela 4 Definio e implementao da interface remota.
@Remote public interface ManterMusica { public void adicionarMusica(MusicaTO musicaTO); public void deletarMusica(MusicaTO musicaTO); public void atualizarMusica(MusicaTO musicaTO); public MusicaTO selecionarMusica(MusicaTO musicaTO); public List selecionarMusicas(); }

@Stateless public class ManterMusicaFacade implements ManterMusica { @PersistenceContext(unitName="ManterMusicaFacade") private EntityManager entityManager; public void adicionarMusica(MusicaTO musicaTO) { entityManager.persist(new Musica(musicaTO)); }

3.4.2.3

Camada de delegao

A camada de delegao fornece o acesso aos mtodos de negcio para o cliente da aplicao, sem expor a camada de persistncia e lgica de negcio. Na Tabela 5 mostrado um trecho do cdigo que implementa o padro de projeto Delegate (Malks et al, 2003). Na construo da aplicao cliente, o programador precisa ter acesso apenas s camadas de delegao e localizao de servio. Assim, as alteraes na camada de negcio sero isoladas, diminuindo o acoplamento e facilitando a manuteno do sistema. O servio de localizao de instncias remotas tambm utilizado pela camada, proporcionando um ponto nico e evitando a duplicao de cdigo.
Tabela 5 Implementao da camada de delegao dos mtodos de negcio.
public class ManterMusicaDelegate { private ServiceLocator serviceLocator; private ManterMusica ManterMusica; public ManterMusicaDelegate() throws MusicaException{ serviceLocator = ServiceLocator.getInstance(); try { ManterMusica = (ManterMusica) serviceLocator.lookup(

ManterMusicaFacade.class.getSimpleName()+"/remote"); } catch (NamingException e) { System.out.print(e.getMessage()); throw new MusicaException(e.getMessage()); } } public void adicionarMusica(MusicaTO musicaTO) throws MusicaException{ ManterMusica.adicionarMusica(musicaTO); }

3.4.2.4

Camada de servio

A camada de servio utiliza o padro Service Locator (Malks et al, 2003) para localizar as instncias de objetos remotos, que representam a lgica de negcio atravs de suas interfaces. A implementao do servio de localizao mostrada na Tabela 6.
Tabela 6 Servio de localizao de interfaces remotas.

public class ServiceLocator { private InitialContext ic; private static ServiceLocator me; public ServiceLocator() { try { ic = new InitialContext(); } catch (NamingException ne) { throw new RuntimeException(ne); }} return } ic.lookup(jndiName);

public static ServiceLocator getInstance() throws RuntimeException { if (me == null) { me = new ServiceLocator(); } } public Object lookup(String jndiName) throws NamingException { public Object lookup(String jndiName) throws NamingException { return ic.lookup(jndiName); } } return me;

O servio de localizao cria um nico ponto para buscas de objetos remotos e por no conter mtodos que faam referncia s interfaces remotas com um tipo de retorno, como eram definidos nas verses anteriores ao EJB 3, ficou bastante fcil e reduzida a sua implementao. 3.4.2.5 Camada de apresentao O acesso aos mtodos de negcio realizado pela aplicao cliente na camada de apresentao dos dados utilizando a camada de delegao, como pode ser visto na Tabela 7. A aplicao cliente, atravs do padro Transfer Objects (Malks et al, 2003) ir utilizar um objeto para passagem de referncia. Essa abordagem foi utilizada para ocultar do cliente preocupaes com definies de tipos de parmetros utilizados nos mtodos de negcio. Por questes de segurana, tambm foi ocultada a definio da classe que representa a camada de persistncia criando uma rplica da classe (e. g. MusicaTO) sem as anotaes.
Tabela 7 Cdigo Java para acesso ao delegate em uma aplicao.
//Acesso ao delegate usado em uma aplicao cliente swing ManterMusicaDelegate delegate = new ManterMusicaDelegate(); List<MusicaTO> MusicaTo = new ArrayList<MusicaTO>(); MusicaTo = (delegate.selecionarMusicas());

//Acesso ao Web Service realizado por uma aplicao Java String nameSpace="http://business/jaws"; String service="SelecionarMusicasService"; String wsdl="http://localhost:8080/easd2007/SelecionarMusicasWS?wsdl"; URL url = new URL(wsdl); QName qname = new QName(nameSpace,service); ServiceFactory factory = ServiceFactory.newInstance(); Service remote = factory.createService(url, qname); SelecionarMusicas proxy = (SelecionarMusicas) remote.getPort(SelecionarMusicas.class); String[] musicas = proxy.selecionarMusicas();

Para acessar o servio Web, o cliente da aplicao precisa acessar o arquivo WSDL contendo a descrio do servio. O continer EJB 3 gera o arquivo automaticamente, aps a identificao das anotaes contidas na Tabela 9. Com as informaes do

EndPoint, nome do servio Web e a URL do arquivo WSDL, possvel criar uma instncia do servio e obter uma referncia ao proxy da interface remota, assim utilizando o seus mtodos de maneira esttica para recuperar os dados, conforme visto na Tabela 7. 3.4.3 Construo do Web service Usando as anotaes do EJB 3, conforme cdigo-fonte mostrado na Tabela 9, muito simples construir um servio Web usando o EJB3. O servio Web construdo utiliza a API JAX-WS 2.0 (Raj, 2006). Com o uso dos padres de projeto delegate, service locator e facade foi possvel reutilizar os mesmos mtodos da camada de negcios, delegao e localizao de servio na publicao do servio Web. Caso esteja em outra mquina virtual, basta compilar e gerar as classes necessrias, sendo possvel ainda, definir um arquivo externo com os nomes das interfaces remotas para que no haja a necessidade de modificao nas classes compiladas.
Tabela 9 Cdigo Java utilizado na criao do servio Web.

@WebService @SOAPBinding(style = Style.RPC) public interface SelecionarMusicas extends Remote{ public String[] selecionarMusicas() ; } @Stateless @WebService(endpointInterface="business.SelecionarMusicas") @Remote(SelecionarMusicas.class) public class SelecionarMusicasWS { public String[] selecionarMusicas() throws MusicaException{ List<MusicaTO> musicas = new ArrayList<MusicaTO>(); ManterMusicaDelegate delegate; delegate = new ManterMusicaDelegate(); musicas = delegate.selecionarMusicas(); String[] musicasNomes = new String[musicas.size()]; int i=0; for (Iterator<MusicaTO> iter = musicas.iterator(); iter.hasNext();){ musicasNomes[i] = new String(iter.next().getNome()); i++; } return musicasNomes; }

4. Concluso
As tecnologias Java sempre sofreram uma grande crtica por serem complexas e exigirem um tempo e esforo muito grande para sua aprendizagem. A partir da verso 3.0, ficou mais fcil a sua utilizao, por incorporar as anotaes nas classes. O

Enterprise Java Beans um framework voltado para a criao de componentes de software e a realizao de uma srie de servios, como os web services. Este trabalho apresentou a construo de uma aplicao distribuda utilizando as tecnologias EJB 3.0, padres de projeto e a API JAX-WS 2.0 que facilita a construo dos web services usando as anotaes. Alm de mostrar as facilidades encontradas atualmente nas tecnologias Java, o trabalho possibilitou um conhecimento breve sobre a criao das composies musicais para os instrumentos de cordas e as principais informaes que formam um resumo de uma obra musical. Uma proposta de trabalho futuro a implantao do software para utilizao na Internet, atravs do seu uso por diversos msicos, ser possvel aperfeiolo e assim haver a possibilidade de compartilhar informaes mais complexas sobre as msicas em diversas mdias (e. g. celular, o computador e o palm) entre as pessoas de todo o mundo.

Referncias
Alexander C. (1979) The Timeless Way of Building, Oxford University Press, ISBN 0195024028. Alexander C. (1977) A Pattern Language, Oxford University Press, ISBN 0195019199. Alur, D., Crupi, J., Malks, D. (2003) "Core J2EE Patterns Best Pratices and Design strategies". Pearson, ISBN 0131422464. Booch, G., Jacobson, I., Rumbaugh, J (1999). Unified Modeling Language Users Guide. Addison-Wesley, ISBN 0201571684. Bossa Nova. (2007) Bossa Nova, http://www.bossanova.mus.br/. Setembro. Chediak, A. (1986) "Harmonia & improvisao". Lumiar Editora, 8 edio. Couloris, G., Dollimore, J., Kindberg, T.. (2005) "Distributed Systems concepts and Design". Addison Wesley, 4 Edio, ISBN 0321263545. Encore. (2007) Encore, http://www.gvox.com/, Setembro. Finale. (2007) Finale, http://www.finalemusic.com/finale/home.aspx, Setembro. Fowler, M. (1996) "Analysis Patterns: Reusable Object Models". Addison Wesley. ISBN 9780201895421. Gamma E., Helm R., Johnson R., Vlissides J. (1995) Design Patterns, AddisonWesley, ISBN 0201633612. HSQLDB. (2007) HSQLDB Database, http://hsqldb.org/, Setembro. JBoss. (2007) JBoss Application http://labs.jboss.com/jbossas/downloads, Setembro. JBossWS. (2007) JBoss Web http://labs.jboss.com/jbossws/downloads, Setembro. Server Service 4.0.5GA, 1.0.3GA,

JBossForum. (2007) JBoss We Service http://www.jboss.org/?module=bb&op=viewtopic&t=103699, Setembro.

Forum,

JCP. (2007) Java Community Process, http://jcp.org/en/jsr/overview, Setembro. Larman, C. (2002) "Applying UML and Patters: An introduction to Object-oriented analysis and design and the Unified Process". Prentice Hall, ISBN 0130925691. Metsker, S. J. (2004) "Padres de Projeto em Java". Bookman, ISBN 8536304111. Mukhar, k., Zelenak, C. (2006) "Beginni Java EE 5 from novice to Professional". Apress, ISBN 1590594703. Raj, G. S., Binod P.G., Babo, K., Palkovic, R. (2006) "Implementing Service-Oriented Architecture (SOA) with the Java EE 5 SDK". Sun Microsystems, revision 3. Silva, J. B. (2007) Paintbrush Distribudo usando RMI-IIOP e CORBA. Especializao Avanada em Sistemas Distribudos, trabalho parte da avaliao da disciplina de objetos distribudos, Universidade Federal da Bahia. Sun. Sun Microsystems (2007). Java Technology. http://www.java.sun.com. Setembro. Tanenbaum, A. S.. (1994) "Redes de computadores". Editora Campus, 2 Edio, ISBN 8570018800. W3C. World Wide Web Consortium (2007). OWL Web Ontology Language Guide. http://www.w3.org/TR/owl-guide/. Setembro.