Referencial teorico

31
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

Transcript of Referencial teorico

Page 1: Referencial teorico

13

UNIVERSIDADE TECNOLÓGIA FEDERAL DO PARANÁCAMPUS PONTA GROSSA

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

CIDRAK NUNES FERREIRA JRRODRIGO 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 GROSSA2010

Page 2: Referencial teorico

14

CIDRAK NUNES FERREIRA JRRODRIGO 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 GROSSA2010

Page 3: Referencial teorico

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.

Page 4: Referencial teorico

16

SUMÁRIO

1 INTRODUÇÃO.......................................................................................................................... 171.1 OBJETIVOS.................................................................................................................................. 171.2 JUSTIFICATIVA............................................................................................................................ 181.3 METODOLOGIA............................................................................................................................ 181.4 ESTRUTURA DO TRABALHO....................................................................................................211.5 A EMPRESA SELECIONADA – BANCA DO RADECK.................................................................212 APLICAÇÕES PARA WEB............................................................................................... 232.1 HISTÓRICO DA INTERNET..........................................................................................................232.2 WEB SERVICE.............................................................................................................................. 232.2.1 SOAP.......................................................................................................................................................26

2.2.2 XML..........................................................................................................................................................28

2.2.3 WSDL.......................................................................................................................................................30

2.2.4 UDDI.........................................................................................................................................................30

3 CONCLUSÃO........................................................................................................................ 334 REFERENCIAS..................................................................................................................... 34

Page 5: Referencial teorico

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

Page 6: Referencial teorico

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:

Page 7: Referencial teorico

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

cada tarefa, quanto menor a nota, mais fácil é a tarefa. Cada integrante dá sua nota

Page 8: Referencial teorico

20

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 DesenvolvimentoFonte: Scrum (2007).

Page 9: Referencial teorico

21

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

realizam o reparte (divisão das revistas entre as bancas). Os jornais são distribuídos

Page 10: Referencial teorico

22

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.

Page 11: Referencial teorico

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.

Page 12: Referencial teorico

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.

Page 13: Referencial teorico

25

Primeiramente, para que um web service funcione, é necessário um

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):

Page 14: Referencial teorico

26

- Escalabilidade: sem limites para quantidade de aplicações

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.

Page 15: Referencial teorico

27

SOAP pode representar qualquer tipo de dados, serialização de

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

Page 16: Referencial teorico

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.

Page 17: Referencial teorico

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.

Page 18: Referencial teorico

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.

Page 19: Referencial teorico

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,

Page 20: Referencial teorico

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.

Page 21: Referencial teorico

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.

Page 22: Referencial teorico

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.