• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio em arquitetura multicamadas
 

Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio em arquitetura multicamadas

on

  • 378 views

 

Statistics

Views

Total Views
378
Views on SlideShare
376
Embed Views
2

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio em arquitetura multicamadas Camada de Serviços: Uma abordagem alternativa de acesso a objetos de domínio em arquitetura multicamadas Document Transcript

    • Abel Gonçalves da Silva abelspquissa@hotmail.com Bruno Gomes Nascimento Arueira brunoarueira@hotmail.com Luciano da Silva Barreto lbarreto.pc@gmail.comCAMADA DE SERVIÇOS: UMA ABORDAGEM ALTERNATIVA DE ACESSO A OBJETOS DE DOMÍNIO EM ARQUITETURA MULTICAMADAS Universidade Candido Mendes – UCAM Campos dos Goytacazes – RJ
    • Abel Gonçalves da Silva Bruno Gomes Nascimento Arueira Luciano da Silva BarretoCAMADA DE SERVIÇOS: UMA ABORDAGEM ALTERNATIVA DE ACESSO A OBJETOS DE DOMÍNIO EM ARQUITETURA MULTICAMADAS Monografia apresentada à Universidade Candido Mendes – Campos dos Goytacazes como requisito parcial à obtenção do título de bacharel em Sistemas de Informação (Orientador) MSc. Mark Douglas de Azevedo Jacyntho CURSO SISTEMAS DE INFORMAÇÃO UNIVERSIDADE CANDIDO MENDES Campos 09, de janeiro de 2008 i
    • Abel Gonçalves da Silva Bruno Gomes Nascimento Arueira Luciano da Silva Barreto CAMADA DE SERVIÇOS: UMA ABORDAGEM ALTERNATIVA DE ACESSO A OBJETOS DE DOMÍNIO EM ARQUITETURA MULTICAMADASMonografia aprovada em ____/____/____ para obtenção do título de Bacharel emSistemas de Informação. Banca Examinadora: _______________________________________ Orientador: MSc. Mark Douglas de Azevedo Jacyntho Universidade Candido Mendes – Campos - RJ _______________________________________ DSc. Dalessandro Soares Viana Universidade Candido Mendes – Campos - RJ _______________________________________ DSc. Adriana Pereira de Medeiros Universidade Candido Mendes – Campos – RJ _______________________________________ Coordenador do Curso _______________________________________ Coordenador Geral de Graduação ii
    • DEDICATÓRIA Dedicamos este trabalho a Deus por ter nos proporcionado, antes de tudo, saúde, força de vontade e capacidade para chegarmos até este momento. As nossas famílias que nos apoiaram nessa longa caminhada. iii
    • AGRADECIMENTOS Agradeço a Deus por me dar sabedoria e forças para superar esse período degraduação, me oferecendo a oportunidade de fazer sempre o melhor para mim e minhafamília. À minha família Silvio, Salete e Matheus que sempre me passaram confiança eforças para lutar pelos meus objetivos. A todos meus parentes que me ajudaram emsuas orações. Aos meus amigos com tantas ajudas com apoios às vezes até maior doque a necessidade. À Prefeitura Municipal de Quissamã que me ajudou financeiramente possibilitandoa realização deste sonho. Ao nosso orientador professor Msc. Mark Douglas de Azevedo Jacyntho por todapaciência e sabedoria na conclusão de nosso projeto. À instituição Candido Mendes pela grandiosa estrutura oferecida para o melhor donosso ensino. Abel Gonçalves da Silva iv
    • AGRADECIMENTOS A Deus por tudo, em especial por mais uma graça alcançada. Aos meus pais, Eduardo e Jelma, por tudo que sempre fizeram e fazem por mim,além da minha família como um todo. Ao nosso orientador professor Msc. Mark Douglas de Azevedo Jacyntho pelosconselhos, pela paciência e pelos ensinamentos. Ao professor Antônio Carlos de Andrade Brito que me auxiliou - e muito - emvárias etapas do meu trajeto pela faculdade devido a um estágio que fui indicado porele. A todos os professores e funcionários da Universidade Candido Mendes –Campos/RJ que nos ajudaram ao longo do curso. A todos os amigos da UCAM, dos quais nunca me esquecerei e sou muitoagradecido. Bruno Gomes Nascimento Arueira v
    • AGRADECIMENTOS A Deus por tudo, em especial por mais uma graça alcançada. Aos meus pais, Renato e Zulmira, por tudo que sempre fizeram e fazem por mim. A Patrícia, minha noiva, pela paciência, compreensão e carinho. Ao nosso orientador professor Msc. Mark Douglas de Azevedo Jacyntho pelosconselhos, pela paciência e pelos ensinamentos. A todos os professores e funcionários da Universidade Candido Mendes –Campos/RJ que nos ajudaram ao longo do curso. A todos os amigos da UCAM, dos quais nunca me esquecerei e sou muitoagradecido. A todos os meus colegas de serviço, policiais civis ou não, pelo apoio durante estacaminhada. Luciano da Silva Barreto vi
    • “Saber e não fazer ainda é não saber.” (Lao Tse) vii
    • RESUMO A Internet, mais especificamente a World Wide Web, revolucionou a forma decomunicação no mundo. Rapidamente as aplicações web evoluíram de sites puramenteinformacionais e estáticos para sistemas de informação altamente transacionais ecomplexos voltados a realização de negócios. Neste cenário, ubiqüidade (apossibilidade de acessar a aplicação usando diferentes tipos de dispositivos e emcontextos distintos de uso) e interoperabilidade entre sistemas têm mostradopropriedades muito importantes no design das aplicações atuais. A partir desse intróito, este trabalho apresenta uma alternativa de comunicação,por meio da web, que ofereça portabilidade, segurança e eficiência em seu uso. Talcomunicação facilitaria a mobilidade dos usuários. Esta monografia inicia-se com o estudo da chamada Arquitetura de Serviços (eminglês, SOA - Service Oriented Architecture), seguido pela proposição de uma camadade serviços e, por fim, um protótipo de um sistema para uma livraria, a fim de atestar oque foi discutido.Palavras-chave: SOA, serviços, web services, Java EE, Java ME viii
    • ABSTRACT The Internet, more specifically the World Wide Web, has revolutionized thecommunication way in our world. Quickly the web applications have evolved from purelyinformational and static web sites to highly complex transactional information systemsfocused in conducting business. In this scenario, ubiquity (the possibility to access theapplication using different types of devices in different contexts of use) andinteroperability between systems have been important properties to be considered in thedesign of applications today. In this way, this work presents to provide an alternative to communicate throughthe web which offers portability, security and efficiency in its use. This communicationwould facilitate the mobility of users. This dissertation begins with the study of the so-called Service OrientedArchitecture (SOA), followed by the proposal of a service layer and, finally, a prototypeof a bookstore system, in order to certify what was discussed.Keywords: SOA, services, web services, Java EE, Java ME ix
    • LISTA DE SIGLAS1. API (Application Programming Interface)2. DTO (Data Transfer Object)3. EJB (Enterprise Java Beans)4. HTML (HyperText Markup Language)5. Java EE (Java Enterprise Edition)6. Java ME (Java Micro Edition)7. Java SE (Java Standard Edition)8. JCP (Java Comunity Process)9. JSP (JavaServer Pages)10. JSR (Java Specification Request)11. JTWI (Java Technology for the Wireless Industry)12. JVM (Java Virtual Machine)13. JWS (Java Web Service)14. JWT (Java Wireless Toolkit)15. MSA (Mobile Service Architecture)16. RPC (Remote Procedure Call)17. SOA (Service Oriented Architecture)18. SOAP (Simple Object Access Protocol)19. UDDI (Universal Description Discovery and Integration)20. UML (Unified Modeling Language)21. URL (Uniform Resource Locator)22. XML (extensible Markup Language)23. WSDD (Web Service Deployment Description)24. WSDL (Web Services Description Language) x
    • LISTA DE FIGURASFigura 2.1 Atores, objetos e operações de web services 10Figura 2.2 Exemplo de XML 10Figura 2.3 Estrutura da mensagem SOAP 12Figura 2.4 Requisição SOAP 13Figura 2.5 Resposta SOAP 13Figura 3.1 Estrutura de um Facade 19Figura 3.2 Organização da camada de serviços e as formas de acesso a esta 20Figura 4.1 Representando a plataforma padrão Java (baseado na plataforma 25 Java 2)Figura 4.2 Figura mostrando o funcionamento do framework Axis 28Figura 5.1 Diagramas de caso de uso do projeto 34Figura 5.2 Diagrama de caso de uso para efetuar pedido 34Figura 5.3 Diagrama de caso de uso de catálogo 35Figura 5.4 Representa o diagrama de domínio 37Figura 5.5 Representa o diagrama de design de domínio 39Figura 5.6 Apresenta o diagrama de finders 41Figura 5.7 Alude a implementação da transferência dos dados no sistema 42Figura 5.8 Ilustra a implementação da camada de banco de dados 44Figura 5.9 Demonstra a implementação da camada de serviços 46Figura 5.10 Apresenta a dinâmica do serviço de catálogo de livros 48Figura 5.11 Busca pelo Código 50Figura 5.12 Busca pelo ISBN 52Figura 5.13 Busca pelo Gênero 54Figura 5.14 Busca pelo Nome 56Figura 5.15 Revela o diagrama de seqüência de efetuar pedido 57Figura 5.16 Conectando o cliente ao servidor para utilizar os serviços 59Figura 5.17 Cria os pedidos na camada de domínio de cliente 60Figura 5.18 Formatação de chamada e resposta do servidor no padrão DTO 61Figura 5.19 Diagrama de classe relacionado às telas para interação com o 62 sistema xi
    • Figura 5.20 Tela inicial do protótipo 63Figura 5.21 Tele inicial de catálogo 64Figura 5.22 Tela com formulário para ver detalhes ou fechar o pedido 65Figura 5.23 Tela para efetuar o pedido 66Figura 5.24 Tela para efetuar uma busca 67 xii
    • SUMÁRIO1. Introdução.......................................................................................................... 12. Service Oriented Architecture SOA)…………………………………………….. 5 2.1 Serviços..................................................................................................... 5 2.2 Vantagens e Desvantagens………………………………………………….. 7 2.3 Web Services………………………………………………………………….. 8 2.3.1 eXtensible Markup Language (XML)…………………………………… 10 2.3.2 Simple Object Access Protocol (SOAP)……………………………….. 11 2.3.3 Web Services Description Language (WSDL)………………………... 14 2.3.4 Universal Description, Discovery and Integration (UDDI)…………… 15 2.4 Considerações finais................................................................................. 163. Proposta do projeto......................................................................................... 17 3.1 Design Pattern........................................................................................... 17 3.2 Facade....................................................................................................... 18 3.3 Service Layer............................................................................................. 19 3.4 Paralelo entre Facade e Service Layer..................................................... 224. Tecnologias e ferramentas do projeto........................................................... 23 4.1 Java............................................................................................................ 23 4.2 Apache Tomcat.......................................................................................... 26 4.3 Framework Apache Axis............................................................................. 26 4.4 Wireless Tool Kit (JWT).............................................................................. 28 4.5 Jude UML.................................................................................................... 29 4.5.1 UML (Unified Modeling Language)...................................................... 29 4.5.2 JUDE (JAVA AND UML DEVELOPERS ENVIRONMENT)................. 29 4.6. Eclipse........................................................................................................ 30 4.6.1 CALLISTO RELEASE........................................................................... 30 4.6.2 EclipseME............................................................................................. 315. Protótipo............................................................................................................ 32 5.1 Estudo de caso............................................................................................ 32 5.2 Aplicação contida no servidor...................................................................... 33 5.2.1 Diagramas de caso de uso.................................................................... 33 xiii
    • 5.2.2 Diagrama de análise de domínio........................................................... 37 5.2.3 Diagrama de design da camada de domínio........................................ 39 5.2.4 Diagrama de design de finders na camada de domínio....................... 41 5.2.5 Diagrama de design Data Transfer Object (DTO)................................ 42 5.2.6 Diagrama de design da camada de persistência.................................. 44 5.2.7 Diagrama de design da camada de serviços........................................ 46 5.2.8 Diagrama de seqüência do caso de uso catálogo................................ 48 5.2.8.1 Busca pelo Código......................................................................... 50 5.2.8.2 Busca pelo ISBN............................................................................ 52 5.2.8.3 Busca pelo Gênero........................................................................ 54 5.2.8.4 Busca pelo Nome.......................................................................... 56 5.2.9 Diagrama de seqüência do caso de uso efetuar pedido...................... 57 5.3 Aplicação cliente (dispositivo portátil).......................................................... 59 5.3.1 Diagrama de design do pacote de conector de serviços...................... 59 5.3.2 Diagrama de design do pacote de domínio........................................... 60 5.3.3 Diagrama de design do pacote de domínio de DTOs............................ 61 5.3.4 Diagrama de design do pacote de visão............................................... 626 . Conclusão.......................................................................................................... 68 6.1 Trabalhos Relacionados............................................................................... 69 6.2 Trabalhos Futuros......................................................................................... 70Referências............................................................................................................. 72APÊNDICE A........................................................................................................... 76 xiv
    • 1. Introdução Com o advento da comunicação entre os computadores e a crescentenecessidade de interoperabilidade entre as aplicações computacionais, váriasalternativas vêm sendo criadas para tal propósito, tendo em mente a facilidadede reuso e a manutenibilidade. Dentre estas várias propostas, uma delas édenominada Service Oriented Architecture (SOA) [OASIS Consortium] que vemapresentando destaque. Esta arquitetura apresenta muitas tecnologias para asua implementação. Este trabalho se baseia em web services que seenquadram em uma dessas tecnologias para desenvolvimento de um projetoSOA. Assim como em outras áreas da computação, a arquitetura em camadastem presença marcante no desenvolvimento de software. Nesta arquitetura,cada camada possui uma responsabilidade e provê serviços para as camadassuperiores. Assim, primeiramente foi desenvolvida uma estrutura baseada emduas camadas, comumente conhecida como cliente-servidor. Esta estrutura tinha basicamente, no cliente, a aplicação com toda lógicade negócio, interação entre requisitos de aplicação e de negócio embutidos queacessavam por sua vez um servidor o qual apresentava apenas uma fonte dedados onde eram concentrados todos os dados. Esse formato de camadas ainda é muito utilizado, porém há um grandeproblema nesta abordagem. Se um dado é alterado no servidor, todas asaplicações que dependem deste devem ser alteradas, pois a estrutura internada aplicação cliente terá que trabalhar com esse novo tipo de dadoocasionando uma varredura interna da aplicação para alteração tanto do dadoquanto da forma de utilizá-lo. Além disso, deve ser feita uma nova distribuição(reinstalação) da aplicação para as variadas estações onde estava sendoutilizada. Isto caracteriza um acoplamento forte. Um exemplo bem clássico deste acoplamento forte são os sistemasantigos ou legados de uma empresa, feitos num único processo dedesenvolvimento, que não oferecem facilidade para incluir novas aplicações emconsonância com as rápidas mudanças do negócio. Isto retrata significantecontraste com as modernas técnicas de desenvolvimento de software. Adinâmica para criar novas aplicações e cooptá-las num mesmo sistema 1
    • fazendo com que todas, as existentes e as recentes, funcionem em perfeitaharmonia é o melhor caminho a seguir. E isso tange outro caminho que não oda arquitetura em duas camadas. Diante desta problemática, fora proposto um novo estilo arquitetural desoftware em três camadas. Este novo modelo de aplicação solucionou oproblema do formato anterior, passando a apresentar uma camada orientada àfonte de dados (antes concentrada no servidor como uma fonte de dadoscomum), uma camada intermediária direcionada a toda a lógica de negócio dedomínio (com intuito de concentrar todas as possíveis interações necessáriasao negócio) e outra camada onde residem as inúmeras aplicações queacessam os serviços comuns oferecidos pelos objetos de domínio. Estas três camadas são de caráter principal, ou seja, podem variar emmais algumas camadas, contudo as possíveis variações não perdem aresponsabilidade nestas principais camadas. Para facilitar a reutilização e manutenção que se espera de uma aplicaçãodesenvolvida em três camadas, uma destas camadas (a camada de domínio) éconcentrada em um servidor de aplicação onde todas as aplicações clientesacessam. Portanto, a lógica de negócio fica concentrada em um único lugar.Os objetos da camada de domínio encapsulam o acesso aos dados, provendotodo o comportamento (serviços) de domínio e isolando as várias aplicações depossíveis efeitos colaterais resultantes de mudanças na estrutura dos dados.Caso haja mudanças nos dados, apenas os objetos de domínio serão afetados.Porém nada impede que haja um mau uso desta arrumação, pois apesar de aaplicação estar bem divida em suas respectivas camadas, a camada dedomínio deve ter uma atenção especial. Esta atenção deve-se ao fato de que uma camada de domínio bemorganizada, ou seja, bem modelada sugere um acoplamento fraco entrequaisquer partes da aplicação, devido ao fato dos relacionamentos serem feitosconhecendo-se conceitos/abstrações, onde uma mudança qualquer em algoconcreto não interfere no resto da aplicação, além de tornar maiscompreensível à criação das outras camadas. Então, sugere-se ao desenvolver um sistema computacional com ascaracterísticas elencadas acima, que modele com muito cuidado a lógica dedomínio para que uma aplicação apresente acoplamento fraco. Onde, por 2
    • exemplo, o cliente que requisita o pedido de um produto conhece, na verdade,uma idéia abstrata deste produto. Se por algum motivo o negócio da empresasofrer mudanças no que tange os tipos de produtos que a empresa possui ou àforma de iniciar uma negociação, o desenvolvedor poderá adaptar a mudançano sistema com algumas poucas alterações no código e/ou inclusão dealgumas aplicações. Neste contexto, o engenheiro de software desenvolverá componentes ouaplicações que representarão serviços. O âmago de cada serviço será umafunção que retratará alguma parte da lógica de negócio da empresa. Essesserviços serão reutilizados em várias outras aplicações. No entanto, não sedevem banalizar os serviços com meras funcionalidades que nada têm a vercom a lógica do domínio em si. Um serviço não é uma função onde um vetor denomes é organizado em ordem alfabética. Mas sim uma função que representeuma parte importante do negócio, como por exemplo, o cadastro de clientes nosistema. O serviço de cadastro, se mantidas suas entradas e saídas o maisgenérico possível, será, com certeza, reutilizado para cadastros de outrosdados na aplicação. A reutilização dos serviços que já existem na própria organização ou noexterior resultará na redução significativa do esforço de desenvolvimento deaplicações e, portanto, dos custos. Os benefícios de reutilização crescemdramaticamente à medida que mais serviços são construídos e incorporadosnas diferentes aplicações. O objetivo deste trabalho é justamente a criação de uma camada deserviços (Service Layer) [Fowler et al, 2002] sobre a camada de domínio,provendo uma forma alternativa para aplicações acessarem os objetos dedomínio. Para a implementação desta camada foi escolhida a tecnologia deweb services. Sem esta camada de serviços a única forma das aplicaçõesacessarem a camada de domínio é o approach tradicional de orientação aobjetos por meio de chamadas de operações em objetos. Já com esta camadaa flexibilidade de acesso torna-se maior, usando protocolos baseado emExtensible Markup Language (XML) [WWW Consortium, 2007], diminuindoainda mais o acoplamento e facilitando a interoperabilidade. 3
    • Organização da Monografia A seguir será apresentada uma pequena descrição a respeito do que setrata cada capítulo que esta monografia é composta. O segundo capítulo trata da tecnologia SOA. A arquitetura abrangeconceitos de extrema importância e grande utilidade. Um destes conceitos é oserviço. O terceiro capítulo aborda a proposta de utilizar Facades [Gamma et al,2000] sobre a camada de domínio, visando estabelecer uma Service Layerutilizada pela tecnologia SOA. Será exposto, de forma detalhada, o conteúdodo projeto. O quarto capítulo versa sobre as tecnologias envolvidas nesse protótipo. No quinto capítulo é mostrado um exemplo prático que demonstre aproposta a qual este estudo se destina a apresentar, desde SOA (passando porserviços, web services e outras características da arquitetura) até o assuntoretratado no terceiro capítulo. Por último, no sexto capítulo provê as considerações finais, mostrandoalguns trabalhos relacionados e futuros. 4
    • 2. Service Oriented Architecture (SOA) A Arquitetura Orientada a Serviços não é um conceito novo. Nadécada de noventa a empresa SUN definiu SOA para descrever a tecnologiaJini [Conexão Jini], que é um ambiente para descoberta dinâmica e o uso deserviços sobre uma rede. Ou seja, uma tecnologia para facilitar a manutençãode redes onde existam competências e necessidades. SOA está emergindo como a primeira integração e framework dearquitetura no ambiente de computação complexa e heterogênea dos diasatuais. Tentativas anteriores não apresentaram soluções de interoperabilidadeabertas, pois confiaram em Application Programming Interface (API), que é umconjunto de rotinas e padrões estabelecidos por um software para utilização desuas funcionalidades proprietárias. Tendo exigido, assim, um alto grau decoordenação entre os grupos. Essa tecnologia terá um papel decisivo nas organizaçõesempresariais viabilizando a execução de processos de forma que possamnegociar de maneira mais eficaz, e adaptarem-se às necessidades variáveis ecompetitivas do mercado, desde que o software seja baseado no conceito decomponentes. SOA desencadeia o acoplamento fraco entre estescomponentes a fim de que os mesmos possam ser reutilizados. E estareutilização é um marco muito importante na velocidade do desenvolvimento desistemas, pois viabiliza a facilidade de se desenvolver aplicações maisrapidamente. Outra característica importante da Arquitetura Orientada aServiços é o alto nível de flexibilidade fornecido às aplicações, permitindo maiorinteroperabilidade entre as aplicações heterogêneas. Estes componentes desoftware são denominados serviços. O serviço é o cerne da SOA.2.1 Serviços No mundo real, existem capacidades e necessidades. Isto significa,por exemplo, que alguém tem a capacidade de pintar um automóvel (serviço) ealguém têm a necessidade de que este automóvel seja pintado (consumidor).Este é um exemplo prático para ilustrar o conceito de serviço. 5
    • O serviço é uma funcionalidade, mais ampla, pertinente à lógica donegócio. Ou seja, um componente de software, com interface bem definida(como chegar à oficina de pintura para pintar o automóvel) e implementaçãoindependente de outros serviços (o serviço de pintura do veículo éindependente de um serviço mecânico, por exemplo), que representa umafunção do sistema computacional (a pintura seria uma parte do sistema derecuperação do veículo). Este componente deve ser stateless, isto é, nãodepender de nenhuma condição pré-existente, seja do cliente ou de outrosserviços. Tais serviços serão consumidos por clientes ou por outros serviços (oserviço de pintura primeiramente faz uso do serviço de lanternagem do auto). Atecnologia utilizada para prover o serviço, tal como numa linguagem deprogramação, não pode fazer parte de sua definição. Um serviço é disponibilizado por um provedor de serviços, entretantoos clientes podem não saber da existência do serviço. A implementação de umserviço, que é acessada por uma interface de serviço, é oculta ao consumidor,salvo quando a própria interface expõe os modelos de informação e oscomportamentos deste e/ou as informações solicitadas tencionam identificarquando um serviço é apropriado para o cliente. Para um consumidor (cliente) solicitar um serviço a um provedor deserviços é necessário que os dois extremos se enxerguem. Na tecnologia SOA,essa visibilidade tem que ser enfatizada, pois não é axiomático que ospartícipes possam ver uns aos outros. Estes precisam conhecer o requisitantee vice-versa, a fim de poderem apontar qual serviço desejam usar e receber aresposta do serviço requisitado. O provedor e o consumidor têm que possuir a informação sobre aexistência do outro. Logicamente, o iniciante deve ter conhecimento de quemresponderá. Uma iniciação bem sucedida é, muitas vezes, satisfatória parainformar a quem vai responder a existência de quem iniciou. A consciência daexistência de um serviço necessita de uma descrição deste. O mais tradicionalé que um provedor de serviços publique em um diretório próprio a descrição detodos os serviços disponíveis. Em contrapartida, um consumidor pode difundira necessidade de um serviço com intuito de ser respondido pelo serviço maisapropriado ou percorrer o diretório onde estão publicados os serviços. Assimsendo, o consumidor precisa conhecer as descrições dos serviços para avaliar 6
    • quando um destes é pertinente à sua necessidade. Seja por parte do provedor,publicando as descrições, ou por parte do consumidor requisitando asdescrições existentes. A descrição do serviço é a informação necessária para usá-lo. Seriauma espécie de manual. O propósito da descrição é facilitar a visibilidade (fazercom que o consumidor e o provedor de serviços vejam-se) e a interação(comunicação entre o provedor e o consumidor), particularmente quando osparticipantes estão em domínios proprietários diferentes. É possível, também, distinguir entre os participantes para a interaçãodo serviço, saber como acessá-lo e negociar sobre as funcionalidadesespecíficas deste. A descrição deve ser representada de forma padrão. Oconceito de SOA admite a utilização de um serviço sem que o consumidortenha conhecimento de como o mesmo foi implementado. A descrição tornadisponíveis informações cruciais para o consumidor decidir pelo uso ou não doserviço. Um consumidor de serviços necessita saber que o serviço existe eestá disponível, que executa alguma função ou um conjunto delas, que trabalhaà sombra de um conjunto de restrições e políticas para concordar com aspolíticas como relatadas pelo próprio consumidor e, por último, deve sabercomo interagir com o serviço a fim de alcançar os objetivos, incluindo o formatoe conteúdo da informação trocada entre o serviço e o consumidor e asseqüências que podem ser esperadas. A ação mútua entre o serviço e o consumidor pode depender depolíticas documentadas na descrição do primeiro. A concordância por parte doprovedor e do consumidor para interagir não significa que há aprovação paraexecutar as ações requisitadas. Mesmo refutando a execução de alguma ação,o provedor de serviços pode estar apto a novas interações com o consumidorde serviços.2.2 Vantagens e Desvantagens Uma das grandes vantagens desta arquitetura é a possibilidade deolhar as aplicações sob o enfoque de processos de negócio, adequando-as aosdiversos contextos corporativos. Desta forma, passa-se a entregar o conteúdo 7
    • de negócios de uma maneira completamente diferente do paradigmatradicional. Esses processos de negócios nada mais são do que os serviços. Oserviço promove reuso de partes da aplicação e isso promove flagrantediminuição de esforço no desenvolvimento de sistemas, diminuindodrasticamente o tempo de criação e expansão destes e extremo declínio doscustos. Tudo o que uma empresa necessita. Outra relevância da SOA é sua interoperabilidade entre todas astecnologias do mercado. Isso significa dizer que os usuários não precisarão sepreocupar com o uso de várias tecnologias distintas. Ou seja, utilização dediferentes plataformas numa mesma aplicação. O acoplamento fraco é outro benefício da Arquitetura Orientada aServiços, pois trabalha com contratos. Clientes conhecem abstrações de algo enão a representação real deste algo. Isso beneficia possíveis mudanças. Uma desvantagem de SOA é que não é fácil reconhecer um serviço.Isso é devido ao fato de que ele apresenta concordância com osrelacionamentos da lógica de negócio, refletindo-os com extrema nitidez. É fácilconfundir serviços com questões de implementação, como por exemplo:manipulação de um simples array ou operação de busca em uma fonte dedados e não é bem assim, haja vista toda a discussão sobre serviçosanteriormente. Outro detalhe negativo é que os sistemas existentes ou legados, nãopodem ser mudados de um dia para o outro. Afinal, são aplicações ativas eisso acarretaria erros em efeito cascata para todo o sistema. É preciso analisarcada sistema legado em separado e o processo de negócio que elesrepresentam. Resumindo, os serviços devem ser coesos, ou seja, bem definidosproporcionando clareza na sua criação e também devem ser o mais fracamenteacoplados possível.2.3 Web Services Um processo de negócio bem definido e de clara importância para astransações da empresa tornar-se-á um serviço, no tocante à implementação do 8
    • software. Este serviço que pode ser acessado pela Web (seja internet, extranetou intranet) constitui um web service. Os padrões que constituem a proposta deweb services são resultados de contribuições submetidas por empresas (IBM,Microsoft, etc) e colaboradores a consórcios como a W3C [WWW Consortium,2007] e OASIS [OASIS Consortium, 2007]. Antes dos web services as empresas criavam bibliotecas edistribuíam para cada aplicação que necessitasse utilizar o sistema. O caossurgia quando havia alguma alteração nas bibliotecas. A empresa, então, teriaque redistribuir os arquivos para todos os usuários de seu sistema. Com ainstituição do web service os usuários do sistema que “buscavam” os dadospertinentes ao negócio que pretendiam realizar acessavam os serviçosdisponibilizados na web e usufruíam de suas funcionalidades. Outra vantagemimportante é que essa busca independe da tecnologia usada no consumidor eno provedor de serviço. Um web service é um componente, ou unidade lógica de aplicação,acessível através de protocolos padrões da Internet. Como componentes,esses serviços possuem uma funcionalidade que pode ser reutilizada sem apreocupação de como é implementada. Há uma chamada de um cliente a umweb service e, por conseguinte, há uma resposta. No entanto, há que se ter em mente alguns detalhes quanto aodesenvolvimento de um web service e de sua utilização baseada em serviços.É preciso: uma forma comum de representar os dados; uma formatação demensagem comum e extensível; um padrão da descrição do serviço comum eextensível; um mecanismo para encontrar os provedores de serviços. Então, observa-se que web services representam uma novaideologia para aplicações distribuídas e se constituem de três partes básicas,conforme ilustra a figura 2.1: • Service directory: responsável por armazenar descrições de serviços que serão potencialmente utilizados por um requisitante; • Service requester: consumidor requisitante em potencial de um serviço; • Service provider: provedor de serviços que publica seus serviços no service directory para que estes sejam localizados pelo requisitante. 9
    • Figura 2.1 - Atores, objetos e operações de web services [CJ-Luca, 2006].2.3.1 eXtensible Markup Language (XML) O XML é uma linguagem cuja sintaxe é semelhante ao HTML [W3C-HTML, 2007], só que este último é utilizado somente na formatação de páginasutilizadas via browser através de tags já definidas, ao contrário do XML com oqual pode se definir novas tags para serem utilizados para o devido fim. Com isso o padrão adotado na representação dos dados é alinguagem XML que é definida como o formato universal para dadosestruturados na web. Com XML é possível: descrever dados (1); apresentardados em algum formato (2); transportar dados (3); e trocar dados entreplataformas diferentes (4). Abaixo segue um exemplo de XML representando informações deum livro na figura 2.2. <livro> <nome>O Apanhador de Sonhos</nome> <autor>Stephen King</autor> <isbn>85-7302-418-6</isbn> <preco>50,00</preco> </livro> Figura 2.2 - Exemplo de XML. 10
    • Não é surpresa o grande número de tecnologias atualmente que sebaseiam na utilização do XML. Assim, para um consumidor (cliente do web service) que estejafuncionando com a tecnologia .NET [.NET Framework, 2007] e quer acessarum Web Service (provedor de serviços) que foi implementado em Java EE[Enterprise Edition, 2007], não haverá problema, pois as duas tecnologiasconhecem XML, que será “traduzido” de uma plataforma para outra.2.3.2 Simple Object Access Protocol (SOAP) A formatação de mensagem comum e extensível ficará por conta doSimple Object Access Protocol (SOAP) [W3C-SOAP, 2007] que é um protocolosimples para a troca de informações entre aplicações e tem por finalidadeinvocar aplicações remotas através de Chamadas Remotas de Procedimento -Remote Procedure Calls (RPC) ou trocar mensagens independentes dasplataformas do requisitante e do respondente. Portanto, SOAP é um padrão já aceito para ser utilizado em webservices e visa garantir total interoperabilidade entre diferentes aplicações,utilizando XML. 11
    • Estrutura da mensagem SOAP Figura 2.3 - Estrutura da mensagem SOAP [SAAJ, 2007].As partes constituintes da mensagem SOAP são (vide figura 2.3):• Envelope: define o documento XML como uma mensagem SOAP. Para esta definição ele torna-se obrigatório na escrita do XML, isto é: deve ser todo estrutrurado em XML;• Header (Cabeçalho, opcional): define formas de autenticação, encriptação e outros detalhes que compõe a mensagem especifica;• Body (Corpo): detém o conteúdo da mensagem, seja para fazer requisição, resposta ou até mesmo uma exceção (fault);• Attachments (Anexos, opcionais): a mensagem pode conter anexos; 12
    • Na figura 2.4 se apresenta um modelo de uma requisição SOAP e logoem seguida (na figura 2.5) uma resposta SOAP. Figura 2.4 - Requisição SOAP. Figura 2.5 - Resposta SOAP. Observando-se estas mensagens pode se notar que é composto peloenvelope, indispensável para se definir uma mensagem SOAP como citadoanteriormente, e body, outra parte também indispensável, onde na primeiramensagem (requisição) o body contém uma chamada de um serviço com umapassagem de um parâmetro e na segunda mensagem (resposta) o serviçorespondendo a sua chamada. 13
    • A troca de mensagens SOAP pode ser feita de duas maneiras, sãoelas: One Way e Request/Response. No modo one way a comunicação éassíncrona, ou seja, é enviada uma mensagem ao receptor e não se esperaum retorno. Ao contrário do modo request/response que é síncrono, onde éenviada uma mensagem de request (requisição) e espera-se uma mensagemde response (resposta). Estas duas abordagens são padrões para troca demensagens e são muito utilizadas em web services.2.3.3 Web Services Description Language (WSDL) A descrição do serviço comum e extensível cabe aos Web ServicesDescription Language (WSDL) [W3C-WSDL, 2007] que é uma linguagem quedescreve os serviços disponibilizados à rede. A WSDL além de ser utilizada para descrição dos serviços, tambémé utilizada para a localização dos web services e estabelece um contrato entrecliente (potencial consumidor do serviço) e o provedor de serviços, utilizandoXML em um esquema próprio. Estes descritores são processados por ferramentas computacionaisde forma automática, então não há necessidade de escrita ou leitura de formamanual. O WSDL é dividido em dois grupos de definições: definição abstratae definição concreta. • Definição abstrata types: descreve todos os tipos de dados não comuns (aqueles que não estão definidos pelo W3C XML Schema) que trafegaram nas mensagens. Se os dados que forem utilizados estiverem em concordância com o W3C não há necessidade de ser fornecido na descrição; message: descreve os tipos de mensagem em formato one way, se é requisição ou resposta, além de tipos de retorno das respostas e parâmetros a serem fornecidos nas requisições; port: descreve o conjunto de operações que podem ser feitas em uma ou mais portas e as respectivas mensagens envolvidas 14
    • • Definição concreta bindings: faz o mapeamento da implementação com a interface descrita e define também o tipo de codificação (rpc ou document); service: define um endereço internet para um binding específico, ou seja, contém uma URL para invocar um serviço SOAP.2.3.4 Universal Description, Discovery and Integration (UDDI) Tudo isso não tem sentido se o consumidor não souber onde está oserviço, a fim de usufruir sua funcionalidade. Para tanto, o UniversalDescription, Discovery, and Integration (UDDI) [OASIS-UDDI, 2007], que é umaespecificação técnica, tem o objetivo de descobrir e integrar os serviços. Uma comparação que se é feita ao UDDI é o fato de se assemelhar auma lista telefônica, onde ao se pesquisar um registro UDDI pode se encontrarempresas/organizações e seus respectivos web services. Um diretório UDDI pode ser acessado através de SOAP tornando-otambém um web service, que apresentam operações como adicionar, atualizar,apagar e buscar informações dentro dos registros. Abaixo alguns problemas que podem ser resolvidos com estaespecificação: • Facilitar a descoberta da organização correta entre as várias existentes; • Demonstrar como trocar mensagens entre as partes já que encontrou-se a organização esperada; • Encontrar e facilitar o acesso a novos clientes; • Aumentar o mercado da organização; • Derrubar barreiras para acessar a economia globalizada pela Internet; 15
    • • Auxiliar a descrição de serviços e business process (processos de negócio) de forma segura.2.4 Considerações finais Muitas empresas temiam prover funcionalidades na Internet. Ataquesà estrutura virtual dessas corporações derivavam de exposições de seus dadose aplicações. Com web service, publica-se serviços de forma simples, que sãototalmente desconectados dos objetos de dados e só enviam a respostanecessária ao consumidor do serviço. Isso elimina a necessidade de exportabelas de dados completas, sendo assim um modo mais seguro de atuação. Algumas desvantagens dos web services são que o uso demensagens em XML implica em um desempenho inferior. E as implementaçõesem SOAP, ainda, não estão cem por cento compatíveis com todas astecnologias. 16
    • 3. Proposta do projeto Este capítulo estabelece o propósito deste trabalho. Inicialmente éapresentada uma breve introdução sobre padrões de projeto (em inglês, designpatterns). A seguir são abordados os dois padrões que servem como base paraa idéia proposta: Facade [Gamma et al, 2000] e Service Layer [Fowler et al,2002]. Por fim, é definida a proposta do trabalho propriamente dita, mostrandoo inter-relacionamento dos dois padrões em sua concepção.3.1. Design Pattern Padrões de projeto surgiram da idéia de que o desenvolvimento deum projeto de software orientado a objetos é difícil, porém um projeto que sejareutilizável e flexível é mais complexo ainda, pois dentro de um projeto deve-seencontrar partes que são comuns a todos e então defini-las no nível correto degranularidade para que estas facilitem a reutilização. Alguns projetistas começaram a perceber que certas definições eplanejamentos de um projeto poderiam ser reutilizados em outros projetos,levando em consideração algumas alterações pertinentes ao projeto emquestão. Nesse âmbito, surgem os padrões de projeto, que são soluçõesreutilizáveis para projetos de software, em especial, orientado a objetos. A idéia original de reuso de padrões surgiu no campo da construçãocivil, descrita em [Alexander et al, 1977], onde Christopher Alexander dizia: “Cada padrão descreve um problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa usar essa solução mais de um milhão de vezes, sem nunca fazê-la da mesma forma” Com isso quatro autores, sendo eles Erich Gamma, Richard Helm,Ralph Johnson e John Vlissides, resolveram reunir várias soluções reutilizáveisde software orientado a objetos em um livro para expor suas experiências atodos, definindo, na verdade, um catálogo de padrões de projeto.Posteriormente, estes autores também passaram a ser conhecidos pelo termoGang of Four (GoF), ou seja, gangue dos quatro. 17
    • De acordo com a Gof, existem dois tipos de classificação dospadrões, a saber: a primeira em relação ao propósito (o que o padrão faz) e asegunda especifica o escopo (onde é aplicado). Com relação ao propósito, têm-se os padrões de criação, osestruturais e os comportamentais. E se tratando do escopo podem serseparados em nível de Classe ou Objeto (onde classe significa uso de herançae objeto implica no uso de composição e/ou agregação). Os padrões de criação definem como é feita a criação/instanciaçãode objetos concentrando esta responsabilidade em um único lugar e de formaabstrata. Os padrões estruturais são voltados para a forma como classes eobjetos se inter-relacionam para compor estruturas maiores. E por último, temos os padrões comportamentais que têm acaracterística de atribuir inteligentemente responsabilidades a objetos e definira colaboração entre eles, determinando assim seus comportamentos. Mas além da classificação citada anteriormente, há umadesenvolvida por Steven John Metsker [Metsker, 2004], que organiza ospadrões por sua intenção: interface, responsabilidade, construção, operações eextensão.3.2. Facade Facade é um padrão de projeto classificado por GoF como estruturalde objetos e por John Metsker como interface. Este padrão tem o propósito deencapsular subsistemas e/ou esconder determinadas funcionalidades para ascamadas superiores, com a finalidade de coibir o acesso a classes específicasdo sistema dando mais segurança ao mesmo ou facilitando o uso de processosde negócio complexos. Este padrão, no que diz respeito ao encapsulamento de subsistemas,objetiva facilitar o uso do subsistema. A idéia é definir uma interface maissimples, de granularidade mais grossa, que esconde os detalhes internos dosubsistema. Um subsistema, por definição, tem vários relacionamentos entreclasses que colaboram entre si e cada classe desempenha um papel único.Portanto o acesso direto a este subsistema seria bem complexo devido a 18
    • grande quantidade de componentes de granularidade fina (vide figura 3.1).Com isso alguém que dependesse da utilização do subsistema, caso nãohouvesse um Facade, teria que conhecer todo o corpo interno do mesmo,aumentando a complexidade de uso e quebra do encapsulamento, pois ousuário dependeria diretamente da estrutura interna e poderia facilmente seratingindo por alterações ou evoluções dos componentes do subsistema. Figura 3.1. Estrutura que representa um Facade [Gamma et al, 2000]. Para se modelar adequadamente um Facade em um sistema não sedeve apenas pensar em atender as funcionalidades que ele deve facilitar oacesso, deve-se também analisar as possíveis saídas das solicitações sendo oideal colocar os tipos mais primitivos ou comuns possíveis.3.3. Service Layer Segundo Randy Stafford [Fowler et al, 2002], service layer define afronteira da aplicação com uma camada de serviços que estabelece umconjunto de operações e coordenam, em cada operação, as respostas daaplicação. Na figura 3.2 pode-se observar onde a Service Layer se localiza emrelação às outras camadas. 19
    • Figura 3.2 - Organização da camada de serviços e as formas de acesso a esta [Fowler et al, 2002]. Normalmente, aplicações empresariais têm várias formas de acessoà lógica de negócio, desde consultas de dados até formas de comunicaçãoentre sistemas heterogêneos. O acesso à lógica de negócio pode ser bastantecomplexo, envolvendo transações e coordenação de vários objetos notratamento de uma requisição. Para cada interação que se faz, criar umainterface provoca inúmeras duplicações de etapas que são comuns a muitasoperações. Pode-se dizer que service layer define uma interface para camadasclientes, encapsulando a lógica de negócio da aplicação, controlandotransações e coordenando responsabilidades em suas respectivasimplementações. 20
    • Existem designers, que diferenciam a lógica de negócio em doistipos. O primeiro seria a representação da lógica de domínio, que representa aessência do problema que o sistema tende a resolver e o segundo seria alógica de aplicação que apresenta um design voltado a atender asresponsabilidades de uma aplicação específica. Basicamente, há duas formas de implementar esta camada: facadesde domínio e script de operações (aqui também chamados de facades deaplicação). Os facades de domínio não implementam nenhuma lógica denegócio, sendo em geral stateless, ou seja, não guardam estado internonenhum e, por sua vez, todas as requisições feitas a eles são repassadas aobjetos de domínio pertinentes. Já os facades de script (ou aplicação)implementam a lógica específica de aplicação, delegando para objetos dedomínio encapsulados, responsabilidade comum ao domínio e independentede aplicação particular. Outro aspecto muito importante a ser considerado é a decisão defazer esta camada distribuída ou local, ou seja, se a service layer irá atendersomente a estrutura interna de uma aplicação fazendo interface de operaçõesentre camadas ou será disponibilizado para atender chamadas remotas. A respeito disso, tem-se que analisar o aspecto do uso da aplicação,pois transportar um objeto do domain model é algo realmente custoso devido ainúmeros relacionamentos que este pode ter. Uma alternativa para utilizaçãodistribuída seria a adoção de Data Transfer Objects (DTOs) [Fowler et al, 2002](em português, Objetos de Transferência de Dados) que visa diminuir aquantidade de informação dos objetos a ser transferida remotamente entrecamadas. Porém estes DTOs terão que ser muito bem definidos, pois umaoutra camada ou aplicação remota só irá conhecer sua interface e não o objetoreal que ele representa. Estes objetos de transferência servem tanto para as saídas dos serviçosdefinidos na camada como para entrada de dados. Lembrando que a noçãoentre o que é serviço e operação já fora denotado em capítulo anterior. 21
    • 3.4. Paralelo entre Facade e Service Layer Após a explicação do que sejam Facade e Service Layer, este tópicomostra como eles podem ser usados em conjunto. Os dois conceitos secomplementam permitindo definir um sistema baseado em serviços muito bemestruturado e flexível. Como há a separação de responsabilidades entre o que é deaplicação e de domínio, os Facades também se dividem dessa forma. No qualFacade de aplicação conhece processos e como determinada atividadeespecífica deve ser feita dentro da aplicação, ao passo que o Facade dedomínio apenas espelha a camada de domínio para outra camada ou sistema.Facades de domínio acessam apenas objetos de domínio. Já facades deaplicação acessam facades de domínio e, se for necessário, podem acessardiretamente objetos de domínio. A idéia deste trabalho é definir uma camada de serviços que forneçaacesso a clientes independentes da plataforma que utilizam, da seguinte forma:são definidos os facades que compõem a camada de serviços (service layer) epara cada facade, em um relacionamento um para um, é definido ocorrespondente web service. Então, quando os web services foremrequisitados pelo cliente haverá uma delegação aos respectivos Facades, ondecada Facade representará um processo (serviço) bem definido. Desta forma,têm-se duas opções de acesso: via facade diretamente ou via web service. Chegou-se a seguinte conclusão: o padrão de projeto Facade facilitao acesso à estrutura interna da aplicação, deixando visível somente afuncionalidade definida por ele e, por conseguinte, vem ao encontro do acessoalternativo a objetos de domínio por meio de web services, muito útil naquestão da computação ubíqua. 22
    • 4. Tecnologias e ferramentas do projeto O foco deste capítulo são as tecnologias e ferramentas que foramutilizadas para o desenvolvimento deste projeto. Sendo elas a plataforma Java[Java, 2007], o framework Axis [Axis, 2007], o Servidor Web Tomcat [Tomcat,2007], Sun Java Wireless Toolkit (comumente conhecido como JWT), [JavaWireless Toolkit, 2007] o Jude UML [Jude, 2007] (ferramenta para modelagem),a IDE Eclipse [Eclipse, 2007], além de plugins que auxiliam nodesenvolvimento.4.1. Java No começo da década de noventa, linguagens como C eram muitoutilizadas no desenvolvimento de sistemas computacionais, entretanto aobrigação de depender diretamente do desempenho do hardware era fatorcrítico e vertente a ser banida com o passar dos anos. Destarte, a SunMicrosystens, através de seus programadores, desenvolveu um protótipo delinguagem de programação chamada Star Seven. O objetivo da empresa eraoferecer ao mercado uma linguagem para a produção de softwares visandoprodutos eletro-eletrônicos como forno de microondas, agendas eletrônicas etc.Alguns anos mais tarde o projeto foi rebatizado para Oak, que significacarvalho em português e era a árvore que James Gosling, idealizador doprojeto, via de seu escritório quando olhava pela janela. Contudo, em 1994 aSun descobriu que o nome Oak já estava registrado e rebatizou-a para Java. Oobjetivo foi cumprido e os desenvolvedores, acompanhado a curva ascendenteda Internet e sua popularização em massa, resolveram dar outros rumos àlinguagem Java. Os pesquisadores trabalharam na linguagem a fim de adaptá-la para o uso em microcomputadores conectados a rede mundial, focalizando aweb. A popularização de Java emergiu no momento em que a Sun desenvolveuo HotJava. Um navegador web que fazia a inteface entre o sistema operacionale a linguagem. A partir daí, grandes empresas como a IBM e outrosnavegadores web passaram a dar suporte a Java. 23
    • Desde seu lançamento, a plataforma Java foi adotada mais rapidamentedo que qualquer outra linguagem de programação na história da computação.Em 2003, Java atingiu a marca de 4 milhões de desenvolvedores em todomundo. Continuou e continua crescendo e hoje é com certeza um padrão parao mercado oferecendo qualidade, performance e segurança. Java tornou-sepopular pelo seu uso na Internet e hoje possui seu ambiente de execuçãopresente em web browsers, mainframes, sistemas operacionais, celulares,palmtops, cartões inteligentes, entre outros. Java tem como características: a portabilidade que tange a finalidadeprecípua da linguagem que é desenvolver softwares que possam rodarindependentemente da plataforma base, a simplicidade que é o fato de alinguagem ter várias bibliotecas que fornecem grande parte dasfuncionalidades, ser baseada no paradigma orientado a objetos promovendoreuso e modularização de um sistema, segurança que reflete o processo decompilação que é a geração de bytecodes no qual os erros são localizados,evitando que se manifestem em tempo de execução, processamento paralelo eaplicações distribuídas que é o conjunto de classes que a linguagem possuipara criação de protocolos, uso de sockets, acesso a URL, criação de clientese servidores. Para permitir melhor desempenho acerca de código, Java permiteprogramação em threads (processos que ocorrem simultaneamente). Como a Sun Microsystens reconhece, é difícil – senão impossível – queuma mesma plataforma se ajuste a todos os tipos de dispositivos. Agruparam,portanto, as tecnologias Java em três edições, cada uma focada em umdeterminado segmento computacional. A seguir uma explicação básica sobre as três diferentes plataformas doJava e pode ser visualizada através da figura 4.1 as plataformas distintasexistentes. 24
    • Figura 4.1 - Representando a plataforma padrão Java (baseado na plataforma Java 2) [Plataforma Java, 2007]. Java Standard Edition – JSE [Standard Edition, 2007] é o ambiente deprogramação Java voltado para o desenvolvimento de aplicações desktop eservidores. Muito utilizado, pois além de ser o carro-chefe os outros segmentosJME [Micro Edition, 2007] e JEE [Enterprise Edition, 2007] são ambientesderivados do primeiro. Java Micro Edtion – JME destina-se à construção de aplicações a fim defuncionarem em aparelhos móveis: celulares, palm-tops etc. Este ambientepossui bibliotecas destinadas ao uso de aparelhos portáteis. Para tanto, bastao equipamento possuir uma JVM (Java Virtual Machine) e hardware compatívelcom softwares Java. Os telefones móveis mais modernos já utilizam Java emlarga escala. Java Enterprise Edition – JEE é o ambiente destinado à criação desoftwares que utilizarão a Internet, Intranet ou mesmo apenas redes físicas dedados. Dispõe de recursos para web tais como servlets [SUN, 2007], JSP[SUN, 2007] e XML. Além de recursos para programação “componentizada” 25
    • com Enterprise Java Beans – EJB [Tecnologia EJB, 2007] . Este trabalho utilizao ambiente JEE para o desenvolvimento da aplicação. A mais nova API para web services da plataforma Java EE 5 [EnterpriseEdition, 2007] é a JAX-WS 2 [API - Web Service, 2007] que permite aosserviços disponibilizados na rede mundial de computadores, total utilização dosesquemas XML, por conseguinte maior interoperabilidade e facilidade de uso.Antes da eclosão da tecnologia Java EE 5, a definição de um web servicerequeria descritores longos e difíceis de manejar. Agora não, pois todos osmétodos públicos na classe são publicados automaticamente como operaçõesde web service e todos os argumentos são mapeados para tipos de dados doesquema XML.4.2. Apache Tomcat O Apache Tomcat é um servidor de aplicações para aplicações Java naweb. Este é distribuído como software livre e desenvolvido como open sourcepelo projeto Apache Jakarta [Apache, 2007]. Atribuído como Referência deImplementação Oficial para as tecnologias Java Servlet e JavaServer Pagesque são especificações desenvolvidas pela Sun e pertencem à JavaCommunity Process [JCP, 2007]. O Tomcat é utilizado, por importantes sistemas web de grandesorganizações, em larga escala por ser robusto e eficiente. Este projeto não utiliza, em sua totalidade, o servidor de aplicações. Oque interessa no momento é o container para aplicações web, pois a aplicaçãoexemplo deste projeto está exposta na Internet por meio do referido servidor.4.3. Framework Apache Axis Um framework é um conjunto de funcionalidades em comum a váriasaplicações, ou seja, é uma API bem definida e tem o objetivo de promoverreutilização de uma solução de arquitetura de software, que contémcomponentes caixas-brancas e caixas-pretas. Os componentes caixas-brancassão reutilizados a partir de herança de classes e override de métodos. Os 26
    • caixas-pretas têm sua reutilização promovida a partir de interfaces definidaspara componentes. As características básicas de um framework são: deve ser reusável,extensível, uso seguro, eficiente e completo. Concluindo com esta observação: “Frameworks são projetados com a intenção de facilitar o desenvolvimento de software, habilitando designers e programadores a gastarem mais tempo determinando as exigências do software do que com detalhes tediosos de baixo nível do sistema”. Citação da Wikipedia assunto Framework [Wikipedia-Framework, 2007]. Acerca do Framework Apache Axis é um projeto open source baseado nalinguagem Java e no padrão XML que permite a construção de clientes eservidores baseados em web service utilizando o protocolo SOAP, ou seja,através deste framework é possível desenvolver aplicações distribuídas. Alémda implementação em Java há uma desenvolvida em C++. “O Axis disponibiliza dois modos para “expor” os métodos de uma classe através de web services. O modo mais simples utiliza os arquivos JWS (Java Web Service) do Axis. O outro método utiliza um arquivo WSDD (Web Service Deployment Descriptor), que descreve com detalhes como serão criados os web services a partir dos recursos (classes Java) existentes. Também é possível, através do Axis, gerar automaticamente o arquivo WSDL (Web Service Description Language). O WSDL contém a definição da interface dos web services.” Citação da Wikipedia assunto Apache Axis [Wikipedia-Apache Axis] Criar documentos XML é demorado e gerar o WSDL é uma característicamuito relevante na escolha de uma implementação de SOAP. O Axis é um dospoucos frameworks que conseguem fazê-lo de maneira transparente para ocliente do serviço, por isso é altamente recomendado na construção de WebServices. 27
    • Figura 4.2 – Mostrando o funcionamento do framework Axis.4.4. Wireless Tool Kit (JWT) O Sun Java Wireless Toolkit – JWT é um conjunto de ferramentas paradesenvolvimento de aplicações Java visando dispositivos portáteis compatíveiscom as especificações Java Technology for the Wireless Industry (JTWI) [JTWI,2007] e Mobile Service Architecture (MAS) [Java MAS, 2007] que implementaas seguintes capacidades expostas através de APIs padronizadas, as quaissão definidas pelo Java Comunity Process – JCP. • Mobile Service Architecture • Java Technology for the Wireless Industry (JTWI) • Connected Limited Device Configuration (CLDC) 1.1 • Mobile Information Device Profile (MIDP) 2.0 • PDA Optional Packages for the JME Platform • Java APIs for Bluetooth • Mobile Media API (MMAPI) • JME Web Services Specification • Security and Trust Services API for JME • Location API for JME • SIP API for JME • Mobile 3D Graphics API for JME 28
    • • Wireless Messaging API (WMA) 2.0 • Content Handler API • Scalable 2D Vector Graphics API for JME • Payment API • Advanced Multimedia Supplements • Mobile Internationalization API • Java Binding for the Ope®® ES API Cada um desses itens acima possui uma JSR (Java SpecificationRequest) que é um esforço coletivo – de engenheiros, projetistas e emp–esas– para padronizar assuntos relacionados à plataforma Java. O JWT possui um emulador que emula, virtualmente, um dispositivo real.4.5. Jude UML4.5.1 UML (Unified Modeling Language) O Surgimento da UML [OMG-UML, 2007] entre os anos de 1990 e 1997veio devido às organizações entenderem o valor do software para os negócios.A UML tem origem na compilação das melhores práticas de engenharia queprovaram ter sucesso na modelagem de sistemas grandes e complexos, então,James Rumbaugh e Ivar Jacobson juntaram-se a Grady Booch na RationalSoftware Corporation para unificar seus enfoques e formaram o grupo dosparceiros e submeteram a versão 1.0 da UML. A UML é uma linguagem paraespecificação, construção, visualização e documentação de sistemas. A versãoatual é a UML 2.0.4.5.2 JUDE (JAVA AND UML DEVE’OPERS’ ENVIRONMENT) O JUDE é uma IDE para modelagem de dados criado com Java e de usofácil e intuitivo. Com a IDE JUDE é possível realizar uma modelagem de dadoscomplexa, apresentar os dados para os usuários de uma forma bem clara. Épossível trabalhar com 8 tipos de diagramas disponíveis, classes, caso de uso,desenvolvimento. O JUDE é basicamente diagramadores da UML, sendo uma 29
    • das ferramentas grátis mais poderosas disponível atualmente, escrita 100% emJava/Swing.4.6. Eclipse Poderosa plataforma de software livre para desenvolvimento desistemas. Existem extensões do Eclipse, em software livre, desenvolvidascomo projetos Eclipse ou independentes, especializadas para outraslinguagens de programação, tais como: C, C++, PHP [PHP, 2007], Ruby [Ruby,2007], Python [Python, 2007], Shell Script etc. A meta principal do Eclipse não é ser um poderoso ambiente deprogramação, mas sim uma plataforma eficaz na qual é possível configurar oambiente a fim de desenvolver sistemas em determinadas linguagens. A seguir serão mostrados vários plugins ou releases (versões) quefacilitaram o desenvolvimento do exemplo deste projeto. Desde a aplicação queexpõe os serviços até a aplicação que os consome.4.6.1. CALLISTO RELEASE O Callisto [Eclipse, 2007] é um release que a Eclipse Foundation(fundação que coordena os variados projetos associados a IDE Eclipse)disponibilizou para facilitar muitas tarefas no desenvolvimento de aplicações naIDE. Esta denominação inclui dez projetos diferentes, são eles: • Eclipse Project 3.2 • Web Tools Platform 1.5 • Business Intelligence and Reporting Tools 2.1 • Data Tools Platform 1.0 • C/C++ IDE 3.1 • Visual Editor 1.2 • Graphical Editor Framework 3.2 • Graphical Modeling Framework 1.0 • Test and Performance Tools. 4.2 30
    • • Eclipse Modeling Framework 2.2 Para o desenvolvimento deste pacote de projetos foram envolvidos maisde 260 pessoas de mais de 15 empresas trabalhando nos diversos projetos.4.6.2. EclipseME É um eficaz plugin para a IDE Eclipse provendo alta integração com o SunJava Wireless Toolkit – JWT que auxilia no desenvolvimento de JME MIDlets[Java Wireless Toolkit]. 31
    • 5. Protótipo Este capítulo apresenta a aplicação utilizada para exemplificar o projeto.Antes, porém, é necessário expor os passos realizados desde sua idealizaçãoaté o exemplo em questão. Chegou-se ao entendimento que uma livraria atenderia a expectativa doprojeto. Assim, foi desenvolvido o seguinte estudo de caso. Imaginando que umcliente houvesse solicitado o sistema para sua livraria, foi elaborado olevantamento inicial a seguir, baseado em entrevista fictícia.5.1 Estudo de caso É requerido um sistema que automatize a compra de livros de uma loja,pois o negócio está crescendo e é preciso automatizar informação. O vendedorrecebe o cliente, procura, manualmente, a obra em um catálogo, encerradonuma grande pasta de cor preta. Caso encontre, informa o valor ao cliente esendo o interesse positivo, recorre ao estoquista para saber se a loja aindadispõe de tal obra em estoque. Se o estoque do produto houver acabado, ovendedor anota os dados do cliente – se o mesmo permitir – entrando emcontato com a editora a fim de comprar o livro e vendê-lo ao cliente. Essaoperação leva pelo menos uma semana. O negócio empresarial funciona àbase de blocos impressos destinados a cada função. Se a loja possui a obra em estoque, esta é trazida e apresentada aocliente que é inquirido pelo vendedor sobre a forma de pagamento. O empresário relata que houve casos onde os clientes querem que a lojaentregue o livro em outro endereço que não o deles e, que a obra estejaembalada como presente. E que se propõem a pagar um pouco mais por isso,entretanto a livraria não pode realizar tal tarefa. O dono da empresa relata que tenciona usar o serviço de entrega emdomicílio e com isso ter um acréscimo justificável no valor da venda. Ele diztambém que os clientes ficam muito insatisfeitos pela demora de todo oprocesso de compra. E que quer transformar funcionários como estoquista,arquivistas, em vendedores, a fim de ter mais atendentes e suportar a grandedemanda. 32
    • Outro pedido do empresário é que o sistema guarde as preferências dosclientes; como por exemplo, gênero e sub-gênero literário, autores preferidosetc. E que o software possa se comunicar com vários outros sistemas de livrosatravés da Internet, provendo inclusive serviços de tradução literária e leiturade e-books. O sistema de gerência de livros deve funcionar em plataformas diferentescomo, por exemplo, aparelhos portáteis, web ou então desktop. Percebeu-se que o dono da loja de livros era um empreendedor. O incentivo à compra à vista é instado e para isso deve-se garantir umaporcentagem a mais aos vendedores além de suas comissões.5.2 Aplicação contida no servidor Abaixo segue o desenvolvimento da aplicação instalada no servidor com aintenção de fornecer os web services para os possíveis clientes.5.2.1 Diagramas de caso de uso A análise focou-se em dois casos de uso em especial (casos de uso decatálogo e efetuar pedido), mas todos foram modelados, para ter a visão geraldos requisitos funcionais do sistema. Os diagramas possuem atores, casos deuso e relacionamentos como associação, dependência, generalização. Estamodelagem revela os papéis dos atores e suas interações com o sistema.Fornece ao desenvolvedor, também, o que o sistema irá fazer e não como iráfazer. Ao final é possível visualizar como o sistema reagirá às interações dosatores. Ou seja, uma visão externa. 33
    • Figura 5.1 – Diagramas de caso de uso do projeto.Figura 5.2 – Diagrama de caso de uso para efetuar pedido. 34
    • O diagrama retratado na figura 5.2 exemplifica o ator cliente efetuando umpedido onde é necessário como pré-condição os livros cadastrados no sistemae como pós-condição a existência do pedido. O fluxo principal dá-se daseguinte maneira: 1. O cliente escolhe o(s) livros(s); 2. O cliente inicia a venda; 3. O cliente informa a quantidade dos itens, local de entrega, forma de pagamento e se é para presente; 4. Ele mesmo finaliza a venda; 5. Fim do caso de uso. O fluxo alternativo tem esta estrutura: 1.1 Se o cliente não existir; 1.1.1 O caso de uso de cadastro de cliente é iniciado; 1.1.2 Segue para o passo 2; 3.1 Se houver local de entrega; 3.1.1 Há um acréscimo de 10%; 3.2 Se a forma de pagamento for à vista, desconto de 10%; 3.3 Segue para o passo 4. O caso uso denominado realiza compra tem a função de realizar ospassos para gravar a venda no repositório de dados. Todo o fluxo principal ealternativo, pré-condição, pós-condição estão descritos nesse caso de uso.Nesta modelagem o próprio cliente grava a compra no sistema. Se o clientenão existir no sistema no ato da compra, o caso de uso cadastro de cliente éiniciado. Figura 5.3 – Diagrama de caso de uso visualizar catálogo. 35
    • A figura 5.3 mostra o cliente visualizando o catálogo de livros. O catálogopoderá ser consultado por ISBN, Título do livro, gênero e depois subgênero enome do autor. Como pré-condição, este caso de uso necessita que asinformações sobre os livros estejam cadastradas. A pós-condição é a listagemdos livros pesquisados. O fluxo principal é o seguinte: 1. O cliente pede para visualizar o catálogo; 2. O cliente escolhe um gênero; 3. A listagem de livros é apresentada; 4. Fim do caso de uso; O fluxo alternativo possui as seguintes características: 2.1 O gênero escolhido possui subgênero; 2.1.1 O cliente escolhe um subgênero; 2.1.2 Segue para o passo 3; Estes dois casos de uso são disponibilizados como serviços, poisoferecerem funcionalidades importantes acerca do negócio da empresa epodem ser disponibilizados na Internet para que clientes de outras cidades,estados ou países possam utilizá-los sem precisar ir à loja. 36
    • 5.2.2 Diagrama de análise de domínio Figura 5.4 – Representa o diagrama de domínio. 37
    • Este diagrama (figura 5.4) tem o objetivo de fornecer, ao desenvolvedor, amais ampla visão, de forma estática, de como se relacionam as váriasentidades que representam o negócio empresarial. A seguir, breve explicação das classes que compõem este diagrama. Osnomes das classes estão em negrito para melhor visualização no esquema. Pessoa é a classe que representa qualquer pessoa no sistema. Os papéisque podem ser desempenhados por uma pessoa são representados pelaclasse Vendedor e Cliente. A classe Venda tem relacionamento com FormaPagamento (para saberqual será a forma de pagamento escolhida pelo cliente), com Vendedor (paracaptar o objeto que representa o vendedor que efetuou a venda), com Cliente(para saber quem é o cliente) e com ItemVendido (a fim de adicionar à vendaos itens de interesse do cliente) que por sua vez se relaciona com Livro cujosobjetos são os livros disponíveis para venda. Um livro sempre tem uma editorae um ou mais autores. Isto é representado nas respectivas classes Editora eAutor. Cliente se relaciona com Gênero e Autor para que, ao visualizar ocatálogo, sejam colocados em evidência os gêneros e autores que o clientetem mais interesse. Existe, também, um auto-relacionamento na classeGênero, pois um gênero pode ter um subgênero. 38
    • 5.2.3 Diagrama de design da camada de domínio Figura 5.5 – Representa o digrama de design de domínio. 39
    • O diagrama de design tem intenção de delinear a implementação dacamada de domínio, já pré-estabelecida pelo diagrama de análise de domínio,visto anteriormente. A seguir, breve explicação das classes que compõem este diagrama(figura 5.5). Os nomes das classes estão em negrito para melhor visualizaçãono esquema e os métodos estão em itálico. Com isso, será abordado qual aimportância de cada elemento no diagrama. A interface ObjetoDominio possui a mais alta abstração para identificaros objetos de domínio e é a interface base de todas as interfaces do diagrama.Tais objetos serão identificados por um identificador. As demais classesimplementam a classe abstrata ObjetoDominioAbstrato, segundo o padrãoLayer Supertype [Fowler et al, 2002], a fim de terem o mesmo comportamentodesta. A abstração Pessoa é implementada pela classe PessoaImpl. Quantoaos papéis desempenhados por uma pessoa, foi introduzida a classe abstrataPapel que implementa a interface Pessoa (sabe se comportar como umapessoa) e conhece a instância de Pessoa associada. Desta forma, a classePapel implementa o comportamento de pessoa delegando para a pessoa quecontém. As abstrações Vendedor e Cliente foram implementadas pelasclasses VendedorImpl e ClienteImpl, respectivamente. Ambas estas classesderivam da classe Papel, herdando o comportamento de Pessoa eacrescentando o respectivo comportamento específico. O design assimestruturado, evitando redundância de informações da Pessoa nas classes queimplementam Vendedor e Cliente e, por conseguinte, na base de dados. ClienteImpl possui dependência com Gênero e Autor para registrar ointeresse do cliente pelo autor ou pelo gênero da obra. A classe Autor são os autores no sistema. FormaPagamento representa a forma de pagamento que o cliente desejautilizar. Para simplificar, modelou-se apenas a classe FormaPgAVistaImplpara representar pagamento à vista. A classe abstrata ItemVendido comporta todos os objetos querepresentam os itens vendidos. A interface Editora tem a função de fornecer a editora de cada livro. 40
    • Venda, que é uma classe abstrata, tem dependência com Vendedor,FormaPagamento e Cliente, pois todos esses objetos constituem uma venda.Além de ser composta de itens vendidos através de um relacionamento decomposição com ItemVendido. A classe Livro representa os livros do sistema. Possui dependência comGênero e Editora e um relacionamento de associação com Autor.5.2.4 Diagrama de design de finders na camada de domínio Figura– 5.6 – Apresenta o diagrama de finders. Este diagrama (figura 5.6) expõe a implementação dos finders que seencarregam de realizar as buscas no banco de dados. Existe um finder paracada classe de negócio que, por sua vez, contém vários métodos para buscasespecíficas. 41
    • A seguir, breve explicação das classes que compõem este diagrama. Osnomes das classes estão em negrito para melhor visualização no esquema eos métodos estão em itálico. A classe RegistroFinder é um registro de todos os finders do sistema. Odesign Pattern de criação de objeto Singleton [Gamma et al, 2000] foi utilizadopara garantir uma única instância global desta classe. RegistroFinder temfunção de prover acesso centralizado a todos os objetos finders da aplicação.Há dependência com LivroFinder, FormaPagamentoFinder, AutorFinder,PessoaFinder, VendaFinder, EditoraFinder, ItemVendidoFinder,GeneroFinder e PapelFinder.5.2.5 Diagrama de design Data Transfer Object (DTO) Figura – 5.7 – Alude a implementação da transferência dos dados no sistema. Data Tranfer Object (DTO) [Fowler et al, 2002] é um design pattern quetem a função de transportar um conjunto de dados uma vez entre camadasdistribuídas, evitando uma enxurrada de chamadas remotas, pois esta requermuito do sistema. Como é preciso realizar várias Remote Procedure Calls(RPC) deve-se aglutinar os resultados dessas chamadas em objetos de 42
    • transferência para que este as armazene gerando, assim, apenas uma RPC enão várias para diferentes procedimentos. A seguir, breve explicação das classes que compõem este diagrama(figura 5.7). Os nomes das classes estão em negrito para melhor visualizaçãono esquema. Existe uma composição entre a classe PedidoDTO e a classeItemVendidoDTO porque o pedido possui itens vendidos. A classePedidoDTO, LivroDTO e ItemVendidoDTO fornecem informações básicas arespeito de seus objetos ao cliente. Como as classes da camada de domíniopossuem vários relacionamentos, usar DTO é o melhor procedimento paraevitar o acesso às informações básicas solicitadas. É por intermédio do objetoda classe ItemVendidoDTO que o cliente envia os itens vendidos para oservidor da aplicação. 43
    • 5.2.6 Diagrama de design da camada de persistência Figura – 5.8 – Ilustra a implementação da camada de banco de dados. 44
    • A seguir, breve explicação das classes que compõem este diagrama (figura5.8). Os nomes das classes estão em negrito para melhor visualização noesquema. Este diagrama simula em memória o processo de persistência dos objetos. Aclasse PersisterFactory é responsável por fabricar os objetos (persisters) quesimulam a gravação. Tal simulação é feita por um respectivo stub. A classeMapperFactoryStub realiza a criação dos objetos de persistência (stubs). Osfinders são usados de acordo com a necessidade de pesquisa feita pelo usuário esão interfaces implementadas pelos stubs, responsáveis por fazer a busca doobjeto. Concluindo para cada objeto da camada de domínio existe umacorrespondente interface persister e uma correspondente interface finder, ondeambas são implementadas pela correspondente classe Mapper, que para fim detestes é um stub que simula um datamapper com o banco de dados. Banco dedados este simulado em memória pela classe RepositórioObjetoDomínio, quenada mais é do que uma tabela hash de dois níveis onde o primeiro nível éindexado pelo tipo do objeto e o segundo nível, pelo identificador (id) do objeto. 45
    • 5.2.7 Diagrama de design da camada de serviços Figura – 5.9 – Demonstra a implementação da camada de serviços. 46
    • Este diagrama (figura 5.9) mostra nitidamente a que este projeto se destina.Existem dois serviços: Realizar Pedido e Visualizar Catálogo que serãodisponibilizados na web para que qualquer cliente possa acessá-los,independentemente da tecnologia que utiliza. Neste ponto é satisfeito a solicitaçãodo empresário para que novos clientes possam ver os livros da loja e comprá-los. A seguir, breve explicação das classes que compõem este diagrama. Osnomes das classes estão em negrito para melhor visualização no esquema. ProvedorServicoCatalogo e ProvedorServicoPedido representam osfacades dos serviços disponibilizados. Esta duas interfaces são implementadaspor ProvedorServicoCatalogoImpl, que tem dependência com a interfaceLivroFinder a fim de retorna as buscas de livro no sistema e utiliza GeneroFinderpara efetuar buscas pelo gênero da obra, e ProvedorServicoPedidoImpl, queconhece as interfaces necessárias para realizar um pedido tais como LivroFinder,PessoaFinder e FormaPagamentoFinder. A classe que implementa o serviço depedido também “conhece” a classe que cria objetos de persistênciaPersisterFactory e a interface VendaPersister, para gravar a venda. 47
    • 5.2.8 Diagrama de seqüência do caso de uso catálogo Figura 5.10 – Apresenta a dinâmica do serviço de catálogo de livros. 48
    • O diagrama de seqüência proporciona a visualização, em ordem temporal,das mensagens que são trocadas entre os objetos participantes de um processo.Acima o processo é o serviço para pesquisar livros, fornecido ao cliente. Umdiagrama de seqüência identifica o evento gerador do processo, o atorresponsável por este evento (no caso o cliente) e dispõe como é o processo deiteração, por intermédio de métodos disparados, entre os objetos. Este diagramaserá dividido em quatro partes para melhor visualização. 49
    • 5.2.8.1 Busca pelo código Figura 5.11 – Busca pelo código. 50
    • A seguir, breve explicação dos componentes que compõem este diagrama.Os nomes das classes estão em negrito e os métodos em itálico, para melhorvisualização no esquema. O ator cliente solicita uma busca de um livro pelo código do livro. A classeProvedorServicoCatalogoImpl dispara o método getInstance da classeregistroFinder a fim de obter a única instância desta classe e em seguida obtém oobjeto de busca (finder) por intermédio do método getLivroFinder. Depois éinvocado outro getInstance, desta vez da classe MapperFactoryStub e após oobjeto de busca dispara o método getLivroMapper pretendendo mapear os dadosdo livro para a simulação de persistência. No decorrer, o objetoMapperFactoryStub dispara um método getInstance na classe LivroMapperStubpara conseguir uma única simulação de persistência naquele exato momento. Depois a classe ProvedorServicoCatalogoImpl aciona o métodobuscarPeloId na classe LivroMapperStub onde é passado o parâmetro queidentificará o id do livro. A própria classe busca a instância do objeto repositório que é um Singletononde o método de busca é sincronizado, tornando, assim, impossível o uso domesmo objeto por diferentes threads. Abaixo ocorre a condição para saber se ocódigoTipo é igual a livro. Se essa condição for verdadeira, o MapperStub disparao método de busca de objetos de domínio no repositório, passando o id e ocodigoTipo como parâmetro. 51
    • 5.2.8.2 Busca pelo ISBN Figura 5.12 – Busca pelo ISBN. 52
    • A busca por ISBN faz a mesma simulação de persistência de pesquisa pelocódigo do livro, porém a classe LivroMapperStub busca todos os objetos dorepositório de objetos de domínio passando o parâmetro codigoTipo. Em seguida,a própria classe realiza uma auto-chamada para listar os livros com ISBN iguaisaos ISBN passado como parâmetro no método buscarPeloIsbn. 53
    • 5.2.8.3 Busca pelo Gênero Figura 5.13 – Busca pelo Gênero. 54
    • A busca por Gênero realiza a mesma simulação feita anteriormente para livroe inova com uma simulação para gênero. Adiante é feito um solicitação à classeGeneroMapperStub para retornar a única instância de gênero e mapear os dadospara representar a persistência. GeneroMapperStub faz uma auto-chamada pararetornar os nomes dos gêneros solicitados no parâmetro do métodobuscaPeloNome. E ocorre outra auto-chamada, desta vez na classeLivroMapperStub para listar todos livros que conferem com o parâmetro gêneropassado no método buscarPeloGenero. 55
    • 5.2.8.4 Busca pelo Nome Figura 5.14 – Busca pelo Nome. 56
    • Por fim, a seqüência do método buscarLivrosPorNome para simular segue ospassos anteriores e a classe LivroMapperStub efetua uma auto-chamada pararetornar todos os livros que coincidem com o nome do livro passado comparâmetro no método buscarPorNome.5.2.9 Diagrama de seqüência do caso de uso efetuar pedido Figura 5.15 – Revela o diagrama de seqüência de efetuar pedido. 57
    • A seguir, breve explicação dos componentes deste diagrama. Os nomes dasclasses estão em negrito e os métodos em itálico, para melhor visualização noesquema. O cliente dispara o método efetuarPedido passando os seguintesparâmetros: idCliente, idVendedor, idFormaPg, endEntrega, itensVendidos. Entãoa classe ProvedorServicoPedidoImpl busca a instância da classeRegistroFinder e depois retorna o objeto de busca do papel. A classe RegistroFinder, por sua vez, busca a instância da classeMapperFactoryStub, para gerar os objetos de persistência já mapeados. Emseguida, dispara o método getPapelMapper para retornar as informações doobjeto papel. A classe ProvedorServicosPedidoImpl dispara dois métodos de busca peloid com seus respectivos parâmetros. Sendo um para o cliente e outro para ovendedor. E ainda busca a forma de pagamento. A classe RegistroFinder acessa a instância da classe MapperFactoryStubpara obter e retornar a instância de FormaPagamentoMapperStub. ProvedorServicosPedidoImpl busca a forma de pagamento pelo id. Depoiscria uma nova venda e informa os objetos participantes da venda, a saber: ocliente, o vendedor, a forma de pagamento e o local para entrega. Por fim, retornaum objeto de busca para o livro. RegistroFinder acessa a instância de MapperFactoryStub e retorna oLivroMapperStub, a partir do qual todos os livros são buscados. O próximo passo é uma auto-chamada para gerar o livro pesquisado e aquantidade de livros. No código é criado um novo item vendido e adicionado osdados pertinentes. A seguir é acessado o VendaPersister, implementado peloVendaMapperStub, para salvar a venda criada. Por fim, ProvedorServicosPedidoImpl, a partir da venda criada, monta umpedidoDTO com os dados da venda e os dados relativos a cada item como preço,quantidade, valor, id e nome a fim de facilitar o transporte das informações pelosistema. 58
    • 5.3 Aplicação cliente (dispositivo portátil) Como parte do protótipo foi desenvolvida uma aplicação cliente, maisespecificamente um dispositivo portátil. Esta aplicação consiste no consumo dosweb services disponibilizados na aplicação desenvolvida para o servidor.5.3.1 Diagrama de design do pacote de conector de serviços Figura 5.16 – Conectando o cliente ao servidor para utilizar os serviços. A seguir, breve explicação dos componentes deste diagrama. Os nomes dasclasses estão em negrito e os métodos em itálico, para melhor visualização noesquema. As interfaces ConectorServicosCatalogo e ConectorServicosPedido sãoimplementadas por ConectorServicosCatalogoImpl eConectorServicosPedidoImpl, respectivamente. Essas duas classes possuemum atributo privado chamado url que fornece a localização dos serviços. A classe ConectorServicosCatalogoImpl possui alguns métodos públicosque disponibilizam várias formas de consultas no catálogo, todos retornando umobjeto do tipo livroDTO para melhor locomoção dos objetos no sistema. Algunsmétodos retornam um único livroDTO e outros um array de livroDTO. Se o clienteconsulta um livro por ISBN, é notório que o retorno será um único ISBN, pois não 59
    • existem dois livros com este mesmo código. Entretanto, se a pesquisa for por umtítulo de um livro, será retornado um array, pois é possível que existam outrasedições da mesma obra. O método montaLivroDTO tem um parâmetro do tipo soapObject porquequando a requisição é respondida pelo servidor vem no formato XML e éencapsulada no formato soapObject ao chegar ao cliente. Então é feito umaconversão e retornado um objeto do tipo livroDTO. ConectorServicosPedidoImpl possui um método para efetuar o pedido.Nesse método são passados vários parâmetros que compõem um pedido. Oretorno é um objeto pedidoDTO.5.3.2 Diagrama de design do pacote de domínio Figura 5.17 – Cria os pedidos na camada de domínio de cliente. A seguir, breve explicação desta classe. Os nomes das classes relacionadasestão em negrito para melhor visualização no esquema. A classe PedidoFactory cria um pedido por vez para o cliente e depoisdelega para a classe ConectorServicosPedidoImpl a fim de que esta últimarepasse o pedido para o servidor. 60
    • 5.3.3 Diagrama de design do pacote de domínio de DTOs Figura 5.18 – Formatação de chamada e resposta do servidor no padrão DTO. A seguir, breve explicação deste diagrama. Os nomes das classes estão emnegrito e os métodos em itálico, para melhor visualização no esquema. O pacote de domínio de DTOs, composto pelas classes LivroDTO,PedidoDTO, ItemPedidoDTO e ItemVendidoDTO, tem a função de retornartodos os objetos para o servidor de maneira menos custosa e única. Ou seja,todos os objetos necessários para retornar o catálogo de livros ou um pedidoefetuado pelo cliente são retornados de uma vez só - no formato DTO – paraevitar várias chamadas de objetos que pertençam a um mesmo processo denegócio. Seria muito custoso para o sistema requisitar ou responder ao servidorenviando os objetos separados. No formato DTO todos os objetos necessários sãoreunidos e passados de uma vez só. A classe itemVendidoDTO auxilia o serviço de efetuar pedido, pois aestrutura JME não suporta muitas estruturas complexas como uma tabela hash,por exemplo. 61
    • 5.3.4 Diagrama de design do pacote de visão Figura 5.19 – Diagrama de classe relacionado às telas para interação com o sistema. 62
    • A seguir, breve explicação dos componentes deste diagrama. Os nomes dasclasses estão em negrito, para melhor visualização no esquema. A classe PrincipalMidlet representa a interface gráfica que inicia a aplicaçãoque tem a seguinte aparência (figura 5.20): Figura 5.20 – Tela inicial do protótipo. 63
    • CatalogoForm representa a interface gráfica que lista todos os livros para ocliente e tem a seguinte aparência: Figura 5.21 – Tela inicial de catálogo. 64
    • DetalhesForm representa a interface gráfica que visualiza as informaçõespertinentes a um determinado livro e tem a seguinte aparência: Figura 5.22 – Tela com formulário para ver detalhes ou fechar o pedido. 65
    • CompraForm representa a interface gráfica onde após selecionado um livrono CatalogoForm visualizado é solicitado a informação da quantidade de livros aserem comprados e tem a seguinte aparência: Figura 5.23 – Tela para efetuar o pedido. 66
    • BuscaForm representa a interface gráfica onde o usuário poderá efetuarbuscas diversas: por nome, gênero, isbn e código. Basta digitar o valor baseadona referência do radiobox. A tela possui a aparência da figura 5.24. Figura 5.24 – Tela para efetuar uma busca. 67
    • 6. Conclusão A necessidade cada vez maior de sistemas que possam interagir entre si demaneira rápida, eficiente e segura fez com que a tecnologia de middlewares,dentre elas Web Services, se tornasse um dos assuntos mais abordados eexplorados nos dias de hoje. Um middleware é uma camada de software,residente acima do sistema operacional e do substrato de comunicação, queoferece abstrações de alto nível, com objetivo de facilitar a programaçãodistribuída. As abstrações oferecidas fornecem uma visão uniforme na utilizaçãode recursos heterogêneos existentes nas camadas inferiores. O nível de interação do ser humano com a Internet é imenso. Basicamente,em termos de negócio, tudo é possível na rede mundial de computadores.Entretanto, quando se apresenta a interação entre softwares são constatadasgrandes dificuldades advindas das várias tecnologias de desenvolvimentodisponibilizadas no mercado. O Web Service, no sentido geral do termo, significa serviços oferecidos pelaInternet, onde o uso de padrões abertos torna possível integrar componentes eaplicações de forma independente da tecnologia utilizada. A padronização temsido a chave para o sucesso e aceitação instantânea da tecnologia. Essatecnologia aborda necessidades latentes, como a interoperabilidade entresistemas distribuídos e o compartilhamento e utilização de dados. Destarte, todas as pesquisas realizadas sobre o tema exortaram a utilizaçãode Web Service quando se pretende disponibilizar serviços na web sem sepreocupar com as tecnologias que darão suporte aos acessos desses serviços. Esta monografia abordou o problema de interoperabilidade de sistemas, bemcom a crescente necessidade do uso de diferentes tipos de dispositivos no acessoàs aplicações. Foi apresentada uma abordagem que serve como ponto inicial paraa definição de uma arquitetura SOA para a implementação destas aplicações. Aproposta apresentada mostrou como utilizar os padrões Facade e Service Layer eweb services de uma maneira sistemática e estruturada buscando flexibilidade deacesso a dados no que tange as tecnologias envolvidas no processo de requisiçãoe resposta acerca de um serviço disponibilizado na web. 68
    • Desta forma temos importantes benefícios como: reutilização de serviços(gerando diminuição do esforço empregado no desenvolvimento de código),aumento do nível de interoperabilidade de sistemas, autonomia acerca daplataforma utilizada, autonomia com relação a tecnologia empregada em clientes eserviços e desprendimento de questões geográficas.6.1 Trabalhos Relacionados O conceito de rede ponto-a-ponto (em inglês, peer-to-peer, sigla P2P)cresceu drasticamente nos últimos anos e se popularizou por meio de programasde compartilhamento de músicas. O conceito-chave da rede ponto-a-ponto é quecada integrante da rede é essencialmente um cliente e um servidor, ao mesmotempo. Há programas que possibilitam a distribuição de arquivos nessa rede,permitindo o acesso de qualquer usuário (da referida rede) ao recurso. O projeto MIDster – da sigla P2P Web Service Medical Image DistributedSystem [FFCRLP, 2007] – propõe um sistema de compartilhamento de imagensmédicas baseado em padrões peer-to-peer e web services. A arquitetura MIDstertem em sua essência a vertente P2P e a dinâmica dos web services oferecendoum relacionamento entre usuários e seus recursos em redes Intranet/Internet quedefine uma plataforma de conhecimento de coleções de imagens médicas. Osistema MIDster desenvolvido suporta produção modular de software; encoraja areutilização de código; permite a integração de diferentes linhas deprogramadores, sistemas operacionais e hardwares; e possibilita longevidade namanutenção. O projeto MIDster foi desenvolvido no laboratório ImagCom(http://imagcom.org) pertencente ao Departamento de Física e Matemática (DFM),Faculdade de Filosofia, Ciências e Letras de Ribeirão Preto (FFCLRP),Universidade de São Paulo (USP). Outro trabalho relacionado é a plataforma .NET. Este possui as mesmascaracterísticas que o web service baseado na plataforma Java EE, entretantoexistem algumas diferenças que são destacadas a seguir: 69
    • Java EE .NET Suporte a Web Suporte por meio de API´s Suporte embutido e simplificado Services O Java ME fornece recursos para O desenvolvimento para dispositivos rodar Java em dispositivos móveis móveis fornece um framework muito que tenham desde recursos produtivo e repleto de recursos: o escassos até aqueles extremamente .NET Compact Framework [.NET robustos. Amplamente difundido, Compact Framework]. Porém, deve estando presente na maioria dos rodar em sistema operacional da celulares disponibilizados no Microsoft, como o Windows Mobile. Dispositivos mercado atualmente. O Eclipse Exige dispositivos móveis com móveis Callisto, fornece diversos recursos processadores mais robustos, mais que aumentam a produtividade e recursos de memória e geralmente tornam simples o desenvolvimento caros. Pouquíssimo difundido de aplicações móveis. quando comparado com a plataforma Java. Exige uma versão comercial do Visual Studio [Visual Studio.NET] para desenvolver aplicações móveis. Escalabilidade Muito Boa Boa Segurança Muito Boa Muito BoaMáquina virtual Kilo Virtual Machine (KVM) e Common Language Runtime (CLR) Compact Virtual Machine (CVM)para dispositivos móveisComunicação de TCP/IP e MAS TCP/IP e MAS Web Services6.2 Trabalhos Futuros Esse protótipo pode possuir algumas funcionalidades que não foramimplementadas. Dentre elas, implementar o banco de dados. Pode-se optar porum banco de dados objeto-relacional. Atualmente é feita uma simulação depersistência em memória. 70
    • Outro ponto importante para se abordar na extensão deste projeto são outrasformas de pesquisas como, por exemplo: pesquisa por trechos do sumário dolivro. Claro está que uma pesquisa para saber se um livro contém um determinadoassunto é primordial para qualquer livraria. Uma alternativa à interface portátil pode ser desenvolvida utilizando a web, jáque a intenção de se expor a funcionalidade através de serviços tem comoobjetivo a independência de plataforma. Pode-se propor um framework específico para expor a funcionalidade destesistema para uma loja de livros, seguindo a vertente de serviços como já foiiniciado por este protótipo, facilitando com isso o desenvolvimento em larga escalade vários protótipos semelhantes. Outra abordagem seria a criação ou adaptação de um framework que trate osfacades propostos como classes de primeira ordem, ou seja, classes que sãodefinidas através de um dicionário bem conhecido facilitando reuso,compartilhamento e flexibilidade. Uma proposta interessante seria adotar os princípios de Model DrivenEngineering – MDE (Engenharia dirigida por modelos), onde diz-se que toda aaplicação é desenvolvida a partir de um modelo desde estruturas para persistênciaaté respostas plausíveis para o usuário da aplicação, sendo assim pode se proporuma forma mais ágil para desenvolver e expor serviços através de metamodelosonde se definiria poucas etapas de transformação para chegar ao mesmoresultado feito por este projeto, reduzindo custo de desenvolvimento eaumentando lucratividade e produtividade, além do que deixando o usuário maisconfiante, pois o código é gerado a partir de modelos formais instanciados a partirde um metamodelo cuidadosamente elaborado. 71
    • Referências[Apache, 2007] The Apache Software Foundation. Site official: http://www.apache.org . Acessado em: 13 out. 2007.[API – Web Application Programming Interface for Web Services. Website:Service, 2007] http://jax-ws.dev.java.net . Acessado em: 10 out. 2007.[Axis, 2007] Web Services – Axis. Official Website: http://ws.apache.org/axis/index.html . Acessado em: 7 set. 2007.[CJ-Luca, 2006] Conexão Java 2006. Palestrante Luca e Daniel Quirino. Site para download: http://www.guj.com.br/posts/list/46354.java. Acessado em: 05 maio 2007.[Conexão Jini, Conexão Jini. Web Site Oficial:2007] http://br.sun.com/support/consultoria/java/jini.html . Acessado em: 7 set. 2007.[DCOM, 2007] Site Oficial: http://www.microsoft.com.br . Acessado em: 22 dez. 2007.[Eclipse, 2007] Eclipse. Site oficial: http://www.eclipse.org . Acessado em: 13 out. 2007.[Enterprise Java Platform Enterprise Edition (Java EE). Official Website:Edition, 2007] http://java.sun.com/javaee . Acessado em: 2 jun. 2007.[FFCRLC, 2007] Departamento de Física e Matemática. Programa de Pós-Graduação em Física Aplicada à Medicina e Biologia. Universidade de São Paulo – USP. Site oficial: http://imagcom.org/index.php . Acessado em: 22 dez. 2007.[Fowler et al, Fowler, Martin; Rice, David; Foemmel, Matthew; Hieatt, Edward; Mee,2002] Robert; Stafford, Randy – Patterns of Enterprise Application Architeture, Addison Wesley, November 05, 2002.[Gamma et al, Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John.2000] “Padrões de projeto – Soluções reutilizáveis de software orientado a objetos”, Bookman, 2000.[Java EE – SUN, Java Enterprise Edition. Site oficial: http://java.sun.com/javaee .2007] Acessado em: 28 dez. 2007. 72
    • [Java MSA, 2007] Java ME Technology – Mobile Service Architecture. Official Website: http://java.sun.com/javame/technology/msa . Acessado em: 5 nov. 2007.[Java Wireless Sun Java Wireless Toolkit (JWT). Oficial Website:Toolkit, 2007] http://java.sun.com/products/sjwtoolkit/overview.html . Acessado em: 14 ago. 2007.[JCP, 2007] Community Development of Java Technology Specifications. Official Website: http://jcp.org/en/home/index . Acessado em: 2 jun. 2007.[JTWI, 2007] Java Technology for the Wireless Industry (JTWI). Official Website: http://java.sun.com/products/jtwi/ . Acessado em: 9 out. 2007.[Jude, 2007] JUDE – System Design Tool. Official Website: http://jude.change-vision.com/jude-web/index.html . Acessado em: 13 out. 2007.[Mattos, 2005] Mattos, Érico Tavares de. “Programação Java para Wireless – Aprenda a desenvolver sistemas em J2ME”, Digerati Books, 2005.[Metsker, 2004] Metsker, Steven John – Padrões de Projeto em Java, Bookman, 2004.[Micro Edition, Java Platform Micro Edition (Java ME). Official Website:2007] http://java.sun.com/javame . Acessado em: 2 jun. 2007.[OASIS Advancing Open Standards for the Information Society. Site oficial:Consortium, http://www.oasis-open.org . Acessado em: 21 dez. 2007.2007][OASIS-UDDI, Advancing Open Standards for the Information Society. Universal2007] Description, Discovery and Integration (UDDI). Official Website: http://www.oasis-open.org/committees/uddi-spec/doc/tns.htm . Acessado em: 10 out. 2007.[OMG-UML, Object Management Group. Official Website: http://www.uml.org2007] Acessado em: 9 nov. 2007.[Plataforma Java, Reality. Official Website: http://www.reality.hk/index.php?paged=43.2008] Acessado em: 25 jan 2008.[PHP, 2007] PHP. Site oficial: http://www.php.net . Acessado em: 20 dez. 2007.[Python, 2007] Python Programming Language – Official Website: 73
    • http://www.python.org . Acessado em: 20 dez. 2007.[Ruby, 2007] Ruby Programming Language – Official Website: http://www.ruby-lang.org . Acessado em: 20 dez. 2007.[SAAJ, 2007] Overview of SAAJ – Official Web Site: http://java.sun.com/j2ee/1.4/docs/tutorial/doc/SAAJ2.html. Acessado em: 10 dez. 2007.[Standard Edition, Java Platform Standard Edition (Java SE). Official Website:2007] http://java.sun.com/javase . Acessado em: 2 jun. 2007.[SUN, 2007] Sun Microsystems. Site oficial: http://java.sun.com . Acessado em: 20 jul. 2007.[Tecnologia EJB, Enterprise JavaBeans Technology. Official Website:2007] http://java.sun.com/products/ejb/ . Acessado em: 14 ago. 2007.[Tomcat, 2007] Apache Tomcat: http://tomcat.apache.org/ . Acessado em: 10 out. 2007.[Visual Microsoft Visual Studio.NET. Official Website:Studio.NET, http://www.microsoft.com/brasil/msdn/visualstudio/default.mspx .2008] Acessado em 10 jan. 2008.[Wikipedia- Wikipédia, a enciclopédia livre. Site oficial:Apache Axis, http://pt.wikipedia.org/wiki/Apache_axis . Acessado em 15 nov. 2007.2007][Wikipedia- Wikipédia, a enciclopédia livre. Site oficial:Framework, http://pt.wikipedia.org/wiki/Framwork . Acessado em 15 nov. 2007.2007][WWW World Wide Web Consortium. Official Website: http://www.w3.org .Consortium, Acessado em: 10 out. 2007.2007][W3C-HTML, World Wide Web Consortium. HyperText Markup Language (HTML).2007] Official Website: http://www.w3c.org/html . Acessado em: 10 out. 2007.[W3C-SOAP, World Wide Web Consortium. Simple Object Access Protocol (SOAP).2007] Official Website: http://www.w3c.org/TR/soap12-part1 . Acessado em: 74
    • 10 out. 2007.[W3C-WSDL, World Wide Web Consortium. Web Services Description Language2007] (WSDL). Official Website: http://www.w3c.org/TR/wsdl . Acessado em: 10 out. 2007.[.NET Microsoft .NET Framework. Site oficial:Framework, http://www.microsoft.com/brasil/msdn/framework/default.mspx2007] Acessado em: 10 nov. 2007.[.NET Compact Microsoft .NET Compact Framework. Official Website:Framework, http://msdn2.microsoft.com/en-us/netframework/aa497273.aspx .2008] Acessado em: 21 jan. 2008. 75
    • APÊNDICE ACódigo dos facades utilizados como Service Layer do protótipo.Pacote br.ucam.campos.projws.provedor.serviçospackage br.ucam.campos.projws.provedor.servicos;import br.ucam.campos.projws.provedor.dto.LivroDTO;public interface ProvedorServicosCatalogo { public LivroDTO buscarLivroPorCodigo(long idLivro); public LivroDTO buscarLivroPorIsbn(String isbn); public LivroDTO[] buscarLivrosPorGenero(String nomeGenero); public LivroDTO[] buscarLivrosPorNome(String nome); public LivroDTO[] buscarTodos();}package br.ucam.campos.projws.provedor.servicos;import br.ucam.campos.projws.dominio.Genero;import br.ucam.campos.projws.dominio.Livro;import br.ucam.campos.projws.dominio.finder.GeneroFinder;import br.ucam.campos.projws.dominio.finder.LivroFinder;import br.ucam.campos.projws.dominio.finder.RegistroFinder;import br.ucam.campos.projws.provedor.dto.LivroDTO;public class ProvedorServicosCatalogoImpl implementsProvedorServicosCatalogo { private LivroDTO montarLivroDTO(Livro livro){ long idLivro = livro.getId(); String nome = livro.getNome(); String descricao = livro.getDescricao(); float preco = livro.getPreco(); String isbn = livro.getIsbn(); String idioma = livro.getIdioma(); String editora = livro.getEditora().getNome(); String autores = ""; for (int i = 0; i < livro.getAutores().length; i++){ autores += "n" +livro.getAutores()[i].getNome(); } String genero = livro.getGenero().getNome(); return newLivroDTO(idLivro,nome,descricao,preco,isbn,idioma,editora,autores,genero); } private LivroDTO[] montarVariosLivroDTOs(Livro[] livros){ LivroDTO[] result = new LivroDTO[livros.length]; for (int i = 0; i < result.length; i++){ result[i] = this.montarLivroDTO(livros[i]); } 76
    • return result; } public LivroDTO buscarLivroPorCodigo(long idLivro) { RegistroFinder registroFinder = RegistroFinder.getInstance(); LivroFinder finder = registroFinder.getLivroFinder(); return this.montarLivroDTO(finder.buscarPeloId(idLivro)); } public LivroDTO buscarLivroPorIsbn(String isbn) { RegistroFinder registroFinder = RegistroFinder.getInstance(); LivroFinder finder = registroFinder.getLivroFinder(); return this.montarLivroDTO(finder.buscarPeloIsbn(isbn)); } public LivroDTO[] buscarLivrosPorGenero(String nomeGenero) { LivroDTO[] result = null; RegistroFinder registroFinder = RegistroFinder.getInstance(); LivroFinder finder = registroFinder.getLivroFinder(); GeneroFinder generoFinder = registroFinder.getGeneroFinder(); Genero genero = generoFinder.buscarPeloNome(nomeGenero)[0]; result =this.montarVariosLivroDTOs(finder.buscarPeloGenero(genero)); return result; } public LivroDTO[] buscarLivrosPorNome(String nome) { RegistroFinder registroFinder = RegistroFinder.getInstance(); LivroFinder finder = registroFinder.getLivroFinder(); returnthis.montarVariosLivroDTOs(finder.buscarPorNome(nome)); } public LivroDTO[] buscarTodos(){ LivroDTO[] result = null; RegistroFinder registroFinder = RegistroFinder.getInstance(); LivroFinder finder = registroFinder.getLivroFinder(); try { result =this.montarVariosLivroDTOs(finder.buscarTodos()); } catch (NullPointerException e) { e.printStackTrace(); } catch (Exception e) { e.printStackTrace(); } return result; }}package br.ucam.campos.projws.provedor.servicos; 77
    • import br.ucam.campos.projws.provedor.dto.ItemVendidoDTO;import br.ucam.campos.projws.provedor.dto.PedidoDTO;public interface ProvedorServicosPedido { public PedidoDTO efetuarPedido(long idCliente, long idVendedor,long idFormaPg, String endEntrega, ItemVendidoDTO[] itensVendidos);}package br.ucam.campos.projws.provedor.servicos;import br.ucam.campos.projws.dominio.Cliente;import br.ucam.campos.projws.dominio.FormaPagamento;import br.ucam.campos.projws.dominio.ItemVendido;import br.ucam.campos.projws.dominio.ItemVendidoImpl;import br.ucam.campos.projws.dominio.Livro;import br.ucam.campos.projws.dominio.Venda;import br.ucam.campos.projws.dominio.VendaImpl;import br.ucam.campos.projws.dominio.Vendedor;import br.ucam.campos.projws.dominio.finder.FormaPagamentoFinder;import br.ucam.campos.projws.dominio.finder.LivroFinder;import br.ucam.campos.projws.dominio.finder.PessoaFinder;import br.ucam.campos.projws.dominio.finder.RegistroFinder;import br.ucam.campos.projws.dominio.finder.VendaFinder;import br.ucam.campos.projws.persistencia.PersisterFactory;import br.ucam.campos.projws.persistencia.VendaPersister;import br.ucam.campos.projws.provedor.dto.ItemPedidoDTO;import br.ucam.campos.projws.provedor.dto.ItemVendidoDTO;import br.ucam.campos.projws.provedor.dto.PedidoDTO;public class ProvedorServicosPedidoImpl implements ProvedorServicosPedido{ public synchronized PedidoDTO efetuarPedido(long idCliente, longidVendedor, long idFormaPg, String endEntrega, ItemVendidoDTO[] itensVendidos) { RegistroFinder registroFinder = RegistroFinder.getInstance(); PessoaFinder pessoaFinder = registroFinder.getPessoaFinder(); Cliente cliente = (Cliente)pessoaFinder.buscarPeloId(idCliente); Vendedor vendedor = (Vendedor)pessoaFinder.buscarPeloId(idVendedor); FormaPagamentoFinder formaPgFinder =registroFinder.getFormaPagamentoFinder(); FormaPagamento formaPg =formaPgFinder.buscarPeloId(idFormaPg); Venda venda = new VendaImpl(); venda.setCliente(cliente); venda.setVendedor(vendedor); venda.setFormasPg(formaPg); venda.setLocalEntrega(endEntrega); LivroFinder livroFinder = registroFinder.getLivroFinder(); 78
    • int tamanho = itensVendidos.length; for (int i = 0; i < tamanho; i++){ Livro livro =livroFinder.buscarPeloId(itensVendidos[i].getIdLivro()); int qtd = itensVendidos[i].getQtd(); ItemVendido itemVendido = new ItemVendidoImpl(); itemVendido.setLivro(livro); itemVendido.setPreco(livro.getPreco()); itemVendido.setPresente(true); itemVendido.setQtd(qtd); venda.adicionarItem(itemVendido); } PersisterFactory persisterFactory =PersisterFactory.getInstance(); VendaPersister vendaPersister =persisterFactory.getVendaPersister(); vendaPersister.inserir(venda); // a partir daqui gerando objeto de resposta VendaFinder vendaFinder = registroFinder.getVendaFinder(); Venda[] todasVendas = vendaFinder.buscarTodos(); Venda atual = todasVendas[todasVendas.length - 1]; PedidoDTO pedidoDTO = new PedidoDTO(); pedidoDTO.setId(atual.getId()); pedidoDTO.setNomeCliente(atual.getCliente().getNome()); pedidoDTO.setNomeFormaPagamento(atual.getFormasPg().getNomeFormaPg()); pedidoDTO.setNomeVendedor(atual.getVendedor().getNome()); pedidoDTO.setLocalEntrega(atual.getLocalEntrega()); tamanho = atual.getItensVendidos().length; for (int i = 0; i < tamanho; i++){ ItemVendido itemVendido = atual.getItemVendido(i); ItemPedidoDTO itemPedidoDTO = new ItemPedidoDTO(); itemPedidoDTO.setId(itemVendido.getId()); itemPedidoDTO.setNomeLivro(itemVendido.getLivro().getNome()); itemPedidoDTO.setPrecoUnitario(itemVendido.getPreco()); itemPedidoDTO.setQtd(itemVendido.getQtd()); itemPedidoDTO.setTotal(itemVendido.getValorTotal()); pedidoDTO.adicionaItemPedido(itemPedidoDTO); } return pedidoDTO; }} 79