Construindo Sistemas Distribudos Pensando no Reuso dos Padres

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

Resumo. A reutilizao de padres de projeto na construo de outros (e.g. padres arquiteturais) um exemplo prtico e pode se mostrar eficaz durante a fase de construo de um domnio de aplicao ou nos projetos de design de sistemas. O trabalho enfatiza o reuso e as oportunidades para melhorar o desenvolvimento de sistemas distribudos atravs dos padres de projeto. Para demonstrar o reuso dos padres de projeto, foi analisada uma aplicao construda a partir dos padres Java EE (Malks et al, 2003). reutilizando os padres JEE em conjunto com o Adaptive Comunication Environment (ACE), o Model View Controller (MVC) e mostrados alguns padres Gof que servem de base para a criao dos padres da arquitetura JEE.

1. Introduo
Com o surgimento de diversos padres para implementao de software pouco se comenta sobre a forma de reuso destes. Na tecnologia Java, por exemplo, os padres mostrados em (Malks et al, 2003) e utilizados durante a construo de um projeto usando a tecnologia Java EE (Sun, 2007), so concebidos re-aproveitando as melhores prticas do Gof (Gamma et al, 1995). A reutilizao de padres de projeto na construo de outros (e.g. padres arquiteturais) um exemplo prtico e pode se mostrar eficaz durante a fase de construo de um domnio de aplicao ou nos projetos de design de sistemas. A proposta deste trabalho demonstrar o reuso e as oportunidades para o melhoramento do design de sistemas atravs dos padres de projeto. Ser feita uma anlise sobre os padres encontrados, alm da oportunidade de utilizao de outros para a melhoria do software. Para demonstrar o uso dos padres de projeto, ser analisada uma aplicao que foi construda a partir dos padres Java EE (Malks et al, 2003). O trabalho est dividido em 4 partes. A proposta e problemas relacionados na seo 1. Uma viso geral sobre os padres de projeto 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. Padres de Projeto
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 para o design de sistemas. Apesar de (Malks el tal, 2003) demonstrar o uso dos 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 1.

Figura 1 Exemplo do padro de projeto Proxy (Silva, 2007 P. 7).

Para um programa cliente, 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 InterfaceEditorRemoto 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 1, 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. Outro padro utilizado para facilitar a programao de sistemas distribudos o Adaptive Comunication Environment (ACE) (Schmidt, 1993). O ACE fornece um toolkit contendo uma srie de invlucros, categorias de classes e frameworks que ajudam na programao de servios que operam sob uma rede de computadores em diversos tipos de sistemas operacionais. Entre as facilidades encontradas, possvel citar: o estabelecimento de conexes de servios, demultiplexao e dispatch de eventos, IPC e protocolos de rede, gerenciamento e cach de armazenamento primrio e secundrio, configurao esttica e dinmica de componentes e controle de concorrncia e sincronizao e threads. A Figura 2 mostra as categorias de classes do ambiente.

Figura 2 - Categoria de classes do ACE (Schmidt, 1993, P.3).

Interfaces de programas para o usurio final so susceptveis a trocas constantes. Em outros tempos, quando normalmente eram estendidas funcionalidades de uma aplicao desktop, habilitavam-se um ou mais menus, alm de modificar o cdigo-fonte. Muitas modificaes no eram compatveis com todos os gostos e cenrios de utilizao e o resultado era definir interfaces personalizadas, duplicando os componentes de acesso a dados e as regras de controle para sua exibio. Com o tempo, as tecnologias emergiram, e as empresas tiveram ao seu alcance outros equipamentos, entre eles, os portteis (e.g. palms, celulares e notebooks). Em virtude da competitividade do mercado, as informaes tinham de ser visualizadas mais rapidamente, em qualquer dispositivo com capacidade para tal e em qualquer lugar, pois a necessidade de criar novas solues para um pblico diversificado com o mnimo de modificaes foi crescente. Ainda se gastava muito tempo para desenvolver as camadas de acesso dados, de regras de negcio da aplicao e a interface para visualizar os dados e controlar as aes feitas pelos usurios, pois todos esses interesses eram misturados em um nico componente, diminuindo a oportunidade de reuso de cada parte isoladamente. Existiam tambm outros problemas com relao visualizao da mesma informao em diferentes componentes, como: a necessidade da aplicao refletir imediatamente as atualizaes dos dados na tela e o suporte a diferentes look and feel (Buschman et al, 1996) e que motivaram a criao do padro arquitetural MVC. O padro MVC divide a aplicao em trs partes: o processamento, a sada e a entrada de dados atravs do modelo, controle e visualizao dos dados respectivamente.

Figura 3 Modelo de classes do padro MVC, (Buschman et al, 1996, P.129).

Conforme a Figura 3, o modelo ou model representa uma camada de acesso aos dados com aes de consulta, alterao, excluso e insero de registros e construdo independente da maneira em que os dados sero visualizados ou das regras de negcio do software. A visualizao ou view representada as telas de interao com os usurios. Cada tela tem um controlador ou controller que antes de acessar o modelo verifica as regras,

encaminha os dados para outra janela, enfim, gerencia todas as aes e a maneira como os dados sero apresentados. O componente observer ou observador opcional, pode ser utilizado para detectar as mudanas no modelo e notificar ao controlador para atualizar os dados na tela do componente view.

3. Desenvolvimento do trabalho
Para demonstrar o reuso dos padres de projeto, foi construdo 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) (Sun, 2008) verso 3 e Web services (Couloris et al, 2005) 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 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, 2008), o servio Web foi implementado usando o JBoss-WS 1.0.3GA (Jboss WS, 2008), 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, 2008). 3.2 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.

Figura 4 Diagrama de seqncia da arquitetura.

A Figura 4 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 2, 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 5 Planejamento da arquitetura do software.

A Figura 5 demonstra como ser a implementao do software atravs da exibio por camadas. Cada retngulo representa uma camada e ter responsabilidades de acordo com o padro representado do lado direito, para proporcionar uma arquitetura flexvel a mudanas e de fcil entendimento. Ao longo deste captulo sero detalhados os problemas, benefcios e modelos de classes sugeridos para implementao do software por camada de responsabilidade. 3.2 Construo do EJB

3.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 bean de entidade e o recurso de anotaes do EJB 3. 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, 2008), 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, 2008).
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 name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/> <property name="hibernate.hbm2ddl.auto" value="create-drop"/> </properties> </persistence-unit> </persistence>

A camada de persistncia representa o modelo de dados, conforme mencionado no captulo anterior, na arquitetura MVC. A Figura 6 mostra como ser a forma de representao dos dados usando o componente model desta arquitetura em conjunto com a camada de lgica de negcios.

Figura 6 Representao do modelo de dados e o seu acesso.

Qualquer cliente interessado em persistir ou recuperar os dados dever utilizar a camada de acesso lgica de negcios. Entre os problemas encontrados na abordagem tradicional de acesso ao modelo de banco de dados direto, possvel citar: a replicao de cdigo para estabelecer a conexo, as mudanas nos mtodos das classes que acessam o banco de dados devem ser replicadas na camada de visualizao ou quando esta camada no mistura interesses de acesso, persistncia e visualizao de dados. Preocupaes com requisitos no-funcionais (e.g. transaes, logs, sees ou espaos de usurios). Entre os maiores benefcios encontrados quando do uso correto dos padres MVC (Buschman et al, 1996) e Session Facade (Malks et al, 2003), esto o desacoplamento e coeso, atravs da diviso dos interesses entre as classes, o que ocasiona maior facilidade de manuteno. Alm disso, os requisitos no-funcionais mencionados sero tratados pelo middleware. O modelo de dados utilizado no design pode ser um exemplo de reuso do padro Memento (Gamma et al, 1995), pois facilita a persistncia de dados a partir de instncias de objetos. 3.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 et al, 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)); }

De acordo com a Figura 6, o padro Session Facade utilizado para servir como uma fachada entre o bean de entidade, representado pelo componente model, e o componente de visualizao da arquitetura MVC (Buschman et al, 1996), que ser mostrado posteriormente. Este padro reutiliza em sua forma de implementao o padro de projeto Facade (Gamma et al, 1996). A proposta de sua utilizao ocultar os detalhes de implementao da camada de acesso aos dados, facilitando para o cliente o acesso aos dados das tabelas atravs de uma interface.

3.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 para estabelecimento de conexes.
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); }

Figura 7 Acesso oferecido camada de visualizao para estabelecer conexo e acesso aos dados.

A Figura 7 mostra o padro Delegate sendo utilizado, este padro uma implementao do padro Proxy (Gamma et al, 1996), explicado no captulo anterior, pois

utiliza uma interface remota, a ManterMusica, como representante da classe ManterMusicaFacade para acessar o modelo de dados. 3.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(); return me; } } public Object lookup(String jndiName) throws NamingException { public Object lookup(String jndiName) throws NamingException { return ic.lookup(jndiName); } }

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. Alm disso, faz o reuso do padro Singleton (Gamma et al, 1996) para criar de um pool de conexes para o banco de dados e o seu gerenciamento em uma nica instncia. 3.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. 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.

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();

A camada de apresentao foi construda pensando na arquitetura MVC (Buschman et al, 1996) e os benefcios obtidos com os padres da arquitetura JEE (Malks et al, 2003). Conforme a Figura 8, um componente GUI (Graphical User Interface) que ser a interface grfica que o usurio ir ter acesso aos dados, ser o componente que ir utilizar um componente view para fazer as requisies ao componente controller, representado pelo delegate. Com isso, o delegate, que j implementa as regras de negcio, no precisa ser alterado, nem a forma como se d o acesso ao modelo de dados representado pelo bean de entidade Musica.

Figura 8 Camada de apresentao.

A implementao da classe Principal que interage com o componente view TelaManterMusica, habilita a criao de vrios tipos de visualizao para os dados, inclusive alteraes da forma de composio de botes, caixas de texto e outros componentes visuais, pois podem ser utilizados diferentes layouts. Entre os benefcios alcanados com a distribuio dos componentes desta forma, possvel citar: a reutilizao

do modelo de dados atravs do controller, facilitando as alteraes em cada componente e isolando esses pontos aumentando a coeso. A reutilizao da camada de lgica de negcios para construo dos mtodos que devem ser apenas delegados pelo Web service atravs do padro Wrapper Facade, explicado posteriormente, e a facilidade de requisitar e receber os dados com a utilizao do padro Transfer Object (Malks et al, 2003) entre todos os componentes evitando problemas com converses de tipos. 3.2 Construo do servio Web

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. Usando as anotaes do EJB 3, conforme cdigo-fonte mostrado na Tabela 8, 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 8 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; }

Entretanto, detalhes do estabelecimento da conexo com o servidor para invocar o servio Web e de como foi implementada a camada de lgica de negcio, devem ser ocultados do lado do cliente, inclusive, para contemplar os requisitos de portabilidade e facilitar a manuteno do componente view que ser provida ao usurio. Para a soluo destes problemas, foram utilizados, em conjunto com os padres JEE, os padres do ACE Acceptor, Connector, Service Handler e Wrapper Facade. O Wrapper Facade encapsula as funes de baixo nvel e estruturas de dados usando interfaces, facilitando a portabilidade, a robustez e a manuteno porque oculta os detalhes da implementao (Schmidt, 1999). J os padres Acceptor e Connector desacopla o estabelecimento da conexo e inicializao de servios em sistemas distribudos (Schmidt, 1997). A Figura 9 mostra como foram utilizados os padres do ACE e a reutilizao dos patterns JEE para prover a soluo.

Figura 9 Construo do servio Web e o seu modo de acesso feito pelo cliente.

O cliente do servio Web ir utilizar-se da classe ManterMusicaDelegate para criar uma instncia do servio que deseja utilizar, para isso faz o uso da interface que encapsula os detalhes de implementao e torna a utilizao do mtodos remotos mais fcil pelo desenvolvedor. A conexo feita atravs da classe ServiceLocator que, alm de proporcionar um nico ponto para a criao do End Point, estabelece a comunicao entre o modelo de dados, atravs do Session Facade e o cliente do servio Web.

4. Concluso
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. 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. Foi utilizado o Enterprise Java Beans que um framework voltado para a criao de componentes de software e a realizao de uma srie de servios, como os web services. Alm de mostrar as facilidades encontradas atualmente nas tecnologias Java, o trabalho possibilitou a prtica e demonstrao do reuso dos padres de projeto. Para isso, reutilizou os padres JEE em conjunto com o Adaptive Comunication Environment (ACE) que fornece um toolkit contendo uma srie de invlucros, categorias de classes e frameworks que ajudam na programao de servios que operam sob uma rede de computadores em diversos tipos de sistemas operacionais e o MVC (Model View Controller), que divide a aplicao em trs partes: o processamento, a sada e a entrada de dados atravs do modelo, controle e visualizao dos dados respectivamente. Tambm foram mostrados alguns padres Gof (Gamma et al 1995), que servem de base para a criao dos padres da arquitetura JEE (Malks et al, 2003), proporcionando mais um exemplo de reuso.

5. 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. Buschmann, F., Meunier, R., Rohnert, H., Sommerland, P., Stal, M.. (1996) PatternOriented Software Architecture Volume 1: A System of Patterns. Couloris, G., Dollimore, J., Kindberg, T.. (2005) "Distributed Systems concepts and Design". Addison Wesley, 4 Edio, ISBN 0321263545. Fowler, M. (1996) "Analysis Patterns: Reusable Object Models". Addison Wesley. ISBN 9780201895421. Gamma E., Helm R., Johnson R., Vlissides J. (1995) Design Patterns, Addison-Wesley, ISBN 0201633612. HSQLDB. (2008) HSQLDB Database, http://hsqldb.org/, Fevereiro. JBoss. (2008) JBoss Application http://labs.jboss.com/jbossas/downloads, Fevereiro. Server 4.0.5GA,

JBossWS. (2008) JBoss Web http://labs.jboss.com/jbossws/downloads, Fevereiro.

Service

1.0.3GA, Forum,

JBossForum. (2008) JBoss We Service http://www.jboss.org/?module=bb&op=viewtopic&t=103699, Fevereiro. JCP. (2008) Java Community Process, http://jcp.org/en/jsr/overview, Fevereiro.

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. Schmidt, D. C. (1993) The Adaptative Comunication Environment An Object-Oriented Network Programming Toolkit for Developing Comunication Software. http://www.cs.wustl.edu/~schmidt/ACE-papers.html Schmidt, D. C. (1999) Wrapper Faade: A Structural Pattern for Encapsulating Functions Within Classes. C++ Report Magazine, Fevereiro. Schmidt, D. C. (1997) Acceptor-Connector: An Object Creational Pattern for Connecting and Initializing Communication Services. http://www.cs.wustl.edu/~schmidt/ACEpapers.html 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 (2008). Java Technology. http://www.java.sun.com. Fevereiro.