Web services

Instituto Superior de Entre Douro e Vouga

Tecnologias da Informação e da Comunicação│2010/2011

Tecnologias de Internet

Trabalho realizado por:
Sérgio Paulo Lopes da Rocha

Santa Maria da Feira, 03 Dezembro de 2010

TP 5 - Trabalho Prático WEB SERVICES

Í NDICE

1. Introdução.............................................................................................................. 3
2. Web Services e as Alternativas Tecnológicas (arquitectura)................................. 5
2.1 SOAP (Simple Object Access Protocol)........................................................ 6
2.2 WSDL (Web Service Description Language) ................................................ 8
2.3 UDDI (Universal Description, Discovery and Integration).............................. 9
3. Conclusão............................................................................................................ 12
4. Bibliografia........................................................................................................... 14

Sérgio Rocha - 2104 ISVOUGA Página 2 de 14


1. INTRODUÇÃO

Web Services, é a mais recente evolução nos padrões de desenvolvimento de
aplicações distribuídas, permitindo que aplicações cooperem facilmente e compartilhem
informações e dados umas com as outras. Espera-se que esta evolução altere a forma
como as aplicações são construídas e desenvolvidas, como a informação é
apresentada e compartilhada e como software é comprado e vendido.

Tecnicamente, Web Services são serviços distribuídos que processam mensagens
SOAP codificadas em XML, enviadas através de HTTP e que são descritas através de
Web Services Description Language (WSDL).

Web Services fornecem interoperabilidade entre componentes de software que podem
estar em diferentes empresas e podem residir em diferentes infra-estruturas. O SOAP é
baseado em XML e “navega” sobre o HTTP através de requisições GET ou POST na
porta 80, base de funcionamento da Web, isto é o que garante a interoperabilidade
entre diferentes plataformas. O WSDL, que também é baseado em XML e “navega”
sobre HTTP, fornece a descrição do serviço possibilitando a integração dele com
ferramentas de desenvolvimento e de gestão de componentes. No WSDL de um Web
Services estão descritos a URL para cessar o serviço, o nome do Web Service, a
descrição de cada método e a forma de fazer a requisição utilizando SOAP, GET ou
POST.

Uma das principais razões para o crescente interesse em Web Services é que eles
permitem uma Arquitectura Orientada a Serviços (SOA - Service-Oriented
Architecture). Quando se utiliza Web Services para a construção de tal arquitectura, as
soluções consistem de colecções de serviços autónomos, identificados por URLs, com
interfaces documentadas através de WSDL e processando mensagens XML. SOA é
um complemento a abordagens orientadas a objectos (OO) e processuais.



Uma arquitectura orientada a serviços difere de sistemas (OO) e processuais num
aspecto: a informação de ligação entre os componentes (binding). Serviços interagem
baseando-se em quais funções eles fornecem e como elas são entregues. Sistemas
(OO) e processuais ligam os elementos baseando-se em tipos e nomes.

Diferente de sistemas anteriores, o modelo de Web Services não opera sobre a noção
de tipos compartilhados que requerem implementações comuns. Em vez disso, os
serviços interagem baseando-se somente em contratos e esquemas. Isto permite que o
serviço descreva a estrutura das mensagens que ele pode enviar e/ou receber e
estabelecer restrições em suas mensagens. A separação entre estrutura e
comportamento, e a explícita descrição dessas características simplificam a integração
em ambientes heterogéneos. Além disso, esta informação caracteriza completamente a
interface do serviço, de forma que a integração da aplicação não requer um ambiente
de execução compartilhado para criar a estrutura ou o comportamento das mensagens.

Web Services, utilizam características de XML, esquemas e cabeçalhos SOAP para
permitir a evolução dos serviços de forma que não prejudiquem aplicações que já os
estejam utilizando.

Problemas como distribuição e transporte, segurança e autenticação, e controle de
transacções, são resolvidos com várias tecnologias e características dos Web Services.



2. WEB SERVICES E AS ALTERNATIVAS TECNOLÓGICAS (ARQUITECTURA)

Um factor decisivo para a consolidação deste novo conceito como um segmento da
indústria de tecnologia foi a formação de um consórcio, designado como Web Services
Interoperability Organization (WS-I), objectivando o desenvolvimento de padrões. Tal
grupo reuniu grandes líderes do mercado de tecnologia, tais como IBM, Microsoft, SAP,
Oracle, BEA System, Fujitsu entre outras, endossado por duas importantes empresas
de consultoria nesta área: o Gartner Group e a Forrester Research. A reunião destes
grandes competidores foi marcada, espantosamente, pelo interesse genuíno e
autêntico de se estabelecer padrões satisfatórios para todos os envolvidos. Adiciona-se
a isto o fato de que este consórcio, mais nitidamente através da Microsoft, vem
trabalhando junto ao W3C, entidade responsável pela padronização de diversas
linguagens e protocolos de Internet, numa proposta visando a padronização do SOAP
(Simple Object Access Protocol) e de outros padrões que dão suporte ao uso de Web
Services.

Conforme citado anteriormente, um Web Service é um componente ou unidade de
software que fornece uma funcionalidade específica, como uma rotina para validação
do número de cartão de crédito. A mesma poderá ser acessada por diferentes
sistemas, através do uso de padrões da Internet, como XML (Extensible Markup
Language) e HTTP (Hyper Text Transfer Protocol). A utilização de tais padrões é
importante para o desenvolvimento de aplicações distribuídas com Web Services.

Portanto, um Web Service poderá ser utilizado internamente, por uma única aplicação
ou por várias aplicações da mesma empresa, podendo ser exposto através da Internet,
a fim de ser utilizado por qualquer aplicação, bastando para isso que a aplicação seja
capaz de entender SOAP e XML. Acrescente-se ao uso do XML, HTTP e SOAP a
necessidade de uma linguagem que esclareça sobre sintaxe, parâmetros, métodos ou
funções, a WSDL (Web Services Description Language) e um directório geral, UDDI
(Universal Description, Discovery and Integration Services), verdadeira espécie de
páginas amarelas descrevendo os serviços disponíveis.



Tais nomenclaturas compõem o conjunto de tecnologias aceites pelos padrões
acordados entre os fornecedores, acima citados, e propostos ao W3C no que concerne
o assunto Web Services, a saber: HTTP, XML, SOAP, WSDL e UDDI. Neste trabalho
abordar-se-á mais detalhadamente as últimas três tecnologias, SOAP, WSDL e UDDI,
dado que as outras duas, HTTP e XML já foram abordadas em trabalhos anteriores.

2.1 SOAP (SIMPLE OBJECT ACCESS PROTOCOL)

É utilizado para invocar serviços remotos de forma síncrona ou assíncrona de um Web
Service. Trata-se, na realidade, de um protocolo padrão para troca de mensagens,
conforme se constata na imagem abaixo.

Possibilita que qualquer aplicação invoque e responda a qualquer outra aplicação.
Justamente, o que garante a inter-operabilidade do Web Services é o uso deste
protocolo padrão (SOAP) para o envio e recebimento destas mensagens. De notar que
a união das tecnologias amplamente disseminadas HTTP e XML deram origem aos
demais elementos que compõem a plataforma Web Services, como o protocolo SOAP,
por exemplo. Vale ainda citar, a título de referência, que este protocolo ainda se
encontra em fase de estudo junto ao W3C, conforme citado, sendo que esta entidade
referenda o mesmo como XML Protocol (XMLP).



No contexto de Web Services, um software hipotético de e-commerce formata uma
mensagem com informações do produto e do local de destino, na forma de uma
mensagem XML, a qual é encapsulada no formato SOAP, a fim de ser transportada
pelo protocolo HTTP, utilizado amplamente na Internet. No destino, o Web Service
"desempacota esta mensagem", lê informações no formato XML, faz cálculos e
empacota o resultado no formato XML, o qual é encapsulado pelo protocolo SOAP para
ser transportado pelo protocolo HTTP, de volta para o programa que fez a solicitação
de cálculo.

O SOAP possui duas vantagens em relação a tais protocolos:

1) Não se utiliza de mecanismos de selecção dinâmica de "ports" e, portanto,
pode processar facilmente através de "firewalls" padrões;

2) Pelo facto de ser derivado do padrão XML pode ser utilizado para dispor
argumentos de qualquer aplicação para qualquer outra aplicação, não
importando o tipo de sistema, linguagem de programação ou sistema
distribuído.

Basicamente, este protocolo compõe-se de três partes:

1) Um envelope que define um "framework", o qual descreve o que a mensagem
contém e como processá-la;

2) Um conjunto de regras codificadas para expressar instâncias dos tipos
definidos da aplicação;

3) Uma convenção que representa chamadas e respostas remotas de
procedimento.



Então, percebe-se que o SOAP não especifica necessidades da informação a ser
trocada, isso cabe às aplicações que o usam. O SOAP é assim uma plataforma sobre a
qual informação específica de aplicações pode ser trocada. É um standard que permite
grande expansibilidade e interoperabilidade entre sistemas. Esta interoperabilidade
poderá naturalmente estar ameaçada se não forem utilizados standards puros SOAP.

2.2 WSDL (WEB SERVICE DESCRIPTION LANGUAGE)

Trata-se de uma linguagem de definição de interface, baseada em XML, a qual
possibilita a descrição das funcionalidades, métodos e atributos disponibilizados pelo
Web Service. Consequentemente, permite que uma aplicação descreva as suas
funcionalidades e atributos num formato padrão, de tal forma que outra aplicação possa
compreendê-la. É considerado como um dos fundamentos que possibilita a
especificação consistente de um Web Service.

A fim de documentar e expor as funcionalidades de um Web Service, a Microsoft
propôs ao W3C a especificação WSDL. Esta define, adicionalmente, regras para a
descrição das funcionalidades de um Web Service, utilizando-se para isso do XML. São
descritos os métodos e propriedades suportados pelo Web Service, os tipos de dados e
os protocolos que podem ser utilizados para o envio e recebimento de mensagens. As
informações inseridas nas mensagens são repassadas por meio de operações e
palavras-chave da linguagem WSDL, como type, message, operation ou binding.



Assumindo que um dos objectivos do Web Services, é permitir que aplicações
desenvolvidas em diferentes linguagens ou mesmo modelos de programação diversos
possam operar entre si, o mesmo utiliza-se desta tecnologia WSDL. Interessante notar
que a mesma, descreve o serviço que será implementado pela lógica do negócio e as
interfaces necessárias para os clientes a chamarem. Não haverá a definição da
implementação da lógica de negócios. Haverá sim, apenas a descrição da mesma,
assumindo um conjunto de ponteiros finais de operações nas mensagens, os quais
contêm informações orientadas a documentos ou procedimentos.

Por tanto, verifica-se que o WSDL é um formato XML para descrever a interface pela
qual um Web Service é usado.

2.3 UDDI (UNIVERSAL DESCRIPTION, DISCOVERY AND INTEGRATION)

O aplicativo que irá utilizar um Web Service necessita identificar, ou descobrir, a
existência do mesmo. Ao criar-se uma aplicação de e-commerce, são necessários
mecanismos para catalogar e localizar Web Services com funcionalidades específicas
e que possam ser utilizados pela aplicação que está sendo criada. O UDDI vem
atender a esta necessidade. Tal como os anteriores formatos, este conceito utiliza-se
do padrão XML. A ideia é similar ao que propõe o padrão Corba com o conceito de
"repositório de objectos", embora as implementações sejam distintas. Analogamente,
trata-se de um serviço similar ao prestado pelas páginas amarelas, excepto pelo facto
de serem as mesmas electrónicas. Estas provêem uma estrutura de informações, na
qual várias entidades de negócio se registam a elas mesmas e aos seus serviços
respectivos, através das suas definições na linguagem WSDL, discriminadas por áreas
de negócio como indústria, produto ou geograficamente, de forma a permitir uma busca
optimizada.

Existem dois tipos de registos:

• Públicos, os quais servem como pontos de agregação para uma variedade de
negócios publicarem os seus serviços;



• Privados, os quais servem um papel similar nas organizações. A analogia que
se faz a este protocolo em face de uma arquitectura utilizando-se do J2EE ou
mesmo CORBA, são os protocolos JNDI Repos ou LDAP.

A especificação UDDI consiste de um esquema de 4 camadas dispostas
hierarquicamente, as quais provêem um modelo base de informação para publicar,
validar e invocar informações a respeito de um Web Service, conforme especifica a
imagem abaixo.

• Entidade de Negócio - o elemento no nível
mais elevado de um registo UDDI captura o
conjunto inicial de informações requeridas por
parceiros, pesquisando para localizar
informações a respeito de serviços de
negócio, incluindo aí o nome, o tipo de
indústria, categoria do produto, sua
localização geográfica, categorizações
opcionais e informações de contacto;

• Serviço de Negócio - esta estrutura agrupa
uma série de Web Services relacionados de
tal forma, que eles possam ser relacionados a
ambos os processos de negócio, quanto por
categorias de serviços. Este agrupamento
possibilita uma melhor optimização no tempo
de pesquisa;

• Informações de troca (Bind Information) -
cada Web Service de negócio tem um ou
mais elementos de descrições capturadas em
XML, designados como exemplos de troca



(Binding Templates). Este contem informações que são relevantes para
aplicações que são necessárias no momento de se invocar um serviço ou
quando está a ocorrer uma troca com um destes. Estas informações referem-
se ao endereço URL e o servidor, por exemplo;

• Informações de concordância - são informações que possibilitam a um cliente
determinar se um Web Service específico está de acordo quanto à sua
implementação. Referem-se a informações de ordem de compra do serviço,
questões de segurança, que protocolos são apropriados, que tipo de resposta
deverá ser aguardada após a ordem de compra, entre outras.

Assim, pode-se dizer que as funções do UDDI são:

• Permitir que as aplicações de negócio se descubram;

• Definir como elas irão interagir através da Internet;

• Compartilhar informações em registos globais.



3. CONCLUSÃO

Em forma de resumo, vale dizer que, o modelo de funcionamento da Web Service
segue uma linha que remete ao seguinte fluxo:

• Uma aplicação é desenvolvida, utilizando-se de qualquer tipo de linguagem de
programação;

• Tal aplicação possui uma série de interfaces formalizadas, as quais são
publicadas em WSDL;

• A entidade responsável pela aplicação, regista a si mesma apropriadamente
como sendo uma entidade de negócio, e publica as suas interfaces em WSDL,
num ou mais registos UDDI, que vêm a ser directórios de Servidores Web;

• Qualquer outra aplicação que necessite das funcionalidades daquela
desenvolvida, pesquisa os registos UDDI e localiza os serviços
correspondentes;

• Finalmente, é então invocado o serviço desejado, utilizando-se das
informações armazenadas no registo UDDI, especificamente, o URL do serviço
a ser localizado e a interface WSDL para ser utilizado.

Por fim, e a respeito das três tecnologias fundamentais para a implementação do
conceito de Web Services:

• SOAP - Utilizado para acesso e transporte. Trata-se do protocolo utilizado para
invocar um Web Service;

• WSDL - Utilizado para descrição. Trata-se da descrição ou definição de um
Web Service;



• UDDI - Utilizado para o descobrimento e publicação. Trata-se do directório no
qual o Web Service pode ser localizado.



4. BIBLIOGRAFIA

• http://pt.wikipedia.org/wiki/Web_service
• http://msdn.microsoft.com/pt-br/library/cc564893.aspx
• http://www.w3schools.com/webservices/default.asp
• http://pt.wikipedia.org/wiki/SOAP
• http://www.w3schools.com/soap/
• http://www.w3.org/TR/wsdl
• http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
• http://technet.microsoft.com/pt-br/library/cc783718%28WS.10%29.aspx


Web services

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à Web services

Similaire à Web services (20)

Plus de Sérgio Rocha

Plus de Sérgio Rocha (20)

Dernier

Dernier (20)

Web services