Web Services - Uma Soluao Para Aplicaoes as Na Internet

5/7/2018 Web Services - Uma Soluao Para Aplicaoes as Na Internet - slidepdf.com

http://slidepdf.com/reader/full/web-services-uma-soluao-para-aplicaoes-as-na-internet 1/58

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ

CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA

CURSO DE PÓS GRADUAÇÃO EM TECNOLOGIAS PARA SISTEMAS DEINFORMAÇÃO

ENIO PERPÉTUO JÚNIOR

IVERSON LOURENÇO JAGIELLO

WEB SERVICES

UMA SOLUÇÃO PARA APLICAÇÕES DISTRIBUÍDAS NA INTERNET

CURITIBA

2003





WEB SERVICES


Monografia apresentada à pós-

graduação em Tecnologias para

Sistemas de Informação da Pontifícia

Universidade Católica do Paraná, sob

a orientação do Professor Edgard

Jamhour.

Orientador:____________________

CURITIBA

2003





WEB SERVICES


Monografia apresentada à pós-graduação em Tecnologias para Sistemas de

Informação da Pontifícia Universidade Católica do Paraná, sob a orientação do

Professor Edgard Jamhour.

Orientador:_________________________________

Prof. Dr. Edgard Jamhour

__________________________________

__________________________________



”Na prática, as máquinas do amanhã

não serão puras máquinas de rede que

adquirem suas funções on-line nem puros PCs,

recheados de softwares de fábrica. Eles usarão

uma mistura de recursos locais e remotos por

meio de softwares nômades, fluentes, porque

isso atenderá melhor às necessidades das

pessoas”

Dertouzos Michael



Resumo

Este trabalho descreve uma nova tecnologia que se apresenta como a precursora de

uma revolução na comunicação entre aplicações: os Web Services. Alguns dos aspectos datecnologia de Web Services nos despertam muita atenção porque, em primeiro lugar, eles são

processados via Internet (à qual praticamente toda empresa está conectada), Intranet ou outras

redes baseadas em IP. Em segundo lugar, importantes fornecedores de tecnologia, como IBM,

Microsoft, Oracle e Sun, concordaram em apoiar um conjunto de padrões que definem como

sistemas diferentes devem interagir entre si, num nível até então improvável de cooperação

entre concorrentes. Além disso, a abordagem de Web Services não torna necessariamente as

tecnologias de integração anteriores obsoletas, mas viabiliza tipos de integração anteriormentemuito complexos.

Palavras-chave: Web Services - Internet – XML - Aplicações Distribuídas - B2B - Segurança



Abstract

This text describes a new technology that presents itself as a revolution in the

communications between applications: the Web Services. Some aspects of the Web Servicestechnology are very attractive. First, because they are processed through the Internet (which

practically all company are connected to), Intranet or other nets based on IP. Second,

important technology suppliers such as IBM, Microsoft, Oracle and Sun, have agreed to

support a set of standards that define how different systems must interact, in a level of

cooperation between competitors that was improbable before it. Moreover, Web Services does

not necessarily become others technologies of integration obsolete, but it makes possible

some integrations that were too complex.

Keywords: Web Services - Internet – XML - Distributed Applications - B2B - Security



Sumário

Sumário......................................................................................................................................7

I - Introdução ............................................................................................................................9

Estrutura do trabalho .........................................................................................................10

II - A Evolução dos Sistemas Distribuídos ...........................................................................11

Arquitetura Cliente / Servidor ............................................................................................11

Arquitetura Orientada a Objetos........................................................................................12

Internet / Intranet................................................................................................................13

Arquiteturas Distribuídas Orientadas a Objetos................................................................14

CORBA x DCOM..........................................................................................................14

J2EE x .NET .................................................................................................................15

Web Services.......................................................................................................................16

III - Arquitetura......................................................................................................................17

Componentes (components)................................................................................................20

Papéis (funções) – Roles.....................................................................................................20

Operações – Operations .....................................................................................................21

IV - Protocolos ........................................................................................................................22

XML – Extensible Markup Language .................................................................................23

Exemplo de documento XML........................................................................................24 Elementos XML (XML elements)..................................................................................26

Elementos XML possuem relacionamentos .............................................................26

Atributos XML ..............................................................................................................27

XML embutido em HTML . ...........................................................................................28

XML News ....................................................................................................................28

XML Namespaces .........................................................................................................29

Usando Namespaces................................................................................................30

SOAP (Simple Object Access Protocol).............................................................................31

Bloco de estrutura SOAP..............................................................................................31

Esqueleto de mensagens SOAP ....................................................................................32 Envelope SOAP.............................................................................................................32

O xmlns:soap namespace.........................................................................................33



O Atributo encodingStyle..............................................................................................33

Header SOAP ...............................................................................................................34

O atributo Actor (autor) ...............................................................................................34

O atributo mustUnderstand..........................................................................................35

SOAP Body ...................................................................................................................36 WSDL..................................................................................................................................36

Estrutura WSDL ...........................................................................................................37

WSDL ports ..................................................................................................................38

Bindings SOAP .............................................................................................................38

UDDI – Universal Description, Discovery and Integration...............................................38

Discovery direto ...........................................................................................................39

Discovery indireto ........................................................................................................39

API UDDI.....................................................................................................................39

UDDI Business Registry ...............................................................................................40

Páginas Brancas (White Pages)...................................................................................40

Páginas Amarelas (Yellow Pages) ...............................................................................40

Páginas Verdes (Green Pages).....................................................................................41

Arquitetura UDDI.........................................................................................................41

Sites-Operadores ..........................................................................................................42

Registrars .....................................................................................................................42

V - Segurança..........................................................................................................................43

Segurança ao nível de Transporte......................................................................................44

SSL................................................................................................................................44

PKI................................................................................................................................44

IPSec.............................................................................................................................45

Segurança ao nível de XML................................................................................................47

XKMS (XML Key Management Services).....................................................................48

WS-Security ..................................................................................................................48

VI - Aplicação de WS em B2B...............................................................................................50

Vantagens e Desvantagens do WS ......................................................................................52

VII - Como o Mercado apoia o padrão.................................................................................54 Microsoft.......................................................................................................................54

Sun Microsystems .........................................................................................................54

Oracle ...........................................................................................................................55

META Group ................................................................................................................55

OASIS............................................................................................................................55

TechMetrix Research....................................................................................................56

Forrester Research Inc.................................................................................................56

VIII – Conclusão.....................................................................................................................57

Referências ..............................................................................................................................58



I - Introdução

Durante o curso de especialização, tivemos contato com as principais tecnologias desistemas de informação e acompanhamos o sua evolução impulsionada, entre outros motivos,

pela enorme necessidade de integração entre os sistemas. Optamos por abordar neste trabalho

de final de curso uma nova tecnologia que se apresenta atualmente como a preconizadora de

uma grande revolução nas comunicações entre as aplicações: os Web Services.

Alguns dos aspectos da tecnologia de Web Services nos despertam muita atenção

porque, em primeiro lugar, eles são processados via Internet (à qual praticamente toda

empresa está conectada), Intranet ou outras redes baseadas em IP. Em segundo lugar,

importantes fornecedores de tecnologia, como IBM, Microsoft, Oracle e Sun, concordaram

em apoiar um conjunto de padrões que definem como sistemas diferentes devem interagir

entre si, num nível até então improvável de cooperação entre concorrentes. Além disso, a

abordagem de Web Services não torna necessariamente as tecnologias de integração

anteriores obsoletas, mas viabiliza tipos de integração anteriormente muito complexos.

Ao longo deste trabalho pretendemos apresentar ao leitor de forma abrangente os

principais aspectos desta nova tecnologia e colocá-lo em contato com a nova tendência de

desenvolvimento de software proposto por ela. A fim de obter informações atualizadas, este

trabalho contou com uma pesquisa realizada exclusivamente em sites da Internet, onde um

vasto material sobre este assunto pode ser encontrado com facilidade. Os endereços acessados

encontram-se listados ao final deste trabalho onde informações ainda mais aprofundadas

podem ser obtidas.



10

Estrutura do trabalho

No capítulo seguinte é descrito de maneira breve a evolução dos sistemas

computacionais distribuídos desde a arquitetura centralizada, Client-Server, AplicaçõesDistribuídas, Objetos Distribuídos, o surgimento de aplicações para a Internet até a

necessidade de se obter uma interoperabilidade entre estas aplicações nos dias atuais.

O capítulo III descreve mais detalhadamente o conceito de Web Services e apresenta a

sua Arquitetura e elementos.

No capítulo IV serão apresentados os principais protocolos utilizados em Web

Services, tais como SOAP, UDDI, WSDL pretendendo assim mostrar como estes protocolosse encaixam para formar a base desta nova arquitetura.

O capítulo V dedica-se a rever alguns dos principais protocolos de segurança

desenvolvidos para suportar as aplicações distribuídas e mostrar como eles podem ser

aplicados para garantir transações seguras em Web Services. Além de citar os novos

protocolos especialmente desenvolvidos para este fim.

O sexto capítulo deste trabalho apresenta como a arquitetura de Web Services se

encaixa neste novo contexto de aplicações distribuídas e B2B além de apresentar quais os

benefícios que ela traz tanto aos desenvolvedores quanto para os usuários. Neste capítulo

também, será apresentado quais as situações em que a aplicação de Web Services não é a mais

adequada.

No capítulo VII apresentamos as ações de algumas das principais empresas envolvidas

na padronização da Arquitetura de Web Services, quais as tendências em relação à

movimentação do mercado em torno do Web Services e algumas pesquisas que apontam oque está previsto para os próximos anos.



II - A Evolução dos Sistemas Distribuídos

Arquitetura Cliente / Servidor

No início da década de 90, a grande novidade nos sistemas corporativos era a

arquitetura cliente/servidor, expressão que designa um tipo de arquitetura de sistemas que se

contrapôs a dois modelos utilizados anteriormente: os sistemas centralizados e os micros

isolados.

No primeiro, todos os dados e funcionalidade do sistema da empresa residiam em

computadores de grande porte, os chamados Mainframes. Os terminais utilizados nãopossuíam nenhuma capacidade de processamento ou armazenamento de dados local,

caracterizando um sistema extremamente inflexível.

Com o adventos das LANs (Local Area Network) a situação começou a melhorar. Os

arquivos e programas mais importantes passaram a residir num servidor de arquivos,

protegidos por senhas e backups automáticos. O gerenciamento das impressoras passou a ser

também centralizado, otimizando sua utilização. Todo o processamento ainda se concentrava

na própria estação de trabalho do usuário.

Entretanto, os sistemas baseados em bancos de dados, espinha dorsal da maioria das

empresas, continuavam a residir nos Mainframes, com interfaces não-amigáveis. Para integrar

os sistemas de bancos de dados aos microcomputadores que tornavam-se cada vez mais

comuns nas mesas dos usuários, começou a ser difundido o conceito de arquitetura

cliente/servidor. A grande novidade desta arquitetura é a separação dos aplicativos

corporativos e do processamento de transações em duas partes, uma executada no servidor e

outra na máquina do cliente. Nesses aplicativos distribuídos, a porção servidor é responsável

pela segurança e pela integridade dos dados, enquanto o cliente serve para exibir os dados



12

numa interface amigável e de modo personalizável ao usuário final. Este modelo, embora

amplamente difundido, possui um alto custo de suporte e manutenção.

Arquitetura Orientada a Objetos

Na programação distribuída usando a arquitetura cliente-servidor, clientes e servidores

podem ser implementados usando qualquer paradigma de programação. Assim, é possível que

um serviço específico seja executado por um método de algum objeto. No entanto, mesmo

que o cliente também tenha sido desenvolvido orientação a objetos, na comunicação entre o

cliente e o servidor esse paradigma deve ser esquecido, devendo ser utilizado algum protocolopreestabelecido de troca de mensagens para a solicitação e resposta ao serviço.

Um sistema de objetos distribuídos é aquele que permite a operação com objetos

remotos. Dessa forma é possível, a partir de uma aplicação cliente orientada a objetos, obter

uma referência para um objeto que oferece o serviço desejado e, através dessa referência,

invocar métodos desse objeto, mesmo que a instância desse objeto esteja em uma máquina

diferente daquela do objeto cliente.

O conceito básico que suporta plataformas de objetos distribuídos é o conceito de

arquiteturas de objetos. Essencialmente, uma arquitetura orientada a objetos estabelece as

regras, diretrizes e convenções definindo como as aplicações podem se comunicar e

interoperar. Dessa forma, o foco da arquitetura não é em como a implementação é realizada,

mas sim na infra-estrutura e na interface entre os componentes da arquitetura.

No paradigma de arquiteturas de objetos, há três elementos principais. A arquitetura

OO fornece uma descrição abstrata do software, que categorias de objetos serão utilizadas,como estarão particionados e como interagirão. As interfaces são as descrições detalhadas das

funcionalidades do software. Finalmente, a implementação é composta por módulos de

software que suportam as funcionalidades especificadas nas interfaces.

O uso de interfaces permite isolar a arquitetura de um sistema de sua implementação.

Dessa forma, o sistema pode ser construído com um alto grau de independência em relação às

implementações específicas de suas funcionalidades, ou seja, é possível substituir

implementações específicas com pequeno impacto sobre o sistema como um todo.



13

A adoção do paradigma de arquitetura de objetos permite também atingir um alto grau

de interoperabilidade através da adoção de uma infra-estrutura padronizada de comunicação

entre objetos através das interfaces. Assim, cada componente da arquitetura deve se preocupar

apenas em como se dará sua comunicação com a infra-estrutura de comunicação.

Internet / Intranet

A partir de 1994, o fenômeno da Web mostrou um novo modelo de integração de

sistemas, constituindo-se de padrões abertos, com maior independência em relação aos

fornecedores, trazendo um novo enfoque para a relação cliente/servidor. Por meio de

formulários desenvolvidos em linguagem HTML (Hypertext Markup Language), clientes e

servidores podem trocar informações, pode-se ter acesso a bancos de dados, documentos

ficam a disposição de usuários na rede e grupos de trabalho encontram meios para o

desenvolvimento de trabalhos colaborativos.

Todas estas facilidades encontradas na Web acabaram sendo levadas para dentro das

corporações, por meio de uma versão doméstica da Internet, a Intranet, tecnologia que vem

varrendo o mundo empresarial. Embora a Intranet ainda apresente limitações nodesenvolvimento de aplicações que acessem bancos de dados no estilo do modelo

cliente/servidor, seu baixo custo e facilidade de implantação vêm fazendo com que cada vez

mais empresas adotem esta tecnologia.

Nos últimos anos diversos padrões foram propostos para a implementação do conceito

de sistemas distribuídos. Um modelo muito popular tem sido o de separação de uma aplicação

em camadas, apresentação, negócio e dados. No entanto, ainda nos deparamos com alguns

problemas que impedem que este modelo desenvolva-se plenamente, tais como:

complexidade de implementação e, principalmente, implantação. Sistemas escritos em

diferentes linguagens, e não raro em plataformas distintas, sofrem ainda de um mal bem mais

grave, a incompatibilidade entre os tipos de dados, além da necessidade de forte envolvimento

das equipes técnicas de ambos os lados no processo de integração. Estas tem sido as

principais causas da baixa integração entre os sistemas de clientes e fornecedores mesmo com

toda a facilidade de infra-estrutura de comunicação existente hoje em dia.



14

Arquiteturas Distribuídas Orientadas a Objetos

A necessidade de integração das aplicações que se encontravam em ambientes

heterogêneos e a necessidade de comunicação entre elas em tempo-real fez com que acomputação distribuída ganhasse cada vez mais espaço no mundo atual. O DCE (Distributed

Computer Environment) foi o começo dessa tendência de computação distribuída em

empresas, porém o DCE não era orientado a objeto, assim surgiu o CORBA, que é uma

arquitetura de objetos para computação distribuída. e junto com o CORBA veio o DCOM da

Microsoft. O DCOM era o principal concorrente do CORBA, a diferença entre essas duas

tecnologias é que o CORBA roda em multiplataforma, enquanto o DCOM só em ambientes

Windows.

CORBA x DCOM

O padrão CORBA (Common Object Request Broker Architecture), é um conjunto de

especificações criado pela OMG (Object Management Group), um grupo formado por mais de

800 empresas da indústria de informática.

Um sistema baseado em CORBA é composto por objetos distribuídos, que são

elementos de software que implementam um determinado processamento e possuem uma

determinada interface. O CORBA define uma camada intermediária (middleware) entre os

objetos distribuídos da aplicação e a rede de comunicação. A localização do objeto e a

linguagem na qual ele está implementado são mantidos totalmente transparentes. Detalhes de

implementação e localização não precisam ser conhecidos para se fazer uma requisição a um

objeto. Tudo que é necessário saber de um objeto CORBA para requisitá-los, é a sua

interface. A interface de um objeto é definida através da linguagem IDL (Interface Definition

Language), que é totalmente declarativa, não trazendo nenhum detalhe de implementação de

objeto. A linguagem IDL permite definir os métodos e atributos de um objeto e exceções que

ele pode gerar. Ela permite a independência de sistema operacional e de linguagem de

programação para os objetos. Objetos clientes e servidor em diferentes linguagens e

executando em diferentes sistemas operacionais podem interoperar sem nenhum problema.

O DCOM foi criado pela Microsoft em 1996 como uma evolução natural do

OLE/COM ( Object Linking Embedding/Component Object Model), lançado em 1993 com

o objetivo de suportar a comunicação entre objetos distribuídos. O DCOM faz uso dos



15

investimentos realizados no COM, tais como aplicações, componentes, ferramentas e

conhecimento para ingressar no mundo da computação distribuída baseado nas padronizações

já existentes. Trata-se de um protocolo que possibilita componentes de software se

comunicarem diretamente sobre uma rede de maneira confiável. O COM define como deve

ser a interação entre os objetos e seus clientes, sem a intermediação de qualquer componente

do sistema.

Analogamente às DLLs, que são códigos compilados prontos para uso, o modelo de

componentes do DCOM seria uma versão “orientada a objeto” da DLL, com poderes

ampliados tais como a reutilização de código.

J2EE x .NET

Com o J2EE (Java 2 Entreprise Edition) e a plataforma .NET, Sun Microsystems e

Microsoft, respectivamente, travam um novo duelo de titãs na competitiva arena de

desenvolvimento de aplicações para Internet.

Com a .NET, a Microsoft introduziu uma plataforma capaz de competir em iguais

condições com a J2EE (Java 2 Platform, Enterprise Edition), da Sun Microsystems. Java

representa mais do que uma linguagem de programação, pois, ao lado da tecnologia de

máquinas virtuais (JVM), permite compilar os programas, sem alterações, para serem

executados em diversos equipamentos. A plataforma da Microsoft era, até pouco tempo atrás,

essencialmente baseada no Windows e estava atrelada ao mundo do PC. Com o advento da

.NET, a primeira grande diferença é que o ambiente de desenvolvimento agora ampliou sua

atuação também para outros dispositivos e para acrescentar a contribuição de ferramentas de

parceiros.

Por outro lado, Mais do que uma plataforma de desenvolvimento de aplicações, a Sun

Microsystems acena para o mercado com uma opção que segue o ideal de se trabalhar com

soluções e sistemas abertos, enriquecidos por comunidades de desenvolvedores.

Um outro fator muito importante e que promete aumentar ainda mais a disputa entre as

duas plataformas é que tanto J2EE quanto .NET são compatíveis com os principais padrões

relacionados aos Web Services, entre eles SOAP, WSDL e UDDI.



16

Web Services

Web Services tratam-se de uma forma simples e padronizada de utilizar a malha da

Internet para implementar a integração entre sistemas heterogêneos, de forma bastanteflexível, substituindo as tradicionais estratégias de EAI.

O significado de “Enterprise Application Integration” (EAI), cuja tradução seria

“Integração de Aplicações Corporativas”, mudou com o tempo. Há algum tempo, o termo era

exclusivamente usado para designar a tentativa de uma empresa de interligar suas aplicações

internas de negócios de forma que os dados possam ser compartilhados entre elas.

Recentemente, o significado foi expandido para também englobar a união de dados e

processos com parceiros comerciais externos.

Não é raro que o ambiente de tecnologia seja bastante heterogêneo dentro de uma

mesma empresa, com sistemas distintos para cada aplicação. Novas tecnologias e frameworks

de desenvolvimento estão surgindo, tendo como objetivo uma maior integração entre os

diversos aplicativos e serviços disponíveis na Internet. Este novo modelo em crescimento

deve tratar tarefas complexas, como o gerenciamento de transações, através da

disponibilização de serviços distribuídos que utilizem interfaces de acesso simples e bem

definidas.

Web Services permitem a integração entre sistemas distintos de forma bastante

simples e direta. Uma das regras que nortearam a criação do padrão foi "não invente nada de

novo". Basicamente um Web service funciona como uma página Web, com a diferença que ao

invés de HTML, utiliza-se XML. Desta forma os dados podem ser descritos e o pacote da

mensagem pode ser manipulado com grande facilidade tanto por quem envia, quanto por

quem recebe.



III - Arquitetura

Uma arquitetura de Web services ocupa, dentro de uma relação, vários componentes etecnologias que compreendem uma pilha de Web services ou implementações completamente

funcionais. Componentes e tecnologias que estendem a arquitetura básica são representadas

dentro da arquitetura estendida.

A arquitetura básica inclui tecnologias Web services capazes de:

• trocar mensagens;

• descrever Web services;

• publicar e descobrir descrições Web services.

O fundamento da arquitetura Web services define uma interação entre agentes de

software como um trocador de mensagens entre serviços requisitados e provedores de serviço.

Os requisitantes são softwares agentes que requisitam a execução do serviço. Provedores são

agentes de software que provêem um serviço. Agentes podem ser ambos, requisitantes e

provedores. Provedores são responsáveis por publicar a descrição do serviço que ele esta

disponibilizando / provendo. Requisitantes devem ser capazes de encontrar as descrições dosserviços.

O fundamento dos modelos de arquitetura do Web service interagem entre agentes

realizando qualquer das três funções: provedor de serviço, agência de serviço de publicação e

requisição do serviço. A interação envolve a publicação, localização e operação de união.

Num cenário típico um provedor de serviço hospeda um exemplo de uma rede acessível

através de agente de software. O provedor do serviço define a descrição do serviço para o

Web service e publica isso para um requisitante ou para um agente de publicação. Orequisitante do serviço usa uma função de procura para recuperar a localização do serviço



18

localmente ou para descobrir uma agência de publicação (ex: registro ou repositório) e usa o

serviço de descrição para ligar o Web service com o provedor e invocar ou interagir com a

implementação do Web service. O provedor de serviço e a função de requisitante são

desenvolvidas e um serviço deve exibir características de ambas.

O uso de Web services na Internet esta se expandindo rapidamente como uma

necessidade por comunicação de aplicativo pra aplicativo e crescente interoperabilidade.

A excitação encima do Web service é baseada no potencial para uma combinação de

especificações de XML, a Internet, o SOAP e o WSDL, e na definição de protocolos de

endereçamento de tarefas, muitos dos problemas dessas tecnologias foram encontradas.

As populares tecnologias Web service SOAP 1.1 e WSDL 1.1 foram originariamente

desenvolvidas fora do W3C, porem, seus sucessores estão agora sendo desenvolvidos dentro

das atividades do Web service W3C. Estas especificações estão sendo usadas como a base

para a criação de uma arquitetura de mensagens extensível (SOAP 1.2) e a definição de uma

interface de linguagem (WSDL 1.2).

A figura acima ilustra a arquitetura básica do Web service, na qual um requisitante de

serviço e um provedor interagem baseados no serviço descrição da informação publicada pelo

provedor e descoberta pelo requisitante através de algumas formas de descobrimento da

agencia. O serviço é requisitado e os provedores interagem trocando mensagens, as quais

devem ser agregadas para o formulário MEP´s message Exchange patterns (padrões de troca

de mensagens).



19

No desenho acima, os nós do triângulo representam as funções ou papeis, e as

extremidades representam as operações.

Um ou mais mediadores devem existir no caminho entre um requisitante e umprovedor. Mediadores, onde presentes, não podem interferir com o MEP. Mediadores devem

realizar certas funções associadas com a mensagem assim como rotinas, segurança,

gerenciamento, ou outras operações. Exemplos de MEPs incluem unilateralmente,

requisições/respostas, publicação/aprovação, e transmissão.

Arquitetura de componentes básica de Web Service são tipicamente definidas usando

aplicações XML, usando definições XML tipos de mensagens e estruturação, e usando para

transporte o http. Componentes de arquitetura estendida em Web services são tipicamentedefinidas usando extensões para conduzir aplicações XML e transportá-la, incluindo

alternativas para o http.

Uma mensagem é definida como uma combinação que pode incluir zeros ou mais

cabeçalhos em adição para dados. A parte do cabeçalho de uma mensagem pode incluir

informação pertinente para estender as funcionalidades, como segurança, contextos de

transação, informação de orquestração, ou informação para roteamento de mensagens. O dado

da parte da mensagem contém um conteúdo de mensagem ou dados.

Um Web service é descrito usando um padrão, uma notação formal XML, chama-se

isso de descrição do serviço, que provê todos os detalhes necessários para interagir com o

serviço, incluindo formato de mensagens, transporte de protocolos, e localização. As

naturezas das interfaces escondem os detalhes da implementação do serviço então isso pode

ser usado independentemente da plataforma de hardware ou software na qual é implementada

e independentemente da linguagem em que foi escrita.

Web service pode ser usado sozinho ou em conjunto com outros Web services para

atingir uma agregação complexa ou uma transação de negócios.

A figura acima ilustra a relação entre requisitantes, provedores, serviços, descrições, e

descobridores de serviço no caso, agentes onde agentes fazem o papel de requisitantes e

provedores. O provedor de publicação um arquivo WSDL que contém a descrição da

mensagem e ponto final da informação para permitir ao requisitante gerar a mensagem SOAP

e enviá-la para o destino correto.



20

Para implantar um MEP comum (padrão de troca de mensagens) da

requisição/resposta, por exemplo, uma implementação Web service prove agentes de software

que funcionam ao mesmo tempo como requisitantes e provedores. O requisitante do serviço

envia uma mensagem em forma de uma requisição de informação, ou para realizar uma

operação, e receber uma mensagem do provedor do serviço que conterá um resultado para a

requisição ou operação. O provedor do serviço recebe a requisição, processa a mensagem e

envia uma resposta. A tecnologia tipicamente usada para esse tipo de interação Web service

inclui SOAP, WSDL, e http.

As seguintes seções provêem mais definições para os componentes, funções, e

operações na arquitetura Web service.

Componentes (components)

Serviço: considerando que um Web service é uma interface descrita por uma descrição

de serviço, esta implementação é o serviço. Um serviço é um modulo de software

desenvolvido em plataformas de rede acessíveis providos por provedores de serviço. E existe

para ser chamado ou interagir com um requisitante do serviço. Isto deve ser funcional também

como um requisitante, usando outros Web services nessa implementação.

Descrição do serviço: As descrições do serviço contem detalhes da interface e

implementação do serviço. Isso inclui seus tipos de dados, operações, informações de

ligações, e localização de rede, poderiam também incluir categorização e outros meta dados

para descobrir facilidades e utilização pelos requisitantes. A descrição completa deve ser

realizada como um conjunto de descrições de documentos XML. A descrição do serviço deve

ser publicada para um requisitante diretamente ou para uma agencia descobridora.

Papéis (funções) – Roles

Provedor de serviço: De uma perspectiva de serviço, este é o proprietário do serviço.

De uma perspectiva de arquitetura é a plataforma que hospeda o acesso para o serviço.

Também sendo referenciado como um ambiente de execução do serviço ou um

compartimento do serviço. Esse papel no padrão de troca de mensagens é aquele de um

servidor.

Requisitante do serviço: de uma perspectiva de um negócio é uma tarefa que requercertas funções para ser satisfeita. De uma perspectiva de arquitetura esse é a aplicação que



21

esta olhando para uma invocação ou inicializando uma interação com um serviço. O papel de

requisitante pode ser feito por um browser dirigido para uma pessoa ou um programa sem

uma interface de usuário.

Agência descobridora: Esta é uma localizadora padrão de descrição de serviços onde

os provedores do serviço publicam suas descrições de serviço. O serviço de agencia

descobridora pode ser centralizada ou distribuída. A agencia descobridora pode suportar

ambos os padrões onde tenha que enviar descrições e onde possa ativamente inspecionar,

procurar por provedores de descrições de serviços. Requisitantes de serviços devem localizar

serviços e obter ligações de informações durante o desenvolvimento de ligações estáticas, ou

durante a execução de ligações dinâmicas.

Operações – Operations

Para uma aplicação tomar vantagens do Web services, três maneiras devem tomar

lugar: publicação das descrições dos serviços, localização e recuperação das descrições dos

serviços, e ligações ou invocação dos serviços baseados nos serviços de descrição. Essas

maneiras podem ocorrer só ou interativamente com qualquer cardinalmente entre os papéis.

Em detalhes, essas operações são:

Publicação: para ser acessível, um serviço precisa publicar suas descrições assim

como o requisitante pode subseqüentemente localizá-las.

Localização: Na operação de localização, o requisitante do serviço recupera uma

descrição do serviço diretamente ou perguntando pelo registro do serviço requerido. A

operação de localização deve ser envolvida em duas fases de ciclos de vida para o requisitante

do serviço: no tempo de construção para recuperar a interface da descrição do programa

desenvolvido, e na hora de execução para recuperar a ligação do serviço e descrição da

localização para invocação.

Interação: eventualmente, um serviço necessita ser invocado. A operação de interação

do requisitante do serviço invoca ou inicializa uma interação com o serviço na hora de

execução usando os detalhes da descrição da ligação para localização, contatar, e inovar o

serviço.



IV - Protocolos

A implementação de Web Services é baseada em um conjunto de protocolos elinguagens padrões da Web, dentre eles podemos destacar o HyperText Transfer Protocol

(HTTP), o Simple Object Access Protocol (SOAP), a Web Service Description Language

(WSDL) e o UDDI. O formato XML é a base dos três últimos padrões.

De uma maneira geral, o protocolo SOAP define o formato que as mensagens

transportadas na rede devem ter para encaminhar requisições a serviços Web. Este protocolo

também define o formato das mensagens de resposta às requisições. Já o WSDL consiste em

uma linguagem XML para a descrição de interfaces de serviços, visando tornar essa descrição

inteligível para programas que irão interagir com esses serviços.

Nas páginas seguintes nós vamos descrever detalhadamente cada um destes protocolos

XML, SOAP, WSDL e UDDI para dar um entendimento maior sobre o funcionamento do

Web Services.



23

XML – Extensible Markup Language

XML é um formato de texto muito simples e flexível derivado do SGML.

Originalmente projetado para encontrar chaves em documentos eletrônicos em larga escala,XML esta também se tornando um importante padrão para a troca de uma vasta variedade de

dados na web.

Com o advento do XML tornou-se fácil para sistemas de diferentes ambientes

trocarem informações. A universalidade do XML tornou-se uma maneira muito atrativa para

comunicação entre programas. Programadores podem usar diferentes sistemas operacionais,

linguagens de programação etc. e ter seus softwares comunicando-se com outros de uma

maneira ininterrupta. XML, XML namespaces e XML schemas são ferramentas úteis para

prover mecanismos para realizar acordos com estruturas extensas em um ambiente

distribuído, especialmente quando usados em conjunto, XML namespaces e XML schemas

serão abordados mais adiante.

No mundo em geral, sistemas de computador e bancos de dados contém dados em

formatos incompatíveis, muito tempo se tem gasto no desafio de desenvolvedores em trocar

dados entre sistemas e a Internet, portanto o objetivo do XML é a troca de dados.

Convertendo dados para XML pode-se reduzir em muito esta complexidade e criar

dados que podem ser lidos por uma variedade de diferentes tipos de sistemas.

Alguns conceitos:

• XML foi desenvolvido para descrever dados e focar o que os dados são.

• HTML foi desenvolvido para mostrar dados e focar em como os dados aparecem.

• Com o XML os dados são armazenados fora do HTML.

Quando o HTML é usado para mostrar dados, o dado é armazenado dentro do HTML.

Com o XML, dados podem ser armazenados em arquivos XML separados, desta maneira

pode-se concentrar o HTML para dados de layout e visualização, e ter certeza que as

mudanças em dados essenciais não irão requerer nenhuma mudança para o HTML.



24

Dados XML também podem ser armazenados dentro de páginas HTML como “ilhas

de dados” (data island), pode-se ainda concentrar em usar somente HTML unicamente para

formatar e visualizar os dados.

XML está se transformando para ser a principal linguagem para troca de informação

financeira entre empresas na Internet, muitas aplicações interessantes de B2B estão sendo

desenvolvidas.

O XML possui outras vantagens nesse aspecto:

• Armazenamento de dados em arquivos ou bancos de dados, podendo ser recuperados mais

tarde;

• Tornar os dados mais úteis para uma quantidade enorme de usuários, pois é independente

de hardware;

• Pode ser usado para criar outras linguagens, XML é a mãe do WAP e WML;

Exemplo de documento XML

Documentos XML usam uma descrição própria e uma sintaxe simples:

<?xml version="1.0" encoding="ISO-8859-1"?>

<note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget me this weekend!</body>

</note>

• A primeira linha no documento ( declaração XML) define a versão do XML e a

codificação dos caracteres usados no documento;

• A próxima linha descreve o elemento raiz do documento, como se fosse um título;

• As próximas quatro linhas descrevem quatro elementos da raiz (to, from, heading, body);

• Na última linha aparece o fechamento do elemento raiz (root).



25

Um dado importante no XML é que todos os elementos possuem uma tag de abertura,

ex.: <note> e uma tag de fechamento ex.: </note>, portanto a falta de um deles é

considerada ilegal.

As tags no XML são diferentes quando expressadas em maiúsculas ou minúsculas

diferentemente do HTML, portanto deve-se tomar o cuidado em digitar as tags da mesma

forma na sua abertura e fechamento. Além disso as tags devem merecer principal atenção no

caso de sua inserção, pois apresentam erros se forem inseridas de maneira errada, ex.:

Abaixo nota-se a inserção do <b><i> e o seu respectivo fechamento </i></b> a

inserção errada desse detalhe ocasiona erros no XML, diferentemente do HTML onde é aceito

essa inversão sem problemas.

Forma aceita no XML

<b><i>This text is bold and italic</i></b>

Forma aceita no HTML

<b><i>This text is bold and italic</b></i>

Outros pontos que devem ser notados em documentos XML:

Nomes e valores devem ser citados, ou seja, devem ser mencionados no documento

com aspas para serem reconhecidos ex:

<note date="12/11/2002"> - modelo correto;

<note date=12/11/2002> - modelo incorreto.

Espaços em branco que são digitados em documentos XML não são levados em

consideração no momento da visualização.

Novas linhas no XML são sempre armazenadas como LF, ou seja, no momento da

impressão o carro da impressora deve ser voltado manualmente para a esquerda e o papel

novamente realinhado, diferentemente de aplicativos Windows que usam o CR (carriage

return – retorno do carro de impressão).



26

Elementos XML (XML elements)

Elementos XML são extensíveis e tem relacionamentos, possuem simples regras de

nomes.

Analisaremos o modelo abaixo:

<note>

<to>Tove</to>

<from>Jani</from>


</note>

Podemos criar uma aplicação que extrai o elemento <to>, <from> e <body> desse

documento XML para produzir esse resultado:

MESSAGE

To: Tove

From: Jani

Don't forget me this weekend!

Por mais que o autor do documento acima adicione mais elementos ao documento aaplicação ainda será capaz de localizar os elementos <to>, <from> e <body> e produzir o

mesmo resultado anterior.

Elementos XML possuem relacionamentos

Elementos são relacionados como pais (parents) e filhos (children).

Imaginemos que essa seja a descrição de um livro:

Book Title: My First XML

Chapter 1: Introduction to XML

What is HTML

What is XML

Chapter 2: XML Syntax

Elements must have a closing tag

Elements must be properly nested



27

Imagine que esse documento XML descreve o livro acima:

<book>

<title>My First XML</title>

<prod id="33-657" media="paper"></prod><chapter>Introduction to XML

<para>What is HTML</para>

<para>What is XML</para>

</chapter>

<chapter>XML Syntax

<para>Elements must have a closing tag</para>

<para>Elements must be properly nested</para>

</chapter>

</book>

Book é o elemento raiz (root element). Title, prod, e chapter são elementos filhos

(child element) do livro.

Book é o elemento pai (parent element) do elemento title, prod e chapter. Title, prod

and chapter são irmãos (siblings ou sister elements) porque eles tem o mesmo pai.

Elementos podem ainda ter diferentes tipos de conteúdo.

Um elemento pode ter elemento de conteúdo, conteúdo misturado, conteúdo simples,

ou conteúdo vazio. Um elemento pode também ter atributos.

No exemplo acima temos os seguintes:

• book, tem um elemento de conteúdo, porque contem outros elementos;

• Chapter, tem um conteúdo misturado, porque contem texto e outro elemento;

• Para, tem conteúdo simples, porque contem somente texto.

• Prod, tem conteúdo vazio, porque não carrega nenhuma informação.

Atributos XML

Elementos XML podem ter atributos no início da tag, sendo parecido com HTML.

Atributos são usados para prover informações adicionais sobre elementos.



28

De documentos HTML podemos lembrar isso: <IMG SRC="computer.gif"> . O

atributo SRC provê informações adicionais sobre o elemento IMG.

No HTML e XML atributos provêem informações adicionais sobre elementos:<img src="computer.gif">

<a href="demo.asp">

Atributos geralmente provem informação que não são parte dos dados. No exemplo

abaixo o tipo de arquivo é irrelevante para os dados, mas importante para o software que quer

manipular o elemento.

<file type="gif">computer.gif</file>

XML embutido em HTML .

XML pode ser inserido diretamente dentro de uma página HTML, como mostrado

abaixo:

<xml id="note"><note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>


</note>

</xml>

ou separadamente, podem ser inserido assim:<xml id="note" src="note.xml">

</xml>

XML News

O XMLNews é uma especificação para troca de noticias e outras informações.

Permite à produtores e consumidores de notícias produzir, receber e arquivar qualquertipo de informação através de diferentes software, hardware e linguagens de programação.



29

Um exemplo de documento XMLNews:

<?xml version="1.0" encoding="ISO-8859-1"?>

<nitf>

<head><title>Colombia Earthquake</title>

</head>

<body>

<body.head>

<headline>

<hl1>143 Dead in Colombia Earthquake</hl1>

</headline>

<byline>

<bytag>By Jared Kotler, Associated Press Writer</bytag>

</byline><dateline>

<location>Bogota, Colombia</location>

<story.date>Monday January 25 1999 7:28 ET</story.date>

</dateline>

</body.head>

</body>

</nitf>

XML Namespaces

Com a visibilidade futura de aplicações XML onde um único documento pode conter

elementos e atributos que são definidos para serem usados por múltiplos softwares, foram

criados os Namespaces.

Um XML Namespace é uma coleção de nomes, identificados por uma referencia URI,

que é usada em documentos XML como tipos e elementos e atributo de nomes. XML

Namespace difere dos “Namespace” convencionalmente usados em disciplinas de

computação em que a versão XML tem uma estrutura interna e não é, matematicamente

falando, um conjunto.

XML Namespaces provêem um método de evitar conflitos de elementos em

documentos XML.

Desde que nomes de elementos em XML não são fixados, muito freqüentemente um

nome irá conflitar com outro ocorrendo dois tipos diferentes de documentos usando a mesma

descrição de nomes para dois tipos diferentes de elementos.



30

Este documento XML carrega informação em uma tabela:

<table>

<tr>

<td>Apples</td><td>Bananas</td>

</tr>

</table>

Este documento XML carrega informação sobre uma tabela:

<table>

<name>African Coffee Table</name>

<width>80</width>

<length>120</length>

</table>

Nos casos acima gerará conflito pois os dois documentos contém uma <table> com

o mesmo nome.

Para resolver o problema exposto acima o XML usa um prefixo, um exemplo de

documento XML usando prefixo:

<h:table>

<h:tr>

<h:td>Apples</h:td>

<h:td>Bananas</h:td>

</h:tr>

</h:table>

<f:table>

<f:name>African Coffee Table</f:name>

<f:width>80</f:width>

<f:length>120</f:length>

</f:table>

Agora os documentos não se conflitam pois usam diferentes tabelas.

Usando Namespaces

Este documento XML carrega informação em uma tabela:



31

<h:table xmlns:h="http://www.w3.org/TR/html4/">

<h:tr>

<h:td>Apples</h:td>

<h:td>Bananas</h:td>

</h:tr></h:table>

Este documento XML carrega informação sobre uma peça:

<f:table xmlns:f="http://www.w3schools.com/furniture">

<f:name>African Coffee Table</f:name>

<f:width>80</f:width>

<f:length>120</f:length>

</f:table>

Ao invés de usar somente prefixos, um atributo xmlns foi adicionado na tag <table>

para dar ao prefixo um nome qualificado associado com um Namespace.

SOAP (Simple Object Access Protocol)

SOAP é um protocolo simples e leve baseado em XML que proporciona troca de

informações encima do protocolo HTTP, em suma, é um protocolo para acessar Web

Services.

A arquitetura tem sido desenhada para ser independente de qualquer modelo particular

de programa e de outras implementações específicas.

Os dois maiores objetivos do SOAP são a simplicidade e extensibilidade e esse

protocolo obedece a esses requisitos pois trafega encima do http e o http é suportado por todos

os servidores e browsers do mercado, com diferentes tecnologias e linguagens de

programação.

Bloco de estrutura SOAP

Uma mensagem SOAP é um documento habitual em XML contendo os seguintes

elementos:



32

Um elemento envelope que identifica o documento XML como um SOAP.

Um elemento header opcional que contem informações de chamadas e repostas;

Um elemento de falha opcional que prove informação sobre erros que ocorrem quando

do processamento da mensagem.

Esqueleto de mensagens SOAP

Abaixo a estrutura de uma mensagem SOAP, explicaremos cada parte dessa estrutura

nos capítulos abaixo:

<?xml version="1.0"?>

<soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Header>

...

...

</soap:Header>

<soap:Body>

...

...

<soap:Fault>

...

...

</soap:Fault>

</soap:Body>

</soap:Envelope>

Envelope SOAP

O envelope SOAP é o elemento mais importante, o elemento raiz de uma mensagem

SOAP, ele define o documento XML como uma mensagem SOAP, em suma, é o mais

importante em uma mensagem SOAP.

Notamos o uso do xmlns:soap namespace. Ele deve sempre ter o valor de:

http://www.w3.org/2001/12/soap-envelope

e este define o envelope como um envelope SOAP:



33


<soap:Envelope



...Message information goes here

...

</soap:Envelope>

O xmlns:soap namespace

Uma mensagem SOAP deve sempre ter um envelope associado com

"http://www.w3.org/2001/12/soap-envelope" namespace.

Se um Namespace diferente é usado, a aplicação deve gerar um erro e descartar a

mensagem.

O Atributo encodingStyle

O atributo encodingStyle é usado para definir tipos de dados usados no documento.

Este atributo deve aparecer em qualquer elemento SOAP e ele irá aplicar o conteúdo desse

elemento para todos os elementos filhos (children elements).

Sintaxe:

soap:encodingStyle="URI"

Podemos visualizar um exemplo do encodingStyle nesse modelo:


<soap:Envelope



...

Message information goes here

...

</soap:Envelope>



34

Header SOAP

O elemento Header (cabeçalho) contem informação específica da aplicação, sobre a

mensagem SOAP. Se o Header estiver presente, este deve ser o primeiro elemento child

(filho) do envelope.

OBS: Todos os elementos child do header devem ser Namespaces qualificados.


<soap:Envelope


soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"><soap:Header>

<m:Trans

xmlns:m="http://www.w3schools.com/transaction/"

soap:mustUnderstand="1">234</m:Trans>

</soap:Header>

...

...

</soap:Envelope>

O exemplo acima contem três atributos contendo um cabeçalho com um elemento

“Trans” um atributo “mustUnderstand” com valor de “1” e 234.

SOAP define três atributos em Namespace padrão ("http://www.w3.org/2001/12/soap-

envelope"). Esses atributos definidos no cabeçalho SOAP definem como um recipiente deve

processar a mensagem SOAP.

O atributo Actor (autor)

Uma mensagem SOAP deve percorrer do remetente para o recebedor passando por

diferentes “endpoints” ao longo do caminho da mensagem. Nem todas as partes de uma

mensagem SOAP devem estar planejados para o ultimo “endpoint” da mensagem mas, ao

invés disso, devem planejar um ou mais “endpoints” no caminho da mensagem.

O atributo actor deve ser usado para endereçar o cabeçalho para um “endpoint”

particular.



35

Sintaxe actor:

soap:actor="URI"

Exemplo:

<?xml version="1.0"?><soap:Envelope



<soap:Header>

<m:Trans


soap:actor="http://www.w3schools.com/appml/">

234

</m:Trans>

</soap:Header>

...

...

</soap:Envelope>

O atributo mustUnderstand

O atributo mustUnderstand pode ser usado para indicar se um cabeçalho de entrada é

obrigatório ou opcional para o processo.

Se adicionarmos “mustUnderstand=”1” para um elemento child do cabeçalho este

indicara que o processo recebedor do cabeçalho deve reconhecer o elemento. Se o recebedor

não identificar o elemento este deve falhar quando processar o cabeçalho.

Sintaxe:

soap:mustUnderstand="0|1"

Exemplo:<?xml version="1.0"?>

<soap:Envelope



<soap:Header>

<m:Trans


soap:mustUnderstand="1">

234

</m:Trans>

</soap:Header>

...

</soap:Envelope>



36

SOAP Body

O SOAP Body (corpo) contem a mensagem SOAP presente, planejada para a

conclusão do “endpoint” da mensagem.

Logo os elementos child do corpo deve ser namespace-qualified (namespace

qualificado). SOAP define um elemento dentro do corpo no namespace padrão

("http://www.w3.org/2001/12/soap-envelope"). Este é o elemento SOAP Fault (falha), que é

usado para indicar mensagens de erro.

WSDL

WSDL é um formato XML para descrever serviços de rede como um conjunto de

operações como ponto final nas mensagens contendo cada documento orientado ou

informação orientada. As operações e mensagens são descritas de forma abstrata e então o

salto para um protocolo de rede concreto e formato de mensagens para definir um ponto final.

WSDL é extensível para permitir descrição do ponto final e suas mensagens não levem em

consideração de quais formatos de mensagens ou protocolos de rede são usados para

comunicação.

Como protocolos de comunicação e formatos de mensagens são padronizadas na

comunidade web, isso se torna crescente a possibilidade e importante ser capaz de descrever

as comunicações em alguma forma de estrutura. Esses endereços WSDL necessitam pela

definição de uma gramática XML para descrever serviços de rede como coleções de pontos

finais de comunicações capazes de trocar mensagens. As definições de serviços WSDL

provêem documentação para sistemas distribuídos e servem como um recipiente para detalhesde automação envolvidos em aplicações de comunicação.

Um serviço WSDL define documentos como coleções de pontos finais de rede, ou

portas. No WSDL, a definição abstrata de pontos finais e mensagens são separadas de suas

organizações de redes concretas ou formatos de dados de comunicação. Isto permite a

reutilização de definições abstratas: mensagens, que são descrições abstratas dos dados sendo

trocados, e tipos de portas que são coleções abstratas de operações. O protocolo concreto e

especificações de dados concretos para uma tipo de porta em particular constituídas comocomunicações reutilizáveis. Uma porta é definida associando um endereço de rede como



37

ligação reutilizável, e uma coleção de portas definindo um serviço. Daqui, um documento

WSDL usa os seguintes elementos em sua definição dos serviços de rede:

Estrutura WSDL

Types (tipos) – Um recipiente para definição de tipos de dados usando alguns tipos de

sistemas. WSDL usa sintaxe XML para definir tipos de dados.

Message (mensagens) – Um resumo de definições de tipos de dados sendo trafegados,

podem conter uma ou mais partes, esses partes podem ser comparadas à parâmetros de uma

função.

portType (Tipo de porta) – Um resumo da configuração das operações suportadas por

um ou mais endpoints.

Binding (Ligação): Define o formato da mensagem e detalhes de protocolos para cada

porta.

Estrutura do WSDL:

<definitions>

<types>

definition of types........

</types>

<message>

definition of a message....

</message>

<portType>

definition of a port.......</portType>

<binding>

definition of a binding....

</binding>

</definitions>



38

WSDL ports

WSDL Ports é o elemento mais importante no WSDL, ele define um WS, suas

operações desempenhadas e mensagens que estão envolvidas.

Operation Types (Tipos de operação)

One-Way – A operação pode receber uma mensagem mas não irá retornar uma

resposta.

Request-responde – A operação pode receber uma requisição e retornar uma resposta.

Solicit-response – A operação pode enviar uma requisição e esperar por uma resposta

Notification – A operação pode enviar uma mensagem mas não ir

Bindings SOAP

O elemento Binding tem dois atributos, name e type, o atributo name define o nome

da ligação, e o type indica o ponto para a ligação da porta, nesse caso o “glossary terms

port”.

O elemento soap:binding tem dois atributos, style e transport, style

pode ser o “rpc” ou “documento”, o transport define o protocolo SOAP a ser usado, no

caso o http.

UDDI – Universal Description, Discovery and Integration.

Quando se constrói Web services, esses serviços necessitam ser acessados em algum

lugar na Web por uma aplicação-cliente. Uma forma de se acessar um Web service é fazer

com que a aplicação-cliente conheça a URI do serviço, desta maneira caracterizando o modo

estático de se localizar e acessar um serviço. Entretanto, quando a aplicação-cliente não

detém, a priori, a localização de um Web service, esse, pode ser descoberto antes de ser

acessado caracterizando o modo dinâmico de se descobrir a localização de um serviço.

UDDI é uma especificação técnica para descrever (describing), descobrir

(discovering) e integrar Web services. Assim, é portanto, uma parte crítica da pilha de



39

protocolos Web services, habilitando usuários dos serviços a publicarem e descobrirem estes

serviços.

Discovery é o processo de localizar Web services através de registries. Registries deWeb services são repositórios contendo documentos que descrevem dados de negócios.

Registries, também, proporcionam características tais como, capacidade de busca e acesso

programático para aplicações remotas. Usando um registry, uma organização que deseja

utilizar, por exemplo, um serviço para processar pagamentos de tickets de alimentação, pode

localizar todos os serviços disponíveis publicamente, que proporcionam a necessária

funcionalidade. A organização pode comparar serviços e então decidir qual serviço melhor se

ajusta às necessidades da organização. Discovery pode ser caracterizado em Discovery direto

ou Discovery indireto.

Discovery direto

É o processo de obter dados a partir de um registry mantido por um provedor de

serviço. Dados obtidos por Discovery direto são mais precisos e, portanto, confiáveis, visto

que a organização que provê a informação também opera o serviço na Web.

Discovery indireto

Com Discovery indireto, uma organização obtém dados através de uma terceiro

registry, cujos dados podem não ser precisos, porque provedores de serviço poderiam não

atualizar as informações nesse registry tão freqüentemente. Quando realizando Discovery

indireto, organizações devem colocar a seguinte questão: quão freqüente, terceiros registries

interagem com provedores de serviço para garantir que os dados são ainda precisos? Embora

discovery indireto tenha seus “drawbacks”, ele ainda permite avaliar serviços de vários

provedores antes do compromisso para usar um serviço particular.

Em seu núcleo, UDDI consiste de duas partes: API UDDI e UDDI Business Registry.

API UDDI

É uma especificação técnica para construir um diretório distribuído de negócios

(business) e Web services. A informação UDDI é armazenada dentro de um formato



40

específico XML, definido por WSDL e XML Schema. A especificação inclui detalhes de

uma API própria para buscar dados existentes ou publicar novos dados.

UDDI Business Registry

Também conhecido como “UDDI cloud services” é uma implementação operacional

completa da especificação UDDI. Tal parte habilita qualquer um a buscar dados UDDI

existentes, e também, a qualquer empresa registrar-se a si própria e seus respectivos serviços.

A informação capturada no contexto UDDI são classificadas em três categorias

principais:

Páginas Brancas (White Pages)

Essas incluem informações sobre uma empresa específica, como por exemplo, nome

de um negócio, descrição do negócio, informação de contato, endereço, números de telefone,

fax, ou mesmo incluir identificadores de negócios (business identifiers), no formato de

classificações Dun & Bradstreet’s D-U-N-S® (Data Universal Numbering System), que são

números de nove dígitos atribuídos a negócios. A especificação UDDI versão 2.0 oferece

suporte para identificadores específicos de indústrias, tal como o sistema do Standard

Industrial Classification (SIC), o qual atribui identificadores numéricos únicos a indústrias.

Por exemplo, 7371 representa Serviços de Programação de Computadores e 2621 representa

Paper Mills.

Páginas Amarelas (Yellow Pages)

Essas incluem dados de classificação geral para qualquer empresa ou serviço

oferecido. Por exemplo, esses dados podem incluir a indústria, o produto, ou códigos

geográficos baseados sobre taxionomias padronizadas.



41

Páginas Verdes (Green Pages)

Esta categoria contém informação técnica sobre um serviço na Web (Web service).

Geralmente, essa informação inclui um apontador (ponteiro) para uma especificação externa eum endereço para invocar o serviço. UDDI não é restrito a descobrir serviços baseados em

SOAP. Ao contrário, pode ser usado também, para descrever qualquer serviço, desde uma

única página Web ou endereços de e-mail, até serviços CORBA, Java RMI, ou mesmo,

serviços EJB.

Arquitetura UDDI

A arquitetura técnica de UDDI consiste de três partes: Um Modelo de Informação

UDDI, o qual baseia-se num XML Schema para descrever negócios e Web Services, uma API

UDDI baseada em SOAP para publicação e busca de informação UDDI e no UDDI Business

Registry (UBR) os quais são os sites-operadores que provêem implementações da

especificação UDDI e sincronizam todos os dados sobre uma “scheduled basis”. Exemplos de

UBR’s providos por grandes corporações, são Microsoft, IBM, HP, SAP e NTT

Communications do Japão



42

Sites-Operadores

Um site-operador é uma organização que hospeda uma implementação do UDDI

Business Registry (UBR). Uma empresa usuária de UDDI necessita registrar-se somente emum site-operador, conhecido como custodian. O princípio básico do UDDI para um UBR é

aquele de que uma empresa “registra uma vez e publica em qualquer lugar”. Princípio que

afirma, que a informação contida em um UBR custodian é replicada sobre os outros UBR’s.

Replicação é o processo de atualizar registros, de modo que todas as instâncias daqueles

registros originais sejam idênticas. Assim, uma empresa registra os seus dados em um site-

operador (custodian) e esses aparecem nos outros sites-operadores. Até a versão UDDI 2.0,

uma empresa podia atualizar sua informação somente através de seu site-operador custodian.

Isto porque, a especificação da API versão 2.0 de UDDI não provia um protocolo para

reconciliar diferentes versões de UDDI. Tal limitação requer interação com somente um site-

operador, proibindo, assim, usuários de entrarem em múltiplas versões de modelos de

informação em diferentes sites-operadores.

Os UDDI Business Registries (UBR’s) proporcionam um diretório de sistes-

operadores UDDI, fisicamente distribuído, mas logicamente centralizado. Isto significa que

dados submetidos a um site-operador serão automaticamente replicados através de todos osoutros sites-operadores. Tal replicação não ocorre instantaneamente, mas os sites-operadores

se sincronizam para atualização de registros, em intervalos de tempo diariamente.

É também possível estabelecer registros UDDI privados. Por exemplo, uma grande

empresa pode estabelecer seu próprio sistema UDDI privado, para registrar todos os seus

serviços Web internos à empresa. Quando esses serviços não são automaticamente

sincronizados com os sites-operadores UDDI, eles não são considerados partes do conjunto de

UDDI Business Registries (os cloud services).

Registrars

Empresas usuárias de UDDI podem também publicar informação em um UBR, através

de uma organização chamada registrar – uma outra empresa que auxilia na criação de

informação de negócios e descrições de Web services, a serem armazenados nos UBR’s. Uma

empresa registrar não é um site-operador, porque essas empresas não hospedam

implementações de UDDI Business Registry.



V - Segurança

Quando planejamos aplicar os Web Services não apenas nos conceitos e em aplicaçõesdemo, mas efetivamente no mundo real, a preocupação com segurança desperta especial

atenção. Pela grande diversidade de sistemas que compõem atualmente os vários ambientes de

TI, é necessário que haja uma abordagem modular à questão de segurança em Web Services.

Na medida em que cresce o uso de Web Services entre empresas que adotam diferentes

modelos de segurança em sua colaboração, as especificações de segurança e confiabilidade

propostas devem oferecer um modelo flexível, que permita a essas empresas se

interconectarem de forma confiável.

Como sabemos, Web services utilizam o protocolo SOAP em sua comunicação, o qual

é baseado em XML, ou seja, um arquivo texto perfeitamente legível. Para tornar um WEB

service seguro você deve encriptar a comunicação e existem duas maneiras de se fazer isso:

garantir a segurança ao nível de transporte e ao nível de XML.

Segurança ao nível de Transporte

SSL

Segurança ao nível de transporte significa proteger o protocolo de rede que o Web

service utiliza para se comunicar. O Secure Sockets Layer (SSL) é um protocolo padrão para

encriptar comunicações sobre TCP/IP. Neste modelo, um cliente abre um socket seguro para

um Web service e então o utiliza para trocar mensagens SOAP via HTTPS.



44

A implementação de SSL garante segurança encriptando todo o tráfego de rede sobre

o socket. Utilizando-se SSL pode-se também autenticar um Web service para um cliente

utilizando-se um Certificado Digital através da Infra-estrutura de Chaves Públicas (PKI).

PKI

Garantir segurança na Internet requer mecanismos seguros para a troca de

informações, mas que além disso sejam modulares e permitam garantir a segurança em

sistemas distribuídos. A Infra-estrutura de Chaves Públicas (PKI) garante a segurança de

comércio eletrônico e de comunicações na Internet através dos seguintes elementos:

Autenticação - verificar a identidade dos usuários e das máquinas torna-se crucial

quando uma organização abre suas portas para a Internet. Mecanismos de Autenticação

robustos, como o PKI, verificam a identidade sem permitir a transmissão ou o armazenamento

de senhas reutilizáveis. Eles certificam-se de que as pessoas ou máquinas sejam as entidades

que dizem ser. Esta tarefa é geralmente feita por um terceiro envolvido no processo, o qual

pode ser uma empresa de autenticação confiável ou um serviço de certificação que utiliza

criptografia convencional. O uso adequado de PKI torna virtualmente impossível que uma

pessoa não autorizada acesse o sistema.

Encriptação - Encriptação e algoritmos de integridade são utilizados para proteger

comunicações e garantir a privacidade durante o envio de dados de um computador a outro.

Estes processos garantem que os dados mantenham-se confidenciais, que não sejam

modificados e que a perda de pacotes possam ser identificadas.

Não repúdio - Não repúdio significa que os remetentes de e-mails ou transaçõesassinadas digitalmente não podem alegar que não a transmitiram. Assinaturas digitais

utilizando PKI podem garantir com segurança que a pessoa que assina a transmissão

eletrônica é realmente aquela pessoa, uma vez que ninguém mais pode criar aquela assinatura

digital. Uma assinatura digital PKI prova que um determinado usuário realizou certas

operações no sistema.

Para a criptografia de chaves públicas, entidades que desejem se comunicar de uma

maneira segura devem utilizar algumas credenciais seguras. As credenciais seguras consistem

em Chaves Públicas e Privadas. Esta forma de criptografia usa uma chave privada secreta e



45

uma chave pública relacionada matematicamente à chave privada. Somente a chave pública

pode ser utilizada para encriptar a informação, e somente a chave privada correspondente

pode ser usada para decriptá-la. Somente o proprietário do par de chaves conhece a chave

privada, enquanto a chave pública pode ser amplamente distribuída e mantém-se associada ao

proprietário. A mensagem encriptada com a chave pública pode ser somente decriptada pelo

proprietário, o qual conhece a chave privada associada. Estas chaves também são utilizadas

em assinaturas digitais para prevenir que um indivíduo se faça passar por outro ou prevenir

repúdio de mensagens válidas.

Certificados Digitais - Certificados são identidades digitais atribuídas por uma

terceira entidade que identifica os usuários e as máquinas. Os certificados são atribuídos

quando a entidade certificadora recebe e valida as informações as informações solicitadas. Os

certificados podem então ser seguramente armazenados em carteiras ou diretórios e utilizados

para fornecer a validação de identidade a qualquer entidade na Internet.

Entidade Certificadora - a Entidade Certificadora é um terceiro agente envolvido

que atua como um provedor independente e confiável de certificados digitais. O uso de um

par de chaves criptografadas para criar um canal de comunicação seguro, garante a

privacidade da mensagem e proporciona a possibilidade de validação do remetente.

A ampla distribuição da chave pública não afeta a sua segurança pois a chave privada

nunca é compartilhada. A chave pública de um indivíduo é publicada por um Entidade

Certificadora em um certificado atribuído ao usuário. As entidades que desejarem trocar

informações seguras podem codificar a informação com a chave pública da entidade

destinatária. Uma entidade que receba uma comunicação codificada por este método pode

usar sua própria chave privada para decodificar a mensagem. Se a mensagem original não for

decodificada usando a chave adequada o resultado da decodificação será ilegível.

IPSec

Descrevendo ainda a segurança ao nível de transporte, o projeto IPSec representa um

esforço desenvolvido pelo Working Group IPSec da IETF para desenvolver uma arquitetura

de segurança para o protocolo IP, integrando mecanismos de autenticação, gestão e

distribuição de chaves que podem ser usados com qualquer das versões do protocolo IP.



46

Através dos seus componentes, a IPSec usa este conceito para permitir a implementação de

redes virtuais privadas e seguras através de redes públicas tais como a Internet.

O IPSec utiliza como mecanismos de autenticação dois cabeçalhos de extensãoespecíficos do protocolo IPv6: o cabeçalho de Autenticação ( Authentication Header ) e o

cabeçalho de encapsulamento de dados de segurança ( Encapsulating Security Payload

Header ). Além destes dois cabeçalhos, o IPSec define também o conceito de associação de

segurança, conjunto de diretivas que permite negociar algoritmos de encriptação a serem

utilizados.

O IPSec integra gestão manual de chaves. A gestão é de responsabilidade de

protocolos criados para este fim. Os componentes da IPSec são, o Cabeçalho de Autenticação(AH), o Cabeçalho de Encapsulamento de Dados de Segurança (ESP) e os Mecanismos de

Gestão de Chaves.

Cabeçalho de Autenticação - O cabeçalho de autenticação representa um cabeçalho

de extensão do protocolo IPv6 e foi criado para validar a identidade de entidades que estão a

comunicar: identifica o emissor e destino corretos, podendo ser usado para verificar se o

emissor que afirma ter enviado os dados é exatamente quem afirma ser e foi desenhado de

modo a providenciar mecanismos de autenticação aos datagramas IP.

Na medida em que alguns dos campos do datagrama IP são alterados durante a

transmissão e dado que o cabeçalho de autenticação é adicionado na fonte do datagrama, este

cabeçalho por si só não fornece proteção contra ataques de análise de tráfego ou

confidencialidade, sendo para tal usado normalmente em conjunto com o cabeçalho de

encapsulamento de dados.

Cabeçalho de Encapsulamento de Dados de Segurança - O cabeçalho de

encapsulamento de dados de segurança (ESP) é um cabeçalho de extensão pertencente ao

protocolo IPv6 que fornece integridade e confidencialidade aos datagramas IP através da cifra

dos dados contidos no datagrama. A utilização do ESP pode ser efetuada de dois modos:

Modo de Transporte (transport-mode) - Providencia proteção principalmente no

respeitante aos protocolos da camada superior. Este modo encripta informação do protocolo

da camada de transporte, adicionando-lhe de seguida um novo cabeçalho IP não-encriptado,

pelo que se torna vantajoso em redes relativamente pequenas, nas quais o(s) servidor(es) e nó

implementam o IPSec.



47

Modo de Túnel (tunnel-mode) - Providencia proteção ao pacote IP. Para tal, após a

adição dos campos ESP ao pacote IP, todo o pacote é tratado como o módulo de dados de um

novo pacote IP. Assim, pode ser usado para enviar dados encriptados através de um túnel, o

que permite enviar dados independentemente da infra-estrutura utilizada. Um exemplo é o

envio de pacotes IP através de canais virtuais criados numa rede IP pública, como a Internet.

Através deste modo, pode ser fornecida segurança a um grupo de nós que não implementem o

IPSec.

Mecanismos de Gestão de Chaves - Além dos mecanismos de autenticação e validação da

informação a IPSec necessita de um mecanismo eficiente de gestão de chaves. A gestão de

chaves diz respeito à criação, eliminação e alteração das chaves. Embora o IPSec não integreum mecanismo de gestão de chaves, a IETF definiu como norma de gestão o protocolo

híbrido ISAKMP/Oakley também denominado IKE, Internet Key Exchange, que se encontra

baseado nos documentos:

• ISAKMP - Internet Security Association and Key Management Protocol.

Protocolo que descreve uma infra-estrutura para a gestão de associações de segurança;

• Oakley - protocolo que define material de chaves para cifra, hashing eautenticação e é compatível com a gestão de associações de segurança ISAKMP;

• Internet Domain Of Interpretation - define parâmetros ISAKMP para as

associações de segurança IPSec no domínio Internet;

• Resolução ISAKMP/Oakley - define o perfil do protocolo híbrido

ISAKMP/Oakley, escolhido como norma de gestão de chaves criptográficas pela

Internet Engineering Task Force;

• IKE - Internet Key Exchange.

Segurança ao nível de XML

Por sua vez, segurança ao nível de XML envolve a encriptação e decriptação de

documentos XML. O World Wide Web Consortium (W3C), o qual mantém o padrão XML,tem criado grupos de trabalhos para definir padrões para segurança em XML, incluindo

assinaturas digitais, encriptação e gerenciamento de chaves para XML.



48

XKMS (XML Key Management Services)

Esta especificação estabelece um formato de documento em XML que permite que a

autenticação de chaves e gerenciamento de certificados sejam feitos em aplicações Web. AXKMS permite um nível mais profundo de interoperabilidade entre sistemas de PKI, ao

mesmo tempo em que permite uma integração mais fácil entre as aplicações da empresa e a

infra-estrutura de chaves publicas corporativa.

WS-Security

Em abril de 2002, a Microsoft Corporation, a IBM Corporation e a VeriSign Inc. seuniram e publicaram um conjunto de novas especificações de segurança denominadas WS-

Security, com o objetivo de que as empresas pudessem criar e construir aplicações de Web

Services com ampla interoperabilidade.

As especificações do WS-Security, propostas pela IBM e Microsoft, são fundamentais

para a concretização de um planejamento amplo de recursos que possam atender à crescente

necessidade de oferecer suporte mais seguro para construção de Web services. O documento

"A Segurança no mundo dos Web services", de autoria da Microsoft e da IBM, explica as

novas especificações de segurança para Web Services que essas empresas pretendem

desenvolver em conjunto com alguns de seus principais clientes, parceiros de mercado e

entidades responsáveis pela padronização.

O WS-Security suporta, integra e unifica vários modelos, mecanismos e tecnologias de

segurança em uso no mercado, permitindo que vários sistemas possam interoperar em

plataformas e linguagens neutras.

As novas especificações de segurança definem um conjunto de padrões para extensões

SOAP (Simple Object Access Protocol) ou para cabeçalhos de mensagens, utilizados para

oferecer maior integridade e confidencialidade às aplicações de Web Services. O SOAP é um

protocolo baseado na linguagem XML, com acesso a diferentes plataformas ou linguagens. O

WS-Security oferece os mecanismos-padrão de segurança necessários para realizar o

intercâmbio seguro de mensagens certificadas em um ambiente de Web Services.

Além da divulgação das especificações WS-Security, a IBM e a Microsoft anunciaram

também a publicação do projeto "A Segurança no mundo dos Web Services" ("Security in a



49

Web Services World"). Esse documento define alguns recursos adicionais de segurança de

Web Services que se enquadram no modelo estabelecido pelas especificações WS-Security,

entre eles:

WS-Policy, WS-Trust e WS-Privacy - O WS-Policy define como os recursos e

restrições das normas de segurança poderão ser expressos; o WS-Trust irá descrever um

modelo para que se obtenha um relacionamento de confiança, tanto direto, quanto por meio de

agentes (incluindo terceiros e intermediários); o WS-Privacy determinará de que forma os

Web Services serão adotados e implementados.

WS-Secure Conversation, WS-Federation e WS-Authorization - O WS-Secure

Conversation explica como autenticar e gerenciar a troca de mensagens, incluindoespecificações para o contexto de segurança desse intercâmbio e a derivação de chaves de

sessão; o WS-Federation gerencia os vários tipos de relacionamento em ambientes

heterogêneos associados, incluindo o suporte à identidade dessas partes associadas; a WS-

Authorization define como os Web services administrarão os dados e as normas de

autorização.



VI - Aplicação de WS em B2B

Nos últimos anos diversos padrões foram propostos para a implementação do conceitode sistemas distribuídos. Um modelo muito popular tem sido o de separação de uma aplicação

em camadas, apresentação, negócio e dados. Este modelo, usado à exaustão na Internet, tem

por base uma infinidade de protocolos, dos quais DCOM e CORBA são os mais conhecidos.

Embora estes protocolos sejam muito diferentes entre si, seus problemas são

basicamente os mesmos: complexidade de implementação e, principalmente, implantação.

Sistemas escritos em diferentes linguagens, e não raro em plataformas distintas, sofrem ainda

de um mal bem mais grave, a incompatibilidade entre os tipos de dados, além da necessidade

de forte envolvimento das equipes técnicas de ambos os lados no processo de integração.

Estas têm sido as principais causas da baixa integração entre os sistemas de clientes e

fornecedores mesmo com toda a facilidade de infra-estrutura de comunicação existente hoje

em dia.

Com a facilidade proporcionada por esta tecnologia para a integração entre sistemas,

adotar o modelo de computação distribuída através de Web Services pode ser um enorme

diferencial competitivo em um futuro próximo.

Para as empresas, os Web Services significam agilidade nos processos e eficiência na

comunicação entre cadeias de produção ou logística. Toda e qualquer comunicação passa a

ser dinâmica e, principalmente, segura, pois não prevê intervenção humana. É possível

formatar regras de negócios e criar fluxos de informações específicas, entre outros recursos

que otimizam as relações entre parceiros corporativos.

Para os usuários é uma garantia de qualidade, agilidade e baixo custo. Se um

consumidor entra em uma loja virtual para comprar um determinado produto, em vez de



51

oferecer o que tem em estoque, o site pode pesquisar nos sistemas de seus fornecedores quem

tem o produto, por que preço e em qual prazo de entrega. Mediante estes dados, exibe para o

consumidor a melhor oferta. Do ponto de vista da loja, além de melhorar o serviço, ocorre

uma redução drástica nos estoques e, consequentemente, no capital de giro demandado.

Abaixo, temos uma figura que ilustra o ciclo da aplicação mostrado a interação entre

os diversos agentes envolvidos na operação:

1. cliente solicita um serviço ao Servidor Web através da Internet ou Intranet.

2. Servidor Web entra em ação, acessando a sua base de dados local para obter parte das

informações a serem devolvidas ao Browser.

3. A aplicação Web faz acesso a um serviço Web Service, que é executado em um servidor

de plataforma desconhecida. Neste momento o contexto da aplicação Inclui o Cliente

(browser), o Servidor Web e o servidor do Web Service.

4. aplicativo Web Service faz acesso à sua base de dados local para obter a informação

solicitada.

5. Web Service devolve a informação ao aplicativo servidor Web solicitante

6.

Servidor Web mescla as informações obtidas localmente (2), com as informações obtidasdo Web Service (5), retornado-os ao Browser solicitante.



52

Vantagens e Desvantagens do WS

A utilização da Internet como infra-estrutura de comunicação para sistemas

distribuídos tem despertado um interesse cada vez maior de pesquisadores e empresas. Poréma insegurança da Internet leva a implementações de políticas de segurança que comprometem

a funcionalidade dos sistemas distribuídos.

A adoção de middlewares baseados em protocolos de comunicação específicos tem

tido grande sucesso em redes locais e corporativas onde restrições de segurança são

planejadas considerando a existência de middlewares nas redes. Entretanto, na Internet

necessitamos de alterações específicas em Firewalls, o que nem sempre é possível.

Por estes problemas, arquiteturas como CORBA não tem conseguido uma utilização

massiva na Internet. Para contornar estas restrições, devemos procurar uma alternativa

compatível com os serviços existentes atualmente e aproveitar todo o suporte existente para

estes na Internet. No caso específico de CORBA, protocolos para tunelamento de IIOP em

HTTP foram desenvolvidos por empresas. Entretanto, estes protocolos não seguem nenhum

padrão, o que pode causar problemas de interoperabilidade entre diversas implementações de

ORBs.

Um Web Service tem por objetivo o fornecimento de um serviço ou funcionalidade,

que pode ser consumido por uma aplicação ou ainda por outro Web Service. Esse serviço

pode ter um retorno simples como a validação de um CPF ou uma informação mais detalhada

como o nome da Cidade, do Estado e da Rua a qual se refere um determinado CEP. Além

disso, a arquitetura dos Web Services é independente de plataforma, o que garante uma maior

portabilidade.

Para que isso seja viável, é necessário prover mecanismos padrão de definição,

transporte, localização e publicação desses serviços e ainda que esses mecanismos sejam

abertos, livres do pagamento de patentes ou royalties e que estejam presentes nas plataformas

que se desejam integrar.

É aí que reside o grande diferencial dos Web Services, pois uma vez que foram

concebidos com o enfoque de integração e oferta de serviços pela Web, eles se utilizam de

protocolos padrão amplamente difundidos (SOAP, HTTP, WSDL), um formato padrão de

troca de informações (XML) e um diretório de registro e localização (UDDI). Esses fatores

então fornecem os pré-requisitos para a sua larga aceitação, em contraste com soluções como



53

CORBA ou COM+ que estão ligadas a um protocolo adicional específico que precisa ser

conhecido pelas camadas que se comunicam.

Um outro fator estratégico de aceitação é a convergência de grandes fornecedores desoftware tais como IBM, Microsoft, Hewlett-Packard e SUN em relação a padrões de

definição dessa arquitetura, embora cada uma dessas organizações tenha uma implementação

de Web Services ligeiramente diferente das outras.

É importante perceber que os objetos distribuídos que seguem o padrão CORBA ou

J2EE podem continuar sendo uma escolha mais acertada se considerado seu uso dentro do

ambiente corporativo de uma empresa. Objetos distribuídos são projetados para troca de

objetos em formato binário, de tipos específicos em um processo síncrono de troca demensagens. Esse fato, aliado à dependência de plataforma, possibilita um alto desempenho e

um baixo acoplamento dos objetos distribuídos, tendo sido estes usados com sucesso em

muitas soluções de sistemas. Já os Web Services são mais adequados para ambientes de

distribuição de escopo mais amplo. Por exemplo, podem ser usados para troca de documentos

entre parceiros de negócio (muitas vezes de forma assíncrona), uma vez que se utilizam de

XML e HTTP, permitindo ultrapassar a barreira dos Firewalls, sendo independente de

plataforma e facilitando assim a comunicação e a troca de informações.

Os Web Services, por outro lado, provavelmente não apresentarão um alto

desempenho como componentes de sistemas voltados para dentro da empresa, devido ao

tamanho e à sobrecarga necessária para o tratamento dos documentos XML, enquanto que os

objetos distribuídos são mais adequados para a construção de sistemas de alto desempenho

com uma arquitetura bem definida.

Outra desvantagem do uso dos Web Services atualmente é o fato de a tecnologia serainda muito recente, estar pouco difundida e ainda estar sendo padronizada em muitos

aspectos pelo W3C. Assim, ainda há problemas quanto aos aspectos de localização dos

serviços, tratamento de transação e segurança. Esses aspectos, no entanto, estão sendo

estudados e existe um grande interesse por parte dos grandes fornecedores de software de

resolvê-los, sendo ao que tudo indica uma questão de tempo e não de rumo. A questão da

segurança, por exemplo já se encontra melhorada com a versão 3.0 do UDDI.

O futuro, cada vez mais próximo, como deixam perceber os investimentos dosfornecedores, está alinhado com os Web Services.



VII - Como o Mercado apoia o padrão

A tecnologia de Web Services tem sido focada em promover a colaboração B2B via

processos de negócios integrados. Mas o real benefício dos Web Services pode ser liberado na

tecnologia de BI (Business Intelligence) e não no processamento de transação. Companhias

estratégicas que desenvolvem aplicativos de negócios assim como Oracle, SAP, PeopleSoft,

Siebel Systems entre outras, estão construindo frameworks de Web Services nos seus

produtos podendo com isto estimular a demanda de BI em rede, através da mudança de

cultura do relacionamento corporativo no comércio colaborativo.

Observe como as principais empresas e organizações estão se posicionando no

mercado em relação ao desenvolvimento e fortalecimento do padrão.

Microsoft

A Microsoft está promovendo .NET como iniciativa de Web Service, que requer o usode software baseado em Windows. Além disso, a Microsoft tem planos de transformar

programadores fluentes no Windows em projetistas Web Services, com a liberação de um

conjunto de ferramentas de desenvolvimento, Framework .NET.

Sun Microsystems

A Sun Microsystems, de outro lado, está liderando uma estratégia de Web Services

orientada em Java, suportado por mais 30 outros vendedores.



55

Oracle

A Oracle e seu produto Oracle9i Application Server release 2 tem suporte a Web

Services padrões (SOAP, WSDL, UDDI) e também tem compatibilidade com a plataformaMicrosoft .NET.

META Group

A previsão do META Group para Web Services é que os padrões inicialmente

desenvolvidos para propiciar a integração e interoperabilidade (XML, WDSL, UDDI, etc.)

chegarão ao biênio 2005/2006 com o status de arquitetura orientada a novos serviços,desbancando o "mito" orientados a componentes como J2EE, CORBA e COM+. Segundo o

META Group até 2004, novas aplicações corporativas surgirão de componentes baseados ou

integrados às tecnologias Java 2 Enterprise Edition (J2EE) e a Microsoft .Net, e que os

fornecedores destas soluções devem se diferenciar com a oferta de valor agregado, como

Serviços Web e de desenvolvimento de produtos e/ou ferramentas específicas.

OASIS

O OASIS (Organization for the Advancement for Structured Information Standards) é

uma organização criada para estabelecer padrões para Web Services. É formada por um

Comitê Técnico criado para desenvolver um Modelo de Componentes para Serviços em Web

(WSCM). Este comitê tem membros como Epicentric Inc., Hewlett-Packard, IBM,

Macromedia Inc., entre outros. Dentro do Comitê Técnico WSCM existe o grupo de trabalho

"Working Group Web Services User Interface" (WSUI) que submeteu as primeiras

especificações ao OASIS para considerações do WSCM. O comitê tem duas grandes metas:

habilitar negócios para distribuir aplicações na Web através de múltiplos canais de revenda e

habilitar novos serviços ou aplicações a serem criados ou liberar as aplicações existentes

através da Web. Isto deve permitir que as companhias possam transferir Web Services através

de Portais e Plataformas, indiferente de produtos proprietários.



56

TechMetrix Research

Veja no gráfico abaixo o que a pesquisa da TechMetrix revelou sobre a iniciativa das

empresas em utilizar a tecnologia de Web Services construídos por Parceiros/Terceiros.

Fonte: TechMetrix Research

(WebServices Adoption & Technology Choices Report)

Forrester Research Inc.

Em pesquisas recentes o Forrester Research mostra que tecnologias tradicionais de

EAI deverão dominar até 2004, enquanto Web Services melhoram o seu desempenho. Por

volta de 2006, companhias devem adotar Web Services básicos, e ampliar o uso da tecnologia

para transações mais complexas. Analistas da Forrester aconselham aos executivos para

iniciar o trabalho em Web Services básicos com parceiros e internamente, monitorando a

evolução de padrões de Web Services para identificar capacidades mais promissoras para

mais tarde adotar.



VIII – Conclusão

Como foi visto neste trabalho, Web Services é um novo modelo de aplicação Web quecombina aspectos de desenvolvimentos baseados em componentes reutilizáveis. Este modelo

está tendo uma aceitação muito grande no mercado além do apoio de grandes indústrias de

software, como Microsoft, IBM e Sun. Os componentes Web services podem ser utilizados

sem nenhuma preocupação de como foram implementadas e podem ser facilmente compostos

com diversos componentes para fornecer serviços complexos.

Apesar de ter ainda poucos anos de existência, a tecnologia de Web Services está

alcançando maturidade notável. Grandes empresas estão apoiando a definição dos padrões

adotados e a questão de segurança que envolve as transações também está recebendo a devida

atenção. Contudo, a adoção desta nova tecnologia, como sempre ocorre nestes casos, está

sendo feita com bastante cautela, existindo poucos cases no mercado disponíveis para estudo

dos acertos e falhas na implementação. A aposta da indústria é que até 2005 um enorme

volume de serviços seja gerado por conta das integrações entre as empresas.



Referências

http://www.w3.orghttp://www.w3schools.com

http://www.webservices.org

http://www.w3.org/2002/ws/arch

http://msdn.microsoft.com/webservices/default.aspx

http://www.iis.com.br/~cat/infoetc/javaone.htm

http://www.xmltrustcenter.org/index.htm

http://www.xmethods.com/

http://java.sun.com/webservices/

http://java.sun.com/webservices/webservicespack.html

http://java.sun.com/features/2003/01/jax_rpc.html

http://java.sun.com/webservices/tutorial.html

http://devedge.netscape.com/viewsource/2002/soap-overview/index_pt_br.html

http://developer.java.sun.com/developer/technicalArticles/WebServices/index.html

http://developer.java.sun.com/developer/technicalArticles/Security/xkms

http://www.javaworld.com/columns/jw-web-services-index.shtml

Os sites acima apresentados foram acessados entre os dias 20 de janeiro e 03 de abril de 2003.

Web Services - Uma Soluao Para Aplicaoes as Na Internet

Documents

Transcript of Web Services - Uma Soluao Para Aplicaoes as Na Internet