13

UNIVERSIDADE TECNOLÓGIA FEDERAL DO PARANÁ

CAMPUS PONTA GROSSA
CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE
SISTEMAS

CIDRAK NUNES FERREIRA JR

RODRIGO PEREIRA LEITE

DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE E

GERENCIAMENTO DE UMA BANCA DE REVISTAS NA
METODOLOGIA SCRUM E COM APLICAÇÃO BASEADA EM WEB
SERVICES.

TRABALHO DE CONCLUSÃO DE CURSO

PONTA GROSSA
2010
 14

CIDRAK NUNES FERREIRA JR

RODRIGO PEREIRA LEITE

DESENVOLVIMENTO DE UM SISTEMA DE CONTROLE E

GERENCIAMENTO DE UMA BANCA DE REVISTAS NA
METODOLOGIA SCRUM E COM APLICAÇÃO BASEADA EM WEB
SERVICES.

Trabalho de Diplomação apresentado

como requisito parcial à aprovação e
conclusão do curso superior de
Tecnologia em Análise e
Desenvolvimento de Sistemas, do
Campus Ponta Grossa, da UTFPR.

PONTA GROSSA
2010
 15

RESUMO

O presente trabalho vem com o intuito de um estudo pertinente a tecnologia

web service e metodologia Scrum e suas funcionalidades, melhorias, usabilidades.
Com este estudo, o desenvolvimento de uma aplicação baseada em web
service juntamente com um software para webl, buscou-se, em um âmbito geral para
os clientes de uma banca de revistas, a praticidade de gerenciar o estabelecimento
sem a necessidade do esforço de ficar procurando por controles feito em papel.

Palavras-chave: Web Service, Scrum, WSDL, XML.

 16

SUMÁRIO

1 INTRODUÇÃO.......................................................................................................................... 17
1.1 OBJETIVOS.................................................................................................................................. 17
1.2 JUSTIFICATIVA............................................................................................................................ 18
1.3 METODOLOGIA............................................................................................................................ 18
1.4 ESTRUTURA DO TRABALHO.................................................................................................... 21
1.5 A EMPRESA SELECIONADA – BANCA DO RADECK.................................................................21
2 APLICAÇÕES PARA WEB............................................................................................... 23
2.1 HISTÓRICO DA INTERNET.......................................................................................................... 23
2.2 WEB SERVICE.............................................................................................................................. 23
2.2.1 SOAP..........................................................................................................................................................26
2.2.2 XML.............................................................................................................................................................28
2.2.3 WSDL..........................................................................................................................................................30
2.2.4 UDDI............................................................................................................................................................30

3 CONCLUSÃO........................................................................................................................ 33
4 REFERENCIAS..................................................................................................................... 34
 17

1 INTRODUÇÃO

Nos dias atuais, a necessidade de facilidades a mais para as pessoas e

praticidade nos leva a crer que, aplicações comerciais e/ou pessoais, serão de
extrema importância para as atividades de cada cidadão que possua acesso a tal
tecnologia cada vez mais emergente nos dias atuais.
As pessoas/empresas estão a cada dia mais independentes sendo assim, a
facilidade de comunicação e a praticidade gerada pela tecnologia, definirão
necessidades específicas da aplicação, deixando evidente a funcionalidade em dias
que estão exigindo cada vez mais horas e horas de trabalho para as pessoas, as
quais deixam muitas vezes de lado ocasiões especiais para trabalhar. Pensando
nisso percebesse a necessidade de um programa que facilite a vida das pessoas de
pequenos empreendimentos e ofereça um diferencial para a pequena empresa.
Com isso a possibilitamos o uso eficiente da tecnologia em favor de
pequenas empresas, para o controle e transmissão de pacotes de dados para os
aparelhos moveis. Tal característica e principalmente acessibilidade econômica, na
qual, muitas pessoas aderiram a esse conceito de tecnologia móvel baseada em
praticidade, comodidade e agilidade.
Neste trabalho consta-se como aplicar uma metodologia ágil que facilite o
tempo de coleta de dados referente as necessidades de pequena empresa,
aplicação desse conceito em tecnologia web a qual vem crescendo e cada vez mais
tomando conta do mercado.

1.1 OBJETIVOS

Com o estudo pertinente a tecnologia utilizada para desenvolvimento de

aplicações web, com os resultados obtidos de tal estudo, implementar uma
ferramenta com o intuito de almejar melhor gerenciamento proporcionando uma
facilidade a mais na empresa selecionada.
Uma nova tecnologia, uma nova visão sistêmica, verificando que tal
tecnologia não pode ser considerada a tecnologia emergente, e sim a tecnologia
 18

atual e de um futuro extremamente próximo. Num âmbito acadêmico, o estudo da

nova tecnologia auxilia ao embasamento teórico adquirido nos anos de estudo para
a formação da capacidade analítica e técnica desenvolvida durante o curso. E sua
aplicação se torna cada vez mais comum nos dias de hoje.

1.2 JUSTIFICATIVA

Com um nicho de mercado crescente atualmente, no qual aplicativos web

aumentam de uma maneira absurdamente rápida pela sua facilidade de acesso,
utilizar a tecnologia web é uma forma de conquistar mais tempo e ganhar mais
agilidades nos processos feitos diariamente.
A web está cada vez com mais recursos e capacidades de processamento
facilitando, assim, que a tecnologia evolua e permita que novas aplicações, cada vez
mais complexas para implementação e fáceis de utilização, sejam desenvolvidas.
Tal tecnologia escolhida para desenvolvimento do tema tem como
pressuposto uma tecnologia muito usada para galgar novos conhecimentos e
futuramente, gerar aplicações num mercado que cresce constantemente.

1.3 METODOLOGIA

“O Scrum foi desenvolvido por Takeuchi e Nonaka como uma forma para gerenciar
projetos em empresas automobilísticas, sendo publicado inicialmente no artigo „The
New Product Development Game‟ (Harvard Business Review, Janeiro 1986).” É uma
metodologia ágil de desenvolvimento.O articulador do funcionamento do Scrum é o
Product Backlog. Nele estão contidas as funcionalidades do programa. Essas podem
estar no formato de responsabilidades: “Cadastrar Nota Fiscal” ou em forma de
histórias: “O usuário necessita, após o recebimento do pedido, cadastrar a nota
fiscal respectiva”. Os itens do Product Backlog, como, por exemplo, os visualizados
na figura 1, são definidos por:
 19

 ID: um identificador numérico no formato de auto-incremento. Usa-se um ID para

organizar e manter uma nomenclatura constante.
 Nome: uma descrição curta, de no máximo 10 palavras, que dê uma
 idéia geral do conteúdo do item, que deve ser detalhado.
 Prioridade: níveis de prioridade de tarefas. Quanto maior o número,
 maior sua prioridade.
 Estimativa inicial: quantos dias, ou horas, serão necessárias para
 concluir o item em sua totalidade.
 Observações: notas no formato de comentário.

fIgura 1 - Exemplo de Product Backlog

Fonte: Autoria Própria

Após definido o Product Backlog pode-se começar o desenvolvimento. Como

se trata de uma metodologia ágil faz-se o uso de iterações, que, neste caso, são
denominadas Sprints. Cada Sprint representa um espaço de tempo onde certos
grupos de tarefas pré-estabelecidas devem ser realizadas (Marçal, Pereira e
Torreão, 2010). Uma Sprint comporta alguns itens do Product Backlog, atuando
como
uma subdivisão do conjunto total de tarefas.
No início de cada Sprint há uma reunião chamada de Sprint Planning Meeting,
onde o Product Owner, o cliente que requisitou o software, define as prioridades
para cada tarefa. A equipe define então o que pode ser desenvolvido, e move as
tarefas do Product Backlog para o Sprint Backlog.
Durante a Planning Meeting acontece o Planning Poker que funciona da
seguinte forma: inicialmente as tarefas são divididas de forma clara e da forma mais
fracamente acoplada possível. Em seguida, o grupo define notas de dificuldade para
 20

cada tarefa, quanto menor a nota, mais fácil é a tarefa. Cada integrante dá sua nota
de acordo com sua capacidade e a equipe então deve decidir qual nota manter, com
base nas notas dadas pelos outros integrantes. Assim, obtém-se uma pontuação
final que deve ser atingida (dada pela soma das notas de dificuldade contidas
naquela Sprint).
As tarefas contidas na Sprint possuirão notas que equivalem a pontos. Cada
vez que uma tarefa é concluída, a equipe ganha os “pontos” respectivos da tarefa.
Quanto maior é a pontuação que a equipe possui, menor é o trabalho restante para
a conclusão da Sprint. Durante uma Sprint são definidas reuniões que podem ser
diárias, semanais, etc., para que se possa discutir o andamento do projeto,
compartilhar conhecimento e expor problemas e barreiras encontradas.
Para o controle geral de cada Sprint usa-se o Burndown Chart (Marçal, 2010). Nele
estão contidos os dias e horas restantes para o final da Sprint e o que já 18 foi
realizado. Ao final de cada Sprint a equipe reúne-se para expor o que foi alcançado
em uma Sprint Review Meeting.
Em seguida, uma nova Sprint é definida e o processo é novamente iniciado
até que tenham sido realizadas Sprints suficientes para a conclusão do projeto em
sua totalidade. Um resumo do processo é exibido na Figura 1.

Figura 2 – Resumo do Modelo “Scrum” de Desenvolvimento

 21

Fonte: Scrum (2007).

1.4 ESTRUTURA DO TRABALHO

Com todos os estudos relacionados para o desenvolvimento deste trabalho,

o mesmo foi dividido da seguinte maneira:
Introdução: dividindo-se em metodologia, referenciando qual foi aplicada
para o contexto geral do trabalho. Justificativa do estudo e desenvolvimento do
trabalho assim como os objetivos buscados.
Capítulo 1 (um): com um embasamento teórico em livros, artigos, sites, foi
desenvolvido como é o funcionamento da metodologia juntamente com as
características inerentes ao seu desenvolvimento, mostrando recursos e requisitos
desses.
Capítulo 2 (dois): Desenvolvido como é o funcionamento das aplicações
web, mais especificamente Web Services, juntamente com suas características
inerentes ao seu desenvolvimento, mostrando seus recursos e requisitos, também,
de acordo com referências de livros, artigos e sites.
A ferramenta implementada: descrição de como a ferramenta funciona,
abordando sobre a tecnologia utilizada, realizando um comparativo com algumas
parecidas existentes no mercado.
Considerações finais, trabalhos futuros e referências.

1.5 A EMPRESA SELECIONADA – BANCA DO RADECK

Empresa no ramo de comércio de revistas e jornais, situada na cidade de

Ponta Grossa, PR, possui suas atividades comerciais desde o ano de 1986 (Mil
novecentos e oitenta e seis).
A comercialização dos produtos da mesma dispõe-se basicamente no
comércio pessoal, onde os clientes dirigem-se até o estabelecimento, verificando os
produtos que estão dispostos para venda. As revistas e os jornais são distribuídos
para todas as bancas da cidade por duas distribuidoras de revistas, as quais
 22

realizam o reparte (divisão das revistas entre as bancas). Os jornais são distribuídos
por outras duas distribuidoras, específicas de jornais, realizando o mesmo processo
das revistas.
Para o proprietário da banca, as revistas/jornais distribuídos estão na forma
de comodato, tudo que não é vendido retorna para as distribuidoras, sendo pago
apenas o valor das revistas vendidas tirando o desconto acordado entre as
distribuidoras e a banca.
Na empresa selecionada, não há nenhum tipo de sistema para controle de
estoque, de vendas ou algo parecido. Todo o processo de controle da empresa é
realizado pelo proprietário manualmente. Sendo as compras realizadas
pessoalmente, muitos dos clientes, ao chegarem à banca, não encontram mais o
produto de seu interesse procurando assim outro estabelecimento que possua o
mesmo, muitas vezes não voltando mais a banca devido a falta do mesmo.
Em casos esporádicos, geralmente em coleções lançadas pela editora,
reservas são realizadas pessoalmente para clientes fixos a empresa, na qual para
garantir realmente a compra do seu produto, realizam o pagamento antecipado da
mesma. Outros pouquíssimos casos, para a fidelidade do cliente, se a revista/jornal
de seu interesse não estiver disponível, o proprietário compra de outra banca na
cidade, não obtém lucro algum mais garante que o seu cliente irá encontrar a revista
desejada.
Com este módulo para a empresa, o sistema proposto visa agilizar o
controle de estoque facilitando assim, ao proprietário, a análise mais criteriosa dos
pedidos das revistas para pedir aumento no reparte, sendo que, as revistas serão
reservadas a modo que vende mais, dando tempo hábil para que o proprietário
consiga tal produto para o seu cliente.
 23

2 APLICAÇÕES PARA WEB

2.1 HISTÓRICO DA INTERNET

A revolução que a internet vem propicia no mundo dos computadores e

das comunicações está no inimaginável de tamanha utilidade prevista por
qualquer pessoa na época do seu surgimento. Considerando a internet, com
objetividade, um mecanismo para disseminação da informação interagindo
entre os indivíduos que utilizam de sua tecnologia, independente de sua
localização geográfica.
Desde 1969 até a atualidade, a internet foi ganhando grande
repercussão mundial principalmente após a década de 90, com a
popularização dos computadores pessoais. Inicialmente era composta por
páginas estáticas e interligadas, utilizada por pessoas através dos “Browser”,
os navegadores web. Com a necessidade e utilização cada vez maior da
população, as páginas começaram a interagir com programas que utilizavam
banco de dados e outras fontes de informações.
Com um nicho de mercado influente, as empresas com seu faro
mercadológico começaram a analisar e ver uma maneira eficiente e valiosa
para a comunicação com seus clientes e fornecedores. várias delas uniram-se
e desenvolveram formas de comunicações entre suas aplicações sem a
necessidade real de alterar, ou até mesmo, trocar os seus sistemas. Em 1983
surgiu a linguagem XML (Extensible Markup Language), para tal feito, e no
início dos anos 2000, os web services foram desenvolvidos.

2.2 WEB SERVICE

Os web services possuem uma promessa de que um ambiente

distribuído possa ser utilizado por qualquer linguagem disponível, trazendo uma
heterogeneidade para os aplicativos das empresas.
 24

Para Chapell & Jewell (2002), um web service é um pedaço de lógica

de negócios, situado em algum lugar da internet, ou seja, acessível por meio de
protocolos de internet como o HTTP ou SMTP. Alguns anos atrás, diversas
tecnologias poderiam ter sido consideradas como tecnologia de web service,
como a Win32, J2EE, CORBA e scripts CGI. A principal diferença entre a
tecnologia de web service considerada na atualidade e estas tecnologias é a
sua padronização.
O W3C é o responsável pelas especificações dos web service, no qual
define como sendo um software identificado por um URI, onde as interfaces e
bindings são definidas, escritas e descobertas por artefatos do XML,
suportando interação entre outros softwares que utilizem o XML usando
mensagens por meio de protocolos de internet.
Conceituamos web services como sistemas distribuído de mensagens
utilizando arquivos no formato XML. Os web services possuem algumas
características especiais:
- Baseadas em XML: camada de representação de dados para todos
os serviços web e de protocolos. Não possui a necessidade de um sistema
operacional;
- Fracamente acoplado: Um consumidor de web service não está
vinculado diretamente a este serviço, o mesmo podendo sofrer alterações em
longo prazo, sem que o cliente perca a capacidade de interação com o mesmo;
- Suporte remoto: permitem que os clientes invoquem métodos,
procedimentos e funções;
- Troca de documentos: forma genérica de representar os dados ou
documentos, podendo os mesmos ser simples como um endereço ou complexo
como um livro.
De um modo geral, os web services trocam mensagens utilizando
arquivos no formato XML, utilizando, geralmente, a tecnologia SOAP (Simple
Object Access Protocol). Para a troca de mensagens utiliza o protocolo para
internet HTTP (Hyper Text Transfer Protocol). A validação do XML é feita pelos
arquivos WSDL (Web Services Definition Language) e um módulo UDDI
(Universal Description, Discovery and Integration) para busca e locação de
serviços.
Primeiramente, para que um web service funcione, é necessário um
 25

provedor de serviço com base na interface Proxy SOAP esteja disponível por
meio da internet, assim como a descrição de seus serviços oferecidos e o
modelo de comunicação implementado no padrão WSDL (1).
Após o serviço criado, o mesmo deve ser publicado e registrado em um
corretor de serviços UDDI, sendo o responsável pela disponibilização da URL
(Uniform Resource Locator) para a localização do WDLS (2). Após estas
etapas, o serviço já está acessível para ser consumido pelo consumer (3), no
qual deverá pesquisar nos registros UDDI e obter a URL do serviço solicitado.
Através destas informações obtidas na UDDI, o cliente solicita a
descrição do serviço padrão do WSDL e cria um Proxy cliente para que o
acesso ao serviço seja realizado através do SOAP (5). Pelo Proxy criado, o
cliente solicita uma informação e o web service retorna os dados solicitados (6).
(ABINADER & LINS, 2006). Conforme figura 9.

Figura 3 – Modelo de implementação de um Web Service

Fonte: Abinader & Lins (2006).

Abinader & Lins (2006) demonstram uma abordagem conceitual:

“Na ótica conceitual, o emprego de web services representa um modo
para integrar tarefas que compõem um processo de negócio através
da Internet, em uma cadeia de valor na qual procedimentos estão
interligados e são interdependentes para atingir um resultado
concreto”.( ABINADER & LINS, 2002)
Algumas vantagens são citadas por consultores da Sun (empresa na
qual desenvolveu a linguagem de programação java):
- Escalabilidade: sem limites para quantidade de aplicações
 26

heterogêneas e alcance;
Automático: transações mais complexas ou simples não têm a
necessidade de interferência humana;
- Acessibilidade: aplicações externas são acessadas pela internet;
- Interoperabilidade: indefere de plataforma, arquitetura ou até mesmo
sistema operacional;
- Disponibilidade: utilizado em qualquer lugar, momento.
Como vimos, os web services possuem várias tecnologias envolvidas
para sua criação e utilização, abordaremos a seguir tais tecnologias.

2.2.1 SOAP

XML fornece uma maneira para acrescentar significado semântico aos

dados que estão sendo enviados pela rede, o SOAP fornece convenções para
criação de “envelopes” para seus dados, possuindo regras explícitas de
codificação de dados para a aplicação.

“O propósito do SOAP é fazer chamadas a procedimentos

remotos em cima do protocolo HTTP (ou outro protocolo padronizado
da web), com a grande vantagem de não impor restrições de algum
tipo de implementação para os pontos de acesso, como fazem
atualmente RMI, CORBA e DCOM”. (MENÉNDEZ, 2003).
Cada aspecto de uma solicitação SOAP é bem estabelecido, as
plataformas e linguagens de programação em ambos os lados do SOAP
conversam, independentes uma das outras. Cada lado da conversa pode,
segundo Chapell & Jewell (2002):
- Enviar e receber transmissões de dados em uma rede utilizando
HTTP ou SMTP;
- Compreender as regras de Extensões Multi-função para mensagens
da internet (MIME) e desconstruindo anexos binários sobre estas regras;
- Construir e desconstruir documentos XML que estejam em
conformidade com as regras estabelecidas pelo SOAP;
- Executar a ação necessária caso indicado no documento do SOAP.
SOAP pode representar qualquer tipo de dados, serialização de
 27

objetos, invocação de métodos, ou troca de documentos. A troca de

mensagens com SOAP é ilustrada na figura 10:

Figura 4 – Etapas na comunicação entre servidores

Fonte: CHAPELL & JEWELL (2002).

A comunicação representada no número um, foi uma solicitação que o

servidor A pediu em formato SOAP, pedindo informações sobre biblioteca de
tipos ao servidor B, ao qual retorna a resposta (2) ao servidor A. Logo após o
servidor A enviar uma solicitação de método (3), devidamente formatado em
um envelope SOAP, em seguida o servidor B responde (4), com um envelope
SOAP que contém os resultados da execução dos métodos anteriormente
solicitados.
A figura 11 demonstra um esquema de camadas da comunicação de
web services e em que encontra-se o protocolo SOAP.

Figura 5 – Pilha Comunicação Web Service

Fonte: ABINADER & LINS (2006).
 28

SOAP tem sua base em XML, possui três elementos importante para a
sua configuração conforme Mendez (2009):
1 – Envelope: Receptor do arquivo onde a mensagem termina e
começa;
2 – Header: adiciona novas entradas ao elemento envelope, podendo
aumentar sua capacidade conforme a necessidade, não sendo obrigatório;
3 – Body: é o recipiente final, contém todos os conteúdos, elemento
obrigatório.

2.2.2 XML

Segundo a XML (2003), é um padrão do W3C para representação dos

dados. Com características marcantes da linguagem, seu formato é simples, de
fácil interpretação e extremamente útil para o intercâmbio de dados.
A linguagem possui duas formas primárias para a composição das
informações:
- Elementos: estruturas que permitem a atribuição de dados simples,
definindo seus nomes com os símbolos de “<” (menor) e “>” (maior),
denotando-o como tag ou nó.
- Atributos: estruturas para atribuição de valores alfanuméricos, sendo
colocados junto às tags de abertura dos elementos. A figura 12 ilustra um
documento XML.
 29

Figura 6 – Documento XML

Fonte: Autoria própria.
O documento apresentado é formado por elementos compostos, tais
como trabalhoDiplomação e Cap1 que são compostos por outros elementos.
Como exemplo de elemento simples, consideramos autor e título, que possuem
os dados. Como atributos, identificamos com o nome de id no elemento cap1.
Os documentos XML podem ser validados contra estruturas
determinadas, de forma que se possa ter vários documentos que sigam a
mesma estruturação (ANDERSON, 2001).
Nos dias atuais, podemos concluir que a linguagem XML tornou-se
universal para troca de dados em aplicações de diferente plataforma e
linguagem de desenvolvimento.
Para que os compiladores XML, chamados de parsers possam
entender o conteúdo dos arquivos, os mesmos devem estar bem formatados,
obedecendo um padrão de construção. Sampaio (2006) cita 5 regras para que,
a construção de um arquivo XML esteja bem formatado:
1 – Elementos internos devem estar perfeitamente alinhados
(identados);
2 – Arquivo XML deve possuir um elemento “root”;
3 – Os elementos deve possuir tag inicial e tag final;
4 – Os arquivos XML, interpretam diferentemente arquivos em caixa
alta ou caixa baixa;
5 – Possui elementos e estes podem ter atributos. Um atributo é um
metadado, devendo sempre vir entre aspas simples ou duplas.
Na figura 13, um exemplo de um arquivo XML bem estruturado.
 30

Figura 7 – Arquivo XML bem formatado

Fonte: Autoria própria.

2.2.3 WSDL

Antes que as comunicações que irão utilizar o web service sejam

iniciadas, o cliente deve obrigatoriamente ter conhecimento dos formatos das
mensagens que serão enviadas e recebidas, além de saber onde encontrar o
servidor do serviço. Foi criada a WSDL, para representação das
funcionalidades de um web service.
Este arquivo é baseado em XML, dividido em parte abstrata pelos
elementos types, message e portType, e por uma parte concreta, representada
pelos elementos binding e service. Na seções abstratas são descritos os dados
e as operações suportadas pelo web service, enquanto nas seções concretas
são definidas informações concretas para realização das operações definidas
Ballinger (2003). Abaixo os elementos do XML que compõe o arquivo WSDL:
- Types: container para definição de tipos;
- Operation: descrição de uma ação disponibilizada pelo serviço;
- portType: conjunto de operações suportadas nos endpoints;
- Message: definição dos tipos dos dados que são passados nas
operações;
- binding: especificação do formato dos dados para um determinado
portType;
- port: É um endpoint, definido como a combinação de um binding com
um endereço de rede
- service: um conjunto de endpoints.
 31

2.2.4 UDDI

No desenvolvimento de uma aplicação, alguns serviços específicos

podem ser necessários, muitas vezes, tais serviços estão em localidade
distantes, em empresas que nunca ouviu-se falar no mercado e o
desenvolvedor nem sequer suspeita quem seja. Com a finalidade de facilitar a
localização dos web services, foi criada a UDDI.
Esta tecnologia surgiu em conjunto da Microsoft, IBM e Ariba,em 2000.
Caracterizada pela existência de bancos de dados abertos, permitindo a busca
e publicação de web services, através de seus metadados Ballinger (2003),
que são compostos de acordo com o protocolo UDDI (UDDI,2003).
Para Abinader & Lins (2006), é um conjunto de especificações, no qual
é definido o que deve ser feito e como fazê-lo, onde devem ser publicados os
serviços para torná-los públicos e onde podemos localizar outros serviços.
No registro UDDI estão armazenados dados da empresa fornecedora
do serviço, podendo ser considerada, por muitos autores, como uma lista
telefônica, onde os serviços são encontrados facilmente.
Abinader & Lins (2006) definem:
“Nos registros são armazenados informações referentes as
empresas como endereço, dados para contato, taxonomia, entre
outros da qual a empresa e os serviços fazem parte. Uma lista
completa dos serviços oferecidos por extenso, acompanhados de
referências para processos dos negócios que realizam”.
Existem duas formas de interação com os repositórios UDDI:
1 – através da interface com o usuário. Por esta interface, é possível a
submissão de consultas manualmente. Preenchimento de todos os dados
necessários para a publicação de um web service, sem a real necessidade de
conhecimento de criação de documentos UDDI.
2 – Através de uma API de programação. Suas funcionalidade podem
ser definidas em dois tipos:
 Funções de investigação: responsáveis pela recuperação de
informações sobre serviços, agregando alguns operações: find_binding,
find_business, find_service, find_tModel, get_serviceDetail, get_bindingDetail,
 32

get_businessDetail, get_businessDetailExt e get_modelDetail

(BALLINGER,2003).
 Funções de publicação: operações referentes a publicação de
serviços em repositórios UDDI, compostas das seguintes operações:
save_binding, save_business, save_service, save_tModel, delete_binding,
delete, business, delete_service, delete_tModel, get_authToken,
discard_authToken, e get_registeredInfo (UDDI,2002).
Pode-se dizer que o ciclo para o consumo de um web service inicia-se na
descoberta dos serviços que serão utilizados, realizada ainda no tempo de
projeto da aplicação. A publicação torna-se a última etapa a ser realizada por
um projetista de web service, sendo na primeira etapa a implementação efetiva.
 33

3 CONCLUSÃO

Nos dias atuais, a web possibilita a uma grande gama de empresas

disponibilizarem seus serviços para que outras aplicações utilizem dos seus
recursos disponíveis com uma facilidade inerente a necessidade dos dias
atuais de praticidade, facilitando assim a comunicação entre empresas,
independente do setor de cada uma.
A tecnologia no mercado tem grande aceite, pois seus sistemas
próprios não precisam de grandes alterações para realizar a comunicação com
o serviço móvel a ser disponibilizado. Outro fator importante, é que web utiliza-
se de uma linguagem de fácil aprendizado na qual a aplicação pode se adaptar
facilmente para que aja interação em diversos navegadores independo da
plataforma em que o cliente se encontra, gerando uma grande aceitação da
tecnologia no mercado.
Atualmente, o mercado dispõe cada dia mais de aplicativos na internet
e vem aumentando gradativamente estes números. Tal tecnologia de
desenvolvimento nos permite uma implementação limitada pelos recursos de
software existentes, porém, o seu desenvolvimento torna-se não muito
complexo possibilitando um melhor aproveitamento da tecnologia crescente.
Alem disso a aplicação pode ser facilmente integrada a dispositivos
móveis a qual o desenvolvimento de aplicações complexas não é viável pelos
recursos limitados que existem hoje nestes aparelhos, mas a integração com o
sistema implementado é viável e traz uma competitividade de mercado as
pequenas empresas. A partir do momento em que utilizamos a web, podemos
gerar um desenvolvimento mais complexo obtendo assim resultados melhores
e softwares mais completos com a integração entre os dispositivos móveis e
nosso software, por exemplo.
Com este trabalho podemos afirmar que a junção entre as tecnologias
estudadas permite que possamos desenvolver aplicações que sejam de uma
facilidade de utilização alta em um possível sistema complexo. Com estes
estudos, salientamos que o desenvolvimento de aplicações simples facilitam a
vida dos clientes, fidelizando, para muitas empresas, os clientes próprios com a
utilização destas tecnologias.
 34

4 REFERENCIAS

ABINADER, Jorge A.; LINS, Rafael D., Web services em Java. São Paulo:
Brasport, 2006.

ANDERSON, R. et al. Professional XML. Rio de Janeiro: Ciência Moderna

LTDA., 2001.

BALLINGER, Keith. .NET Web Services: Architecture and Implementation.

Boston: Addison-Wesley, 2003.

CHAPELL, David.; JEWELL, Tyler. Java Web Services, O’Reilly, 2002.

HARVARD Business Review. Estados Unidos. HBR. 1986. IMPROVE IT.

SCRUM. Disponível em < http://improveit.com.br/scrum>. Acesso em

20 abr. 2010.

MARÇAL, Ana Sofia; PEREIRA, Paulo; TORREÃO, Paula. Entendendo

Scrum para Gerenciar Projetos de Forma Ágil.
<http://www.cesar.org.br/files/file/SCRUM_MundoPM-Abril-Maio-2007.pdf>
Acesso em: 21 abr. 2010.

SAMPAIO, Cleoton. Soa e Web services em Java. São Paulo: Brasport, 2006.

UDDI.org. Disponível em: < http://uddi.xml.org/uddi-org>. Acesso em: 22 mar.

2010.