1. Abel Gonçalves da Silva
abelspquissa@hotmail.com
Bruno Gomes Nascimento Arueira
brunoarueira@hotmail.com
Luciano da Silva Barreto
lbarreto.pc@gmail.com
CAMADA DE SERVIÇOS: UMA ABORDAGEM ALTERNATIVA DE ACESSO A
OBJETOS DE DOMÍNIO EM ARQUITETURA MULTICAMADAS
Universidade Candido Mendes – UCAM
Campos dos Goytacazes – RJ

2. 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 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

3. 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 MULTICAMADAS
Monografia aprovada em ____/____/____ para obtenção do título de Bacharel em
Sistemas 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

4. 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

5. AGRADECIMENTOS
Agradeço a Deus por me dar sabedoria e forças para superar esse período de
graduação, me oferecendo a oportunidade de fazer sempre o melhor para mim e minha
família.
À minha família Silvio, Salete e Matheus que sempre me passaram confiança e
forças para lutar pelos meus objetivos. A todos meus parentes que me ajudaram em
suas orações. Aos meus amigos com tantas ajudas com apoios às vezes até maior do
que a necessidade.
À Prefeitura Municipal de Quissamã que me ajudou financeiramente possibilitando
a realização deste sonho.
Ao nosso orientador professor Msc. Mark Douglas de Azevedo Jacyntho por toda
paciência e sabedoria na conclusão de nosso projeto.
À instituição Candido Mendes pela grandiosa estrutura oferecida para o melhor do
nosso ensino.
Abel Gonçalves da Silva
iv

6. 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 pelos
conselhos, pela paciência e pelos ensinamentos.
Ao professor Antônio Carlos de Andrade Brito que me auxiliou - e muito - em
várias etapas do meu trajeto pela faculdade devido a um estágio que fui indicado por
ele.
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 muito
agradecido.
Bruno Gomes Nascimento Arueira
v

7. 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 pelos
conselhos, 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 muito
agradecido.
A todos os meus colegas de serviço, policiais civis ou não, pelo apoio durante esta
caminhada.
Luciano da Silva Barreto
vi

8. “Saber e não fazer ainda é não saber.”
(Lao Tse)
vii

9. RESUMO
A Internet, mais especificamente a World Wide Web, revolucionou a forma de
comunicação no mundo. Rapidamente as aplicações web evoluíram de sites puramente
informacionais e estáticos para sistemas de informação altamente transacionais e
complexos voltados a realização de negócios. Neste cenário, ubiqüidade (a
possibilidade de acessar a aplicação usando diferentes tipos de dispositivos e em
contextos distintos de uso) e interoperabilidade entre sistemas têm mostrado
propriedades 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. Tal
comunicação facilitaria a mobilidade dos usuários.
Esta monografia inicia-se com o estudo da chamada Arquitetura de Serviços (em
inglês, SOA - Service Oriented Architecture), seguido pela proposição de uma camada
de serviços e, por fim, um protótipo de um sistema para uma livraria, a fim de atestar o
que foi discutido.
Palavras-chave: SOA, serviços, web services, Java EE, Java ME
viii

10. ABSTRACT
The Internet, more specifically the World Wide Web, has revolutionized the
communication way in our world. Quickly the web applications have evolved from purely
informational and static web sites to highly complex transactional information systems
focused in conducting business. In this scenario, ubiquity (the possibility to access the
application using different types of devices in different contexts of use) and
interoperability between systems have been important properties to be considered in the
design of applications today.
In this way, this work presents to provide an alternative to communicate through
the web which offers portability, security and efficiency in its use. This communication
would facilitate the mobility of users.
This dissertation begins with the study of the so-called Service Oriented
Architecture (SOA), followed by the proposal of a service layer and, finally, a prototype
of a bookstore system, in order to certify what was discussed.
Keywords: SOA, services, web services, Java EE, Java ME
ix

11. LISTA DE SIGLAS
1. 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

12. LISTA DE FIGURAS
Figura 2.1 Atores, objetos e operações de web services 10
Figura 2.2 Exemplo de XML 10
Figura 2.3 Estrutura da mensagem SOAP 12
Figura 2.4 Requisição SOAP 13
Figura 2.5 Resposta SOAP 13
Figura 3.1 Estrutura de um Facade 19
Figura 3.2 Organização da camada de serviços e as formas de acesso a esta 20
Figura 4.1 Representando a plataforma padrão Java (baseado na plataforma 25
Java 2)
Figura 4.2 Figura mostrando o funcionamento do framework Axis 28
Figura 5.1 Diagramas de caso de uso do projeto 34
Figura 5.2 Diagrama de caso de uso para efetuar pedido 34
Figura 5.3 Diagrama de caso de uso de catálogo 35
Figura 5.4 Representa o diagrama de domínio 37
Figura 5.5 Representa o diagrama de design de domínio 39
Figura 5.6 Apresenta o diagrama de finders 41
Figura 5.7 Alude a implementação da transferência dos dados no sistema 42
Figura 5.8 Ilustra a implementação da camada de banco de dados 44
Figura 5.9 Demonstra a implementação da camada de serviços 46
Figura 5.10 Apresenta a dinâmica do serviço de catálogo de livros 48
Figura 5.11 Busca pelo Código 50
Figura 5.12 Busca pelo ISBN 52
Figura 5.13 Busca pelo Gênero 54
Figura 5.14 Busca pelo Nome 56
Figura 5.15 Revela o diagrama de seqüência de efetuar pedido 57
Figura 5.16 Conectando o cliente ao servidor para utilizar os serviços 59
Figura 5.17 Cria os pedidos na camada de domínio de cliente 60
Figura 5.18 Formatação de chamada e resposta do servidor no padrão DTO 61
Figura 5.19 Diagrama de classe relacionado às telas para interação com o 62
sistema
xi

13. Figura 5.20 Tela inicial do protótipo 63
Figura 5.21 Tele inicial de catálogo 64
Figura 5.22 Tela com formulário para ver detalhes ou fechar o pedido 65
Figura 5.23 Tela para efetuar o pedido 66
Figura 5.24 Tela para efetuar uma busca 67
xii

14. SUMÁRIO
1. Introdução.......................................................................................................... 1
2. 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................................................................................. 16
3. 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..................................................... 22
4. 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............................................................................................. 31
5. 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

15. 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............................................... 62
6 . Conclusão.......................................................................................................... 68
6.1 Trabalhos Relacionados............................................................................... 69
6.2 Trabalhos Futuros......................................................................................... 70
Referências............................................................................................................. 72
APÊNDICE A........................................................................................................... 76
xiv

16. 1. Introdução
Com o advento da comunicação entre os computadores e a crescente
necessidade de interoperabilidade entre as aplicações computacionais, várias
alternativas vêm sendo criadas para tal propósito, tendo em mente a facilidade
de reuso e a manutenibilidade. Dentre estas várias propostas, uma delas é
denominada Service Oriented Architecture (SOA) [OASIS Consortium] que vem
apresentando destaque. Esta arquitetura apresenta muitas tecnologias para a
sua implementação. Este trabalho se baseia em web services que se
enquadram em uma dessas tecnologias para desenvolvimento de um projeto
SOA.
Assim como em outras áreas da computação, a arquitetura em camadas
tem presença marcante no desenvolvimento de software. Nesta arquitetura,
cada camada possui uma responsabilidade e provê serviços para as camadas
superiores. Assim, primeiramente foi desenvolvida uma estrutura baseada em
duas camadas, comumente conhecida como cliente-servidor.
Esta estrutura tinha basicamente, no cliente, a aplicação com toda lógica
de negócio, interação entre requisitos de aplicação e de negócio embutidos que
acessavam por sua vez um servidor o qual apresentava apenas uma fonte de
dados onde eram concentrados todos os dados.
Esse formato de camadas ainda é muito utilizado, porém há um grande
problema nesta abordagem. Se um dado é alterado no servidor, todas as
aplicações que dependem deste devem ser alteradas, pois a estrutura interna
da aplicação cliente terá que trabalhar com esse novo tipo de dado
ocasionando uma varredura interna da aplicação para alteração tanto do dado
quanto 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 sendo
utilizada. Isto caracteriza um acoplamento forte.
Um exemplo bem clássico deste acoplamento forte são os sistemas
antigos ou legados de uma empresa, feitos num único processo de
desenvolvimento, que não oferecem facilidade para incluir novas aplicações em
consonância com as rápidas mudanças do negócio. Isto retrata significante
contraste com as modernas técnicas de desenvolvimento de software. A
dinâmica para criar novas aplicações e cooptá-las num mesmo sistema
1

17. fazendo com que todas, as existentes e as recentes, funcionem em perfeita
harmonia é o melhor caminho a seguir. E isso tange outro caminho que não o
da arquitetura em duas camadas.
Diante desta problemática, fora proposto um novo estilo arquitetural de
software em três camadas. Este novo modelo de aplicação solucionou o
problema do formato anterior, passando a apresentar uma camada orientada à
fonte de dados (antes concentrada no servidor como uma fonte de dados
comum), uma camada intermediária direcionada a toda a lógica de negócio de
domínio (com intuito de concentrar todas as possíveis interações necessárias
ao negócio) e outra camada onde residem as inúmeras aplicações que
acessam os serviços comuns oferecidos pelos objetos de domínio.
Estas três camadas são de caráter principal, ou seja, podem variar em
mais algumas camadas, contudo as possíveis variações não perdem a
responsabilidade nestas principais camadas.
Para facilitar a reutilização e manutenção que se espera de uma aplicação
desenvolvida em três camadas, uma destas camadas (a camada de domínio) é
concentrada em um servidor de aplicação onde todas as aplicações clientes
acessam. 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, provendo
todo o comportamento (serviços) de domínio e isolando as várias aplicações de
possí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 a
aplicação estar bem divida em suas respectivas camadas, a camada de
domínio deve ter uma atenção especial.
Esta atenção deve-se ao fato de que uma camada de domínio bem
organizada, ou seja, bem modelada sugere um acoplamento fraco entre
quaisquer partes da aplicação, devido ao fato dos relacionamentos serem feitos
conhecendo-se conceitos/abstrações, onde uma mudança qualquer em algo
concreto não interfere no resto da aplicação, além de tornar mais
compreensível à criação das outras camadas.
Então, sugere-se ao desenvolver um sistema computacional com as
características elencadas acima, que modele com muito cuidado a lógica de
domínio para que uma aplicação apresente acoplamento fraco. Onde, por
2

18. 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 empresa
sofrer 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ça
no sistema com algumas poucas alterações no código e/ou inclusão de
algumas aplicações.
Neste contexto, o engenheiro de software desenvolverá componentes ou
aplicações que representarão serviços. O âmago de cada serviço será uma
função que retratará alguma parte da lógica de negócio da empresa. Esses
serviços serão reutilizados em várias outras aplicações. No entanto, não se
devem banalizar os serviços com meras funcionalidades que nada têm a ver
com a lógica do domínio em si. Um serviço não é uma função onde um vetor de
nomes é organizado em ordem alfabética. Mas sim uma função que represente
uma parte importante do negócio, como por exemplo, o cadastro de clientes no
sistema. O serviço de cadastro, se mantidas suas entradas e saídas o mais
genérico possível, será, com certeza, reutilizado para cadastros de outros
dados na aplicação.
A reutilização dos serviços que já existem na própria organização ou no
exterior resultará na redução significativa do esforço de desenvolvimento de
aplicações e, portanto, dos custos. Os benefícios de reutilização crescem
dramaticamente à medida que mais serviços são construídos e incorporados
nas diferentes aplicações.
O objetivo deste trabalho é justamente a criação de uma camada de
serviços (Service Layer) [Fowler et al, 2002] sobre a camada de domínio,
provendo uma forma alternativa para aplicações acessarem os objetos de
domínio. Para a implementação desta camada foi escolhida a tecnologia de
web services. Sem esta camada de serviços a única forma das aplicações
acessarem a camada de domínio é o approach tradicional de orientação a
objetos por meio de chamadas de operações em objetos. Já com esta camada
a flexibilidade de acesso torna-se maior, usando protocolos baseado em
Extensible Markup Language (XML) [WWW Consortium, 2007], diminuindo
ainda mais o acoplamento e facilitando a interoperabilidade.
3

19. Organização da Monografia
A seguir será apresentada uma pequena descrição a respeito do que se
trata cada capítulo que esta monografia é composta.
O segundo capítulo trata da tecnologia SOA. A arquitetura abrange
conceitos de extrema importância e grande utilidade. Um destes conceitos é o
serviç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 Layer
utilizada pela tecnologia SOA. Será exposto, de forma detalhada, o conteúdo
do projeto.
O quarto capítulo versa sobre as tecnologias envolvidas nesse protótipo.
No quinto capítulo é mostrado um exemplo prático que demonstre a
proposta a qual este estudo se destina a apresentar, desde SOA (passando por
serviços, web services e outras características da arquitetura) até o assunto
retratado no terceiro capítulo.
Por último, no sexto capítulo provê as considerações finais, mostrando
alguns trabalhos relacionados e futuros.
4

20. 2. Service Oriented Architecture (SOA)
A Arquitetura Orientada a Serviços não é um conceito novo. Na
década de noventa a empresa SUN definiu SOA para descrever a tecnologia
Jini [Conexão Jini], que é um ambiente para descoberta dinâmica e o uso de
serviços sobre uma rede. Ou seja, uma tecnologia para facilitar a manutenção
de redes onde existam competências e necessidades.
SOA está emergindo como a primeira integração e framework de
arquitetura no ambiente de computação complexa e heterogênea dos dias
atuais. Tentativas anteriores não apresentaram soluções de interoperabilidade
abertas, pois confiaram em Application Programming Interface (API), que é um
conjunto de rotinas e padrões estabelecidos por um software para utilização de
suas funcionalidades proprietárias. Tendo exigido, assim, um alto grau de
coordenação entre os grupos.
Essa tecnologia terá um papel decisivo nas organizações
empresariais viabilizando a execução de processos de forma que possam
negociar de maneira mais eficaz, e adaptarem-se às necessidades variáveis e
competitivas do mercado, desde que o software seja baseado no conceito de
componentes. SOA desencadeia o acoplamento fraco entre estes
componentes a fim de que os mesmos possam ser reutilizados. E esta
reutilização é um marco muito importante na velocidade do desenvolvimento de
sistemas, pois viabiliza a facilidade de se desenvolver aplicações mais
rapidamente. Outra característica importante da Arquitetura Orientada a
Serviços é o alto nível de flexibilidade fornecido às aplicações, permitindo maior
interoperabilidade entre as aplicações heterogêneas. Estes componentes de
software 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) e
algué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

21. O serviço é uma funcionalidade, mais ampla, pertinente à lógica do
negócio. Ou seja, um componente de software, com interface bem definida
(como chegar à oficina de pintura para pintar o automóvel) e implementação
independente de outros serviços (o serviço de pintura do veículo é
independente de um serviço mecânico, por exemplo), que representa uma
função do sistema computacional (a pintura seria uma parte do sistema de
recuperação do veículo). Este componente deve ser stateless, isto é, não
depender de nenhuma condição pré-existente, seja do cliente ou de outros
serviços. Tais serviços serão consumidos por clientes ou por outros serviços (o
serviço de pintura primeiramente faz uso do serviço de lanternagem do auto). A
tecnologia utilizada para prover o serviço, tal como numa linguagem de
programação, não pode fazer parte de sua definição.
Um serviço é disponibilizado por um provedor de serviços, entretanto
os clientes podem não saber da existência do serviço. A implementação de um
serviç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 os
comportamentos deste e/ou as informações solicitadas tencionam identificar
quando um serviço é apropriado para o cliente.
Para um consumidor (cliente) solicitar um serviço a um provedor de
serviços é necessário que os dois extremos se enxerguem. Na tecnologia SOA,
essa visibilidade tem que ser enfatizada, pois não é axiomático que os
partícipes possam ver uns aos outros. Estes precisam conhecer o requisitante
e vice-versa, a fim de poderem apontar qual serviço desejam usar e receber a
resposta do serviço requisitado.
O provedor e o consumidor têm que possuir a informação sobre a
existência do outro. Logicamente, o iniciante deve ter conhecimento de quem
responderá. Uma iniciação bem sucedida é, muitas vezes, satisfatória para
informar a quem vai responder a existência de quem iniciou. A consciência da
existê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 de
todos os serviços disponíveis. Em contrapartida, um consumidor pode difundir
a necessidade de um serviço com intuito de ser respondido pelo serviço mais
apropriado ou percorrer o diretório onde estão publicados os serviços. Assim
sendo, o consumidor precisa conhecer as descrições dos serviços para avaliar
6

22. quando um destes é pertinente à sua necessidade. Seja por parte do provedor,
publicando as descrições, ou por parte do consumidor requisitando as
descrições existentes.
A descrição do serviço é a informação necessária para usá-lo. Seria
uma espécie de manual. O propósito da descrição é facilitar a visibilidade (fazer
com 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 os
participantes estão em domínios proprietários diferentes.
É possível, também, distinguir entre os participantes para a interação
do serviço, saber como acessá-lo e negociar sobre as funcionalidades
específicas deste. A descrição deve ser representada de forma padrão. O
conceito de SOA admite a utilização de um serviço sem que o consumidor
tenha conhecimento de como o mesmo foi implementado. A descrição torna
disponíveis informações cruciais para o consumidor decidir pelo uso ou não do
serviço. Um consumidor de serviços necessita saber que o serviço existe e
está 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 as
políticas como relatadas pelo próprio consumidor e, por último, deve saber
como interagir com o serviço a fim de alcançar os objetivos, incluindo o formato
e conteúdo da informação trocada entre o serviço e o consumidor e as
seqüências que podem ser esperadas.
A ação mútua entre o serviço e o consumidor pode depender de
políticas documentadas na descrição do primeiro. A concordância por parte do
provedor e do consumidor para interagir não significa que há aprovação para
executar 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 consumidor
de serviços.
2.2 Vantagens e Desvantagens
Uma das grandes vantagens desta arquitetura é a possibilidade de
olhar as aplicações sob o enfoque de processos de negócio, adequando-as aos
diversos contextos corporativos. Desta forma, passa-se a entregar o conteúdo
7

23. de negócios de uma maneira completamente diferente do paradigma
tradicional.
Esses processos de negócios nada mais são do que os serviços. O
serviço promove reuso de partes da aplicação e isso promove flagrante
diminuição de esforço no desenvolvimento de sistemas, diminuindo
drasticamente o tempo de criação e expansão destes e extremo declínio dos
custos. Tudo o que uma empresa necessita.
Outra relevância da SOA é sua interoperabilidade entre todas as
tecnologias do mercado. Isso significa dizer que os usuários não precisarão se
preocupar com o uso de várias tecnologias distintas. Ou seja, utilização de
diferentes plataformas numa mesma aplicação.
O acoplamento fraco é outro benefício da Arquitetura Orientada a
Serviços, pois trabalha com contratos. Clientes conhecem abstrações de algo e
nã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 os
relacionamentos da lógica de negócio, refletindo-os com extrema nitidez. É fácil
confundir 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 de
dados e não é bem assim, haja vista toda a discussão sobre serviços
anteriormente.
Outro detalhe negativo é que os sistemas existentes ou legados, não
podem ser mudados de um dia para o outro. Afinal, são aplicações ativas e
isso acarretaria erros em efeito cascata para todo o sistema. É preciso analisar
cada sistema legado em separado e o processo de negócio que eles
representam.
Resumindo, os serviços devem ser coesos, ou seja, bem definidos
proporcionando clareza na sua criação e também devem ser o mais fracamente
acoplados possível.
2.3 Web Services
Um processo de negócio bem definido e de clara importância para as
transações da empresa tornar-se-á um serviço, no tocante à implementação do
8

24. software. Este serviço que pode ser acessado pela Web (seja internet, extranet
ou intranet) constitui um web service. Os padrões que constituem a proposta de
web 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 e
distribuíam para cada aplicação que necessitasse utilizar o sistema. O caos
surgia quando havia alguma alteração nas bibliotecas. A empresa, então, teria
que redistribuir os arquivos para todos os usuários de seu sistema. Com a
instituição do web service os usuários do sistema que “buscavam” os dados
pertinentes ao negócio que pretendiam realizar acessavam os serviços
disponibilizados na web e usufruíam de suas funcionalidades. Outra vantagem
importante é que essa busca independe da tecnologia usada no consumidor e
no 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 a
preocupação de como é implementada. Há uma chamada de um cliente a um
web service e, por conseguinte, há uma resposta.
No entanto, há que se ter em mente alguns detalhes quanto ao
desenvolvimento de um web service e de sua utilização baseada em serviços.
É preciso: uma forma comum de representar os dados; uma formatação de
mensagem comum e extensível; um padrão da descrição do serviço comum e
extensível; um mecanismo para encontrar os provedores de serviços.
Então, observa-se que web services representam uma nova
ideologia 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

25. 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áginas
utilizadas via browser através de tags já definidas, ao contrário do XML com o
qual pode se definir novas tags para serem utilizados para o devido fim.
Com isso o padrão adotado na representação dos dados é a
linguagem XML que é definida como o formato universal para dados
estruturados na web. Com XML é possível: descrever dados (1); apresentar
dados em algum formato (2); transportar dados (3); e trocar dados entre
plataformas diferentes (4).
Abaixo segue um exemplo de XML representando informações de
um 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

26. Não é surpresa o grande número de tecnologias atualmente que se
baseiam na utilização do XML.
Assim, para um consumidor (cliente do web service) que esteja
funcionando com a tecnologia .NET [.NET Framework, 2007] e quer acessar
um Web Service (provedor de serviços) que foi implementado em Java EE
[Enterprise Edition, 2007], não haverá problema, pois as duas tecnologias
conhecem 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 do
Simple Object Access Protocol (SOAP) [W3C-SOAP, 2007] que é um protocolo
simples para a troca de informações entre aplicações e tem por finalidade
invocar aplicações remotas através de Chamadas Remotas de Procedimento -
Remote Procedure Calls (RPC) ou trocar mensagens independentes das
plataformas do requisitante e do respondente.
Portanto, SOAP é um padrão já aceito para ser utilizado em web
services e visa garantir total interoperabilidade entre diferentes aplicações,
utilizando XML.
11

27. 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

28. Na figura 2.4 se apresenta um modelo de uma requisição SOAP e logo
em 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 pelo
envelope, indispensável para se definir uma mensagem SOAP como citado
anteriormente, e body, outra parte também indispensável, onde na primeira
mensagem (requisição) o body contém uma chamada de um serviço com uma
passagem de um parâmetro e na segunda mensagem (resposta) o serviço
respondendo a sua chamada.
13

29. A troca de mensagens SOAP pode ser feita de duas maneiras, são
elas: 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 espera
um retorno. Ao contrário do modo request/response que é síncrono, onde é
enviada uma mensagem de request (requisição) e espera-se uma mensagem
de response (resposta). Estas duas abordagens são padrões para troca de
mensagens 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 Services
Description Language (WSDL) [W3C-WSDL, 2007] que é uma linguagem que
descreve 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 entre
cliente (potencial consumidor do serviço) e o provedor de serviços, utilizando
XML em um esquema próprio.
Estes descritores são processados por ferramentas computacionais
de forma automática, então não há necessidade de escrita ou leitura de forma
manual.
O WSDL é dividido em dois grupos de definições: definição abstrata
e 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

30. • 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á o
serviço, a fim de usufruir sua funcionalidade. Para tanto, o Universal
Description, Discovery, and Integration (UDDI) [OASIS-UDDI, 2007], que é uma
especificaçã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 a
uma lista telefônica, onde ao se pesquisar um registro UDDI pode se encontrar
empresas/organizações e seus respectivos web services.
Um diretório UDDI pode ser acessado através de SOAP tornando-o
també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 esta
especificaçã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

31. • 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 dados
e aplicações. Com web service, publica-se serviços de forma simples, que são
totalmente desconectados dos objetos de dados e só enviam a resposta
necessária ao consumidor do serviço. Isso elimina a necessidade de expor
tabelas de dados completas, sendo assim um modo mais seguro de atuação.
Algumas desvantagens dos web services são que o uso de
mensagens em XML implica em um desempenho inferior. E as implementações
em SOAP, ainda, não estão cem por cento compatíveis com todas as
tecnologias.
16

32. 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, design
patterns). A seguir são abordados os dois padrões que servem como base para
a idéia proposta: Facade [Gamma et al, 2000] e Service Layer [Fowler et al,
2002]. Por fim, é definida a proposta do trabalho propriamente dita, mostrando
o 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 de
um projeto de software orientado a objetos é difícil, porém um projeto que seja
reutilizável e flexível é mais complexo ainda, pois dentro de um projeto deve-se
encontrar partes que são comuns a todos e então defini-las no nível correto de
granularidade para que estas facilitem a reutilização.
Alguns projetistas começaram a perceber que certas definições e
planejamentos de um projeto poderiam ser reutilizados em outros projetos,
levando em consideração algumas alterações pertinentes ao projeto em
questão. Nesse âmbito, surgem os padrões de projeto, que são soluções
reutilizáveis para projetos de software, em especial, orientado a objetos.
A idéia original de reuso de padrões surgiu no campo da construção
civil, 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áveis
de software orientado a objetos em um livro para expor suas experiências a
todos, definindo, na verdade, um catálogo de padrões de projeto.
Posteriormente, estes autores também passaram a ser conhecidos pelo termo
Gang of Four (GoF), ou seja, gangue dos quatro.
17

33. De acordo com a Gof, existem dois tipos de classificação dos
padrões, a saber: a primeira em relação ao propósito (o que o padrão faz) e a
segunda especifica o escopo (onde é aplicado).
Com relação ao propósito, têm-se os padrões de criação, os
estruturais e os comportamentais. E se tratando do escopo podem ser
separados em nível de Classe ou Objeto (onde classe significa uso de herança
e objeto implica no uso de composição e/ou agregação).
Os padrões de criação definem como é feita a criação/instanciação
de objetos concentrando esta responsabilidade em um único lugar e de forma
abstrata.
Os padrões estruturais são voltados para a forma como classes e
objetos se inter-relacionam para compor estruturas maiores.
E por último, temos os padrões comportamentais que têm a
característica de atribuir inteligentemente responsabilidades a objetos e definir
a colaboração entre eles, determinando assim seus comportamentos.
Mas além da classificação citada anteriormente, há uma
desenvolvida por Steven John Metsker [Metsker, 2004], que organiza os
padrões por sua intenção: interface, responsabilidade, construção, operações e
extensão.
3.2. Facade
Facade é um padrão de projeto classificado por GoF como estrutural
de objetos e por John Metsker como interface. Este padrão tem o propósito de
encapsular subsistemas e/ou esconder determinadas funcionalidades para as
camadas superiores, com a finalidade de coibir o acesso a classes específicas
do sistema dando mais segurança ao mesmo ou facilitando o uso de processos
de 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 mais
simples, de granularidade mais grossa, que esconde os detalhes internos do
subsistema. Um subsistema, por definição, tem vários relacionamentos entre
classes que colaboram entre si e cada classe desempenha um papel único.
Portanto o acesso direto a este subsistema seria bem complexo devido a
18

34. grande quantidade de componentes de granularidade fina (vide figura 3.1).
Com isso alguém que dependesse da utilização do subsistema, caso não
houvesse um Facade, teria que conhecer todo o corpo interno do mesmo,
aumentando a complexidade de uso e quebra do encapsulamento, pois o
usuário dependeria diretamente da estrutura interna e poderia facilmente ser
atingindo 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 se
deve apenas pensar em atender as funcionalidades que ele deve facilitar o
acesso, deve-se também analisar as possíveis saídas das solicitações sendo o
ideal colocar os tipos mais primitivos ou comuns possíveis.
3.3. Service Layer
Segundo Randy Stafford [Fowler et al, 2002], service layer define a
fronteira da aplicação com uma camada de serviços que estabelece um
conjunto de operações e coordenam, em cada operação, as respostas da
aplicação. Na figura 3.2 pode-se observar onde a Service Layer se localiza em
relação às outras camadas.
19

35. 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ção
entre sistemas heterogêneos. O acesso à lógica de negócio pode ser bastante
complexo, envolvendo transações e coordenação de vários objetos no
tratamento de uma requisição. Para cada interação que se faz, criar uma
interface provoca inúmeras duplicações de etapas que são comuns a muitas
operações.
Pode-se dizer que service layer define uma interface para camadas
clientes, encapsulando a lógica de negócio da aplicação, controlando
transações e coordenando responsabilidades em suas respectivas
implementações.
20

36. Existem designers, que diferenciam a lógica de negócio em dois
tipos. O primeiro seria a representação da lógica de domínio, que representa a
essência do problema que o sistema tende a resolver e o segundo seria a
lógica de aplicação que apresenta um design voltado a atender as
responsabilidades de uma aplicação específica.
Basicamente, há duas formas de implementar esta camada: facades
de domínio e script de operações (aqui também chamados de facades de
aplicação). Os facades de domínio não implementam nenhuma lógica de
negócio, sendo em geral stateless, ou seja, não guardam estado interno
nenhum e, por sua vez, todas as requisições feitas a eles são repassadas a
objetos de domínio pertinentes. Já os facades de script (ou aplicação)
implementam a lógica específica de aplicação, delegando para objetos de
domínio encapsulados, responsabilidade comum ao domínio e independente
de aplicação particular.
Outro aspecto muito importante a ser considerado é a decisão de
fazer esta camada distribuída ou local, ou seja, se a service layer irá atender
somente a estrutura interna de uma aplicação fazendo interface de operações
entre 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 a
inúmeros relacionamentos que este pode ter. Uma alternativa para utilização
distribuí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 a
quantidade de informação dos objetos a ser transferida remotamente entre
camadas. Porém estes DTOs terão que ser muito bem definidos, pois uma
outra camada ou aplicação remota só irá conhecer sua interface e não o objeto
real que ele representa.
Estes objetos de transferência servem tanto para as saídas dos serviços
definidos na camada como para entrada de dados. Lembrando que a noção
entre o que é serviço e operação já fora denotado em capítulo anterior.
21

37. 3.4. Paralelo entre Facade e Service Layer
Após a explicação do que sejam Facade e Service Layer, este tópico
mostra como eles podem ser usados em conjunto. Os dois conceitos se
complementam permitindo definir um sistema baseado em serviços muito bem
estruturado e flexível.
Como há a separação de responsabilidades entre o que é de
aplicação e de domínio, os Facades também se dividem dessa forma. No qual
Facade de aplicação conhece processos e como determinada atividade
específica deve ser feita dentro da aplicação, ao passo que o Facade de
domí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 de
aplicação acessam facades de domínio e, se for necessário, podem acessar
diretamente objetos de domínio.
A idéia deste trabalho é definir uma camada de serviços que forneça
acesso 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) e
para cada facade, em um relacionamento um para um, é definido o
correspondente web service. Então, quando os web services forem
requisitados pelo cliente haverá uma delegação aos respectivos Facades, onde
cada 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 facilita
o acesso à estrutura interna da aplicação, deixando visível somente a
funcionalidade definida por ele e, por conseguinte, vem ao encontro do acesso
alternativo a objetos de domínio por meio de web services, muito útil na
questão da computação ubíqua.
22

38. 4. Tecnologias e ferramentas do projeto
O foco deste capítulo são as tecnologias e ferramentas que foram
utilizadas 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), [Java
Wireless Toolkit, 2007] o Jude UML [Jude, 2007] (ferramenta para modelagem),
a IDE Eclipse [Eclipse, 2007], além de plugins que auxiliam no
desenvolvimento.
4.1. Java
No começo da década de noventa, linguagens como C eram muito
utilizadas no desenvolvimento de sistemas computacionais, entretanto a
obrigação de depender diretamente do desempenho do hardware era fator
crítico e vertente a ser banida com o passar dos anos. Destarte, a Sun
Microsystens, através de seus programadores, desenvolveu um protótipo de
linguagem de programação chamada Star Seven. O objetivo da empresa era
oferecer ao mercado uma linguagem para a produção de softwares visando
produtos eletro-eletrônicos como forno de microondas, agendas eletrônicas etc.
Alguns anos mais tarde o projeto foi rebatizado para Oak, que significa
carvalho em português e era a árvore que James Gosling, idealizador do
projeto, via de seu escritório quando olhava pela janela. Contudo, em 1994 a
Sun descobriu que o nome Oak já estava registrado e rebatizou-a para Java. O
objetivo foi cumprido e os desenvolvedores, acompanhado a curva ascendente
da 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 a
web.
A popularização de Java emergiu no momento em que a Sun desenvolveu
o HotJava. Um navegador web que fazia a inteface entre o sistema operacional
e a linguagem. A partir daí, grandes empresas como a IBM e outros
navegadores web passaram a dar suporte a Java.
23

39. Desde seu lançamento, a plataforma Java foi adotada mais rapidamente
do 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 todo
mundo. Continuou e continua crescendo e hoje é com certeza um padrão para
o mercado oferecendo qualidade, performance e segurança. Java tornou-se
popular pelo seu uso na Internet e hoje possui seu ambiente de execução
presente em web browsers, mainframes, sistemas operacionais, celulares,
palmtops, cartões inteligentes, entre outros.
Java tem como características: a portabilidade que tange a finalidade
precípua da linguagem que é desenvolver softwares que possam rodar
independentemente da plataforma base, a simplicidade que é o fato de a
linguagem ter várias bibliotecas que fornecem grande parte das
funcionalidades, ser baseada no paradigma orientado a objetos promovendo
reuso e modularização de um sistema, segurança que reflete o processo de
compilaçã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 e
aplicações distribuídas que é o conjunto de classes que a linguagem possui
para criação de protocolos, uso de sockets, acesso a URL, criação de clientes
e servidores. Para permitir melhor desempenho acerca de código, Java permite
programação em threads (processos que ocorrem simultaneamente).
Como a Sun Microsystens reconhece, é difícil – senão impossível – que
uma mesma plataforma se ajuste a todos os tipos de dispositivos. Agruparam,
portanto, as tecnologias Java em três edições, cada uma focada em um
determinado segmento computacional.
A seguir uma explicação básica sobre as três diferentes plataformas do
Java e pode ser visualizada através da figura 4.1 as plataformas distintas
existentes.
24

40. 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 de
programação Java voltado para o desenvolvimento de aplicações desktop e
servidores. Muito utilizado, pois além de ser o carro-chefe os outros segmentos
JME [Micro Edition, 2007] e JEE [Enterprise Edition, 2007] são ambientes
derivados do primeiro.
Java Micro Edtion – JME destina-se à construção de aplicações a fim de
funcionarem em aparelhos móveis: celulares, palm-tops etc. Este ambiente
possui bibliotecas destinadas ao uso de aparelhos portáteis. Para tanto, basta
o equipamento possuir uma JVM (Java Virtual Machine) e hardware compatível
com softwares Java. Os telefones móveis mais modernos já utilizam Java em
larga escala.
Java Enterprise Edition – JEE é o ambiente destinado à criação de
softwares que utilizarão a Internet, Intranet ou mesmo apenas redes físicas de
dados. 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

41. com Enterprise Java Beans – EJB [Tecnologia EJB, 2007] . Este trabalho utiliza
o ambiente JEE para o desenvolvimento da aplicação.
A mais nova API para web services da plataforma Java EE 5 [Enterprise
Edition, 2007] é a JAX-WS 2 [API - Web Service, 2007] que permite aos
serviços disponibilizados na rede mundial de computadores, total utilização dos
esquemas XML, por conseguinte maior interoperabilidade e facilidade de uso.
Antes da eclosão da tecnologia Java EE 5, a definição de um web service
requeria descritores longos e difíceis de manejar. Agora não, pois todos os
métodos públicos na classe são publicados automaticamente como operações
de web service e todos os argumentos são mapeados para tipos de dados do
esquema XML.
4.2. Apache Tomcat
O Apache Tomcat é um servidor de aplicações para aplicações Java na
web. Este é distribuído como software livre e desenvolvido como open source
pelo projeto Apache Jakarta [Apache, 2007]. Atribuído como Referência de
Implementação Oficial para as tecnologias Java Servlet e JavaServer Pages
que são especificações desenvolvidas pela Sun e pertencem à Java
Community Process [JCP, 2007].
O Tomcat é utilizado, por importantes sistemas web de grandes
organizações, em larga escala por ser robusto e eficiente.
Este projeto não utiliza, em sua totalidade, o servidor de aplicações. O
que interessa no momento é o container para aplicações web, pois a aplicação
exemplo 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árias
aplicações, ou seja, é uma API bem definida e tem o objetivo de promover
reutilização de uma solução de arquitetura de software, que contém
componentes caixas-brancas e caixas-pretas. Os componentes caixas-brancas
são reutilizados a partir de herança de classes e override de métodos. Os
26

42. caixas-pretas têm sua reutilização promovida a partir de interfaces definidas
para 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 na
linguagem Java e no padrão XML que permite a construção de clientes e
servidores baseados em web service utilizando o protocolo SOAP, ou seja,
através deste framework é possível desenvolver aplicações distribuídas. Além
da 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ística
muito relevante na escolha de uma implementação de SOAP. O Axis é um dos
poucos frameworks que conseguem fazê-lo de maneira transparente para o
cliente do serviço, por isso é altamente recomendado na construção de Web
Services.
27

43. 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 para
desenvolvimento de aplicações Java visando dispositivos portáteis compatíveis
com as especificações Java Technology for the Wireless Industry (JTWI) [JTWI,
2007] e Mobile Service Architecture (MAS) [Java MAS, 2007] que implementa
as seguintes capacidades expostas através de APIs padronizadas, as quais
sã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

44. • 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 Specification
Request) 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 UML
4.5.1 UML (Unified Modeling Language)
O Surgimento da UML [OMG-UML, 2007] entre os anos de 1990 e 1997
veio 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 que
provaram ter sucesso na modelagem de sistemas grandes e complexos, então,
James Rumbaugh e Ivar Jacobson juntaram-se a Grady Booch na Rational
Software Corporation para unificar seus enfoques e formaram o grupo dos
parceiros e submeteram a versão 1.0 da UML. A UML é uma linguagem para
especificação, construção, visualização e documentação de sistemas. A versão
atual é 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 uso
fácil e intuitivo. Com a IDE JUDE é possível realizar uma modelagem de dados
complexa, 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

45. das ferramentas grátis mais poderosas disponível atualmente, escrita 100% em
Java/Swing.
4.6. Eclipse
Poderosa plataforma de software livre para desenvolvimento de
sistemas. Existem extensões do Eclipse, em software livre, desenvolvidas
como projetos Eclipse ou independentes, especializadas para outras
linguagens 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 de
programação, mas sim uma plataforma eficaz na qual é possível configurar o
ambiente a fim de desenvolver sistemas em determinadas linguagens.
A seguir serão mostrados vários plugins ou releases (versões) que
facilitaram o desenvolvimento do exemplo deste projeto. Desde a aplicação que
expõ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 na
IDE.
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

46. • Eclipse Modeling Framework 2.2
Para o desenvolvimento deste pacote de projetos foram envolvidos mais
de 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 Sun
Java Wireless Toolkit – JWT que auxilia no desenvolvimento de JME MIDlets
[Java Wireless Toolkit].
31

47. 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ção
até o exemplo em questão.
Chegou-se ao entendimento que uma livraria atenderia a expectativa do
projeto. Assim, foi desenvolvido o seguinte estudo de caso. Imaginando que um
cliente houvesse solicitado o sistema para sua livraria, foi elaborado o
levantamento 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 vendedor
recebe o cliente, procura, manualmente, a obra em um catálogo, encerrado
numa grande pasta de cor preta. Caso encontre, informa o valor ao cliente e
sendo o interesse positivo, recorre ao estoquista para saber se a loja ainda
dispõe de tal obra em estoque. Se o estoque do produto houver acabado, o
vendedor anota os dados do cliente – se o mesmo permitir – entrando em
contato com a editora a fim de comprar o livro e vendê-lo ao cliente. Essa
operaçã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 ao
cliente que é inquirido pelo vendedor sobre a forma de pagamento.
O empresário relata que houve casos onde os clientes querem que a loja
entregue o livro em outro endereço que não o deles e, que a obra esteja
embalada 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 em
domicílio e com isso ter um acréscimo justificável no valor da venda. Ele diz
também que os clientes ficam muito insatisfeitos pela demora de todo o
processo de compra. E que quer transformar funcionários como estoquista,
arquivistas, em vendedores, a fim de ter mais atendentes e suportar a grande
demanda.
32

48. Outro pedido do empresário é que o sistema guarde as preferências dos
clientes; como por exemplo, gênero e sub-gênero literário, autores preferidos
etc. E que o software possa se comunicar com vários outros sistemas de livros
através da Internet, provendo inclusive serviços de tradução literária e leitura
de e-books.
O sistema de gerência de livros deve funcionar em plataformas diferentes
como, 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 uma
porcentagem 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 a
intençã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 de
catálogo e efetuar pedido), mas todos foram modelados, para ter a visão geral
dos requisitos funcionais do sistema. Os diagramas possuem atores, casos de
uso e relacionamentos como associação, dependência, generalização. Esta
modelagem 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 dos
atores. Ou seja, uma visão externa.
33

49. Figura 5.1 – Diagramas de caso de uso do projeto.
Figura 5.2 – Diagrama de caso de uso para efetuar pedido.
34

50. O diagrama retratado na figura 5.2 exemplifica o ator cliente efetuando um
pedido onde é necessário como pré-condição os livros cadastrados no sistema
e como pós-condição a existência do pedido. O fluxo principal dá-se da
seguinte 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 os
passos para gravar a venda no repositório de dados. Todo o fluxo principal e
alternativo, 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 cliente
nã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

51. A figura 5.3 mostra o cliente visualizando o catálogo de livros. O catálogo
poderá ser consultado por ISBN, Título do livro, gênero e depois subgênero e
nome do autor. Como pré-condição, este caso de uso necessita que as
informações sobre os livros estejam cadastradas. A pós-condição é a listagem
dos 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, pois
oferecerem funcionalidades importantes acerca do negócio da empresa e
podem ser disponibilizados na Internet para que clientes de outras cidades,
estados ou países possam utilizá-los sem precisar ir à loja.
36

52. 5.2.2 Diagrama de análise de domínio
Figura 5.4 – Representa o diagrama de domínio.
37

53. Este diagrama (figura 5.4) tem o objetivo de fornecer, ao desenvolvedor, a
mais ampla visão, de forma estática, de como se relacionam as várias
entidades que representam o negócio empresarial.
A seguir, breve explicação das classes que compõem este diagrama. Os
nomes das classes estão em negrito para melhor visualização no esquema.
Pessoa é a classe que representa qualquer pessoa no sistema. Os papéis
que podem ser desempenhados por uma pessoa são representados pela
classe Vendedor e Cliente.
A classe Venda tem relacionamento com FormaPagamento (para saber
qual será a forma de pagamento escolhida pelo cliente), com Vendedor (para
captar o objeto que representa o vendedor que efetuou a venda), com Cliente
(para saber quem é o cliente) e com ItemVendido (a fim de adicionar à venda
os itens de interesse do cliente) que por sua vez se relaciona com Livro cujos
objetos são os livros disponíveis para venda. Um livro sempre tem uma editora
e um ou mais autores. Isto é representado nas respectivas classes Editora e
Autor.
Cliente se relaciona com Gênero e Autor para que, ao visualizar o
catálogo, sejam colocados em evidência os gêneros e autores que o cliente
tem mais interesse. Existe, também, um auto-relacionamento na classe
Gênero, pois um gênero pode ter um subgênero.
38

54. 5.2.3 Diagrama de design da camada de domínio
Figura 5.5 – Representa o digrama de design de domínio.
39

55. O diagrama de design tem intenção de delinear a implementação da
camada 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ção
no esquema e os métodos estão em itálico. Com isso, será abordado qual a
importância de cada elemento no diagrama.
A interface ObjetoDominio possui a mais alta abstração para identificar
os objetos de domínio e é a interface base de todas as interfaces do diagrama.
Tais objetos serão identificados por um identificador. As demais classes
implementam a classe abstrata ObjetoDominioAbstrato, segundo o padrão
Layer Supertype [Fowler et al, 2002], a fim de terem o mesmo comportamento
desta.
A abstração Pessoa é implementada pela classe PessoaImpl. Quanto
aos papéis desempenhados por uma pessoa, foi introduzida a classe abstrata
Papel que implementa a interface Pessoa (sabe se comportar como uma
pessoa) e conhece a instância de Pessoa associada. Desta forma, a classe
Papel implementa o comportamento de pessoa delegando para a pessoa que
contém. As abstrações Vendedor e Cliente foram implementadas pelas
classes VendedorImpl e ClienteImpl, respectivamente. Ambas estas classes
derivam da classe Papel, herdando o comportamento de Pessoa e
acrescentando o respectivo comportamento específico. O design assim
estruturado, evitando redundância de informações da Pessoa nas classes que
implementam Vendedor e Cliente e, por conseguinte, na base de dados.
ClienteImpl possui dependência com Gênero e Autor para registrar o
interesse 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 deseja
utilizar. Para simplificar, modelou-se apenas a classe FormaPgAVistaImpl
para representar pagamento à vista.
A classe abstrata ItemVendido comporta todos os objetos que
representam os itens vendidos.
A interface Editora tem a função de fornecer a editora de cada livro.
40

56. 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 de
composição com ItemVendido.
A classe Livro representa os livros do sistema. Possui dependência com
Gê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 se
encarregam de realizar as buscas no banco de dados. Existe um finder para
cada classe de negócio que, por sua vez, contém vários métodos para buscas
específicas.
41

57. A seguir, breve explicação das classes que compõem este diagrama. Os
nomes das classes estão em negrito para melhor visualização no esquema e
os métodos estão em itálico.
A classe RegistroFinder é um registro de todos os finders do sistema. O
design Pattern de criação de objeto Singleton [Gamma et al, 2000] foi utilizado
para garantir uma única instância global desta classe. RegistroFinder tem
funçã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 que
tem a função de transportar um conjunto de dados uma vez entre camadas
distribuídas, evitando uma enxurrada de chamadas remotas, pois esta requer
muito do sistema. Como é preciso realizar várias Remote Procedure Calls
(RPC) deve-se aglutinar os resultados dessas chamadas em objetos de
42

58. transferência para que este as armazene gerando, assim, apenas uma RPC e
nã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ção
no esquema.
Existe uma composição entre a classe PedidoDTO e a classe
ItemVendidoDTO porque o pedido possui itens vendidos. A classe
PedidoDTO, LivroDTO e ItemVendidoDTO fornecem informações básicas a
respeito de seus objetos ao cliente. Como as classes da camada de domínio
possuem vários relacionamentos, usar DTO é o melhor procedimento para
evitar o acesso às informações básicas solicitadas. É por intermédio do objeto
da classe ItemVendidoDTO que o cliente envia os itens vendidos para o
servidor da aplicação.
43

59. 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

60. A seguir, breve explicação das classes que compõem este diagrama (figura
5.8). Os nomes das classes estão em negrito para melhor visualização no
esquema.
Este diagrama simula em memória o processo de persistência dos objetos. A
classe PersisterFactory é responsável por fabricar os objetos (persisters) que
simulam a gravação. Tal simulação é feita por um respectivo stub. A classe
MapperFactoryStub realiza a criação dos objetos de persistência (stubs). Os
finders são usados de acordo com a necessidade de pesquisa feita pelo usuário e
são interfaces implementadas pelos stubs, responsáveis por fazer a busca do
objeto. Concluindo para cada objeto da camada de domínio existe uma
correspondente interface persister e uma correspondente interface finder, onde
ambas são implementadas pela correspondente classe Mapper, que para fim de
testes é um stub que simula um datamapper com o banco de dados. Banco de
dados este simulado em memória pela classe RepositórioObjetoDomínio, que
nada 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

61. 5.2.7 Diagrama de design da camada de serviços
Figura – 5.9 – Demonstra a implementação da camada de serviços.
46

62. 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ão
disponibilizados na web para que qualquer cliente possa acessá-los,
independentemente da tecnologia que utiliza. Neste ponto é satisfeito a solicitação
do 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. Os
nomes das classes estão em negrito para melhor visualização no esquema.
ProvedorServicoCatalogo e ProvedorServicoPedido representam os
facades dos serviços disponibilizados. Esta duas interfaces são implementadas
por ProvedorServicoCatalogoImpl, que tem dependência com a interface
LivroFinder a fim de retorna as buscas de livro no sistema e utiliza GeneroFinder
para efetuar buscas pelo gênero da obra, e ProvedorServicoPedidoImpl, que
conhece as interfaces necessárias para realizar um pedido tais como LivroFinder,
PessoaFinder e FormaPagamentoFinder. A classe que implementa o serviço de
pedido também “conhece” a classe que cria objetos de persistência
PersisterFactory e a interface VendaPersister, para gravar a venda.
47

63. 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

64. 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. Um
diagrama de seqüência identifica o evento gerador do processo, o ator
responsável por este evento (no caso o cliente) e dispõe como é o processo de
iteração, por intermédio de métodos disparados, entre os objetos. Este diagrama
será dividido em quatro partes para melhor visualização.
49

65. 5.2.8.1 Busca pelo código
Figura 5.11 – Busca pelo código.
50

66. 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 melhor
visualização no esquema.
O ator cliente solicita uma busca de um livro pelo código do livro. A classe
ProvedorServicoCatalogoImpl dispara o método getInstance da classe
registroFinder a fim de obter a única instância desta classe e em seguida obtém o
objeto de busca (finder) por intermédio do método getLivroFinder. Depois é
invocado outro getInstance, desta vez da classe MapperFactoryStub e após o
objeto de busca dispara o método getLivroMapper pretendendo mapear os dados
do livro para a simulação de persistência. No decorrer, o objeto
MapperFactoryStub dispara um método getInstance na classe LivroMapperStub
para conseguir uma única simulação de persistência naquele exato momento.
Depois a classe ProvedorServicoCatalogoImpl aciona o método
buscarPeloId na classe LivroMapperStub onde é passado o parâmetro que
identificará o id do livro.
A própria classe busca a instância do objeto repositório que é um Singleton
onde o método de busca é sincronizado, tornando, assim, impossível o uso do
mesmo objeto por diferentes threads. Abaixo ocorre a condição para saber se o
códigoTipo é igual a livro. Se essa condição for verdadeira, o MapperStub dispara
o método de busca de objetos de domínio no repositório, passando o id e o
codigoTipo como parâmetro.
51

67. 5.2.8.2 Busca pelo ISBN
Figura 5.12 – Busca pelo ISBN.
52

68. A busca por ISBN faz a mesma simulação de persistência de pesquisa pelo
código do livro, porém a classe LivroMapperStub busca todos os objetos do
repositó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 iguais
aos ISBN passado como parâmetro no método buscarPeloIsbn.
53

69. 5.2.8.3 Busca pelo Gênero
Figura 5.13 – Busca pelo Gênero.
54

70. A busca por Gênero realiza a mesma simulação feita anteriormente para livro
e inova com uma simulação para gênero. Adiante é feito um solicitação à classe
GeneroMapperStub para retornar a única instância de gênero e mapear os dados
para representar a persistência. GeneroMapperStub faz uma auto-chamada para
retornar os nomes dos gêneros solicitados no parâmetro do método
buscaPeloNome. E ocorre outra auto-chamada, desta vez na classe
LivroMapperStub para listar todos livros que conferem com o parâmetro gênero
passado no método buscarPeloGenero.
55

71. 5.2.8.4 Busca pelo Nome
Figura 5.14 – Busca pelo Nome.
56

72. Por fim, a seqüência do método buscarLivrosPorNome para simular segue os
passos anteriores e a classe LivroMapperStub efetua uma auto-chamada para
retornar todos os livros que coincidem com o nome do livro passado com
parâ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

73. A seguir, breve explicação dos componentes deste diagrama. Os nomes das
classes estão em negrito e os métodos em itálico, para melhor visualização no
esquema.
O cliente dispara o método efetuarPedido passando os seguintes
parâmetros: idCliente, idVendedor, idFormaPg, endEntrega, itensVendidos. Então
a classe ProvedorServicoPedidoImpl busca a instância da classe
RegistroFinder e depois retorna o objeto de busca do papel.
A classe RegistroFinder, por sua vez, busca a instância da classe
MapperFactoryStub, para gerar os objetos de persistência já mapeados. Em
seguida, dispara o método getPapelMapper para retornar as informações do
objeto papel.
A classe ProvedorServicosPedidoImpl dispara dois métodos de busca pelo
id com seus respectivos parâmetros. Sendo um para o cliente e outro para o
vendedor. E ainda busca a forma de pagamento.
A classe RegistroFinder acessa a instância da classe MapperFactoryStub
para obter e retornar a instância de FormaPagamentoMapperStub.
ProvedorServicosPedidoImpl busca a forma de pagamento pelo id. Depois
cria uma nova venda e informa os objetos participantes da venda, a saber: o
cliente, o vendedor, a forma de pagamento e o local para entrega. Por fim, retorna
um objeto de busca para o livro.
RegistroFinder acessa a instância de MapperFactoryStub e retorna o
LivroMapperStub, a partir do qual todos os livros são buscados.
O próximo passo é uma auto-chamada para gerar o livro pesquisado e a
quantidade de livros. No código é criado um novo item vendido e adicionado os
dados pertinentes.
A seguir é acessado o VendaPersister, implementado pelo
VendaMapperStub, para salvar a venda criada.
Por fim, ProvedorServicosPedidoImpl, a partir da venda criada, monta um
pedidoDTO 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 pelo
sistema.
58

74. 5.3 Aplicação cliente (dispositivo portátil)
Como parte do protótipo foi desenvolvida uma aplicação cliente, mais
especificamente um dispositivo portátil. Esta aplicação consiste no consumo dos
web 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 das
classes estão em negrito e os métodos em itálico, para melhor visualização no
esquema.
As interfaces ConectorServicosCatalogo e ConectorServicosPedido são
implementadas por ConectorServicosCatalogoImpl e
ConectorServicosPedidoImpl, respectivamente. Essas duas classes possuem
um atributo privado chamado url que fornece a localização dos serviços.
A classe ConectorServicosCatalogoImpl possui alguns métodos públicos
que disponibilizam várias formas de consultas no catálogo, todos retornando um
objeto do tipo livroDTO para melhor locomoção dos objetos no sistema. Alguns
métodos retornam um único livroDTO e outros um array de livroDTO. Se o cliente
consulta um livro por ISBN, é notório que o retorno será um único ISBN, pois não
59